Flutter混合栈管理方案对比
1.Google官方（多引擎方案）
Google官方建议的方式是多引擎方案，即每次使用一个新的FlutterEngine来渲染Widget树，存在的主要问题是每个引擎都要有比较大的内存等资源消耗，虽然Flutter 2.0之后的FlutterEngineGroup通过在引擎间共享GPU 上下文、font metrics 和 isolate group snapshot，开销已大大降低，但是仍然没有解决每个FlutterEngine是一个单独isolate，不同FlutterEngine间的通信将会是非常麻烦的问题。
2.大名鼎鼎的闲鱼flutter_boost（单引擎方案）
Flutter Boost采用的是直接共享Flutter engine对象，在页面切换时， Flutter View与Flutter Engine进行attach与detach操作。Flutter boost早期版本Dart侧维护了一个Navigator栈的结构，基于栈的操作依赖对Flutter框架的一个属性修改，具有侵入性，并且由于pop出的页面就会销毁，在多个平级逻辑页面切换时，无法使其它flutter平级页面状态得到保持。最新版本主要变化是， 不再用栈式结构来管理Flutter页面， 改为在native侧和Flutter侧对所有页面都进行缓存。页面的创建与销毁与对应的native容器的生命周期保持一致。这一改变解决了侵入性问题，并且所有页面的状态都可以保持。
简言之， Flutter boost最新版本的核心逻辑是，页面导航的核心仍然由native进行驱动，根据native侧的页面生命周期事件，通过channel通知Flutter侧响应页面上屏等逻辑。 对于每个Flutter页面， 在native侧， 则都有一个FlutterViewContainer实例与之对应， 在dart侧则是一个BoostContainer实例，其缓由FlutterContainerManager进行管理，两者通过通信，保持生命周期一致。哪个页面需要显示，在native侧就是将对应的vc push进导航栈，同时将flutter引擎attach到对应的FlutterViewController。
但Flutter boost方案仍然存在一些问题：
（1）开源版本不够稳定， 适配Flutter新版本非常慢
（2）未完全剥离对阿里业务框架的依赖，里面包含很多与导航无关的代码依赖
3.哈喽单车团队的flutter_thrio（单引擎/多引擎均支持）
flutter_thiro是哈喽单车团队提供的一个解决方案，其与flutter_boost的主要不同是，flutter_boost的导航切换都是由native侧驱动，每次页面切换native侧都会创建一新的页面放到导航栈中，而flutter_thrio在native之间及native和flutter之间的页面切换同样由native侧驱动，但flutter页面内部的切换由flutter自带的Navigator来管理，native侧导航栈不创建对应的页面容器。这样做的好处是可以节省部分内存，但需要通过一层包装处理隔离这种导航实现方式上的差异，实现上会更复杂一些。
不过flutter_thrio整体封装相当不错，所有的页面切换逻辑非常统一，均采用基于url进行页面跳转。同时既支持单引擎工作模式，也支持多引擎工作模式，同时不存在对引擎代码的侵入式修改，不过该方案开源代码已经有两年多没有更新，如果遇到问题，可能需要自行维护。
4.字节跳动团队的Isolate复用方案和腾讯心悦团队的TRouter方案
这两个方案均未开源，从介绍来看都存在对flutter引擎的侵入式修改，比如今日头条的方案就是通过修改 Flutter Engine 源码，使多 FlutterView 实例对应的多 Flutter Engine 能够在底层共享 Isolate。即在上层看来有多个Flutter Engine 实例，但在底层只有一个唯一的Isolate，这样就可以在解决多引擎内存占用大的问题的同时，保持数据仍然可以在引擎间共享。这类侵入性比较强的方案存在的主要问题是，接入方案就需要接入相关的自定义flutter引擎代码，后续在可维护性上以及对flutter版本升级的兼容性上都存在较大不确定性。