掘力計劃第 20 期：Flutter 混合開發的混亂之治

量子位的朋友們 2023-08-03 10:48:43 來源：量子位

在掘力計劃系列活動第20場，《Flutter 開發實戰詳解》作者，掘金優秀作者，Github GSY 系列目負責人戀貓的小郭分享了Flutter 混合開發的混亂之治。

Flutter 基于自研的 Skia 引擎實現了跨平臺高性能渲染，但其獨立的渲染層帶來了與 Android 混合開發的技術挑戰。經過幾年的演進，Android 目前提供了多種混合渲染方案，但都無法完美解決問題，且共存于 Flutter API 中，增加了復雜性。本文將深入解析 Flutter Android 混合開發面臨的困境，以及開發者應對策略。

Flutter 獨立的渲染機制

Flutter 能夠跨平臺高性能渲染的關鍵在于其自研的 Skia 圖形渲染引擎。Skia 通過自身的 renderers、GPU 線程等直接與 GPU 層進行交互，實現繪圖功能。這使得 Flutter 的渲染層可以獨立于 Android 的原生 UI 線程之外。

這種獨立的渲染機制給 Flutter 帶來很大優勢，不依賴原生視圖層即可實現高效的跨平臺渲染。但是同時也導致了 Flutter 要與原生視圖進行混合開發時的困難。

如果用一個簡單的類比，Flutter 更像是一個游戲引擎。想要往 Unity 這類游戲引擎中插入原生 Android 視圖，就像往 HTML 中直接嵌入一個 Canvas 元素一樣困難。這需要游戲引擎提供針對性的接口與機制，將不同的 UI 系統進行「適配」。

針對這個問題，Android 和 Flutter 社區也經歷了多年的探索，提供了一系列的混合渲染方案。

Android 混合渲染方案演進

Android 在支持 Flutter 混合開發時，經歷了多種技術方案的演進過程。現階段主要存在以下三種混合渲染技術：

VD 模式

VD 全稱 Virtual Display，表示利用虛擬顯示的方式進行混合渲染。其關鍵是采用 VirtualDisplay 將原生視圖渲染到一個內存緩沖區中，得到相應的渲染紋理。

Flutter 通過特定的 API 調用，可以獲取這個渲染紋理，并集成到自身的 Scene 中進行統一渲染。

VD 最大的 特點就是渲染的控件其實不是真實存在屏幕位置，而是在內存，所以容易有觸摸和鍵盤問題。

HC 模式

HC 全稱 Hybrid Composition。它的思路是直接將原生視圖通過 Add View 的方式添加到 Flutter 的 View 層次中，進行物理層面的視圖混合。

這種直接混合模式可以保存原生視圖的用戶交互，并且可與 Flutter 視圖自由疊加。但是由于需要跨線程同步渲染，可能會引入一定的性能開銷。

TLHC 模式

TLHC 即 Texture Layer Hybrid Composition。這是 Android 團隊後期提出的方案，試圖結合 VD 和 HC 兩種模式的優點。

TLHC 會通過 hook 原生視圖的 onDraw 方法，將其渲染輸出重定向到內存中，再提供給 Flutter 作為紋理。這樣既避免了線程同步，也可以像 HC 那樣自由布局。

但是 TLHC 不支持 SurfaceView 等基于獨立 Surface 的視圖類型。對于一些依賴 SurfaceView 的邏輯，如地圖或視頻播放，TLHC 存在兼容性問題。

共存的模式帶來的困境

經過幾年的演進，Flutter 現在已經可以通過上述三種模式支持 Android 混合開發了。但它們都存在自身的優劣勢，無法解決所有的問題場景。

更重要的是，這三種模式現在同時存在于 Flutter 的 API 中，可以被開發者同時使用：

這其實帶來了很大的復雜性。首先，開發者需要自行理解不同模式的適用場景，進行正確的調用。

其次，隨著 Flutter 版本的演進，默認的模式也在變化。例如在早期只有 VD，到 1.2 提供 HC，3.0 又引入 TLHC。這意味著在版本升級后，你的混合視圖可能會在不知情的情況下發生渲染模式變化，導致問題。

再者，TLHC 存在對 SurfaceView 的兼容性問題。就算默認使用 TLHC，后續引入 SurfaceView 也可能觸發問題。

除此之外，不同模式的性能開銷也存在差異。HC 和 TLHC 的額外渲染消耗需要評估。模式切換也可能影響渲染性能。

綜上所述，困擾 Flutter Android 混合開發的主要問題在于：

? 存在多種共存的渲染模式，各有特性，選擇復雜

? 模式之間兼容性存在，可能引入難以察覺的問題

? 性能開銷和穩定性難以保證

這已經成為困擾 Flutter 混合渲染的主要困境。

開發者應對策略

面對復雜的混合渲染困境，Flutter 開發者也形成了一些應對策略：

1. 優先使用 TLHC 模式，能覆蓋更多場景

2. 調用時詳細指定模式，不要依賴默認值

3. 注意版本變更帶來的潛在問題

4. 留意是否引入了 SurfaceView 等不兼容場景

5. 評估不同模式的性能開銷區別

6. 通過自身封裝控制模式變更范圍

7. 提前測試不同模式的兼容性

當然，這需要開發者對不同混合渲染模式有足夠的理解，才能做出正確的技術選型。實際使用中也需要關注模式帶來的兼容性風險，建立健壯的自測方案。

未來 Flutter 混合渲染模式是否還會繼續增多也需要持續跟進。理想情況下，如果能夠演進出一個統一的混合解決方案，將大大簡化 Android 平臺的混合開發。

總結

Flutter 基于 Skia 的獨立渲染機制，給其在 Android 平臺的混合開發帶來了挑戰。經過幾年探索，Android 形成了多種混合渲染方案。但都無法完美解決問題，它們的共存也增加了復雜性。

開發者需要深入理解不同模式，并有針對性地進行場景選擇和風險評估。未來仍需要社區持續努力，簡化這一關鍵的技術難題，以進一步發揮 Flutter 的跨平臺優勢。

關于掘力計劃

掘力計劃由稀土掘金技術社區發起，致力于打造一個高品質的技術分享和交流的系列品牌。聚集國內外頂尖的技術專家、開發者和實踐者，通過線下沙龍、閉門會、公開課等多種形式分享最前沿的技術動態。