在上一篇中，我们已经完成了最小闭环：
Android 工程接入 Flutter Module，Application 中预热 FlutterEngine，并通过缓存引擎打开 Flutter 页面。

到这一步，很多项目已经“能跑了”。
但几乎所有真正上线的混合项目，都会在接下来几周内遇到同一批问题：

• Flutter 页面第一次快，后面越来越卡
• 内存持续上涨
• Flutter 页面偶发白屏
• 页面状态错乱、串页
• Flutter 页面关闭后资源不释放
• 多业务模块互相影响

这些问题，90% 都不是“Flutter 不稳定”，而是：

👉 引擎模型一开始就选错了。

这一篇，我们只讲一件事：
FlutterEngine 应该怎么管理，才是企业级正确姿势。

一、FlutterEngine 到底有多“重”？

很多人潜意识把 FlutterEngine 当成“一个工具类”，这是混合项目最大误解。

一个 FlutterEngine 内部至少包含：

• Dart VM（Isolate / GC / Heap）
• Flutter Framework Runtime
• Skia 渲染管线
• 纹理、字体、图片缓存
• Platform Channel 管理器
• 插件注册表
• IO / UI / GPU 多线程体系

你可以把 FlutterEngine 理解为：

👉 一套完整的小型 UI 子系统。

所以“多引擎”不是多 Activity，
而是：多个 Flutter 子系统同时存在。

二、两种模式的本质区别

模式 A：每个 Flutter 页面一个引擎（默认直觉）

特点：

• 每次打开 FlutterActivity → new FlutterEngine

• 用完即丢

表面看起来很干净，实际上带来：

• Dart VM 反复启动（慢）
• 内存不断抖动
• 插件重复初始化
• GPU 上下文频繁创建
• 大量短生命周期对象

这种模式只适合：
👉 Demo / 临时页 / 实验项目

模式 B：统一管理，引擎复用（企业级做法）

特点：

• Application 启动时创建引擎
• Dart 世界长期运行
• 所有 Flutter UI 共享同一套运行时

结果是：

• 首帧极快
• 内存稳定
• 插件只初始化一次
• Flutter 真正变成“系统子模块”

👉 这才是混合项目真正应该采用的模型。

三、为什么真实项目几乎都会走向“单引擎”

1️⃣ 性能决定的

多引擎 = 多 Dart VM + 多渲染体系
在移动端 / 设备端，这是极其昂贵的结构。

尤其在：

• 设备类 App
• 长时间运行 App
• FlutterView 嵌入式 UI
• 控制台 / 面板型系统

多引擎非常容易触发：

• OOM
• GPU 抖动
• 首帧雪崩
• 系统调度混乱

单引擎 = 一个 Flutter 子系统
这是唯一可长期稳定运行的形态。

2️⃣ 架构决定的

混合项目一旦发展，必然出现：

• 多 Flutter 页面
• 多业务模块
• FlutterView 嵌入
• Flutter ↔ 原生频繁通信

如果每个模块一个引擎，你很快会遇到：

• 数据怎么同步？
• 登录态怎么共享？
• 插件注册冲突
• 事件总线分裂
• Debug 极度困难

而单引擎天然具备：

• 全局状态中心
• 统一通信通道
• 可控生命周期
• 可治理架构

3️⃣ 官方路径决定的

Flutter 官方 Add-to-App 体系：

• FlutterEngineCache
• withCachedEngine
• engine attach / detach

从 API 设计本身就可以看出：

👉 官方预期模型就是：少量引擎，长期复用。

四、那为什么“单引擎”反而会出很多问题？

因为单引擎暴露了真实系统问题。

单引擎下：

• Flutter 会记住页面栈
• 会保留 Widget 状态
• 会保留全局单例

如果你只是：

👉 “attach 引擎 → 不管显示什么”

那你一定会遇到：

• 页面串了
• 上个模块的数据还在
• 返回键异常
• 嵌入 FlutterView 显示不对

这些不是单引擎的缺点，而是：

👉 你缺了一层“引擎调度与显示控制”。

五、企业级混合项目必备的一层：EngineManager

真实项目里，FlutterEngine 绝不应该散落在 Activity 中。

它必须被抽成：

👉 FlutterEngineManager（引擎中枢）

职责通常包括：

• 创建 / 预热引擎
• 管理缓存
• 提供统一获取入口
• 绑定 Application 生命周期
• 提供 reset / 重载 / 释放能力
• 注册全局通信桥

结构上类似：

Android Application
→ FlutterEngineManager
→ FlutterEngine
→ 所有 Flutter 页面 / View 共享

这是混合架构的“内核层”。

六、单引擎模型下，真正的控制点在哪？

不在引擎，而在 Flutter 层。

你必须引入一个概念：

👉 “显示调度 / 模块调度”

也就是：

• 原生每次使用 Flutter
• 必须明确告诉 Flutter：现在要显示什么

常见做法：

• route 控制（/pay /profile /panel）
• 模块标识控制
• 根组件状态切换

本质一句话：

👉 FlutterEngine 负责运行
👉 Flutter AppShell 负责调度
👉 业务模块只负责页面

七、从系统角度看混合架构的三层模型

企业级混合项目，通常会自然演化成三层：

1️⃣ 引擎层（运行时内核）

• FlutterEngine
• Dart VM
• 渲染系统
• 插件体系

关注点：
性能、稳定性、生命周期

2️⃣ 壳层（AppShell / 中控层）

• main()
• MaterialApp
• Navigator
• RouteDispatcher
• 全局状态中心
• NativeBridge

关注点：
调度、模块管理、通信、边界

3️⃣ 模块层（业务层）

• pay / profile / panel / marketing
• 只提供页面和能力
• 不控制引擎
• 不掌控全局

关注点：
业务、复用、独立开发

你会发现，这个结构和：

• Android Framework / Application / Feature
• Linux Kernel / System Service / App

在抽象层次上是高度一致的。

八、多引擎什么时候才成立？

说清楚边界，反而更利于你坚持单引擎。

多引擎真正成立的典型场景：

• 第三方 Flutter SDK（互不信任）
• 不同 Flutter App 产物必须并存
• 强隔离（状态 / 插件 / VM）
• 特殊计算型 Isolate 需求

但代价一定要清楚：

• 内存显著上升
• 生命周期管理复杂
• 通信通道成倍增加
• Debug 成本上升

👉 多引擎是“架构升级手段”，不是默认解。

下一篇：

Flutter 模块化架构设计：像 Android 组件化一样开发 Flutter