码上用它开始Flutter混合开发——FlutterBoost

为什么要混合方案

具有一定规模的App通常有一套成熟通用的基础库，尤其是阿里系App，一般需要依赖很多体系内的基础库。那么使用Flutter重新从头开发App的成本和风险都较高。所以在Native App进行渐进式迁移是Flutter技术在现有Native App进行应用的稳健型方式。

闲鱼在实践中沉淀出一套自己的混合技术方案。在此过程中，我们跟Google Flutter团队进行着密切的沟通，听取了官方的一些建议，同时也针对我们业务具体情况进行方案的选型以及具体的实现。

官方提出的混合方案

1基本原理

Flutter技术链主要由C++实现的Flutter Engine和Dart实现的Framework组成（其配套的编译和构建工具我们这里不参与讨论）。Flutter Engine负责线程管理，Dart VM状态管理和Dart代码加载等工作。而Dart代码所实现的Framework则是业务接触到的主要API，诸如Widget等概念就是在Dart层面Framework内容。

一个进程里面最多只会初始化一个Dart VM。然而一个进程可以有多个Flutter Engine，多个Engine实例共享同一个Dart VM。

我们来看具体实现，在iOS上面每初始化一个FlutterViewController就会有一个引擎随之初始化，也就意味着会有新的线程（理论上线程可以复用）去跑Dart代码。Android类似的Activity也会有类似的效果。如果你启动多个引擎实例，注意此时Dart VM依然是共享的，只是不同Engine实例加载的代码跑在各自独立的Isolate。

2官方建议

引擎深度共享

在混合方案方面，我们跟Google讨论了可能的一些方案。Flutter官方给出的建议是从长期来看，我们应该支持在同一个引擎支持多窗口绘制的能力，至少在逻辑上做到FlutterViewController是共享同一个引擎的资源的。换句话说，我们希望所有绘制窗口共享同一个主Isolate。

但官方给出的长期建议目前来说没有很好的支持。

多引擎模式

我们在混合方案中解决的主要问题是如何去处理交替出现的Flutter和Native页面。Google工程师给出了一个Keep It Simple的方案：对于连续的Flutter页面（Widget）只需要在当前FlutterViewController打开即可，对于间隔的Flutter页面我们初始化新的引擎。

例如，我们进行下面一组导航操作：

我们只需要在Flutter Page1和Flutter Page3创建不同的Flutter实例即可。

这个方案的好处就是简单易懂，逻辑清晰，但是也有潜在的问题。如果一个Native页面一个Flutter
页面一直交替进行