iOS Flutter混编方案 之 双引擎模式

本文主要是对Flutter作为模块在iOS中的使用方案介绍
目录
一、FlutterViewController在iOS中的使用方式
二、开发方案
三、方案对比
四、结语

一、FlutterViewController在iOS中的使用方式

Flutter作为一种新的跨平台解决方案，由于其优秀的平台支撑能力，现已得到许多开发者的支持。
Flutter在iOS中的使用，主要是以FlutterViewController这个控制器作为载体，并在其内部采用FlutterEngine对视图进行渲染。
在创建FlutterViewController时,可以在外部传入，并手动开启。如果不传，FlutterViewController会在内部创建并启动FlutterEngine。如下：

//不采用engin初始化的方式
[[FlutterViewController alloc] initWithProject:nil nibName:nil bundle:nil];

//采用engin初始化的方式
FlutterEngine *flutterEngine = [[FlutterEngine alloc] initWithName:@"io.flutter" project:nil];
[flutterEngine runWithEntrypoint:nil];    //必须调用该方法运行engin，Flutter才会创建一个Isolate
[[FlutterViewController alloc] initWithEngine:self.flutterEngine nibName:nil bundle:nil];

采用上述方式初始化成功后，便可以在原生中像使用UIViewController一样的方式来使用FlutterViewController。
FlutterEngine管理Flutter运行过程中的插件channel通道。如下图：

flutterEngine.png

FlutterViewController的使用存在以上两种方式，它们之间的区别在于是否由外部管理FlutterEngine。

• 不采用engin初始化的方式

  如果外部不管理FlutterEngine，则每初始化一个FlutterViewController实例，其内部都会创建一个FlutterEngine，每一个FlutterEngine都会占用一定的内存空间。由于Flutter本身的缺陷，目前FlutterEngine在页面销毁时，内存是不会释放的。所以该方案只适用于整个App都采用Flutter开发的情况，并且Flutter内部页面采用Flutter路由跳转。

• 外部管理engin初始化的方式

  该方案采用外部管理FlutterEngine，即不管创建多少个FlutterViewController实例，都只使用一个FlutterEngine。所有的页面渲染都交由该FlutterEngine，并且FlutterPlugin插件通道同样也只对应一套。
  使用该方案的好处是能节省运行内存，并且多个页面之间可以使用原生的UINavigationViewController路由栈进行跳转。

二、开发方案

我最近开发的项目中就加入了Flutter模块的功能。在开发过程中，由于初期对Flutter的了解不足，所以也试过多种混编集成方案：

• 单engine截图方案
• 双engine方案

1、单engine截图方案

该方案核心原理如下图：

单engine截图方案

实现流程：

• 整个应用运行期间只有一个FlutterViewController实例，只有一个FlutterView视图，只有一个FlutterEngine。
• FlutterUI层使用IndexedStack视图用来控制显示不同的页面。
• 页面跳转：
  • 页面A跳转到页面B，页面A会先对当前页面进行截图并添加到view上，然后移除FlutterView；页面B通过通道告知FlutterEngine即将要显示的页面B路由地址，并且将FlutterView放到view上显示。
  • 页面B回到页面A，页面跳转动画过程中，页面B不对页面进行任何处理，页面A此时显示的是截图，页面B显示的为实际的FlutterView视图。动画结束后，页面A将FlutterView添加到view上，并移除截图，此时页面B已销毁。

优点：
1、单一FlutterEngine内存占用小
2、统一插件通道管理方便

缺点：
1、页面动态性不足：因为采用截图方式，所以页面在跳转期间有变动或更新，则截图移除时，会导致页面有一个闪烁变动的过程，非常影响体验
2、页面跳转有短暂延迟：页面截图必须要在新页面打开之前进行，而且截图会有短暂的耗时，体验明显。

单engine方案，页面A跳转到页面B

---

2、双engine方案

该方案核心原理如下图：

双engine方案

实现流程：

• 整个应用运行期间有两个FlutterViewController实例，有两个FlutterView视图，有两个FlutterEngine。（此方案由于有两个FlutterEngine，所以所有注册的插件通道，在不同的engine上都对应分别一一对应一份。比如：插件A有一个methodChannel, 则两个FlutterEngine上都有一个插件A的methodChannel）
• FlutterUI层同样IndexedStack视图用来控制显示不同的页面。
• 页面跳转（两个FlutterEngine是交替渲染页面的）：
  • 页面A跳转到页面B，页面A显示的是engine A的FlutterView，由于采用轮换方式，所以此时页面B的视图渲染即会采用engine B的FlutterView。因此页面跳转过程中，几乎不需要对页面进行其他多余操作。
  • 页面B回到页面A，页面跳转过程中，因为两个页面采用不同的engine，相互独立，所以只需在页面B销毁时，通过插件通道将engine B的FlutterView销毁即可。

优点：
1、页面跳转响应速度快：由于采用不同的engine交替渲染页面，页面跳转过程中无须对页面进行截图处理
2、支持页面的动态变化：每个显示在屏幕上的可见视图都是实际的FlutterView，页面的更新也是即时的。

缺点：
1、内存占用比单engine的方案大
2、插件管理相对复杂：两个FlutterEngine都有单独的插件通道，需要协调不同插件在不同FlutterEngine上的调用。

双engine方案，页面A跳转到页面B

三、方案对比

对比	优点	缺点
单engine截图方案	1、单一engine，节约内存 2、插件管理统一	1、页面跳转容易出现闪动 2、页面截图会延迟页面的跳转 3、页面跳转期间不支持动态变化
双engine方案	1、页面影响速度快，体验好 2、页面跳转期间支持动态变化	1、内存占用大 2、插件管理相对复杂

综合比较两者，目前当前项目中使用的是双engine方案。
因为此方案页面体验效果非常好，页面跳转在release模式下和原生页面渲染速度几乎没有差别。
关于插件管理，在多engine的方式下，目前处理为所有插件通道的采用通道消息类处理。

• Flutter给原生发送消息：每一个页面在创建时都有生成一个唯一的key作为页面标识，并且每个页面都会创建接收Flutter消息的接收者。Flutter发送的消息默认会优先给正在显示的页面，也可以通过页面标识key给指定的页面发送消息。
• 原生给Flutter发送消息：原生的消息管理器会通过页面的唯一key找到渲染该页面的FlutterEngine，并将消息发送给此FlutterEngine。

四、结语

以上为使用Flutter过程中遇到问题的解决方案，目前已经双engine方案在公司项目中运用。
单engine截图方案为网上搜索的解决方案，暂时找不到当初参考的链接了（尴尬）。
双engine方案目前仅记录实现思路，代码部分暂未完全抽离独立出来。
项目目前为内测版本，以下是Flutter在release环境下的实现效果演示：

运行效果演示

实际运行效果还是很流畅的，转为gif后丢帧太严重了😂