搜索分頁技術往往和另一個術語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條。

更多渲染細節，請參考我的博客：

Paging Implementation in S/4HANA for Customer Management

了解了咱們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條。所以我的猜測是后端這個神奇的算法可能會判斷返回的內容用戶大概會瀏覽多久，如果比較耗時，則少返回一些。例如如果推文中有長視頻，則判斷為閱讀耗時較長，可以少返回幾條。但這只是我瞎猜的，有知道其中原理的朋友可以留言告訴我，非常感謝。