在之前的《Flutter Web 的未來，Wasm Native 即將到來》 中我們知道，F(xiàn)lutter 通過推進 WasmGC 的落地來支持 Dart Native ，從而讓 Flutter Web 在瀏覽器上實現(xiàn)原生的 Wasm Native 的支持， 這也是 Flutter Web 最終決定的技術(shù)路線，也就是 CanvasKit 才是Flutter Web 的未來 。
因為將 Flutter Widget 轉(zhuǎn)化為 Html 標(biāo)簽渲染的方式，其實本質(zhì)上違背了 Flutter Engine 的跨平臺方式。
在這個基礎(chǔ)上，官方認為與基于 WebGL 的 CanvasKit 和 Skwasm 渲染器相比，HTML 渲染器復(fù)雜、性能表現(xiàn)不佳且圖形表現(xiàn)力有限等原因，同時 CanvasKit 渲染器又即將引來突破性的更新，而未來 Html renderer 能提供的價值遠低于維護成本和開發(fā)人員面臨的復(fù)雜性，畢竟在多個渲染器之間進行兼容和解決問題的成本太高，所以官方提議棄用并刪除 Flutter Web 的 Html renderer。
在歷史問題上，Html renderer 經(jīng)常會出現(xiàn)渲染效果和其他平臺不一致的問題，因為 HTML renderer 必須通過 HTML 的方式去模擬其他平臺的某些功能，如漸變、文本布局、像素著色器等，而這些適配十分占用開發(fā)資源，并且效果也存在微妙的差異。
為什么要移除 Html renderer
事實上 Html renderer 是從 2018 年開始作為 Flutter Web 的第一個渲染器，HTML renderer 其實是 HTML、CSS、Canvas 2D、SVG 和 WebGL 的組合產(chǎn)品，在早期它也具備了一些優(yōu)勢：
- Size 更小，加載更快，并且可以通過deferred-components 的方式進行懶加載拆包 。
- PlatformView 的支持零成本，因為支持介入更多的 “HTML” 而已，在 HTML 中嵌套 HTML 很簡單。
- 支持 CORS 圖像 ，因為是基于
<img>標(biāo)簽實現(xiàn)，但是這對于 Flutter 而言有好有壞，因為 Flutter 沒有處理圖像的像素，所以和其他平臺相比，無法控制幀和應(yīng)用一些像素效果 - HTML 可以更輕松訪問本地字體，無需從網(wǎng)絡(luò)獲取字體，這對比 WebGL 是一個比較大的優(yōu)勢，目前從長遠來看，W3C 提案例如[canvas-formatted-text](https://github.com/WICG/canvas-formatted-text) 理論可以徹底解決這個問題。
那既然有這么多優(yōu)勢，為什么還要移除？
前面提到過，由于 Flutter 一直以來都是以 Canvas 為基準通過 Engine 來實現(xiàn)跨平臺，并且保證不同平臺上的控件得到一致的渲染效果，而 Html renderer 的渲染方式明顯違背了初衷，在兼容適配的過程中產(chǎn)生了許多額多的開發(fā)成本。
其次，將 HTML、CSS、Canvas 2D、SVG 和 WebGL 組合到單個渲染器中并不容易，對于 Flutter 本身的 API ，他喪失了很多原本應(yīng)該具備的能力，比如：
- Path.combine
- drawAtlas, drawRawAtlas
- dilate, erode, compose image filters
- conic path segments
- linearToSrgbGamma, srgbToLinearGamma color filters
- saveLayer
- FragmentProgram, FragmentShader
- strokeMiterLimit
- Paint.imageFilter
- Scene.toImage, Scene.toImageSync
- Image features that require access to pixel data
而有些功能雖然有實現(xiàn)，但它們的實現(xiàn)存在著性能缺陷，例如：
- BlendMode
- Gradient
- drawVertices
- drawPoints
- drawPicture
- Picture.toImage
- MaskFilter.blur (throws in Safari)
由于 HTML renderer 無法支持 Flutter 的 API，這就會讓 Framework 、 Plugin 和 App 需要在開發(fā)時兼容和維護一些特殊的代碼如 kIsWeb 檢查。
最后，F(xiàn)lutter 團隊需要對 HTML 特定問題進行分類，它還使非 HTML 問題的分類變得更加復(fù)雜，因為處理問題的第一步經(jīng)常需要區(qū)分是哪個渲染器受到影響。
當(dāng)然，在此之前社區(qū)對于 HTML renderer 還存在一些誤解，例如：
- HTML 支持 Accessibility：事實上，F(xiàn)lutter 得 Semantic DOM 設(shè)計完全支持 Flutter 的輔助功能，對于全部渲染器 CanvasKit、Skwasm 和 HTML 都是一樣可以適配支持無障礙能力。
- 它提供 SEO：與 Accessibility 一樣，渲染樹不適合作為 SEO 的來源，因為它不以邏輯方式呈現(xiàn)內(nèi)容，爬蟲最多只能看到一些使用 HTML 或 SVG 繪制的文本片段，但最終出現(xiàn)在 2D 畫布中的文本對于爬蟲來說是不可見的，所以目前 Flutter 官方也正在研究使用語義樹作為 SEO 數(shù)據(jù)的來源。
新的 CanvasKit
在此之前， CanvasKit 最飽受爭議的就是它的大小和加載速度，最初引入 CanvasKit 時，F(xiàn)lutter 需要 3.2MB 的額外負載才能渲染第一幀，并且很多移動端設(shè)備并不支持 WebGL 2。
例如有人提到了，他們的網(wǎng)站是使用 CanvasKit 構(gòu)建，而在跟蹤用戶流失情況是發(fā)現(xiàn) 33% 的潛在客戶在加載應(yīng)用是離開，這三個罪魁禍首似乎是 dart.main.js 1.6mb、canvaskit.wasm 1.5mb 以及啟動 Engine 所需的時間：
而現(xiàn)在在經(jīng)過多次優(yōu)化和時間沉淀后：
-
CanvasKit的大小已經(jīng)縮小到 1.5MB，新的渲染器 Skwasm 還可以其進一步縮小到 1MB 左右 -
WebGL 2.0 在每個主要瀏覽器中[至少支持3個版本](https://caniuse.com/?search=WebGL 2.0)
-
新的 Web API 可提高基于 WebGL 的渲染效率，包括：
- 支持 WebCodecs（特別是 ImageDecoder）
- SharedArrayBuffer，啟用共享內(nèi)存多線程
- WasmGC
預(yù)計在 10 mbps 網(wǎng)速下，啟動開銷為 0.8 秒，并且由于
CanvasKit是可緩存資源，因此它可以在開始時與其他資源并行加載，實踐使用中的開銷可以小于 0.8 秒。
而在新的 CanvasKit 下，F(xiàn)lutter 正在推動進一步的優(yōu)化支持，例如：
-
可以在獲取靜態(tài)資源時支持并行加載，在獲取
canvaskit.wasm的同時同步獲取數(shù)據(jù)main.dart.js -
Bootstrap API 支持在后臺加載 Flutter 時為應(yīng)用創(chuàng)建純 HTML 登錄頁面，當(dāng)用戶完成與登陸頁面的交互時，大部分 Flutter Web loading 已經(jīng)完成
-
iOS 中的大部分緩慢都是由于缺乏
ImageDecoderAPI，因此目前還需要找到比當(dāng)前單線程 wasm 編解碼器解決方案更好的圖像解碼器。
當(dāng)然，對于 CanvasKit 來說，目前還需要推進的問題還有：
- CORS 圖像
- 更好的 PlatformView
- iOS （即 Safari/WebKit）適配
而對于 CanvasKit 來說，無法解決的問題就是不支持沒有 GPU 的硬件，因為對于 Flutter 來說，GPU 是至關(guān)重要的一環(huán)，特別未來對于 Impeller 的支持上。
最后
其實 Flutter web一直是 Flutter 里的另類而有特殊的存在，F(xiàn)lutter 來源于前端 Chrome 團隊，起初 Flutter 的創(chuàng)始人和整個團隊幾乎都是來自 Web，但是由于前期技術(shù)局限的原因，為了適配 Web，F(xiàn)lutter Web 成了 Flutter 所有平臺里“最另類又奇葩”的落地。
而如今官方在明確了以
CanvasKit和 Wasm Native 為核心路線的情況下看，Html Renderer 退出歷史舞臺是必然的趨勢，而差別就在于它的過渡期需要多久？
目前看來 CanvasKit 還有諸多這樣那樣的不足，例如原生層面還不支持 SVG ，需要通過 flutter_svg 來做支持，對于 Web 來說其實支持 SVG 應(yīng)該是一件“非常簡單”的事情。
另外例如 CanvasKit 還有一些比較邊緣的兼容問題，例如這個頁面是采用 wasm 渲染的 Flutter Web 頁面，但是當(dāng)我們用插件翻譯頁面內(nèi)容時，可以看到只有標(biāo)題被翻譯了，主體內(nèi)容并沒有，因為此時 Flutter Web 的主體內(nèi)容都是 Canvas 繪制，沒有 html 內(nèi)容，所以無法被識別翻譯，另外如果你保存或者打印網(wǎng)頁，也是輸出不了完整 body 內(nèi)容。
所以目前來看，CanvasKit 還是有許多需要打磨的地方，不過不可否認的是，它正在變得更好。
那么，你支持這次移除并啟用 Html renderer 的提議嗎？文章來源：http://www.zghlxwxcb.cn/news/detail-845383.html
更多可見：https://github.com/flutter/flutter/issues/145954文章來源地址http://www.zghlxwxcb.cn/news/detail-845383.html
到了這里，關(guān)于Flutter 即將放棄 Html renderer ，你是否支持這個提議？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
