Weex 的 recycle-list 诞生记

关注 Weex 开发进展的同学，可能会知道 Weex 前段时间发布了 v0.18.0 版本（release note），其中包含了一个叫 <recycle-list> 的组件，它是一个带有回收复用功能的列表容器，据说是有史以来最特别的组件，性能也有大幅提升，开发过程也涉及到很多底层的改造，陆陆续续花了半年才实现了第一个正式的版本。<recycle-list> 的文档也在官网上线了，不过整体看下来好像和普通的 <list> 也差不多，反而多了一大堆莫名其妙的注意事项，一副很敏感又很脆弱的样子，真的有那么好用吗？这篇文章里就好好聊一聊它的特别之处。

为什么要搞个新的列表容器

在如今 App 的开发中，有大部分的页面都是以可滚动列表的形式展现的，尤其是在货架式琳琅满目的活动页面中，更是长列表的主场，而且越来越长，带上“懒加载”和“自动加载更多”以后，其实就是一个可以无限滚动的列表。所以说，列表的性能和体验往往从很大程度上决定了页面的性能和体验，优化了列表的性能就会大幅提高页面的性能。

Weex 目前提供的列表组件 <list> 其实已经是功能很强大的一个组件了，在 Android 上使用的是 RecyclerView 组件，在 iOS 上使用的是 UITableView，本身就具有了操作系统原生提供的回收功能，在节点离屏时可以回收掉部分原生组件持有的内存。和 Web 中的开发技术相比，在 webview 中实现的列表，无论是渲染性能、滚动体验还是内存占用方面，都难以和原生列表相媲美。即便如此，性能也永远是值得优化的，使用 Weex 的开发者对列表性能的追求也是永无止境的。

就像大家觉得前端框架引入 Virtual DOM 之后就一定比原生 DOM 慢一样，一些 Weex 的原生开发者也觉得 Weex 提供的列表毕竟多了一层封装，不能精细地操控列表的渲染行为，性能一定不如直接操作原生列表。这也是有一定道理的，如果再仔细分析一下这些需求，到底如何精细操控列表的渲染行为能提升性能呢？有没有办法抽象出通用的逻辑呢？假如说不考虑兼容现有的 list 组件，也允许对框架和现有渲染流程做重构级别的改动，能不能开个脑洞放个大招来提升列表的性能呢？这也是要开发新列表容器的出发点。

有啥不一样

既然名字叫 recycle-list，它与普通 list 的最大差异就在于节点的回收复用能力。

在大部分使用列表的场景中，有很多行节点的结构都是大致相同的，一个列表可能有 500 行那么长，全部展开的话长度会超过 100 屏，但是很可能只用了 5 个不同的模板。如果在渲染这 500 行节点的时候，能不断复用这 5 个模板结构的话，只渲染可视区内的组件的话，肯定能大幅优化列表的渲染性能。

所以在渲染 recycle-list 的时候，会记录不同的模板结构，用数据驱动模板的渲染，首次渲染时只会先创建首屏以及有可能滚动到的安全区域内的节点；在滚动时，会将脱离安全区域内的节点回收，清空模板并灌注新数据追加到即将出现的区域内。这是 recycle-list 在渲染行为上最大的不同。基于这种行为，前端和客户端之间节点的通信数据量将会减少，列表的内存也可以得到大幅的优化，即使列表越来越长，内存的增量也不会很多。

常规列表的渲染过程

首先分析一下目前在 Weex 里常规组件的渲染流程是怎样的。

在 Weex 的架构中，可以简略的分成三层：【DSL】->【JS Framework】->【原生渲染引擎】。其中 DSL (Domain Specific Language) 指的是 Weex 里支持的上层前端框架，即 Vue 和 Rax。原生渲染引擎就是在 Weex 支持的平台上（Android 或 iOS）绘制原生 UI 的引擎。JS Framework 是桥接并适配 DSL 和原生渲染引擎的一层。参考 《详细介绍 Weex 的 JS Framework》。

常规组件的渲染过程可以分为如下这几个步骤：

1. 创建前端组件
2. 构建 Virtual DOM
3. 生成“真实” DOM
4. 发送渲染指令
5. 绘制原生 UI

以 Vue.js 为例，它在 Weex 里的渲染过程可以用下面这一张图来概括：

简而言之，模板是可以被复用的，传入多条数据可以展开成多个前端组件，这也是组件化的优势之一，组件进一步在前端框架中展开成 VNode 节点。JS Framework 里提供了很多类似 DOM API 的接口，在内部构建出适用于 Weex 平台的 Element 节点（和 DOM 很像，但并不是“真实”的 DOM），这些节点会以渲染指令的形式发给客户端。客户端根据渲染指令创建相应的原生组件，最终调用系统提供的接口绘制原生 UI。具体过程请参考：Weex 页面的渲染。

改造思路

回顾上述过程可以看出，组件的模板结构是可复用的，这也是组件化的优势之一，但是组件的展开发生在前端框架内部，在传递到客户端的过程中，节点的结构保留了，但是组件的信息都被过滤掉了。即使同一个组件使用两份数据来渲染，生成了两份结构一致只有小部分内容有差异的节点，客户端也不会认为他们之间有联系，依然彼此独立的渲染。也就是说，在常规组件的渲染流程中，客户端感知不到前端组件的概念，渲染粒度太小，难以复用。

借鉴函数式编程里的惰性计算的思路，可以将渲染过程延后，交给客户端执行，这样客户端就能更好的施展复用逻辑。具体来讲就是不把节点在前端渲染好了再把结果发给客户端，而是把“渲染方法”和数据分别发给客户端，避免模板在前端框架中展开，客户端根据数据和用户的操作行为控制模板的渲染和复用。

可复用列表的渲染过程

如上图所示，前端框架中的 Template 不再需要数据，而是直接展开成一种纯静态的模板结构，结构中包含了模板渲染逻辑，格式仍然是 VNode。然后经过 JS Framework 转换成 Weex 支持的 Element，其中也包含了模板的原生渲染指令。客户端解析出可复用的模板结构，由数据驱动模板渲染，这个模板结构和前端组件中的定义是一致的。

这个过程除了要把模板发给客户端，还得带上模板的渲染逻辑，告诉客户端如何根据数据来渲染模板。为了描述这些渲染逻辑，就得设计一套面向原生渲染引擎的模板渲染指令，用来声明节点的循环渲染、条件渲染、事件绑定等逻辑。下文有详解。

性能对比

上述改造过程如果能实现的话，从理论上上讲，内存和渲染性能必然会有提升，而且列表越长性能优势越明显。下面也从实际的数据中看一下性能的对比结果到底是怎样的。

目前 Weex 提供了 <scroller> 、 <list> 、 和 <recycle-list> 这三种可滚动容器，功能看起来差不多，但是能力和特征都有差异。为了方便比较性能，我们对同样的一个页面，分别使用了不同的列表容器来实现，并记录了在 iOS 和 Android 下页面的加载时间、进入页面时的内存、滑动到页面底部时的内存、滑动时CPU的使用量等数据。

使用的测试用例如下：

• 使用 <scroller>。
• 使用 <list>。
• 使用 <recycle-list> （需要使用最新版 playground app 扫码才能看到渲染效果）。

在 iOS 设备（iPhone 6, iOS 11.0）中的测试结果如下所示：

在 Android 设备（Honor 6x, Android 7.0）中的测试结果如下所示：

从上面的数据可以看出，<list> 相比 <scroller> 已经有了较大的性能提升，<recycle-list> 比 <list> 的性能表现更加优秀。尤其在内存方面，<recycle-list> 在 iOS 下的内存占用量始终保持在个位数，在 Android 下除此加载时的内存和滑动到底部时的内存也分别优化了 42.7% 和 23.6%。

研发历程

recycle-list 不仅特别，也是开发跨时最久的一个组件了，从最早明确提出 Proposal（2017/08/04）到发布 v0.18.0（2018/02/09）历时长达半年之久。因为它是一个重要但不紧急的功能，在研发期间不断被打断，本身的技术难度由很大，涉及的技术面比较多，整个研发过程也是陆陆续续、磕磕绊绊、边探索边验证。

recycle-list 虽说是一个组件，但是它开辟了一条新的渲染模式，无论是前端框架、JS Framework 还是原生渲染引擎都有重构级别的改造；开发者也是多样的，前端、iOS、Android 都全程参与了。由于这个组件涉及大量对前端框架内部的改造，Vue.js 的原作者尤雨溪（微博 @尤小右） 也深度参与了开发和讨论，尤其在前期讨论实现方案的时候提供了大量思路。这个组件无论是技术方案还是开发协作方式都和以往不同，可以说是相当特别了。

先弄出来 MVP

这个组件虽然开发历时很久，但是在讨论了大致思路以后，几乎在前几天内就做出了一个 MVP (Minimum Viable Product) 版本来验证想法，并且立即对比了渲染性能。

为了快速验证想法，先随意约定了一套模板指令，绕过前端框架和 JS Framework 的渲染流程，直接手写 callNative 指令将模板结构和数据发给客户端，客户端也不考虑兼容性和副作用，先实现了渲染和复用的基本逻辑。这个步骤只是用来验证设想的方案是否可行，如果行不通就没必要继续浪费时间。

虽然快速做出了 MVP 版本，看似已经成功一半，但是设计得太过粗糙，很多流程并未想清楚，原有列表的大部分功能都没有实现思路，真正的进度可能连 10% 都不到。

明确技术方案

验证了可行性之后，下一步并没有立即继续写代码，而是静下心来认真再讨论一下详细的技术方案。这个过程邀请了尤雨溪一起参与，从编译工具、上层语法糖到组件生命周期和状态同步等功能，都做过细致的分析和讨论。

最初在讨论的时候，觉得生命周期和有状态的子组件这些功能都是无法实现的，因为组件的私有状态和生命周期是在前端框架里的，然而组件渲染过程又完全交给了客户端来控制，语言都不一样，甚至不在同一个线程里，简直无法再联系起来。不过最终还是设计出了一系列的通信和状态同步机制，将功能做得更完善，下文有详解。

在明确实现细节的过程中，由于没有兼容历史版本的包袱，开发期间可以冷静思考真正合理并且好用的技术方案，不惜多次推翻原有的设计，反复重构代码，最终才能实现“看起来和旧的 list 差不多嘛，无非是用了新的名字多了 for/switch/case 的语法而已”这种效果。

分期实现功能

有了详细的设计以后，前端、iOS、Android 开发者分别独立开发，同时编译工具的用例也在不断的更新，三端都频繁的迭代，渐进式的完善功能。这个项目的前期工作做的比较足，先有的使用文档和实现方案，然后有的测试用例和各种 demo，最后才是写代码实现功能，开发流程还是比较工整的。

目前发布的第一个版本中，基础功能都完备了，但是存在较多注意事项，有些是组件固有的差异，还有些是正在讨论技术方案但还没来得及实现的功能，如支持动态绑定样式类名、双向绑定、filter、组件的自定义事件等。这些功能将在后续版本里逐步实现，虽然它们写出来只有短短几个字，看起来也都是现有组件理所当然就支持的功能，但是在 recycle-list 里可能对应了涉及多端的大范围改造。

实现原理

在前面的章节里介绍了可复用列表的渲染过程，这只是开了个头，想要实现这个效果，至少要涉及编译工具、客户端渲染引擎以及前端框架里的改造。

自定义原生渲染指令

把“渲染方法”发给客户端，说起来简单，这里边包含了循环、条件、使用自定义组件的逻辑，能把它们完备地发给客户端吗？绝大多数渲染逻辑都可以。 要实现这个功能，就得设计一套描述渲染逻辑的原生指令，保障自身的完备性，然后对接上层前端框架中的模板语法，这个对接过程可以交给工具在编译期实现。

以 Vue 为例，它提供了单文件组件的语法，其中 v-bind 、 v-for 、 v-if 之类的特殊属性（模板指令），以及 {{}} 中的数据绑定都是描述渲染逻辑的，这些特殊语法如果用在 recycle-list 里，将会被编译工具编译成 Weex 支持的原生渲染指令。这层渲染指令是面向客户端的渲染行为设计的，是原生渲染器和 JS Framework 之间的约定，可以对接到 Vue 和 Rax 等多个上层框架，语法基本上都是一一对应的。具体的语法规则，可以参考 Implementation.md#模板语法。

Vue 里的渲染逻辑是声明式的写在模板里的，因此可以很容易的编译成 Weex 的原生渲染指令，整个转换过程可以融入到现有的编译工具中处理，对上层开发者透明，基本上对开发过程无影响，也不影响原有功能。在 Rax/React 的渲染函数中，标签语法可以使用 JSX 编写，但是模板的渲染规则（循环和条件）仍然由 JS 脚本来控制，是命令式的而不是声明式的，很难编译成静态的描述，要想使用长列表的复用功能，需要对开发时的写法做特殊约定，或者使用特殊的渲染流程控制组件。

客户端根据数据渲染模板

客户端拿到了数据和模板以后，在内部建立起 Watcher 和 Updater 的更新机制，由数据驱动模板的渲染。在最初渲染时只渲染屏幕内呈现出来的节点。

当列表向下滚动时，回收掉上方不在屏幕内的模板，并不销毁而是将其中的数据清空。当列表下方需要渲染新的数据时，会取出回收的空模板，注入数据渲染出真实节点，然后追加到列表下方。列表向上滚动时的原理是一样的，为了保障列表滚动的流畅，也会渲染屏幕上下方扩展区域内的节点。无论真实的数据有多少条，真实渲染的只有可滚动区域内的节点，这样不仅可以加快首屏的渲染速度，内存的占用量也不会随着列表长度大幅增长。

由于我只是个前端开发，对于客户端里的底层细节就不在这里班门弄斧了，期待客户端开发者再详细介绍一下这一部分。

使用 Virtual Component 管理组件状态

想让客户端只根据模板和数据就能渲染出来节点，看起来只有函数式组件才可以做到，也就是要求组件必须是不含内部状态的，然而实际应用中绝大多数组件都含有内部状态的，只做到这一步是远远不够的。

对于包含了状态的组件，渲染过程就比较复杂了，因为组件内部状态的处理逻辑（data,watch, computed）都在前端中，然而模板和数据都已经发给客户端处理了，所以需要经过多个回合的通信来解决状态同步问题（详细处理过程可以参考 Implementation.md#渲染过程）。

为了实现可复用的原生组件，在前端框架中引入了 Virtual Component Template 和 Virtual Component 这两个概念：

在渲染的过程中，如果发现某个组件用在了 <recycle-list> 里，就不再走之前的处理逻辑，而是创建一个 Virtual Component Template，并且不初始化任何状态（data,watch, computed）、不绑定生命周期，但是会初始化自定义事件的功能。渲染组件时不执行 render 函数，而是执行定制的 @render 函数生成带有原生渲染指令的模板结构，这个结构将一次性发给客户端，后续不会再修改。

在创建 Virtual Component Template 时，会监听客户端原生组件的 create 生命周期钩子，当客户端派发了 create 的时候，才会真正的开始创建只含状态不含节点的 Virtual Component。虚拟组件模板只有一份，但是从同一份模板创建出的 Virtual Component 会有多个，与客户端发送的 create 钩子的次数有关，与数据有关。另外，由于事件是绑定在节点上的，原生 UI 捕获到的事件只会派发给 Virtual Component Template，然后再找到相应的 Virtual Component 并以其为作用域执行事件处理函数。

Virtual Component 内部只管理数据，即使数据有变动也不会触发渲染，而是调用特殊接口向客户端更新组件的内部状态，由客户端根据新数据更新组件的 UI。在创建 Virtual Component 时，会监听客户端原生组件的 attach 、detach 、 update 、 syncState 生命周期，生命周期的派发有客户端来控制，语义和前端框架略有差异。

题外话

Weex 是个开源项目，是一个社区项目，分享经验、贡献代码、贡献想法、修订文档都算是为开源项目贡献力量，我相信有许多开发者都使用过 Weex，也踩过一些坑，积累了实践经验，也希望大家能多多分享，一起参与改善 Weex，让它变得更强大用起来更顺手。