訂閱專欄
搜尋分頁技術往往和另一個術語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請求的參數，KaTeX parse error: Expected 'EOF', got '&' at position 7: skip=0&̲top=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庫檔案發送的帶有s k i p 和 skip和skip和top參數的OData請求，被背景接收并維護于io_query_options參數中：
而最終在資料庫查詢層面的分頁處理，是由ABAP Open SQL的關鍵字OFFSET實作的。
上圖第1674行@lv_offset的值，是基于UI傳入的s k i p 和 skip和skip和top計算而得。
CRM Fiori應用搜尋分頁實作原理
CRM Fiori應用的前台搜尋分頁實作原理和S/4HANA Fiori應用類似，隻是分頁尺寸變成了20。
上圖的s k i p 和 skip和skip和top參數同S/4HANA應用的行為相同，傳遞到背景并得到處理：
CRM Fiori背景的搜尋分頁處理和S/4HANA Fiori的差別：并未使用ABAP的OFFSET關鍵字，而由應用開發人員自行實作。
(1) 首先将所有滿足搜尋條件的記錄的GUID全部從資料庫取出，從資料庫層傳回到ABAP層。在我這個測試系統裡，總共有21條記錄，全部傳回到了ABAP層：
(2) 由應用開發人員根據s k i p 和 skip和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條。是以我的猜測是後端這個神奇的算法可能會判斷傳回的内容使用者大概會浏覽多久，如果比較耗時，則少傳回一些。例如如果推文中有長視訊，則判斷為閱讀耗時較長，可以少傳回幾條。但這隻是我瞎猜的，有知道其中原理的朋友可以留言告訴我，非常感謝。
Debug之痛
坦率講整個Debug過程花費了我很多時間，一方面是對于其代碼結構的不熟悉，另一方面是minify過的js代碼實在是讓人頭疼啊。所有的變量都長成abcd不說，到處都是用邏輯運算符寫的條件判斷語句，看得人口吐白沫。
不過從學習的角度講，整個過程跑下來無論是debug能力還是代碼閱讀能力都會有所提升，推薦大家也試一試。