2020年的双11，阿里需要什么样的渲染方案？
?
阿里妹導讀：前端技術的"新陳代謝"是有目共睹的，新技術的不斷發展也推動著前端應用場景的不斷擴大，從 Web 、Weex 到 Node.js 再到 FaaS。我們在發展中看不變的部分，唯有追求更好的用戶體驗是端技術持續發展中不變的責任。在阿里，雙 11 的復雜與廣泛是全方面檢驗一個技術最直接有效的途徑，今年的雙 11 是全面使用由阿里巴巴開源的 Rax 的一年，本文將介紹 Rax 在用戶體驗上努力探索的方向。
?
1. 輕量化
?
更輕量意味著什么？JS 引擎的解析與編譯的時間會將會直接減少。在我們歷史的測試中，性能較低的一些 Android 設備上，初始 JS Bundle 的整體時間需要 300ms 或甚至更多，已是影響體驗的非常大的一部分時間占比，所以在相同功能的前提下輕量化對業務優化體驗是非常有效的手段之一。
?
圖片來源：https://v8.dev/blog/background-compilation
?
年初我們啟動了 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 的修正大概有幾類：文本修正、屬性修正、節點修正，節點修正過程中如果遇到已經不存在的節點也會進行刪除，保障渲染結果的正確性。
?
?
2. 快照渲染（Snapshot Rendering）
?
快照渲染在終端上不算一個新的概念，比如手淘的首頁就有快照的機制，每次進入手淘會首先展示上一次的頁面。Rax 快照渲染結合自適應復合渲染，其讓快照渲染的體驗變的更快更自然。
?
?
Rax 快照技術同樣也需要有前置的歷史狀態，使用快照技術時我們可以把任何時候的頁面狀態存儲為快照，然后下一次加載頁面時首先從本地存儲中加載上一次的頁面快照。加載完快照后我們需要更新到最新的狀態，在以往的技術方案中，當新頁面完成后先置空為了體驗設置的當前快照頁面，然后再設置最新頁面，這個過程有可能會觸發頁面的閃動。但通過 Rax 自適應復合渲染方式更新快照到最新的狀態則可以避免此問題，這也是 Rax Hydration 把兼容性作為一個重要設計目標的帶來的好處。
?
?
3. 服務端渲染（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?
4. 客戶端渲染（Native Side Rendering）
?
NSR 與 SSR 的工作原理非常接近，最大差別是 NSR 把 SSR 執行的過程放在了客戶端上，不需要服務器就可享受到 SSR 的體驗。NSR 與 CSR 渲染對比：
?
?
5. 個性化渲染
?
為什么會有個性化渲染？無論 CSR、SSR、NSR、SR 都有其適用的場景，當用戶的網絡足夠好的情況下，可想而至無論哪一種渲染方式體驗都還是不錯的，但事實情況是怎么樣的？我們通過這次雙 11 端外體驗數據可見一斑，不到 50% 的用戶首屏可交互時間在 3s 內，90% 的用戶在 0-7s 內，有 10% 的用戶都在 7s 后：
?
?
無論低端機還是弱網絡用戶，都是我們需要重點關注的，而且邏輯上即是低端機又是弱網絡的重合率可能很高。因此在不同的場景下選擇合適的渲染方案變的非常有必要。比如在網絡不佳并且在端內選擇 NSR 方式渲染，網絡不佳但在端外選擇 SSR 方式渲染，設備性能不佳無論在端內還是端外選擇 SSR， 所以我們認為未來的渲染方式都應是個性化的，不應是所有人都是一樣的策略。
?
期望 2020 年的雙 11 通過我們的努力讓更多人的體驗在 3s 內，更少的人在 7s 后，不再平均。
?
?
總結
以上是生活随笔為你收集整理的2020年的双11，阿里需要什么样的渲染方案？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 送给程序员终身受用的建议
- 下一篇： 仅1年GitHub Star数翻倍，Fl