掘力方案第 20 期：Flutter 混合开发的混乱之治
回放链接：live./4354/jpower…
本场沙龙系列文章：
Topic1:掘力方案第 20 期：崔红保-跨端框架功能优化实践
Topic2:掘力方案第 20 期：Flutter 动态方案 Fair 原理与实践
Topic3:掘力方案第 20 期： Pake —— 运用 Rust 轻松构建跨端轻量级应用
在掘力方案系列活动第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 中，可以被开发者同时运用：
// VD形式
initAndroidVew()
// HC形式
initSurfaceAndroidView()
// TLHC形式
initAndroidView()
这其实带来了很大的杂乱性。首先，开发者需求自行了解不同形式的适用场景，进行正确的调用。
其次，跟着 Flutter 版别的演进，默许的形式也在改变。例如在前期只要 VD，到 1.2 供给 HC，3.0 又引进 TLHC。这意味着在版别晋级后，你的混合视图或许会在不知情的情况下发生烘托形式改变，导致问题。
再者，TLHC 存在对 SurfaceView 的兼容性问题。就算默许运用 TLHC，后续引进 SurfaceView 也或许触发问题。
除此之外，不同形式的功能开支也存在差异。HC 和 TLHC 的额外烘托消耗需求评价。形式切换也或许影响烘托功能。
综上所述，困扰 Flutter Android 混合开发的首要问题在于：
- 存在多种共存的烘托形式，各有特性，挑选杂乱
- 形式之间兼容性存在，或许引进难以察觉的问题
- 功能开支和稳定性难以保证
这现已成为困扰 Flutter 混合烘托的首要窘境。
开发者应对战略
面对杂乱的混合烘托窘境，Flutter 开发者也形成了一些应对战略：
- 优先运用 TLHC 形式，能掩盖更多场景
- 调用时详细指定形式，不要依靠默许值
- 留意版别改变带来的潜在问题
- 留意是否引进了 SurfaceView 等不兼容场景
- 评价不同形式的功能开支差异
- 经过本身封装操控形式改变范围
- 提前测试不同形式的兼容性
当然，这需求开发者对不同混合烘托形式有满足的了解，才能做出正确的技能选型。实际运用中也需求关注形式带来的兼容性危险，树立健壮的自测方案。
未来 Flutter 混合烘托形式是否还会继续增多也需求继续跟进。抱负情况下，假如可以演进出一个一致的混合解决方案，将大大简化 Android 渠道的混合开发。
总结
Flutter 基于 Skia 的独立烘托机制，给其在 Android 渠道的混合开发带来了应战。经过几年探究，Android 形成了多种混合烘托方案。但都无法完美解决问题，它们的共存也增加了杂乱性。
开发者需求深化了解不同形式，并有针对性地进行场景挑选和危险评价。未来仍需求社区继续尽力，简化这一要害的技能难题，以进一步发挥 Flutter 的跨渠道优势。
关于掘力方案
掘力方案由稀土技能社区建议，致力于打造一个高品质的技能共享和交流的系列品牌。集合国内外顶尖的技能专家、开发者和实践者，经过线下沙龙、闭门会、公开课等多种形式共享最前沿的技能动态。
