README.md

虚拟列表模拟长列表方案

1. 长列表问题：页面等待时间长，白屏时间久，用户体验差；CPU计算能力不够，滑动会卡顿；GPU渲染能力不够，页面会跳屏；RAM内存容量不够，浏览器会崩溃。

2. 长列表解决：

   1. 滚动加载：一屏触底再请求下一屏数据。
   2. 虚拟列表：处理用户滚动时，只改变列表在可视区域的渲染部分，使用padding、translate来让渲染的列表偏移到可视区域中，不可见区域的节点被删除释放内存。

1. H5

   0. 可视区、缓冲区、空节点（也可以用父节点padding等代替）；若滚动到一个元素离开可视区范围内时，则 删除上缓冲区顶上的一个元素 并 增加下缓冲区底下的一个元素；滚动时、节点增删时，顶部和底部空节点或父节点padding变化；

      注意：滚动事件节流、浏览器渲染前事件requestAnimationFrame。

   1. 方案一：

      元素不脱离文档流。

   2. 方案二：

      元素脱离文档流；撑开容器后（容器也需要随着滚动变化，让用户能根据滚动条感知滚动距离），用滚动事件触发节点的transform: translate（或absolute对应的top/down/left/right）。

2. 类RN（前端维护逻辑，客户端上屏）

   1. 方案一：

      仅按照前端方案处理（虚拟DOM 翻译成 调用Native组件渲染上屏），不关注客户端优化。

   2. （方案一的优化）方案二：

      利用Native支持的长列表组件优化（如：<ListView>已在Native层面处理客户端视图复用等长列表相关逻辑）。

   3. （方案二的优化）方案三：

      <ListView>的视图复用只体现在终端视图优化上，前端的视图描述（虚拟Dom、渲染树等）没有实现复用，大量的列表依然会在前端维持着大量的数据，导致内存占用、阻塞与终端交互。

      （参考vue的v-for的方式，）通过前端分离数据源和视图模板（前端不进行渲染，改成只传递 数据和模板 给Native），省去前端渲染列表的虚拟dom开销、减少与终端交互的数据量。