作者| 元彥
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 的修正大概有幾類：文本修正、屬性修正、節點修正，節點修正過程中如果遇到已經不存在的節點也會進行删除，保障渲染結果的正确性。
- 快照渲染（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。
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
- 用戶端渲染（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 後，不再平均。