前言
因为工作需要，我开始在原生应用中引入 flutter 来实现一些通用的功能或者模块，但是官方文档提供的办法，使用起来，还是稍微有些麻烦的，幸好，我发现了一个叫 flutter_boost 的框架，帮助我打通了原生和 flutter，实现了一套统一的页面管理方案。
准确地说，flutter boost 是在 Native / Flutter 混合栈开发模式下，一套标准的使用流程，就算以后不想使用 flutter boost ，了解一下它的工作原理，也是很有必要的。
首先因为我对 android 的原生开发也不算很了解，所以我的解释以 iOS 为主，但是其实从容器的角度来抽象的话，原理是一样的，只是不同的原生平台，容器的实现方式不同而已。
开始
flutter boost 采用「单引擎、多 FlutterViewController 容器方案」，单个容器渲染单个页面，也即容器和页面一对一的关系，通过切换不同的容器来实现多页面支持。
具体来说，在 iOS 那一侧来看：
页面栈管理全部由 UINavigationController 管理， FlutterViewController 容器和普通的 UIViewContorller 没有任何区别，可以完全相容，对于 UINavigationController 而言是完全透明的。
页面切换时，通过通知 FlutterEngine attach 不同的 FlutterViewController 容器，从而实现多页面支持。
从 Flutter 侧的视角来看：
只需要接收来自 FlutterEngine 的通知，在容器切换时，渲染不同的 Flutter 页面即可，职责单一且简单。
BoostContainerManager 本身是一个 StatefulWidget ，当 Native 侧切换到不同的容器时，BootContainerManager 改变其子 Widget，从而实现与容器的同步。
当然你需要在 flutter 侧自己实现一套通用的抹平了平台差异的路由方案，flutter_boost 的实现是这样的：以 BoostContainerManager 为树根，然后接收 Native 消息，根据原生消息内容对这棵 Widget 树进行调整（增删改查），从而完成所定义的功能。
BoostContainerManager 派生自 StatefulWidget，在这棵 UI 树中，Overlay Widget 是最关键的 Widget。每当 Native 侧创建一个 FLBFlutterViewContainer 实例，Flutter 侧便对应创建一个 OverlayEntry ，并加入到 Overlay 的 _entries 中。因此 Native 侧的容器和 Flutter 侧的 OverlayEntry 是一一对应的。
具体的通信相关都是由 BoostChannel 来实现的，特别地，生命周期的变化，也是需要由原生通知给 flutter 的。
总结
FlutterBoost 的设计是基于 App 一次只有一个页面（ ViewController ）对用户可见的假设来设计的。在 Native 侧支撑的 Push 和 Present 都必须是全屏展示，以使得 ViewController 的相关生命周期能够正常调用，Flutter 侧其实也只有一个引擎和一个 Widget 占据整个屏幕，即使有多个容器时，也只能一个可见的 Widget 。这导致的问题是我们无法实现显示半屏的页面。关于这种情况，我觉得解决方案是不是从容器这个角度来支持这种能力，而是通过设计一个半屏的 Widget 来实现这种需求。
在初开发阶段，引入 flutter_boost 确实增加了开发效率，但是重度依赖这种第三方框架（尤其是它的维护团队还不是很给力的前提下），其实不是一个好主意，所以我想也许我们可以先了解一下它的实现逻辑，参考它的方案，在成熟的时候，自己实现一套适合自己的页面管理方案。