Flutter 混合开发技术选型与 PlatformView 实践指南
在 Flutter 工程化建设中，混合开发一直是核心痛点之一。由于 Flutter 拥有独立的渲染引擎，其控件渲染脱离了原生平台的 Render Tree，这导致在混合开发场景下的实现复杂度显著增加。本文旨在深入探讨 Flutter 混合开发中的技术选型，重点分析 Android 平台下 PlatformView 的三种实现方案，并结合实际案例提供避坑指南。
一、混合开发的挑战与分类
在 Flutter 中，混合开发主要分为两类：
- 在 Flutter 里混合原生平台控件（使用
PlatformView） - 将 Flutter 混合到原生平台项目（使用
add-to-app）
本文聚焦于第一类，即如何在 Flutter 应用中嵌入原生 Android 控件。Android 平台在不同 Flutter 版本中出现了三种主要的 PlatformView 实现逻辑，理解它们的差异是选型的关键。
二、PlatformView 三大实现方案详解
1. VirtualDisplays
这是最早期的实现方式。它类似于创建一个虚拟显示区域，将内容渲染在一个内存 Surface 上，然后同步纹理到 Engine。实际上，控件并不在真实的渲染位置。
- 优点：兼容性好，支持低版本 SDK。
- 缺点：存在触摸事件和键盘输入问题，性能开销较大。
- 适用场景：列表项较少的小控件，或需要兼容旧版 SDK 的场景。
2. HybridComposition
通过 addView 直接添加原生平台控件，利用 FlutterImageView 承载 Flutter 控件进行堆叠。原生控件位于真实渲染位置。
- 优点：解决了手势和键盘问题，控件特性保留完整。
- 缺点：性能开销大，不适合高频滚动的列表场景，可能导致渲染线程不同步导致的闪动。
- 注意：Flutter 3.0 开始需显式调用
PlatformViewsService.initExpensiveAndroidView才能使用。
3. TextureLayer
在渲染位置通过原生的透明 PlatformViewWrapper 做容器，替换 Canvas 将原生控件的纹理渲染到特定 Surface 上。
- 优点：性能较好，默认推荐方案。
- 缺点：要求 Flutter Mini SDK API 23 以上；无法替代某些原生控件的 Canvas 场景（如
SurfaceView）。 - 适用场景：大多数现代 Android 设备上的常规视图。
三、版本演进与兼容性矩阵
Flutter 对 PlatformView 的支持经历了多次调整，以下是关键版本的兼容性说明：
| Flutter 版本 | 可用方案 | 备注 |
|---|---|---|
| < 1.2 | VirtualDisplays | 仅支持基础模式 |
| 1.2 - 3.0 |
