1.2 混合工程改造实践

当使用Flutter 实现跨平台开发时，如果原有的iOS 和Android 工程已相当庞大，那么如何将Flutter 无缝地桥接到这些大工程中并保证开发效率不受影响是优先要解决的问题。

本文给出了一种通用的工程改造方案，希望为准备转型Flutter 的团队提供参考。

1.2.1 项目背景及问题

Flutter 的工程结构比较特殊，由Flutter 目录再分别包含Native 工程的目录（即iOS 和Android 两个目录）组成，如图1-12 所示。在默认情况下，引入Flutter 的Native 工程无法脱离父目录进行独立构建和运行，因为它会反向依赖于Flutter 相关的库和资源。

图1-12

很显然，在拥有了Native 工程的情况下，开发者不太可能去创建一个全新的Flutter 工程并重写整个产品，因此Flutter 工程将包含已有的Native工程，这样就带来了一系列问题。

1）构建打包问题：引入Flutter 后，Native 工程因对其有了依赖和耦合，从而无法独立编译和构建。在Flutter 环境下，工程的构建从Flutter的构建命令开始，执行过程中包含了Native 工程的构建，开发者要配置完整的Flutter 运行环境才能走通整个流程。

2）混合编译导致开发效率的降低：在向Flutter 转型的过程中必然有许多业务仍使用Native 进行开发，工程结构的改动会使开发过程无法在纯Native 环境下进行，而适配到Flutter 工程结构对纯Native 开发来说又会造成不必要的构建步骤，导致开发效率的降低。

1.2.2 改造目标

针对以上问题，我们提出了以下改造目标，力求使Native 工程对Flutter相关文件的依赖最小化。

Native 工程可以独立地编译构建和调试执行，进而最大限度地减少对相关开发人员的干扰，使打包平台不再依赖Flutter 环境及相关流程。

当Native 工程处在Flutter 环境中时（即作为iOS 或Android 子目录）能够正确依赖相关库和文件，正常执行各类Flutter 功能，如Dart 代码的构建、调试、热重载等，保证在Flutter 环境下开发的正确性。