搜尋分頁技術往往和另一個術語Lazy Loading（懶載入）聯絡起來。今天由Jerry首先介紹S/4HANA，CRM Fiori和S4CRM應用裡的UI搜尋分頁的實現原理。後半部分由SAP成都研究院菜園子小哥王聰向您介紹Twitter的懶載入實現。

關於王聰的背景介紹，您可以參考他的前一篇文章：SAP成都研究院非典型程式猿，菜園子小哥：當我用UI5診斷工具時我用些什麼。

S/4HANA Fiori應用搜尋分頁實現原理

以S/4HANA Product Master Fiori應用為例，如果什麼搜尋條件都不指定，預設會返回25條資料，並且在UI上顯示該系統總的product數量，在Jerry使用的系統裡總共存在140個product。

該搜尋分頁的實現歸功於OData請求的引數，$skip=0&top=25，意為從請求命中的第0條記錄開始, 總共返回25條記錄。而另一個引數$inlinecount，其工作原理可以類比ABAP Open SQL的關鍵字SELECT COUNT(*)，用於統計資料庫表的條目數。

一旦用滑鼠滾輪向下移動頁面至螢幕底部，會自動觸發一個新的OData請求，引數為$skip=25&top=25。這樣，從第26到第50個product也從資料庫表中讀取出來顯示在Fiori UI上。

為什麼分頁的尺寸為25？在Fiori UI列表實現檔案sap.m.ListBase.js裡，預設的分頁尺寸(GrowingThreshold)為20，這說明一定存在某個配置，或者在Product Master應用某處的JavaScript程式碼將這個分頁尺寸從20改成了25。

由於篇幅限制，Jerry直接揭曉答案了。S/4HANA裡的Fiori應用都是使用Smart Template技術實現的，其列表區域的實現位於SmartTable.fragment.xml這個模板檔案裡，growingThreshold指定為25。因為從時間序列上來說SmartTable.fragment.xml後於sap.m.ListBase.js載入，所以對於分頁尺寸的定義其優先順序更高。

如果您想透過自己除錯找到這個答案，鍛鍊自己的分析能力，可以參考我的除錯過程：

How does UI5 AutoGrowing list(Lazy Load behavior) work

以及使用Smart Template開發Fiori應用的介紹：

Jerry的透過CDS view + Smart Template 開發Fiori應用的blog合集

再來看看搜尋分頁的後臺處理。在Netweaver事務碼ST05的資料庫跟蹤檢視裡，能清晰觀察到這個分頁效果：每次到資料庫的查詢只命中並返回25條記錄，如下圖三條高亮的跟蹤記錄所示。

從前臺透過UI5庫檔案傳送的帶有$skip和$top引數的OData請求，被後臺接收並維護於io_query_options引數中：

而最終在資料庫查詢層面的分頁處理，是由ABAP Open SQL的關鍵字OFFSET實現的。

上圖第1674行@lv_offset的值，是基於UI傳入的$skip和$top計算而得。

CRM Fiori應用搜尋分頁實現原理

CRM Fiori應用的前臺搜尋分頁實現原理和S/4HANA Fiori應用類似，只是分頁尺寸變成了20。

上圖的$skip和$top引數同S/4HANA應用的行為相同，傳遞到後臺並得到處理：

CRM Fiori後臺的搜尋分頁處理和S/4HANA Fiori的區別：並未使用ABAP的OFFSET關鍵字，而由應用開發人員自行實現。

(1) 首先將所有滿足搜尋條件的記錄的GUID全部從資料庫取出，從資料庫層返回到ABAP層。在我這個測試系統裡，總共有21條記錄，全部返回到了ABAP層：

(2) 由應用開發人員根據$skip和$top值，將多餘的記錄丟棄掉，保證最後只返回20條記錄給UI。

至此S/4HANA和CRM Fiori應用的搜尋分頁原理介紹完畢。更多細節，請參考我的部落格：

Search Paging implementation in S/4HANA and CRM Fiori application

S4CRM應用的搜尋分頁實現原理

S4CRM，全稱為S/4HANA for Customer Management，UI開發技術仍然採用WebClient UI。和S/4HANA基於UI5的前端技術截然不同，WebClient UI走的是伺服器端渲染的BSP路線。嚴格意義上講，WebClient UI不存在資料庫層面的搜尋分頁，其分頁行為僅僅體現在伺服器端渲染上。

下圖例子裡，我指定Max Number of Results為200，意思是期望滿足搜尋條件的記錄裡，顯示200條到UI上。

從搜尋結果能看出分頁效果。全部200條記錄已經從資料庫查詢出來並儲存到應用程式的記憶體裡。如下圖所示：

WebClient UI僅僅將第一頁的HTML原始碼在ABAP後臺渲染出來然後顯示給使用者。當使用者點了螢幕下方的“2”頁碼時，不會有任何的資料庫查詢發生，伺服器做的事情僅僅是將第二頁對應的HTML原始碼渲染出來。

伺服器怎麼知道應該渲染第二頁的原始碼呢？這個資訊也是點了“2”頁碼後，從前臺傳給ABAP伺服器的：

ABAP後臺拿到這個visibleFirstRow引數後，知道從搜尋結果記錄裡的第21條開始渲染，一直到第40條。

瞭解了我們們SAP的搜尋分頁實現原理後，讓我們再來看看其他廠商是怎麼做的。

像國內的知乎，簡書，新浪微博這些網站，其列表顯示均實現了懶載入。菜園子小哥王聰對這些實現也很好奇。為什麼最後選擇了Twitter去研究？這就得從他和基友老金的故事說起。

下面是菜園子小哥王聰的講解。還是老規矩，您可以點選文末的"閱讀原文”，獲取王聰的中英德三個版本的講解文章。

懶載入，看看Twitter是怎麼做的

老金痛恨Twitter。

老金是我在德國讀書時的好基友，在國內時就酷愛文學創作。但他卻從未開通個部落格什麼的，堅持使用新浪“長微博”功能寫文章。用他的話說，這代表新銳文學的姿態。到了德國之後，老金發現人家老外不用微博，人家用Twitter。新銳的他自然要入鄉隨俗，可正準備舞文弄墨，卻發現Twitter裡並沒有個東西叫“Long Twitter”，140個字元啥也幹不了。於是老金憤而解除安裝Twitter，逢人便感慨西方文學這下是要徹底完了。

看著老金整天悶悶不樂，我便安慰他說什麼長微博，不就是文字變圖片嘛。Twitter沒這東西，看小爺我的本事啊。我給你寫個App，名字就叫“大Twitter”，圖示我都給你設計好了。

然後我用了兩個晚上搞了個小工具，把大段文字轉成圖片，然後直接發到Twitter上。

可沒想到，老金剛用了半天就找到我，說自己寫的東西不知道為什麼全被打上了馬賽克，並信誓旦旦對“秦老師”發誓說自己沒寫什麼大尺度的東西。我問他秦老師是誰?他說是印度著名詩人秦戈爾老師啊！善良的我並沒有當面給他指出那位老師不姓秦這件事，只想著好好的圖片怎麼會被打碼了呢？

我拿來一看，原來是老金實在憋了太久，這一次足足寫了8400多個字，生成的圖片尺寸過大，被雞賊的Twitter給壓縮了，於是便模糊得像打了碼一樣。心灰意冷的老金決定與Twitter恩斷義絕，連賬戶都登出了。

雖然我也不怎麼用Twitter，但作為一個程式設計師我對它還是很有興趣的。作為同類產品中的佼佼者，Twitter自然是有它的優勢。其中比較有特色的一點就是其懶載入的機制。今天我們就透過Debug的方式來對其探究一番。

一些你需要知道的概念

時間軸（Time Line）: Twitter中最最重要的部分。一條條的推文組合在一起，就成了頁面上中間那條長長的時間軸。

位（Position）: 一條推文的識別符號，說白了就是推文的ID。新推文的Position比老推文的要大，所以我覺得Position很有可能代表著“這是Twitter有史以來的第xxx條推文”。可我隨便找到的一個Position卻著實大得讓我懷疑自己的猜測。

千里之行，始於Network

首先我們在開發者工具的Network工具中擷取一條當使用者滾動載入時發出的請求。結果發現它長下面這個樣子。

在這裡我們可以發現幾個有意義的資訊：

max_position：翻遍Header資訊以及請求引數，這是唯一一個跟所要請求的內容相關的東西。具體含義後面再講。
has_more_items：顧名思義，伺服器透過這個欄位告訴前端是否還有更早的內容。
items_html：格式化之後發現，這個部分就是我們所請求到的推文內容。顯然Twitter使用到的是後端渲染的技術，將推文內容渲染好直接發給前端進行展示。
min_position：恰好對應了請求當中的max_position。
new_latent_count：這一次所請求到的推文的條數。

深入探究

為了搞清楚這些資訊到底是怎麼回事，我們透過尋找請求的發起者來深入到程式碼當中。原來Twitter在這裡傳送了一個XMLHttpRequest。無論是什麼請求，總歸要有一個處理的方法，我們在Call Stack中層層向上追溯，然後找到了請求的定義位置。

這裡我們進入到請求成功的方法中繼續探索。最終到達終點，items_html被新增到了時間軸當中。

那min_position和max_position呢？我們回到剛才定義請求的位置繼續向上追溯，找到了getOldItems的方法。當使用者在時間軸上向下滾動滑鼠到最後時，就會呼叫到這個方法，而在其中會把上一次響應當中的min_position賦值給這一次請求當中的max_postion。

至此我們可以將整個Twitter的懶載入流程串接起來：

使用者向下滾動時間軸，發出請求，通知伺服器“我已經把第A條看完啦，快讓我看更之前的內容”。
伺服器返回從A再往前的20條內容，並告訴使用者“喏，現在發給你直到第B條的所有內容了，慢慢看吧”。
使用者再次看完這些內容，向下滾動時間軸，告訴伺服器“到第B條的我也看完啦，B之前的你再發給我吧”。

每次不一定20條？

在研究的過程中，我發現了一個有趣的現象，就是new_latent_count絕大多數都是20，而偶爾會略小於20。由於前端請求中並不存在所要請求的條數，所以這個決策是在後端完成的。

起初我以為後端會根據需要即將響應的內容大小決定發多少條，可分析了一些例子之後發現有的時候響應明明很小，卻還是發了不到20條。所以我的猜測是後端這個神奇的演算法可能會判斷返回的內容使用者大概會瀏覽多久，如果比較耗時，則少返回一些。例如如果推文中有長影片，則判斷為閱讀耗時較長，可以少返回幾條。但這只是我瞎猜的，有知道其中原理的朋友可以留言告訴我，非常感謝。

Debug之痛

坦率講整個Debug過程花費了我很多時間，一方面是對於其程式碼結構的不熟悉，另一方面是minify過的js程式碼實在是讓人頭疼啊。所有的變數都長成abcd不說，到處都是用邏輯運算子寫的條件判斷語句，看得人口吐白沫。

不過從學習的角度講，整個過程跑下來無論是debug能力還是程式碼閱讀能力都會有所提升，推薦大家也試一試。

SAP UI 搜尋分頁技術