如何在现有Flutter应用中集成闭源Flutter模块？

首先明确：传统认知里add-to-app仅支持原生宿主的认知是有局限的，在模块为闭源、无法拆分Dart package的场景下，可按照改造成本从低到高选择以下落地路径：

双引擎隔离嵌入（Flutter 3.0+ 原生支持，改造成本最低） #

Flutter 3.0 版本后官方正式放开同一宿主应用内多Flutter引擎实例的创建限制，不需要依赖模块源码即可完成集成：

• 协调模块提供方按照标准add-to-app构建流程，输出可嵌入的原生产物：Android端执行flutter build aar生成AAR包，iOS端执行flutter build ios-framework生成Framework包，整个过程不需要暴露模块的Dart源码
• 将生成的闭源模块原生产物，按照主应用原有的原生依赖集成规则，添加到工程的对应位置：iOS端在Podfile中声明依赖，Android端在模块级build.gradle中添加maven依赖路径
• 集成时注意为闭源模块单独分配独立的FlutterEngine实例，不要复用主应用已经初始化的主引擎，直接将独立引擎的初始路由指向闭源模块的入口页面即可；跨引擎的页面通信可以通过原生层的MethodChannel做转发，完全不需要打通两层的Dart运行时
• 关键注意点：双独立引擎的内存开销会比单引擎架构高10%-15%，正式上线前需要做全链路的内存基准测试；如果闭源模块使用的Flutter SDK版本和主应用的版本差距超过两个大版本，会出现原生层符号冲突，需要提前协调模块提供方对齐版本

平台通道桥接封装（规避版本冲突的折中方案） #

如果不想处理多引擎直接集成带来的版本对齐问题，可以在原生层做一层薄的桥接封装，将闭源模块的所有能力对主应用Dart层完全透明：

• 依旧按照add-to-app流程拿到闭源模块的AAR/Framework产物
• 在主应用的原生侧编写桥接代码：代码负责闭源模块独立引擎的初始化、页面生命周期托管、事件透传，将模块的页面跳转入参、数据回传、事件通知全部通过主应用已经注册的MethodChannel、EventChannel和Dart层通信
• 主应用的Dart层完全感知不到下方是独立的Flutter运行时，只需要像调用普通原生能力一样，通过通道发起模块打开、参数传递、结果接收的操作，全程不需要接触闭源模块的Dart代码
• 该方案的核心优势是可以将闭源模块的编译依赖完全隔离在原生层，不会和主应用的Dart编译流程产生耦合，哪怕两边的Flutter SDK版本不一致，只要原生通道的交互逻辑对齐就可以正常运行

独立进程隔离（极端依赖冲突的兜底方案） #

如果闭源模块的原生依赖和主应用存在无法调和的冲突（比如原生库版本不兼容、混淆规则冲突、第三方SDK签名冲突），可以通过进程隔离的方式兜底：

• Android端将承载闭源模块页面的Activity通过android:process=":flutter_module"属性配置为独立进程运行，两个进程之间通过Binder跨进程通道做通信
• iOS端受系统机制限制没有轻量独立进程能力，遇到同等级冲突时，一般会协调模块提供方重新编译和主应用同Flutter版本的产物，回归到前两种集成流程
• 该方案的改造成本最高，会引入跨进程通信的额外开销，仅在前两种方案都无法解决冲突时才考虑使用

注意：直接将闭源模块的Dart中间产物（.dill文件）塞进主应用的Dart编译流程是没有落地可行性的，这种方式会因为Dart AOT编译的符号校验规则，触发重复符号错误导致打包失败。

内容的提问来源于stack exchange，提问作者Caio Coelho