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

基於 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)。

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 上很好地完成渲染。

undefined

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

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

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

undefined

通過對接了 Chrome DevTools Protocol,使開發者可以直接使用非常熟悉的 Chrome DevTools 來調試所開發的頁面。無論開發者需要修改 CSS 樣式,還是查看 DOM 結構,或者是通過斷點調試 JavaScript 代碼,都能保證跟 Web 開發一致的調試體驗。

渲染一致性

Kraken 的渲染能力是對其 W3C 標準的,所以可以保證跟 Web 渲染的結果完全一致。

下圖是實際業務的截圖,從左到右分別是 Kraken(iOS),Kraken(Android)以及 Web 版本,可以看出渲染結果是完全一致的。

比 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 明顯下降。此外,在內存方面也有較大收益。

同步光柵化

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

增強的手勢能力

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 的穩定性。

undefined

業務落地

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

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

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

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

天貓 U 先

社區協作機制

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章