搜索分頁技術(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 Fiori應(yīng)用搜索分頁實(shí)現(xiàn)原理

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

該搜索分頁的實(shí)現(xiàn)歸功于OData請求的參數(shù)，KaTeX parse error: Expected 'EOF', got '&' at position 7: skip=0&?top=25，意為從請求命中的…inlinecount，其工作原理可以類比ABAP Open SQL的關(guān)鍵字SELECT COUNT(*)，用于統(tǒng)計(jì)數(shù)據(jù)庫表的條目數(shù)。

一旦用鼠標(biāo)滾輪向下移動頁面至屏幕底部，會自動觸發(fā)一個(gè)新的OData請求，參數(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加載，所以對于分頁尺寸的定義其優(yōu)先級更高。

如果您想通過自己調(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合集

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

從前臺通過UI5庫文件發(fā)送的帶有$skip和$top參數(shù)的OData請求，被后臺接收并維護(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)用搜索分頁實(shí)現(xiàn)原理

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

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

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

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

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

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

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

S4CRM應(yīng)用的搜索分頁實(shí)現(xiàn)原理

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后臺渲染出來然后顯示給用戶。當(dāng)用戶點(diǎn)了屏幕下方的“2”頁碼時(shí)，不會有任何的數(shù)據(jù)庫查詢發(fā)生，服務(wù)器做的事情僅僅是將第二頁對應(yīng)的HTML源代碼渲染出來。

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

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

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

Paging Implementation in S/4HANA for Customer Management

了解了咱們SAP的搜索分頁實(shí)現(xiàn)原理后，讓我們再來看看其他廠商是怎么做的。

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

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

---

懶加載，看看Twitter是怎么做的

老金痛恨Twitter。

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

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

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

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

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

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

一些你需要知道的概念

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

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

千里之行，始于Network

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

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

• max_position：翻遍Header信息以及請求參數(shù)，這是唯一一個(gè)跟所要請求的內(nèi)容相關(guān)的東西。具體含義后面再講。
• has_more_items：顧名思義，服務(wù)器通過這個(gè)字段告訴前端是否還有更早的內(nèi)容。
• items_html：格式化之后發(fā)現(xiàn)，這個(gè)部分就是我們所請求到的推文內(nèi)容。顯然Twitter使用到的是后端渲染的技術(shù)，將推文內(nèi)容渲染好直接發(fā)給前端進(jìn)行展示。
• min_position：恰好對應(yīng)了請求當(dāng)中的max_position。
• new_latent_count：這一次所請求到的推文的條數(shù)。

深入探究

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

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

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

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

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

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

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

每次不一定20條？

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

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

Debug之痛

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

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

更多閱讀

• 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ù)文章，請關(guān)注公眾號"汪子熙"或者掃描下面二維碼:

總結(jié)

以上是生活随笔為你收集整理的SAP UI 搜索分页技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。