2020年的双11，阿里须要什么样的渲染方案？

阿里妹导读：前端技术的"新陈代谢"是有目共睹的，新技术的不断发展也推进着前端应用场景的不断扩大，从 Web 、Weex 到 Node.js 再到 FaaS。咱们在发展中看不变的部分，惟有追求更好的用户体验是端技术持续发展中不变的责任。在阿里，双 11 的复杂与普遍是全方面检验一个技术最直接有效的途径，今年的双 11 是全面使用由阿里巴巴开源的 Rax 的一年，本文将介绍 Rax 在用户体验上努力探索的方向。

1. 轻量化

更轻量意味着什么？JS 引擎的解析与编译的时间会将会直接减小。在咱们历史的测试中，性能较低的一些 Android 设备上，初始 JS Bundle 的总体时间须要 300ms 或甚至更多，已经是影响体验的很是大的一部分时间占比，因此在相同功能的前提下轻量化对业务优化体验是很是有效的手段之一。

图片来源：https://v8.dev/blog/backgroun...

年初咱们启动了 Rax 1.0 的计划，能力上支持 Hooks，经过 Hooks 函数组件的写法自己能让业务代码更少，同时全新的 Rax 1.0 相比 Rax 上一个 0.6 的版本的内核代码从 57k 降低到了 17k，更轻量更快。

2. 自适应复合渲染（Adaptive Hydration Rendering）

Rax 的 Hydration 渲染最大的特色是自适应能力。什么是自适应能力？咱们对比 React 的 Hydration 机制，咱们能够在服务器端先提早生成了 HTML，而后执行 hydrate 在已有的 DOM 结构上绑定事件。过程当中若是已有的 DOM 结构与当前 js bundle 输出的结构不一致，React 能够修正文本内容的差别，但不能保证在不匹配的状况下调整属性的差别。并且在 DOM 结构不匹配的时候 React 可能会有渲染两次的问题，此时反而使得渲染变的更慢。

在 Rax Hydration 的方案设计中，咱们把兼容性与易用性做为一个重要设计目标，因此 Rax 会尽量的复用已有节点，对任何有差别的地方进行修正。Rax 的修正大概有几类：文本修正、属性修正、节点修正，节点修正过程当中若是遇到已经不存在的节点也会进行删除，保障渲染结果的正确性。

3. 快照渲染（Snapshot Rendering）

快照渲染在终端上不算一个新的概念，好比手淘的首页就有快照的机制，每次进入手淘会首先展现上一次的页面。Rax 快照渲染结合自适应复合渲染，其让快照渲染的体验变的更快更天然。

Rax 快照技术一样也须要有前置的历史状态，使用快照技术时咱们能够把任什么时候候的页面状态存储为快照，而后下一次加载页面时首先从本地存储中加载上一次的页面快照。加载完快照后咱们须要更新到最新的状态，在以往的技术方案中，当新页面完成后先置空为了体验设置的当前快照页面，而后再设置最新页面，这个过程有可能会触发页面的闪动。但经过 Rax 自适应复合渲染方式更新快照到最新的状态则能够避免此问题，这也是 Rax Hydration 把兼容性做为一个重要设计目标的带来的好处。

4. 服务端渲染（Server Side Rendering）

SSR 是在当下云+端趋势下咱们很是看中的能力。因此 Rax 的服务端渲染在今年作了很是多尝试与突破，好比尝试经过 C++ 去实现一个完整的服务器端渲染，JS 与 C++ 间类型转换的效率致使性能还不如纯 JS 实现的方案，也考虑过可否把部分功能纯字符串操做的能力用 C++ 实现，这些尝试最终都没有符合咱们的指望。

最终咱们在工程上找到了解决方案，在编译时预先作了计算与字符串拼接，经过从下面的测试数据中了解到 Rax 的 SSR 性能是 React 的 8 倍，甚至已经超过了 xtpl，这也让咱们有机会在合适的场景中用 jsx 去替换 xtpl。

-----------compare renderToString----------
React(16.12.0)#renderToString x 1,664 ops/sec ±1.40% (84 runs sampled)
Rax(1.0.13)#renderToString x 13,411 ops/sec ±1.05% (85 runs sampled)
Preact(10.0.5)#renderToString x 1,237 ops/sec ±2.18% (84 runs sampled)
Xtpl(3.4.2)#renderFile x 11,335 ops/sec ±8.17% (69 runs sampled)

The benchmark was run on:
   PLATFORM: darwin 17.5.0
   CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
   SYSTEM MEMORY: 16GB
   NODE VERSION: v10.11.0

5. 客户端渲染（Native Side Rendering）

NSR 与 SSR 的工做原理很是接近，最大差异是 NSR 把 SSR 执行的过程放在了客户端上，不须要服务器就可享受到 SSR 的体验。NSR 与 CSR 渲染对比：

6. 个性化渲染

为何会有个性化渲染？不管 CSR、SSR、NSR、SR 都有其适用的场景，当用户的网络足够好的状况下，可想而至不管哪种渲染方式体验都仍是不错的，但事实状况是怎么样的？咱们经过此次双 11 端外体验数据可见一斑，不到 50% 的用户首屏可交互时间在 3s 内，90% 的用户在 0-7s 内，有 10% 的用户都在 7s 后：

不管低端机仍是弱网络用户，都是咱们须要重点关注的，并且逻辑上便是低端机又是弱网络的重合率可能很高。所以在不一样的场景下选择合适的渲染方案变的很是有必要。好比在网络不佳而且在端内选择 NSR 方式渲染，网络不佳但在端外选择 SSR 方式渲染，设备性能不佳不管在端内仍是端外选择 SSR， 因此咱们认为将来的渲染方式都应是个性化的，不该是全部人都是同样的策略。

指望 2020 年的双 11 经过咱们的努力让更多人的体验在 3s 内，更少的人在 7s 后，再也不平均。

---

本文做者：元彦

阅读原文

本文来自阿里云合做伙伴“阿里技术”，如需转载请联系原做者。