Mar 28

一种超长移动端双向联动列表分页加载方案

Lrdcq , 2020/03/28 04:38 , 程序 , 閱讀(2485) , Via 本站原創
现代电商类应用很常见一种“双向联动列表”的设计,比如京东分类页类目列表的顶部tab联动锚定:
點擊在新視窗中瀏覽此圖片

并且行业内各种移动端组件库也有类似的输出:https://taro-ext.jd.com/plugin/view/5edf005bbe897edf72b35ea8。不过看起来真正用这样的组件的人并不多——就算用肯定也是自己开发的。究其原因,我们在讨论某个场景是否适合使用这个交互方式的时候,注意到几个痛点:

1. 如果列表是完整的并且能快速锚定到某个滚动位置,这意味着这个列表在初始化的时候应该是加载完毕的,也就是说很难做分页。因此当数据量极大,长度不可控时,这个加载无论是对于前端还是后端都是不可控的。

2. 同时即使可以加载这么大的数据,对用户流量上也是一种挑战。

因此实际在不可控的场景,对这个交互方案的场景进行接口设计的时候,我们讨论了多种假设:

a. 数据需要分页加载的主要原因是数据查询量大,每一个item都包含多项子数据的查询,成百上千条查询后端确实受不了。因此我们是否可以优先全量的下载出来一个信息简略的数据(比如只包含title和imgurl)来构成基本列表,在随着用户浏览滑动,类似于精准曝光的逻辑,在慢速滑动的时候去加载对应的详细数据。

这个方案还是基于一口气加载完整,不过也有明显的缺点:需要一边加载一边补充数据,可能带来页面抖动与看到异常数据,用户体验不佳。另外实际上到上千个品的时候,就算简略数据服务端也很难一口气返回回来,

b. 另一个方案,即手动进行全部加载,在进入界面的时候,渐进式的往下逐步完成分页加载。当然,如果用户有快速切锚点进行跳转的动作,只能让用户等待直到实际加载到用户的目标跳转位置为止。

这个做法可以很好的兼容绝大部分即顺序滑的场景,也能大概率兼容锚点切换的场景,对应的代价是——会大概率请求超级多多余的数据(相对于有正常的分页),流量当然也有无效的浪费,因此整体看下来肯定是一个愚蠢的方案。

c. 在调研过程中,发现美团外卖商超,比如家乐福店铺页左边一级分类与顶部都有锚定:
點擊在新視窗中瀏覽此圖片

并且支持的数据量奇大,家乐福的完整列表品数甚至高达3-4k的数量。因此对外卖app进行了黑盒断网测试研究起加载逻辑,并结合我们的场景,得出了目前判断最优的双向联动列表分页加载方案。

方案描述

方案的设计原则遵循我们的理想态:

a. 最小请求加载,访问啥加载啥。
b. 完整列表,流程滚动,最终还是会成为一个长列表。
c. 快速锚点,通过锚点定位到列表的某个位置准确并迅速。

基于以上设定,我们有以下初步方案设计结论:

a. 基于请求最小化,肯定有分页,并且基于快速跳转锚点,那分页的第一纬度肯定是锚点分页,每个锚点内部可以再分页,类似于假设我有abcde五个锚点,但是c的数据量确实很大,可能需要分三页,所以分页会得到a->b->c->c2->c3->d->e。

b. 基于可以快速跳转到某一点的设定,列表肯定是支持从中间加载的,比如我初始状态处于a,快速点击到d,我会优先加载d,往前滚到c3,往后滚到e。同时基于滚动流畅性的特点,肯定会有提前加载的逻辑,比如落地到d的开始位置时,肯定需要同时加载c3,稍微往下滑动即需要加载e。

c. 整个分页的前后关系必须是明确的,即我必须知道d的前面是c3,可以是从d的接口返回的,但是更好的情况是直接通过锚点接口下发,这样加载控制只需要query上mark=c&pagenumber=3即可获取到对应数据了。

因此接口设计清晰了,分页由前端控制,那么锚点接口必须稳定的返回锚点于分页情况:
[{
  "markTitle":"a",
  "markId":1001,
  "markPageCount":1
},{
  "markTitle":"b",
  "markId":1002,
  "markPageCount":1
},{
  "markTitle":"c",
  "markId":1003,
  "markPageCount":3
},{
  "markTitle":"d",
  "markId":1004,
  "markPageCount":1
},{
  "markTitle":"e",
  "markId":1005,
  "markPageCount":1
}]

主列表的核心分页请求参数也即为:
{
  "pageMarkId":1004,
  "pageNumber":1,
    //再配合上其他请求参数
}

本地为锚点准备数据数组,储存每个mark的分页与其加载完成的数据。比如上面描述快速跳转到d,那么完成加载后我们这个数组储存的数据为[A(List), B(null), C(null), C2(null), C3(List), D(List), E(null)],随着用户前后滑动,逐步将数据填充完整即可。

- 这个的填充逻辑即我们场景的提前分页加载,即距离列表顶部还有多少个item,即开始加载上一页,距离列表底部还有多少个item,即开始加载列表底部,同时配上滚动预判更佳。
- 列表可以适当加入更新逻辑,但是需要处理抖动问题,具体见下。

渲染逻辑

那么到头ListView怎么渲染这么一份不连续的分section列表?说起来也简单,只渲染当前加载的连续部分。比如刚才这个操作流程:

a. 初始态填充了a数据,因此列表渲染的,A(List)。

b. 快速点击到d,先转圈圈加载了c3和d,那么列表改为渲染C3(List), D(List),并且offset调整到d的开始位置。

c. 如果用户继续往下滑,继续加载e,当前的渲染窗口即C3(List), D(List),  E(List)了。

d. 如果用户继续往上滑,加载c2,append到前面,即渲染C2(List), C3(List), D(List)。

e. 当然如果持续滑动到a的时候,a由于已经完成加载,所以直接继续append到渲染数据上,形成完整的渲染结果。

这个流程里注意到会出现往渲染数据前append数据,并reload的过程。正常理解一个ListView在头部添加数据并刷新,当然展示数据窗口offset肯定不会变化,因此会发现用户看到的数据发生跳变。因此reload的时候需要手动调整offset。同时以来以下动作:

a. 调整列表offset需要和reload一起完成才能实现流程操作,这意味着列表的高度是一定需要预先知道的,不能根据渲染结果取计算,否则肯定会闪跳的。不过这种复杂列表的高度理应都是数据可计算的,所以还好问题不大。

b. 同时如果担心数据加载过慢,真的滑动出数据窗口外了,有两种做法:一种是列表上线直接是结束位置,停下来展示上下拉下载那个圈圈,让用户有明显加载感;或者列表上下留足够空白区域,直接滑进空白,数据加载进来后再做布局替换,这样滚动流畅性不会收到影响,就是用户偶尔会看到白屏。

用图来描述目标过程和可选方案,即如下:
點擊在新視窗中瀏覽此圖片

当然,实际的分页加载逻辑不用那么死板,听起来都合理的逻辑包括:

a. 保证列表向前有n个多余的卡片加载,如果每加载一个分页填充的卡片数量不足n,则继续往前加载,向后同理。
b. 总是尝试填充满用户最近连续加载的数据,链接到一起。
c. 如果有多级分类,优先加载同一个大分类下的数据。

根据业务场景与业务预期的用户场景,比如同品类比价场景,都可以针对性优化。

适用与适配

实际看这个方案的可用性,注意到明显存在的需要同步解决的问题是:

- reload的同时调整offset以避免跳变问题。
- 快速滚动提前加载。

涉及到的即要求,渲染操作同步性与事件响应同步性。因此客户端原生开发及Android与iOS一定可以做到。

- H5事件响应与渲染均有高延迟,所以做不到。
- RN和小程序类似,有跨jscore通信,因此问题也很大。
- Flutter事件类似于native,可以同步处理,因此可以做到。

对于明显做不到的端,对这个方案可以进行降级处理。因为主要问题出在保证向上加载的用户视野/操作的连续性。那么只要用户停下来明显感受到加载过程问题就不到了。——因此将方案中上滑预加载改成触顶,甚至下拉加载,让用户有明显的停止动作,并且强调出加载过程,比如弹出一个加载圈圈,即可解决该问题了。

当然偏web容器上这样加载引起的长列表性能问题,就是另一个话题了。
关键词:双向联动列表
logo