摘要：搜索分頁技術(shù)往往和另一個(gè)術(shù)語懶加載聯(lián)系起來。該搜索分頁的實(shí)現(xiàn)歸功于請(qǐng)求的參數(shù)，，意為從請(qǐng)求命中的第條記錄開始總共返回條記錄。更多細(xì)節(jié)，請(qǐng)參考我的博客應(yīng)用的搜索分頁實(shí)現(xiàn)原理，全稱為，開發(fā)技術(shù)仍然采用。

搜索分頁技術(shù)往往和另一個(gè)術(shù)語Lazy Loading（懶加載）聯(lián)系起來。今天由Jerry首先介紹S/4HANA，CRM Fiori和S4CRM應(yīng)用里的UI搜索分頁的實(shí)現(xiàn)原理。后半部分由SAP成都研究院菜園子小哥王聰向您介紹Twitter的懶加載實(shí)現(xiàn)。

關(guān)于王聰?shù)谋尘敖榻B，您可以參考他的前一篇文章：SAP成都研究院非典型程序猿，菜園子小哥：當(dāng)我用UI5診斷工具時(shí)我用些什么。

以S/4HANA Product Master Fiori應(yīng)用為例，如果什么搜索條件都不指定，默認(rèn)會(huì)返回25條數(shù)據(jù)，并且在UI上顯示該系統(tǒng)總的product數(shù)量，在Jerry使用的系統(tǒng)里總共存在140個(gè)product。

該搜索分頁的實(shí)現(xiàn)歸功于OData請(qǐng)求的參數(shù)，$skip=0&top=25，意為從請(qǐng)求命中的第0條記錄開始, 總共返回25條記錄。而另一個(gè)參數(shù)$inlinecount，其工作原理可以類比ABAP Open SQL的關(guān)鍵字SELECT COUNT(*)，用于統(tǒng)計(jì)數(shù)據(jù)庫表的條目數(shù)。

一旦用鼠標(biāo)滾輪向下移動(dòng)頁面至屏幕底部，會(huì)自動(dòng)觸發(fā)一個(gè)新的OData請(qǐng)求，參數(shù)為$skip=25&top=25。?這樣，從第26到第50個(gè)product也從數(shù)據(jù)庫表中讀取出來顯示在Fiori UI上。

為什么分頁的尺寸為25？在Fiori UI列表實(shí)現(xiàn)文件sap.m.ListBase.js里，默認(rèn)的分頁尺寸(GrowingThreshold)為20，這說明一定存在某個(gè)配置，或者在Product Master應(yīng)用某處的JavaScript代碼將這個(gè)分頁尺寸從20改成了25。

由于篇幅限制，Jerry直接揭曉答案了。S/4HANA里的Fiori應(yīng)用都是使用Smart Template技術(shù)實(shí)現(xiàn)的，其列表區(qū)域的實(shí)現(xiàn)位于SmartTable.fragment.xml這個(gè)模板文件里，growingThreshold指定為25。因?yàn)閺臅r(shí)間序列上來說SmartTable.fragment.xml后于sap.m.ListBase.js加載，所以對(duì)于分頁尺寸的定義其優(yōu)先級(jí)更高。

如果您想通過自己調(diào)試找到這個(gè)答案，鍛煉自己的分析能力，可以參考我的調(diào)試過程：

How does UI5 AutoGrowing list(Lazy Load behavior) work

以及使用Smart Template開發(fā)Fiori應(yīng)用的介紹：

Jerry的通過CDS view + Smart Template 開發(fā)Fiori應(yīng)用的blog合集

再來看看搜索分頁的后臺(tái)處理。在Netweaver事務(wù)碼ST05的數(shù)據(jù)庫跟蹤視圖里，能清晰觀察到這個(gè)分頁效果：每次到數(shù)據(jù)庫的查詢只命中并返回25條記錄，如下圖三條高亮的跟蹤記錄所示。

從前臺(tái)通過UI5庫文件發(fā)送的帶有$skip和$top參數(shù)的OData請(qǐng)求，被后臺(tái)接收并維護(hù)于io_query_options參數(shù)中：

而最終在數(shù)據(jù)庫查詢層面的分頁處理，是由ABAP Open SQL的關(guān)鍵字OFFSET實(shí)現(xiàn)的。

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

CRM Fiori應(yīng)用的前臺(tái)搜索分頁實(shí)現(xiàn)原理和S/4HANA Fiori應(yīng)用類似，只是分頁尺寸變成了20。

上圖的$skip和$top參數(shù)同S/4HANA應(yīng)用的行為相同，傳遞到后臺(tái)并得到處理：

CRM Fiori后臺(tái)的搜索分頁處理和S/4HANA Fiori的區(qū)別：并未使用ABAP的OFFSET關(guān)鍵字，而由應(yīng)用開發(fā)人員自行實(shí)現(xiàn)。

(1) 首先將所有滿足搜索條件的記錄的GUID全部從數(shù)據(jù)庫取出，從數(shù)據(jù)庫層返回到ABAP層。在我這個(gè)測(cè)試系統(tǒng)里，總共有21條記錄，全部返回到了ABAP層：

(2) 由應(yīng)用開發(fā)人員根據(jù)$skip和$top值，將多余的記錄丟棄掉，保證最后只返回20條記錄給UI。

至此S/4HANA和CRM Fiori應(yīng)用的搜索分頁原理介紹完畢。更多細(xì)節(jié)，請(qǐng)參考我的博客：

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

S4CRM，全稱為S/4HANA for Customer Management，UI開發(fā)技術(shù)仍然采用WebClient UI。和S/4HANA基于UI5的前端技術(shù)截然不同，WebClient UI走的是服務(wù)器端渲染的BSP路線。嚴(yán)格意義上講，WebClient UI不存在數(shù)據(jù)庫層面的搜索分頁，其分頁行為僅僅體現(xiàn)在服務(wù)器端渲染上。

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

從搜索結(jié)果能看出分頁效果。全部200條記錄已經(jīng)從數(shù)據(jù)庫查詢出來并保存到應(yīng)用程序的內(nèi)存里。如下圖所示：

WebClient UI僅僅將第一頁的HTML源代碼在ABAP后臺(tái)渲染出來然后顯示給用戶。當(dāng)用戶點(diǎn)了屏幕下方的“2”頁碼時(shí)，不會(huì)有任何的數(shù)據(jù)庫查詢發(fā)生，服務(wù)器做的事情僅僅是將第二頁對(duì)應(yīng)的HTML源代碼渲染出來。

服務(wù)器怎么知道應(yīng)該渲染第二頁的源代碼呢？這個(gè)信息也是點(diǎn)了“2”頁碼后，從前臺(tái)傳給ABAP服務(wù)器的：

ABAP后臺(tái)拿到這個(gè)visibleFirstRow參數(shù)后，知道從搜索結(jié)果記錄里的第21條開始渲染，一直到第40條。

更多渲染細(xì)節(jié)，請(qǐng)參考我的博客：

Paging Implementation in S/4HANA for Customer Management

了解了咱們SAP的搜索分頁實(shí)現(xiàn)原理后，讓我們?cè)賮砜纯雌渌麖S商是怎么做的。

像國(guó)內(nèi)的知乎，簡(jiǎn)書，新浪微博這些網(wǎng)站，其列表顯示均實(shí)現(xiàn)了懶加載。菜園子小哥王聰對(duì)這些實(shí)現(xiàn)也很好奇。為什么最后選擇了Twitter去研究？這就得從他和基友老金的故事說起。

下面是菜園子小哥王聰?shù)闹v解。還是老規(guī)矩，您可以點(diǎn)擊文末的"閱讀原文”，獲取王聰?shù)闹杏⒌氯齻€(gè)版本的講解文章。

*

老金痛恨Twitter。

老金是我在德國(guó)讀書時(shí)的好基友，在國(guó)內(nèi)時(shí)就酷愛文學(xué)創(chuàng)作。但他卻從未開通個(gè)博客什么的，堅(jiān)持使用新浪“長(zhǎng)微博”功能寫文章。用他的話說，這代表新銳文學(xué)的姿態(tài)。到了德國(guó)之后，老金發(fā)現(xiàn)人家老外不用微博，人家用Twitter。新銳的他自然要入鄉(xiāng)隨俗，可正準(zhǔn)備舞文弄墨，卻發(fā)現(xiàn)Twitter里并沒有個(gè)東西叫“Long Twitter”，140個(gè)字符啥也干不了。于是老金憤而卸載Twitter，逢人便感慨西方文學(xué)這下是要徹底完了。

看著老金整天悶悶不樂，我便安慰他說什么長(zhǎng)微博，不就是文字變圖片嘛。Twitter沒這東西，看小爺我的本事啊。我給你寫個(gè)App，名字就叫“大Twitter”，圖標(biāo)我都給你設(shè)計(jì)好了。

然后我用了兩個(gè)晚上搞了個(gè)小工具，把大段文字轉(zhuǎn)成圖片，然后直接發(fā)到Twitter上。

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

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

雖然我也不怎么用Twitter，但作為一個(gè)程序員我對(duì)它還是很有興趣的。作為同類產(chǎn)品中的佼佼者，Twitter自然是有它的優(yōu)勢(shì)。其中比較有特色的一點(diǎn)就是其懶加載的機(jī)制。今天我們就通過Debug的方式來對(duì)其探究一番。

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

位（Position）:?一條推文的標(biāo)識(shí)符，說白了就是推文的ID。新推文的Position比老推文的要大，所以我覺得Position很有可能代表著“這是Twitter有史以來的第xxx條推文”?？晌译S便找到的一個(gè)Position卻著實(shí)大得讓我懷疑自己的猜測(cè)。

首先我們?cè)陂_發(fā)者工具的Network工具中截取一條當(dāng)用戶滾動(dòng)加載時(shí)發(fā)出的請(qǐng)求。結(jié)果發(fā)現(xiàn)它長(zhǎng)下面這個(gè)樣子。

在這里我們可以發(fā)現(xiàn)幾個(gè)有意義的信息：

max_position：翻遍Header信息以及請(qǐng)求參數(shù)，這是唯一一個(gè)跟所要請(qǐng)求的內(nèi)容相關(guān)的東西。具體含義后面再講。

has_more_items：顧名思義，服務(wù)器通過這個(gè)字段告訴前端是否還有更早的內(nèi)容。

items_html：格式化之后發(fā)現(xiàn)，這個(gè)部分就是我們所請(qǐng)求到的推文內(nèi)容。顯然Twitter使用到的是后端渲染的技術(shù)，將推文內(nèi)容渲染好直接發(fā)給前端進(jìn)行展示。

min_position：恰好對(duì)應(yīng)了請(qǐng)求當(dāng)中的max_position。

new_latent_count：這一次所請(qǐng)求到的推文的條數(shù)。

為了搞清楚這些信息到底是怎么回事，我們通過尋找請(qǐng)求的發(fā)起者來深入到代碼當(dāng)中。原來Twitter在這里發(fā)送了一個(gè)XMLHttpRequest。無論是什么請(qǐng)求，總歸要有一個(gè)處理的方法，我們?cè)贑all Stack中層層向上追溯，然后找到了請(qǐng)求的定義位置。

這里我們進(jìn)入到請(qǐng)求成功的方法中繼續(xù)探索。最終到達(dá)終點(diǎn)，items_html被添加到了時(shí)間軸當(dāng)中。

那min_position和max_position呢？我們回到剛才定義請(qǐng)求的位置繼續(xù)向上追溯，找到了getOldItems的方法。當(dāng)用戶在時(shí)間軸上向下滾動(dòng)鼠標(biāo)到最后時(shí)，就會(huì)調(diào)用到這個(gè)方法，而在其中會(huì)把上一次響應(yīng)當(dāng)中的min_position賦值給這一次請(qǐng)求當(dāng)中的max_postion。

至此我們可以將整個(gè)Twitter的懶加載流程串接起來：

用戶向下滾動(dòng)時(shí)間軸，發(fā)出請(qǐng)求，通知服務(wù)器“我已經(jīng)把第A條看完啦，快讓我看更之前的內(nèi)容”。

服務(wù)器返回從A再往前的20條內(nèi)容，并告訴用戶“喏，現(xiàn)在發(fā)給你直到第B條的所有內(nèi)容了，慢慢看吧”。

用戶再次看完這些內(nèi)容，向下滾動(dòng)時(shí)間軸，告訴服務(wù)器“到第B條的我也看完啦，B之前的你再發(fā)給我吧”。

在研究的過程中，我發(fā)現(xiàn)了一個(gè)有趣的現(xiàn)象，就是new_latent_count絕大多數(shù)都是20，而偶爾會(huì)略小于20。由于前端請(qǐng)求中并不存在所要請(qǐng)求的條數(shù)，所以這個(gè)決策是在后端完成的。

起初我以為后端會(huì)根據(jù)需要即將響應(yīng)的內(nèi)容大小決定發(fā)多少條，可分析了一些例子之后發(fā)現(xiàn)有的時(shí)候響應(yīng)明明很小，卻還是發(fā)了不到20條。所以我的猜測(cè)是后端這個(gè)神奇的算法可能會(huì)判斷返回的內(nèi)容用戶大概會(huì)瀏覽多久，如果比較耗時(shí)，則少返回一些。例如如果推文中有長(zhǎng)視頻，則判斷為閱讀耗時(shí)較長(zhǎng)，可以少返回幾條。但這只是我瞎猜的，有知道其中原理的朋友可以留言告訴我，非常感謝。

坦率講整個(gè)Debug過程花費(fèi)了我很多時(shí)間，一方面是對(duì)于其代碼結(jié)構(gòu)的不熟悉，另一方面是minify過的js代碼實(shí)在是讓人頭疼啊。所有的變量都長(zhǎng)成abcd不說，到處都是用邏輯運(yùn)算符寫的條件判斷語句，看得人口吐白沫。

不過從學(xué)習(xí)的角度講，整個(gè)過程跑下來無論是debug能力還是代碼閱讀能力都會(huì)有所提升，推薦大家也試一試。

Jerry的UI5框架代碼自學(xué)教程

Jerry的Fiori原創(chuàng)文章合集

Jerry的WebClient UI 42篇原創(chuàng)文章合集

Jerry的碎碎念：SAPUI5, Angular, React和Vue

SAP UI和Salesforce UI開發(fā)漫談

SAP S4CRM vs C4C, 諸葛亮和周瑜?

Jerry和您聊聊Chrome開發(fā)者工具

Hello World, S/4HANA for Customer Management 1.0

那些年我用過的SAP IDE

要獲取更多Jerry的原創(chuàng)技術(shù)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙"