搜尋分頁技術往往和另一個術語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。
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5SMmVGMzQWM0MWM5QWZ3UDO2QjZ0ATMmlDNllDOjJDOh9CX5d2bs92Yl1iclB3bsVmdlR2LcNWaw9CXt92Yu4GZjlGbh5yYjV3Lc9CX6MHc0RHaiojIsJye.png)
如果您想通過自己調試找到這個答案,鍛煉自己的分析能力,可以參考我的調試過程:
How does UI5 AutoGrowing list(Lazy Load behavior) work
以及使用Smart Template開發Fiori應用的介紹:
Jerry的通過CDS view + Smart Template 開發Fiori應用的blog合集
再來看看搜尋分頁的背景處理。在Netweaver事務碼ST05的資料庫跟蹤視圖裡,能清晰觀察到這個分頁效果:每次到資料庫的查詢隻命中并傳回25條記錄,如下圖三條高亮的跟蹤記錄所示。
上圖第1674行@lv_offset的值,是基于UI傳入的s k i p 和 skip和skip和top計算而得。
CRM Fiori應用搜尋分頁實作原理
CRM Fiori應用的前台搜尋分頁實作原理和S/4HANA Fiori應用類似,隻是分頁尺寸變成了20。
CRM Fiori背景的搜尋分頁處理和S/4HANA Fiori的差別:并未使用ABAP的OFFSET關鍵字,而由應用開發人員自行實作。
(1) 首先将所有滿足搜尋條件的記錄的GUID全部從資料庫取出,從資料庫層傳回到ABAP層。在我這個測試系統裡,總共有21條記錄,全部傳回到了ABAP層:
至此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上。
更多渲染細節,請參考我的部落格:
Paging Implementation in S/4HANA for Customer Management
了解了咱們SAP的搜尋分頁實作原理後,讓我們再來看看其他廠商是怎麼做的。
像國内的知乎,簡書,新浪微網誌這些網站,其清單顯示均實作了懶加載。菜園子小哥王聰對這些實作也很好奇。為什麼最後選擇了Twitter去研究?這就得從他和基友老金的故事說起。
下面是菜園子小哥王聰的講解。還是老規矩,您可以點選文末的"閱讀原文”,擷取王聰的中英德三個版本的講解文章。
懶加載,看看Twitter是怎麼做的
老金痛恨Twitter。
老金是我在德國讀書時的好基友,在國内時就酷愛文學創作。但他卻從未開通個部落格什麼的,堅持使用新浪“長微網誌”功能寫文章。用他的話說,這代表新銳文學的姿态。到了德國之後,老金發現人家老外不用微網誌,人家用Twitter。新銳的他自然要入鄉随俗,可正準備舞文弄墨,卻發現Twitter裡并沒有個東西叫“Long Twitter”,140個字元啥也幹不了。于是老金憤而解除安裝Twitter,逢人便感慨西方文學這下是要徹底完了。
看着老金整天悶悶不樂,我便安慰他說什麼長微網誌,不就是文字變圖檔嘛。Twitter沒這東西,看小爺我的本事啊。我給你寫個App,名字就叫“大Twitter”,圖示我都給你設計好了。
可沒想到,老金剛用了半天就找到我,說自己寫的東西不知道為什麼全被打上了馬賽克,并信誓旦旦對“秦老師”發誓說自己沒寫什麼大尺度的東西。我問他秦老師是誰?他說是印度著名詩人秦戈爾老師啊!善良的我并沒有當面給他指出那位老師不姓秦這件事,隻想着好好的圖檔怎麼會被打碼了呢?
我拿來一看,原來是老金實在憋了太久,這一次足足寫了8400多個字,生成的圖檔尺寸過大,被雞賊的Twitter給壓縮了,于是便模糊得像打了碼一樣。心灰意冷的老金決定與Twitter恩斷義絕,連賬戶都登出了。
雖然我也不怎麼用Twitter,但作為一個程式員我對它還是很有興趣的。作為同類産品中的佼佼者,Twitter自然是有它的優勢。其中比較有特色的一點就是其懶加載的機制。今天我們就通過Debug的方式來對其探究一番。
一些你需要知道的概念
時間軸(Time Line): Twitter中最最重要的部分。一條條的推文組合在一起,就成了頁面上中間那條長長的時間軸。
千裡之行,始于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能力還是代碼閱讀能力都會有所提升,推薦大家也試一試。
更多閱讀
Jerry的UI5架構代碼自學教程
Jerry的Fiori原創文章合集
Jerry的WebClient UI 42篇原創文章合集
Jerry的碎碎念:SAPUI5, Angular, React和Vue
SAP UI和Salesforce UI開發漫談
SAP S4CRM vs C4C, 諸葛亮和周瑜?
Jerry和您聊聊Chrome開發者工具
Hello World, S/4HANA for Customer Management 1.0
那些年我用過的SAP IDE