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 後，再也不平均。

---

本文做者：元彥

閱讀原文

本文來自阿里雲合做夥伴「阿里技術」，如需轉載請聯繫原做者。