Flutter 混合开发框架模式探索
内容提要
本文分析Flutter混合开发框架Flutter Boost与Thrio的架构及源码。官方方案仅支持单个Flutter View，缺乏路由传参、生命周期和路由栈管理，因此需借助第三方框架。Flutter Boost将每个Flutter页面包装为FlutterViewController，通过切换engine的viewController展示页面，路由统一交由Native管理，但频繁创建容器易导致内存泄漏。Thrio区分Native与Flutter页面，连续Flutter页面复用现有容器，内存占用更低，并支持多引擎模式。
延伸解读
Flutter Boost 的容器切换与内存隐患
Flutter Boost 将每个 Flutter 页面包装为独立的 FlutterViewController，并在容器 viewWillAppear 时通过切换 engine 的 viewController 来展示页面。这种实现直观简单，但频繁创建容器后，pop 掉的 FlutterViewController 内存并未被 engine 释放，文章指出这是 engine 的已知 bug，可能导致内存泄漏。读者需注意该方案在页面频繁跳转场景下的内存风险。
Thrio 的容器复用策略
与 Flutter Boost 不同，Thrio 在打开 Flutter 页面时先判断当前顶层容器是否为 FlutterViewController。若是，则直接复用现有容器，通过 Flutter 的 Navigator push 新页面，而非创建新容器。因此连续打开多个 Flutter 页面时，Thrio 的内存占用更低。这种区分 Native 与 Flutter 页面的设计，是两者架构上的关键差异。
多引擎模式的权衡
文章提到多引擎模式能带来隔离性，但每个引擎都是较重对象，启动约耗时 30ms、内存增加约 30MB，且各引擎独立维护图片缓存，会加大内存压力。同时多引擎会使通信层逻辑更复杂，需要设计好索引维护机制。Thrio 已支持多引擎模式，但其性能提升仍需进一步测试，读者应结合业务场景谨慎评估。
Q&A
为什么官方 Flutter 混合开发方案不够用，需要引入第三方框架？
官方方案仅支持打开一个 Flutter View，不支持路由间传参、统一的生命周期、路由栈管理等业务开发必要能力，因此需要第三方混合开发框架（如 Flutter Boost、Thrio）来整合。
Flutter Boost 是如何实现混合路由栈管理的？
Flutter Boost 将每个 Flutter 页面用 FlutterViewController 包装成多例，通过切换 engine 的 viewController 来展示页面，路由统一交由 Native 侧管理，Native 和 Flutter 打开页面最终都调用业务侧路由管理类的 open 方法。
Flutter Boost 频繁创建 FlutterViewController 会有什么问题？
频繁创建 FlutterViewController 并在 pop 后，这些内存不会被 engine 释放，导致内存泄漏，这是 engine 的 bug（issue 25255），至今未很好解决。
Thrio 和 Flutter Boost 在打开 Flutter 页面时有什么主要区别？
Thrio 会区分情况：如果当前最上层是 FlutterViewController 且 entrypoint 相同，则直接使用 Navigator push 新页面，复用现有容器；否则才创建新的 FlutterViewController。而 Flutter Boost 每次打开 Flutter 页面都会创建新的 FlutterViewController 容器。因此 Thrio 在连续打开 Flutter 页面时内存占用更低。
Thrio 如何判断一个路由是打开 Native 页面还是 Flutter 页面？
Thrio 根据路由名在 Native 侧注册的 map 中查找 builder，如果找到则创建 NativeViewController，打开 Native 页面；如果未找到，则视为 Flutter 页面，交由 Flutter 处理（可能 Flutter 侧也未注册）。
多引擎模式有什么优缺点？
优点：引擎间隔离。缺点：启动和运行消耗额外资源（每个引擎约30ms启动时间、30MB内存），每个引擎维护独立的图片缓存增加内存压力，通信层逻辑变复杂。可通过裁剪引擎优化资源。
