十個可以手動編寫的 JavaScript 數組 API
JavaScript 中有很多API，使用得當，會很方便，省力不少。 你知道它的原理嗎? 今天這篇文章，我們將對它們進行一次小總結。現在開始吧。1.forEach()forEach()用于遍歷數組接收一參
在掘力計劃系列活動第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 中，可以被開發者同時使用：
Plain Text |
這其實帶來了很大的復雜性。首先，開發者需要自行理解不同模式的適用場景，進行正確的調用。
其次，隨著 Flutter 版本的演進，默認的模式也在變化。例如在早期只有 VD，到 1.2 提供 HC，3.0 又引入 TLHC。這意味著在版本升級后，你的混合視圖可能會在不知情的情況下發生渲染模式變化，導致問題。
再者，TLHC 存在對 SurfaceView 的兼容性問題。就算默認使用 TLHC，后續引入 SurfaceView 也可能觸發問題。
除此之外，不同模式的性能開銷也存在差異。HC 和 TLHC 的額外渲染消耗需要評估。模式切換也可能影響渲染性能。
綜上所述，困擾 Flutter Android 混合開發的主要問題在于：
這已經成為困擾 Flutter 混合渲染的主要困境。
開發者應對策略
面對復雜的混合渲染困境，Flutter 開發者也形成了一些應對策略：
當然，這需要開發者對不同混合渲染模式有足夠的理解，才能做出正確的技術選型。實際使用中也需要關注模式帶來的兼容性風險，建立健壯的自測方案。
未來 Flutter 混合渲染模式是否還會繼續增多也需要持續跟進。理想情況下，如果能夠演進出一個統一的混合解決方案，將大大簡化 Android 平臺的混合開發。
總結
Flutter 基于 Skia 的獨立渲染機制，給其在 Android 平臺的混合開發帶來了挑戰。經過幾年探索，Android 形成了多種混合渲染方案。但都無法完美解決問題，它們的共存也增加了復雜性。
開發者需要深入理解不同模式，并有針對性地進行場景選擇和風險評估。未來仍需要社區持續努力，簡化這一關鍵的技術難題，以進一步發揮 Flutter 的跨平臺優勢。
本文鏈接：http://www.www897cc.com/showinfo-26-80-0.html掘力計劃第 20 期：Flutter 混合開發的混亂之治
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 摸魚心法第一章——和配置文件說拜拜
下一篇： 2023 年的 Node.js 生態系統
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號