基於 Flutter 的 Web 渲染引擎「北海」正式開源

阿里巴巴歷時 3 年自研開發的 Web 渲染引擎 北海（英文名：Kraken）正式開源，致力打造易擴展，跨平臺，高性能的渲染引擎，並已在優酷、大麥、天貓等業務場景中使用。

官網：https://openkraken.com

Github：https://github.com/openkraken/kraken

背景

互聯網業務如火如荼地發展離不開跨平臺技術，而最成熟的跨平臺技術就是你們熟悉的瀏覽器了，它與生俱來的跨平臺能力、開放的標準以及強大的生態使它成爲煊赫一時的容器之一。而因爲其自己不是爲了性能而設計的，而且歷史包袱重、兼容性、廠商更新慢等問題，瀏覽器在移動端的表現並不突出。儘管網絡以及硬件的發展帶來了足夠多的性能紅利，可是日益複雜的業務總能把已有的性能吃透。

過去也有不少對跨平臺方案的探索與實踐，新的技術方案也隨着歷史的浪潮不斷地發展。從最先的 H5 方案到 Hybrid 方案，以及後來的 Weex/React Native 方案，到如今如火如荼的 Flutter。

Flutter 因爲其精簡的渲染管線，高效的佈局渲染能力，以及自繪渲染的特性，一躍成爲這兩年跨端屆的新寵。而在 Flutter 出現以前，主流的方案仍是用 React Native（Weex）的，這套方案的底層調用了原生的 View。正是由於如此，致使這套方案很難保證徹底的多端一致性，由於原生 View 自己就存在一些限制，有限的能力不能知足開發者全部的需求，因此在實現 W3C 標準時有些牽強。而 Flutter 基於更底層的 Skia 作自繪渲染，能夠很好地保證多端一致性。

熟悉 Flutter 的同窗確定知道 Flutter 是用 Dart 語言以及 Widget 來開發的，雖然說 Dart 語言對熟悉 JavaScript 的前端同窗來講上手成本並非很高，對於 Widget 這種基於狀態驅動的開發模式也已是很是熟悉，可是總體上與已有基建與前端生態割裂的矛盾是沒法接受的。再者，動態化能力對於互聯網業務來講簡直就是剛需，而目前來看 Flutter for Web 並不理想。

畢竟，引入一項新技術的第一步是解決引入這項新技術的成本問題。因此咱們積極探索一種向上對接前端生態，向下使用自繪渲染的跨平臺方案。

因而誕生了這款基於 W3C 標準的高性能跨終端渲染引擎——北海（Kraken）。

基於 W3C 標準

Kraken 最終要服務的用戶仍是前端開發者，那麼如何下降前端開發者的學習熟悉成本以及如何將老項目快速地遷移到 Kraken 之上呢？咱們並不想從新創造一套新的 DSL 做爲研發框架來給開發者用，若是須要的話，那 Flutter 自己的 Widget + Dart 已經作得很不錯了。前端開發者多是用 Rax，也有多是用 Vue 或是 React 的，咱們都指望 Kraken 的用戶可以作到「零成本」的快速接入。那麼，就須要依賴一套開發者很是熟悉的標準來實現 Kraken。

<img src="https://img.alicdn.com/imgextra/i4/O1CN01Edx8Jk1ELTLfISD7H_!!6000000000335-2-tps-1000-1000.png" width="300px" />

W3C 標準是互聯網最重要的標準之一，也是前端開發者很是熟悉的標準，基於 W3C 標準來實現渲染引擎，對於熟悉瀏覽器的前端開發者能夠作到近乎「零成本」的快速上手。同時，咱們能夠擯棄一些沉重的歷史包袱，使得 Kraken 的渲染效率更高。

強大的前端開發者生態

受益於基於 W3C 標準來開發，在 Kraken 上前端開發者徹底可使用目前熟悉的龐大的前端生態。

首先，在研發框架的選擇上，不管開發者使用的是 Rax 或者 Vue ，仍是 React 或者 Angular 的，均可以保證在 Kraken 上很好地完成渲染。

再次，前端擁有很是繁榮的生態，社區海量的 NPM 包均可以在 Kraken 項目上直接使用，大量成熟的模塊保證了業務開發的效率。

<img src="https://img.alicdn.com/imgextra/i4/O1CN01Fxvi1F26lZA3iicyC_!!6000000007702-2-tps-1799-800.png" width="300px" />

除此以外，開發者平時在開發項目使用的各式各樣的工具，均可以在 Kraken 項目上直接使用，無需任何額外的熟悉以及學習成本。

經過對接了 Chrome DevTools Protocol，使開發者能夠直接使用很是熟悉的 Chrome DevTools 來調試所開發的頁面。不管開發者須要修改 CSS 樣式，仍是查看 DOM 結構，或者是經過斷點調試 JavaScript 代碼，都能保證跟 Web 開發一致的調試體驗。

<video autoplay loop="loop" align="center" src="https://kraken.oss-cn-hangzhou.aliyuncs.com/videos/devtools.mp4" controls="controls" width="500" ></video>

渲染一致性

Kraken 的渲染能力是對其 W3C 標準的，因此能夠保證跟 Web 渲染的結果徹底一致。

下圖是實際業務的截圖，從左到右分別是 Kraken（iOS），Kraken（Android）以及 Web 版本，能夠看出渲染結果是徹底一致的。

<video autoplay loop="loop" align="center" src="https://kraken.oss-cn-hangzhou.aliyuncs.com/videos/youku.mp4" controls="controls" width="500" height="300"></video>

比 Web 更好的體驗與能力

那麼到這裏會有同窗想問了，除了與目前前端開發一致的開發及調試體驗，以及渲染一致性，那麼最終到底能獲得怎麼樣的能力，以及跟瀏覽器比，到底能夠得到哪些收益呢？

無限滾動列表

在業務開發中，有時開發者會遇到一些沒法用分頁卻又大量數據的「無限滾動列表」。在客戶端開發中有 RecyclerView/UITableView 來實現滾動回收的佈局容器，而 Web 標準上儘管也有不少前端側的優化方案來處理這個問題，但也一直是個難題。Kraken 嘗試在容器側解決了此問題，增長 CSS Display 屬性值——sliver。

當 Sliver 容器中的子元素滾動出該容器的 Viewport 時，能夠將該子元素中用於渲染的 renderobject 回收以達到節省內存佔用的目的。當子元素從新出現時，根據 DOM 描述從新生成 renderobject。

這是一個上萬個節點的 demo，左邊是 overflow: scroll 的容器，而右邊是 display: sliver 的容器，能夠看到 sliver 容器在「無限滾動列表」場景下滾動明顯流暢不少。左上角有 FPS 的數據，能夠看到 display: sliver 的容器 FPS 一直維持正常水平，而 overflow: scroll 的容器 FPS 明顯降低。此外，在內存方面也有較大收益。

<video autoplay loop="loop" align="center" src="https://kraken.oss-cn-hangzhou.aliyuncs.com/videos/sliver.mp4" controls="controls" width="500" height="300"></video>

同步光柵化

在瀏覽器中，光柵化是異步進行的，進行慣性滾動時，會出現白屏，這個是 WebView 始終沒法避免的問題。而藉助 Flutter 足夠高效的同步光柵化實現，Kraken 能夠作到長列表快速滾動不白屏。

<video autoplay loop="loop" align="center" src="https://kraken.oss-cn-hangzhou.aliyuncs.com/videos/kraken-long-list.mp4" controls="controls" width="500" height="300"></video>

加強的手勢能力

Kraken 經過對經常使用手勢進行內置，使業務開發者使用手勢能力的時候，不再須要引入一個 JavaScript lib 以劫持 Touch event 來作開發了。

以輕掃手勢「swipe」爲例，開發者只須要經過如下方式就能夠得到一個 element 上默認提供的手勢能力。直接使用內置加強的手勢能力，可以更快速地開發複雜的可交互應用。

element.addEventLisenter('swipe',(gestureEvent) => {
    ///...
})

加強的手勢能力解決了 Web 下本來須要頻繁傳遞事件的性能問題以及 JavaScript 處理手勢佔用 UI 線程的問題。此外，經過容器內部實現的競爭場能力，能夠解決 Web 下手勢穿透等問題。

而內置的標準化手勢能力，也保證同個容器的不一樣應用下，手勢交互能力的標準化以及統一性。

插件化能力

除了上面的那些超越 Web 的體驗與能力之外，Kraken 很是重要的一個特性就是插件化能力，插件化能力提供給前端工程師從新定義瀏覽器能力的機會，開發者只須要編碼一個 Flutter plugin，就能夠擴展 Kraken 自己的能力。

經過插件化能力，開發者能夠在內部實現許多自定義的標籤（譬如說 Camera 或者自定義的視頻播放器等），也能夠基於性能的考慮將經常使用的業務組件（譬如說 Slider）下沉到容器層。因爲瀏覽器廠商開發以及標準制定每每是滯後的，用插件化能力開發者能夠快速地自定義各類渲染能力，使業務開發能夠用到最新的或者加強的各類能力。

除了擴展渲染能力，開發者還能夠擴展手勢能力，擴展手勢能力能夠將以往須要在前端劫持 Touch Event 實現的能力下沉到容器自己，除了加強了交互體驗，也給交互提供了更多可能性。

穩定性保障

渲染引擎很是複雜，常常出現改一個 Bug 牽一髮而動全身，因此須要高覆蓋率的自動化測試來保障渲染引擎的穩定性，每次修改後都須要保障已有的 case 沒有問題。經過自動化測試來保障每一個 case 與修改以前的結果作對比，若是有差別，能夠經過 case 以及差別的 diff 來修改 Bug。

這套自動化測試系統保證了 Kraken 每次修改先後獲得的 case 結果的一致性，以確保渲染引擎自己的穩定性。

目前已經有近 3000 個測試用例，將來還會根據更多的場景繼續增長，以此來保證 Kraken 的穩定性。

業務落地

講了那麼多 Kraken 的能力，確定有同窗想知道 Kraken 在實際生產場景的表現如何。

目前 Kraken 在 C 端場景移動設備以及低性能 IoT 設備均有相關業務接入，徹底可使用在實際生產場景。

在優酷 APP 中，Kraken 已經落地了大量業務。如下方所示「發電王排行榜」的分會場頁面爲例，Kraken 改造後啓動有了一個質的提高，相較於同個頁面的 原方案，首屏渲染提高28.4%，幀率提高 8.3%。

<video autoplay loop="loop" align="center" src="https://kraken.oss-cn-hangzhou.aliyuncs.com/videos/kraken_vs_prev.mp4" controls="controls" width="500" height="300"></video>

在 IoT 設備上，咱們的天貓 U 先業務在線下低性能的 IoT 設備上，Kraken 也有很是不錯的表現。在線下相對較複雜的 Slider 等場景下，動畫以及交互性能都表現較好，長時間運行應用，內存穩定並沒有明顯增加，保證線下 IoT 應用的穩定性。

社區協做機制

kraken 團隊指望經過一種良好的社區協做機制，來與社區的衆多開發者一塊兒共建 Kraken 底層能力及生態。

kraken 團隊指望經過協做者的方式來參與 Kraken 功能迭代以及 issue 討論等工做。同時，經過由一部分協做者組成的技術委員會（TSC）來肯定技術方向、發佈以及定製標準等工做。

kraken 團隊指望經過一種公平良好的協做機制，讓社區的開發者可以更好地參與到對 Web 標準的容器技術的演進中去，讓每一個人的聲音都能被聽到，共同促進 Kraken 以及行業的發展。

查看更詳細的協做機制能夠移步github。

將來展望

以往咱們在作前端性能優化的時候，每每優化到瀏覽器層面就優化不動了，很難向下進行進一步的優化。而 Kraken 的出現，給予了前端工程師新的機會與挑戰，它提供了前端工程師一個從新定義瀏覽器的能力的機會，擁有很是大的想象空間：

• 超越 Web 的能力，比肩 Native 的性能與體驗。
• 比瀏覽器廠商更快地實現標準，站在標準的前沿定義問題，經過實現的能力去反推標準，促進行業的發展。
• 能夠自頂向下看整個渲染鏈路的優化及體驗，經過全鏈路的手段去優化性能以及定義一些新的渲染能力。
• 目前日益複雜的前端應用致使 JS bundle 的已經顯得愈來愈臃腫，開發者也能夠把經常使用能力抽象複用並下沉到容器層面，渲染與公用能力的複用再也不只依賴於 NPM，能夠經過下沉通用能力來作更多事情。
• 經過「雲+端」的結合，也有機會去探索麪向將來的新一代渲染技術。
• 基於 Kraken，探索更多的可能性......

最後，指望 Kraken 能給你們帶來更好的體驗及能力，也但願你們能夠積極參與到 Kraken 項目中去，你們一塊兒共建 Kraken 生態。

官網：https://openkraken.com

Github：https://github.com/openkraken/kraken