前言
本文章是渲染引擎北海 (Kraken) v0.9 的釋出日志，如果你對 Kraken 還不了解，不妨先跳轉到本文末尾閱讀我們之前釋出的文章。
繼 v0.8 更新到 Flutter 2.0 + Null Safety 之後，在這個版本我們重點對首屏的加載性能、布局的正确性和性能以及前端社群生态做了重點優化，詳細的更新日志可見
CHANGELOG。
接下來我會重點介紹在 v0.9 加入的幾大新特性。
支援 QuickJS 作為 JavaScript Engine
QuickJS 是一個輕量級的 JavaScript 引擎，與 JavaScriptCore 相比它具有以下幾個優點：
- 輕量，它的實作僅僅由幾個 C 檔案，沒有外部依賴，一個 x86 下的簡單的 “hello world” 程式隻要約 180 KiB。
- 具有極低啟動時間的快速解釋器，配合将 JS 源碼預編譯為 bytecode 格式，忽略解析耗時後對應用啟動性能有很大提升。
- 幾乎完整的 ECMA 标準支援，最新版本原生支援 ES2020，不再需要 babel 編譯為 ES5，不僅 JSBundle 體積可以下降，也能提升執行的性能。
- 更好的多平台支援，即使完整編譯也不需要耗費太多工夫。
Kraken v0.9 将原先的 Bridge 層的 JavaScript Engine 預設實作遷移為 QuickJS，配合 bytecode 預編譯可以将應用啟動性能得到提升。而且這些改動對前端開發者是完全無感的。
我們也對 Kraken 新版本和上一個版本進行了 Benchmark 性能測試：
測試裝置： MI 6 (Android arm64)
測試頁面：
https://kraken.oss-cn-hangzhou.aliyuncs.com/data/cvd3r6f068.js測試方法：使用 0.8.4（JavaScriptCore） 和 0.9.0-rc（QuickJS） 版本各冷啟動一次頁面，對比加載耗時。
詳細日志：
分析日志中與 JavaScript 相關的關鍵性能名額：
- js_context_init_cost：JS Engine 初始化耗時
- polyfill_init_cost：Kraken JS polyfill 初始化耗時
- js_bundle_eval_cost：JS Bundle 執行耗時
- js_parse_time_cost：JS Bundle 解析耗時
| Version | js_context_init_cost | polyfill_init_cost | js_bundle_eval_cost | js_parse_time_cost |
|---|---|---|---|---|
| 17.30ms | 20.39ms | 229.53ms | 31.25ms | |
| 0.55ms | 2.06ms | 122.61ms | 122.91ms |
QuickJS 支援 bytecode 加載，故
js_parse_time_cost
在使用 bytecode 格式的時候可幾乎忽略不計。
得到有關 JS 的總加載耗時：
- JavaScriptCore: 17.3 + 20.39 + 229.53 + 31.25 = 298.47ms
- QuickJS: 0.55 + 2.06 + 122.61 = 125ms
真機錄屏驗證
以上屬于代碼級别的 Benchmark 資料，實際使用者體感效果如何呢，我們在真機上進行了錄屏測試：
名額定義：
- 白屏階段：從使用者點選 App 啟動到頁面首幀出現的時間
- 渲染階段：從頁面首幀出現到目标頁所有内容(含圖檔)渲染穩定完成的時間
通過逐幀分析，多組取平均值得到以下資料：
受限于視訊播放器進度條的精度，測試資料精度為 0.05s。
| 測試分組 | 白屏階段 (均值) | 渲染階段 (均值) |
|---|---|---|
| 0.95s | 0.80s | |
| 0.60s | ||
| 0.9.0-rc + bytecode | 0.76s | 0.66s |
可得結論，在上述條件下，Kraken v0.9 + bytecode 模式相比 v0.8 版本在首屏性能上可再提升 18.86%。值得注意的是，真機測試使用的是一台 Android 中端裝置，JS Engine 解析耗時的影響在低端裝置上影響更大，故有理由相信 QuickJS 帶來的優化在低端裝置上可以獲得更多的收益，具體資料我們也将進一步測試更新。
支援 HTML 檔案的解析和渲染
對浏覽器來說，SSR 直出渲染的性能要比異步 JS 渲染的 CSR 要好上不少，對于 Kraken 也是如此。這次我們給 Kraken 帶來了 HTML 檔案解析渲染的支援，直接解析 HTML 并渲染視圖，無需等待 JS 的初始化與執行。
使用上與 JSBundle 并無任何不同，隻需要将 HTML 檔案的 URL 傳入 bundleURL 即可：
void main() {
runApp(Kraken(
bundleURL: 'https://domain.com/url/to/html',
));
} Kraken 會根據 HTTP
Content-Type
協商使用 HTML 解析或者是 JavaScript 引擎啟動。
性能測試：
測試裝置： MI 11 Lite (Android arm64) https://kraken.oss-cn-hangzhou.aliyuncs.com/data/....js 測試方法：使用 0.9.0-rc 分别用 JSBundle / Bytecode / HTML 格式各冷啟動一次頁面，對比加載耗時。
| Total time cost (平均) | |
|---|---|
| JS Bundle | 865ms |
| Bytecode | 662ms |
| HTML | 255ms |
支援 HTTP 協定的緩存特性
衆所周知，程式設計的終極問題有兩個，其一是給變量命名，另一個就是緩存的使用。
在浏覽器中預設支援 HTTP 緩存，包含強緩存、協商緩存，它是由多個 HTTP Headers 組合形成的一種描述緩存的規範。而在用戶端生态或者 Flutter 的基礎能力中，都是不包含 HTTP 緩存功能的。Kraken v0.9 開始預設支援了 HTTP 緩存功能，無論是 XHR/fetch 或者是通過 img 标簽加載的圖檔，script 标簽加載的 JS 檔案等，隻要是從 Kraken 内部發出的 HTTP(s) 請求，都能夠享受到緩存帶來的收益，目前支援的特性包括：
- 無需二次請求的強緩存
- Expires
- Cache-Control (max-age/no-store/no-cache)
- 需要二次請求的協商緩存 (根據 HTTP 狀态碼 304 協商)
- Last-Modified / If-Modified-Since
- Etag / If-None-Match
本功能對于電商商品 Feeds 流等頁面中包含大量圖檔的場景，帶來的優化收益更明顯，由于圖檔幾乎全是強緩存類型的資源，在緩存命中的情況下無需再次請求網絡，且緩存是落磁盤的固化式緩存，對于二次冷啟應用也能享受到優化。
支援 Vue/React 官方工具鍊
前端開發者是 Kraken 面向的使用者，在開源之後我們也持續收到了許多社群開發者的回報。
對于現代前端開發來說，架構是必不可少的，除了淘系廣泛使用的 Rax，最近我們也對 Vue 和 React 的官方工具鍊、生态庫進行了支援，現在使用 v0.9 開發 Vue/React App 會更加順暢。
具體可參考官方示例工程：
https://github.com/openkraken/samples支援子產品熱更新 (Hot Module Replacement)
子產品熱更新是 Webpack 的常用功能，通過它可以在修改代碼後直接替換、添加或者删除節點，而無需重新加載整個頁面。
Webpack 官方說明文檔 支援 querySelector / querySelectorAll*
同時我們也對呼聲比較大的
querySelector/querySelectorAll
做了支援，目前已支援的 CSS 選擇器包括：
- id ID 選擇器
- class 類名選擇器
- tag 标簽選擇器
- attr 屬性選擇器，包含以下幾種判斷
- =
- ^=
- *=
- $=
*：目前僅支援部分 CSS 選擇器，詳見上述說明。
關于北海 KRAKEN 更多的内容
社群協作機制
我們期望通過一種良好的社群協作機制，來與社群的衆多開發者一起共建 Kraken 底層能力及生态。
Kraken 團隊通過
協作者的方式來參與 Kraken 功能疊代以及 issue 讨論等工作。同時，通過由一部分協作者組成的
技術委員會（TSC）來确定技術方向、釋出以及定制标準等工作。
簡單地說，隻要向 Openkraken Group 送出一定品質和數量的代碼即可成為協作者；對項目送出建設性的貢獻後，TSC 成員有權提名協作者參與到 TSC 中。
Kraken 團隊期望通過一種友好、共同參與的協作機制，讓社群的開發者能夠更好地參與到對項目的演進中去，讓每個人的聲音都能被聽到，共同促進 Kraken 以及 Web 标準 的發展。
更詳細的協作機制可以移步
Github TSC。
往期文章推薦
聯系我們
詳細的 CHANGELOG 可以查閱
。 如若希望擷取更多關于 Kraken 的資訊，可以通路我們的
Github、
官方文檔與 Kraken 項目組取得聯系。