?

阿里妹導(dǎo)讀：前端技術(shù)的"新陳代謝"是有目共睹的，新技術(shù)的不斷發(fā)展也推動著前端應(yīng)用場景的不斷擴大，從 Web 、Weex 到 Node.js 再到 FaaS。我們在發(fā)展中看不變的部分，唯有追求更好的用戶體驗是端技術(shù)持續(xù)發(fā)展中不變的責(zé)任。在阿里，雙 11 的復(fù)雜與廣泛是全方面檢驗一個技術(shù)最直接有效的途徑，今年的雙 11 是全面使用由阿里巴巴開源的 Rax 的一年，本文將介紹 Rax 在用戶體驗上努力探索的方向。

?

1. 輕量化

?

更輕量意味著什么？JS 引擎的解析與編譯的時間會將會直接減少。在我們歷史的測試中，性能較低的一些 Android 設(shè)備上，初始 JS Bundle 的整體時間需要 300ms 或甚至更多，已是影響體驗的非常大的一部分時間占比，所以在相同功能的前提下輕量化對業(yè)務(wù)優(yōu)化體驗是非常有效的手段之一。

?

圖片來源：https://v8.dev/blog/background-compilation

?

年初我們啟動了 Rax 1.0 的計劃，能力上支持 Hooks，通過 Hooks 函數(shù)組件的寫法本身能讓業(yè)務(wù)代碼更少，同時全新的 Rax 1.0 相比 Rax 上一個 0.6 的版本的內(nèi)核代碼從 57k 下降到了 17k，更輕量更快。

?

?

2. 自適應(yīng)復(fù)合渲染（Adaptive Hydration Rendering）

?

Rax 的 Hydration 渲染最大的特點是自適應(yīng)能力。什么是自適應(yīng)能力？我們對比 React 的 Hydration 機制，我們可以在服務(wù)器端先提前生成了 HTML，然后執(zhí)行 hydrate 在已有的 DOM 結(jié)構(gòu)上綁定事件。過程中如果已有的 DOM 結(jié)構(gòu)與當(dāng)前 js bundle 輸出的結(jié)構(gòu)不一致，React 可以修正文本內(nèi)容的差異，但不能保證在不匹配的情況下調(diào)整屬性的差異。而且在 DOM 結(jié)構(gòu)不匹配的時候 React 可能會有渲染兩次的問題，此時反而使得渲染變的更慢。

?

在 Rax Hydration 的方案設(shè)計中，我們把兼容性與易用性作為一個重要設(shè)計目標，所以 Rax 會盡可能的復(fù)用已有節(jié)點，對任何有差異的地方進行修正。Rax 的修正大概有幾類：文本修正、屬性修正、節(jié)點修正，節(jié)點修正過程中如果遇到已經(jīng)不存在的節(jié)點也會進行刪除，保障渲染結(jié)果的正確性。

?

?

2. 快照渲染（Snapshot Rendering）

?

快照渲染在終端上不算一個新的概念，比如手淘的首頁就有快照的機制，每次進入手淘會首先展示上一次的頁面。Rax 快照渲染結(jié)合自適應(yīng)復(fù)合渲染，其讓快照渲染的體驗變的更快更自然。

?

?

Rax 快照技術(shù)同樣也需要有前置的歷史狀態(tài)，使用快照技術(shù)時我們可以把任何時候的頁面狀態(tài)存儲為快照，然后下一次加載頁面時首先從本地存儲中加載上一次的頁面快照。加載完快照后我們需要更新到最新的狀態(tài)，在以往的技術(shù)方案中，當(dāng)新頁面完成后先置空為了體驗設(shè)置的當(dāng)前快照頁面，然后再設(shè)置最新頁面，這個過程有可能會觸發(fā)頁面的閃動。但通過 Rax 自適應(yīng)復(fù)合渲染方式更新快照到最新的狀態(tài)則可以避免此問題，這也是 Rax Hydration 把兼容性作為一個重要設(shè)計目標的帶來的好處。

?

?

3. 服務(wù)端渲染（Server Side Rendering）

?

SSR 是在當(dāng)下云+端趨勢下我們非常看中的能力。所以 Rax 的服務(wù)端渲染在今年做了非常多嘗試與突破，比如嘗試通過 C++ 去實現(xiàn)一個完整的服務(wù)器端渲染，JS 與 C++ 間類型轉(zhuǎn)換的效率導(dǎo)致性能還不如純 JS 實現(xiàn)的方案，也考慮過能否把部分功能純字符串操作的能力用 C++ 實現(xiàn)，這些嘗試最終都沒有符合我們的期望。

?

最終我們在工程上找到了解決方案，在編譯時預(yù)先做了計算與字符串拼接，通過從下面的測試數(shù)據(jù)中了解到 Rax 的 SSR 性能是 React 的 8 倍，甚至已經(jīng)超過了 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 執(zhí)行的過程放在了客戶端上，不需要服務(wù)器就可享受到 SSR 的體驗。NSR 與 CSR 渲染對比：

?

?

5. 個性化渲染

?

為什么會有個性化渲染？無論 CSR、SSR、NSR、SR 都有其適用的場景，當(dāng)用戶的網(wǎng)絡(luò)足夠好的情況下，可想而至無論哪一種渲染方式體驗都還是不錯的，但事實情況是怎么樣的？我們通過這次雙 11 端外體驗數(shù)據(jù)可見一斑，不到 50% 的用戶首屏可交互時間在 3s 內(nèi)，90% 的用戶在 0-7s 內(nèi)，有 10% 的用戶都在 7s 后：

?

?

無論低端機還是弱網(wǎng)絡(luò)用戶，都是我們需要重點關(guān)注的，而且邏輯上即是低端機又是弱網(wǎng)絡(luò)的重合率可能很高。因此在不同的場景下選擇合適的渲染方案變的非常有必要。比如在網(wǎng)絡(luò)不佳并且在端內(nèi)選擇 NSR 方式渲染，網(wǎng)絡(luò)不佳但在端外選擇 SSR 方式渲染，設(shè)備性能不佳無論在端內(nèi)還是端外選擇 SSR， 所以我們認為未來的渲染方式都應(yīng)是個性化的，不應(yīng)是所有人都是一樣的策略。

?

期望 2020 年的雙 11 通過我們的努力讓更多人的體驗在 3s 內(nèi)，更少的人在 7s 后，不再平均。

?

?

總結(jié)

以上是生活随笔為你收集整理的2020年的双11，阿里需要什么样的渲染方案？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。