测试
全部博文（931）
分类： 架构设计与优化
2019-08-25 17:29:24
搜索分页技术往往和另一个术语Lazy Loading（懒加载）联系起来。今天由Jerry首先介绍S/4HANA，CRM Fiori和S4CRM应用里的UI搜索分页的实现原理。后半部分由SAP成 都研究院菜园子小哥王聪向您介绍Twitter的懒加载实现。
关于王聪的背景介绍，您可以参考他的前一篇文章：SAP成 都研究院非典型程序猿，菜园子小哥：当我用UI5诊断工具时我用些什么。
以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应用的前台搜索分页实现原理和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，全称为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里并没有个东西叫“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工具中截取一条当用户滚动加载时发出的请求。结果发现它长下面这个样子。
在这里我们可以发现几个有意义的信息：
