1、简述
对于构建Flutter类型应用，因其开发语言Dart、虚拟机、构建工具与平时咱们开发Native应用不一样且平台虚拟机也不支持，因此须要Flutter SDK来支持，如构建Android应用须要Android SDK同样，下载Flutter SDK一般有两种方式：android
- 在官网下载构建好的zip包，里面包含完整的Flutter基础Api，Dart VM，Dart SDK等
- 手动构建，Clone Flutter源码后，运行
flutter --packages get或其它具备检测类型的命令如build、doctor，这时会自动构建和下载Dart SDK以及Flutter引擎产物
在咱们微店App团队的多人协做开发下，这种依赖每一个开发本地下载Flutter SDK的方式，不能保证Flutter SDK的版本一致性与自动化管理，在开发时若是Flutter SDK版本不一致，每每会出现Dart层Api兼容性或Flutter虚拟机不一致等问题，由于每一个版本的Flutter都有各自对应的Flutter虚拟机，构建产物中会包含对应构建版本的虚拟机。Flutter工程的构建须要Flutter标准的工程结构目录和依赖于本地的Flutter环境，每一个对应Flutter工程都有对应的Flutter SDK路径，Android在local.properties中，IOS在Generated.xcconfig中，这个路径会在Native工程本地依赖Flutter工程构建时读取，并从中获取引擎、资源和编译构建Flutter工程，而调用flutter命令时构建Flutter工程则会获取当前flutter命令所在的Flutter SDK路径，并从中获取引擎、资源和编译构建Flutter工程，因此flutter命令构建环境与Flutter工程中平台子工程的环境变量必定得保持一致，且这个环境变量是随flutter执行动态改变的，团队多人协做下这个得保证，在打包Flutter工程的正式版每一个版本也应该有一个对应的Flutter构建版本，无论是本地打包仍是在打包平台打包。ios
咱们知道Flutter应用的工程结构都与Native应用工程结构不同，不一致地方主要是Native工程是做为Flutter工程子工程，外层经过Pub进行依赖管理，这样经过依赖下来的Flutter Plugin/Package代码便可与多平台共享，在打包时Native子工程只打包工程代码与Pub所依赖库的平台代码，Flutter工程则经过flutter_tools打包lib目录下以及Pub所依赖库的Dart代码。回到正题，因工程结构的差别，若是基于现有的Native工程想使用Flutter来开发其中一个功能模块，通常来讲混合开发至少得保证以下特色：git
- 对Native工程无侵入
- 对Native工程零耦合
- 不影响Native工程的开发流程与打包流程
- 易本地调试
显然改变工程结构的方案能够直接忽略，官方也提供了一种Flutter本地依赖到现有Native的方案，不过这种方案不加改变优化而直接依赖的话，则会直接影响了其它无Flutter环境的开发同窗的开发，影响开发流程，且打包平台也不支持这种依赖方式的打包。github
再讲讲Flutter SDK，平时进行Flutter开发过程当中，不免避免不了因Flutter SDK的Bug亦或是须要改Flutter SDK中平台连接的脚本代码致使直接改动或者定制Flutter SDK，这种方式虽然能够解决问题或定制化，不过极其不推荐，这种方式对后续Flutter SDK的平滑升级极不友好，且带来更多的后期维护成本。api
接下来，本文主要是介绍如何对上述问题解决与实现：xcode
- Flutter SDK版本一致性与自动化管理
- 无侵入Flutter SDK源码进行BugFix或定制化
- Flutter混合开发组件化架构
- Flutter混合开发工程化架构
2、Flutter四种工程类型
Flutter工程中，一般有如下几种工程类型，下面分别简单概述下： 1. Flutter Application 标准的Flutter App工程，包含标准的Dart层与Native平台层 2. Flutter Module Flutter组件工程，仅包含Dart层实现，Native平台层子工程为经过Flutter自动生成的隐藏工程 3. Flutter Plugin Flutter平台插件工程，包含Dart层与Native平台层的实现 4. Flutter Package Flutter纯Dart插件工程，仅包含Dart层的实现，每每定义一些公共Widgetruby
3、Flutter工程Pub依赖管理
Flutter工程之间的依赖管理是经过Pub来管理的，依赖的产物是直接源码依赖，这种依赖方式和IOS中的Pod有点像，均可以进行依赖库版本号的区间限定与Git远程依赖等，其中具体声明依赖是在pubspec.yaml文件中，其中的依赖编写是基于YAML语法，YAML是一个专门用来编写文件配置的语言，下面是一个经过Git地址远程依赖示例：bash
dependencies:
uuid:
git:
url: git://github.com/Daegalus/dart-uuid.git
ref: master
复制代码
声明依赖后，经过运行flutter packages get命名，会从远程或本地拉取对应的依赖，同时会生成pubspec.lock文件，这个文件和IOS中的Podfile.lock极其类似，会在本地锁定当前依赖的库以及对应版本号，只有当执行flutter packages upgrade时，这时才会更新，一样pubspec.lock文件也须要做为版本管理文件提交到Git中，而不该gitignore。架构
1. Pub依赖冲突处理
对于Pub和Pod这种依赖管理工具对于发生冲突时处理冲突的能力与Android的Gradle依赖管理相比差了一大截，因此当同一个库发生版本冲突时，只能咱们本身手动进行处理，并且随着开发规模的扩大，确定会出现传递依赖的库之间的冲突。app
Pub依赖冲突主要有两种：
- 当前依赖库的版本与当前的Dart SDK环境版本冲突
- 传递依赖时出现一个库版本不一致冲突
第一种会在flutter packages get时报错并提示为什么出现冲突且最低须要的版本是多少，以下：
The current Dart SDK version is 2.1.0-dev.5.0.flutter-a2eb050044.
Because flutter_app depends on xml >=0.1.0 <3.0.1 which requires SDK version <2.0.0, version solving failed.
pub get failed (1)
复制代码
这个能够直接根据提示进行依赖库的版本升级解决
而第二种则比较复杂点，假若有A、B、C三个库，A和B都依赖C库，若是A的某个版本依赖的C和B版本依赖的C版本不一致，则会发生冲突，而如何解决这种冲突呢？有两种方式
一、首先把A和B库的版本都设为any任意版本，以下：
dependencies:
A: any
B: any
复制代码
此时再经过flutter packages get时，则不会提示有版本冲突报错，由于Pub已经自动选取了让C库版本一致的A、B库的版本号，此时打开同级目录下的pubspec.lock文件，搜索A、B两个库，则会有对应无冲突的版本号，最后再把这两个版本号分别替换掉any版本，这个版本冲突就解决了
二、经过版本覆盖进行解决
2. Pub依赖版本覆盖
在Pub依赖管理中，既然支持传递依赖，一样也提供了一种版本覆盖的方式，意为强制指定一个版本，这和Android中Gradle的force有点类似，一样版本覆盖方式也能够用于解决冲突，若是知道某一个版本确定不会冲突，则可直接经过版本覆盖方式解决：
dependency_overrides:
A: 2.0.0
复制代码
4、Flutter连接到Native工程原理
官方提供了一种本地依赖到现有的Native工程方式，具体可看官方wiki：Flutter本地依赖，这种方式太依赖于本地环境和侵入Native工程会影响其它开发同窗，且打包平台不支持这种方式的打包，因此确定得基于这种方式进行优化改造，这个后面再说，先说说Native两端本地依赖的原理
1. Android
在Android中本地依赖方式为：
- 在
settings.gradle中注入include_flutter.groovy脚本- 在须要依赖的module中
build.gradle添加project(':flutter')依赖
对于Android的本地依赖，主要是由include_flutter.groovy和flutter.gradle这两个脚本负责Flutter的本地依赖和产物构建
1. include_flutter.groovy
在settings.gradle中注入时，分别绑定了当前执行Gradle的上下文环境与执行include_flutter.groovy脚本，该脚本只作了下面三件事：
- include FlutterModule中的
.android/Flutter工程- include FlutterModule中的
.flutter-plugins文件中包含的Flutter工程路径下的android module- 配置全部工程的
build.gradle配置执行阶段都依赖于:flutter工程，也即它最早执行配置阶段
其中.flutter-plugins文件，是根据当前依赖自动生成的，里面包含了当前Flutter工程所依赖（直接依赖和传递依赖）的Flutter子工程与绝对路径的K-V关系，子工程多是一个Flutter Plugin或者是一个Flutter Package，下面是.flutter-plugins中的一段内容示例： .flutter-plugins：
url_launcher=/Users/Sunzxyong/.pub-cache/hosted/pub.flutter-io.cn/url_launcher-4.0.2/
复制代码
2. flutter.gradle
该脚本位于Flutter SDK中，内容看起来很长，其实主要作了下面三件事：
- 选择符合对应架构的Flutter引擎（flutter.so）
- 解析上述
.flutter-plugins文件，把对应的android module添加到Native工程的依赖中（上述的include其实为这步作准备）- Hook mergeAssets/processResources Task，预先执行FlutterTask，调用
flutter命令编译Dart层代码构建出flutter_assets产物，并拷贝到assets目录下
有了上述三步，则直接在Native工程中运行构建便可自动构建Flutter工程中的代码并自动拷贝产物到Native中
2. IOS
在IOS中本地依赖方式为：
- 在Podfile中经过
eval binding特性注入podhelper.rb脚本，在pod install/update时会执行它- 在IOS构建阶段
Build Phases中注入构建时须要执行的xcode_backend.sh脚本
对于IOS的本地依赖，主要是由podhelper.rb和xcode_backend.sh这两个脚本负责Flutter的Pod本地依赖和产物构建
1. podhelper.rb
因Podfile是经过ruby语言写的，因此该脚本也是ruby脚本，该脚本在pod install/update时主要作了三件事：
- Pod本地依赖Flutter引擎（Flutter.framework）与Flutter插件注册表（FlutterPluginRegistrant）
- Pod本地源码依赖
.flutter-plugins文件中包含的Flutter工程路径下的ios工程- 在pod install执行完后
post_install中，获取当前target工程对象，导入Generated.xcconfig配置，这些配置都为环境变量配置，主要为构建阶段xcode_backend.sh脚本执行作准备
上述事情便可保证Flutter工程以及传递依赖的都经过pod本地依赖进Native工程了，接下来就是构建了
2. xcode_backend.sh
该Shell脚本位于Flutter SDK中，该脚本主要就作了两件事：
- 调用flutter命令编译构建出产物（App.framework、flutter_assets）
- 把产物（*.framework、flutter_assets）拷贝到对应XCode构建产物中，对应产物目录为：
$HOME/Library/Developer/Xcode/DerivedData/${AppName}
上述两个静态库*.framework是拷贝到${BUILT_PRODUCTS_DIR}"/"${PRODUCT_NAME}".app/Frameworks"目录下
flutter_assets拷贝到${BUILT_PRODUCTS_DIR}"/"${PRODUCT_NAME}".app"目录下
在XCode工程中，对应的是在${AppName}/Products/${AppName}.app
5、Flutter与Native通讯
Flutter与Native通讯有三种方式，这里只简单介绍下：
- MethodChannel：方法调用
- EventChannel：事件监听
- BasicMessageChannel：消息传递
Flutter与Native通讯都是双向通道，能够互相调用和消息传递
接下来是本文的重点内容，上述主要是普及下Flutter工程上比较重要的内容以及为下面要讲作准备，固然还有打包模式、构建流程等就不放这里了，后面能够单独开一篇讲
6、Flutter版本一致性与自动化管理
在团队多人协做开发模式下，Flutter SDK的版本一致性与自动化管理，这是个必须解决的问题，经过这个问题，咱们回看Android中Gradle的版本管理模式：
Gradle的版本管理是经过包装器模式，每一个Gradle项目都会对应一个Gradle构建版本，对应的Gradle版本在
gradle-wrapper.properties配置文件中进行配置，若是执行构建时本地没有当前工程中对应的Gradle版本，则会自动下载所需的Gradle版本，而执行构建则是经过./gradlew包装器模式进行执行，这样本地配置的全局Gradle环境与工程环境便可隔离开，对应的项目始终保持同一个Gradle版本的构建
这种包装器模式的版本管理方式，可与每台机器中全局配置的环境保持隔离，在团队多人协做下，也可保持同一个项目工程保持同一个构建版本
因此，咱们沿用Gradle版本管理思想，在每一个Flutter工程（包含上述说的四种工程）的根目录加入三个文件：
wrapper/flutter-wrapper.properties
flutterw
flutterw.bat
复制代码
加入后的项目结构则多了三个文件，以下：
上述flutter-wrapper.properties为当前工程Flutter SDK版本配置文件，内容为：
distributionUrl=https://github.com/flutter/flutter
flutterVersion=1.0.0
复制代码
固然有须要能够再增长一些配置，目前这两个配置已经足够了，指定了Flutter的远程地址以及版本号，若是Clone Github上项目比较慢，也能够改成私有维护的镜像地址
而flutterw为一个Shell脚本，内部对版本管理主要作的事情为：
- 读取配置的版本号，校验Flutter SDK版本，不存在则触发下载
- 更新Android中
local.properties和IOS中Generated.xcconfig文件中Flutter SDK地址- 最后把命令行传来的参数连接到Flutter SDK中的flutter进行执行
以后构建Flutter工程则用flutterw命令：
./flutterw build bundle
复制代码
而不用本地全局配置的flutter命令，避免每一个开发同窗版本不一致问题，且这种方式对于新加入Flutter开发的同窗来讲，彻底不须要本身手动下载Flutter SDK，只需执行一下flutterw任何命令，如./flutterw --version，便可自动触发对应Flutter SDK的下载与安装，实现优雅的自动化管理，这种方式对打包平台来讲也为支持Flutter工程的打包提供基础
7、Flutter混合开发组件化架构
上述说的若是咱们要利用Flutter来开发咱们现有Native工程中的一个模块或功能，确定得不能改变Native的工程结构以及不影响现有的开发流程，那么，以何种方式进行混合开发呢？ 前面说到Flutter的四种工程模型，Flutter App咱们能够直接忽略，由于这是一个开发全新的Flutter App工程，对于Flutter Module，官方提供的本地依赖即是使用Flutter Module依赖到Native App的，而对于Flutter工程来讲，构建Flutter工程必须得有个main.dart主入口，刚好Flutter Module中也有主入口
因而，咱们进行组件划分，经过Flutter Module做为全部经过Flutter实现的模块或功能的聚合入口，经过它进行Flutter层到Native层的双向关联。而Flutter开发代码写在哪里呢？固然能够直接写在Flutter Module中，这没问题，而若是后续开发了多个模块、组件，咱们的Dart代码总不可能所有写在Flutter Module中lib/吧，若是在lib/目录下再创建子目录进行模块区分，这不失为一种最简单的方式，不过这会带来一些问题，全部模块共用一个远程Git地址，首先在组件开发隔离上彻底耦合了，其次各个模块组件没有单独的版本号或Tag，且后续模块组件的增多，带来更多的测试回归成本
正确的组件化方式为一个组件有一个独立的远程Git地址管理，这样各个组件在发正式版时都有一个版本号和Tag，且在各个组件开发上彻底隔离，后续组件的增多不影响其它组件，某个组件新增需求而不需回归其它组件，带来更低的测试成本
前面提到Flutter Plugin能够有对应Dart层代码与平台层的实现，因此能够这样设计，一个组件对应一个Flutter Plugin，一个Flutter Plugin为一个完整的Flutter工程，有独立的Git地址，而这些组件之间不能互相依赖，保持零耦合，因此这些组件都在业务层，能够叫作业务组件，这些业务组件之间的通讯和公共服务能够再划分一层基础层，能够叫作基础组件，全部业务组件依赖基础层，而Flutter Module做为聚合层依赖于全部Flutter组件，这些Flutter工程之间的依赖正是经过Pub依赖进行管理的
因此，综合上述，总体的组件化架构能够设计为：
业务组件与基础组件的定位
对于上面的基础组件好比还能够进行更细粒度的划分，不过不建议划分太多，对于与Native平台层的通讯，每一个业务组件对应一个Channel，固然内部还能够进行更细粒度的Channel进行划分，这个Channel主要是负责Native层服务的提供，让Flutter层消费。而对于Native层调用Flutter层的Api，应该尽量少，须要调也只有出现一些值回调时
由于Flutter的出现最本质的就是一次开发两端运行，而若是有太多这种依赖于平台层的实现，反而出现违背了，最后只是UI写了一份而已。对于平台层的实现也要尽可能保持一个原则，即：
尽可能让Native平台层成为服务层，让Flutter层成为消费层调用Native层的服务，即Dart调用Native的Api，这样当两端开发人员编写好一致基础的服务接口后，Flutter的开发人员便可平滑使用和开发
而对于基础组件中的公共服务组件Dart Api层的设计，由于公共服务主要调用Native层的服务，在Flutter中提供公共的Dart Api，做为Native到Flutter的一个桥梁，对于Native的服务，会有颇有多种，而对应Api的设计为一个dart文件对应一个种类的服务，整个公共服务组件提供一个统一个对外暴露的Dart，内部的细粒度的Dart实现经过export导入，这种设计思想正是Flutter官方Api的设计，即统一对外暴露的Dart为common_service.dart：
library common_service;
export 'network_plugin.dart';
export 'messager_plugin.dart';
...
复制代码
而上层业务组件调用Api只须要import一个dart便可，这样对上层业务组件开发人员是透明的，上层不须要了解有哪些Api可用：
import 'package:common_service/common_service.dart';
复制代码
8、Flutter混合开发工程化架构
基本组件化的架构咱们搭建好了，接下来是如何让Flutter混合开发进行完整的工程化管理，咱们都知道，对于官方的本地依赖这种方式，咱们不能直接用，由于这会直接影响Native工程、开发流程与打包流程，因此咱们得基于官方这种依赖方式进行优化改造，因而咱们衍生出两种Flutter连接到Native工程的方式：
- 本地依赖（源码依赖）
- 远程依赖（产物依赖）
为何要有这两种方式，首先本地依赖对于打包平台不支持，现有打包平台的环境，只能支持标准的Gradle工程结构进行打包，且本地依赖对于无需开发Flutter相关业务的同窗来讲是灾难性的，因此便有了远程依赖，远程依赖直接依赖于打包好的Flutter产物，Android经过Gradle依赖，IOS经过Pod远程依赖，这样对其它业务开发同窗来讲是透明的，他们无需关心Flutter也不须要知道Flutter是否存在
对于这两种依赖模式的使用环境也各不同
1. 本地依赖 本地依赖主要用于须要进行Flutter开发的同窗，经过在对应Native工程中配置文件配置是否打开本地Flutter Module依赖，以及配置连接的本地Flutter Module地址，这样Native工程便可自动依赖到本地的Flutter工程，整个过程是无缝的，同时本地依赖是经过源码进行依赖的，也能够很方便的进行Debug调试 对于Android中配置文件为本地的local.properties，IOS中为本地新建的local.xcconfig，两个平台的配置属性保持一致：
FLUTTER_MODULE_LINK_ENABLE=true
FLUTTER_MODULE_LOCAL_LINK=/Users/Sunzxyong/FlutterProject/flutter_module
复制代码
2. 远程依赖 远程依赖是把Flutter Module的构成产物发布到远程，而后在Native工程中远程依赖，这种依赖方式是默认的依赖方式，这样对其它开发同窗来讲是透明的，不影响开发流程和打包平台
上述说到的两种依赖方式，接下来主要说怎么进行这两种依赖方式的工程化管理和定制化
1. 无侵入Flutter SDK源码进行BugFix和定制化
Flutter SDK在使用时，难免会遇到一些Flutter SDK的问题或Bug，但这些问题一般是在各平台层的连接脚本中出现坑，而若是咱们要兼容现有工程和扩展定制化功能，每每会直接修改Flutter SDK源码，这种侵入性的方式极不推荐，这对后续SDK的平滑升级会带来更多的成本
一般出现Bug或须要定制化的脚本每每是和平台连接时相关的，固然排除须要修改dart层Api代码的状况下，这种只能更改源码了，不过这种出bug的概率仍是比较小的，比较涉及到SDK的Api层面了。而大几率出现问题须要兼容或进行定制化的几个地方一般为下面几处：
$FLUTTER_SDK/packages/flutter_tools/gradle/flutter.gradle$FLUTTER_SDK/bin/cache/artifacts/engine/android-arch/flutter.jar$FLUTTER_MODULE/.android/build.gradle、.android/settings.gradle$FLUTTER_MODULE/.android/Flutter/build.gradle$FLUTTER_MODULE/.ios/Flutter/Generated.xcconfig$FLUTTER_MODULE/.ios/Flutter/podhelper.rb$FLUTTER_MODULE/.ios/Podfile$FLUTTER_SDK/packages/flutter_tools/bin/xcode_backend.sh
而咱们须要兼容的Flutter SDK的问题和定制化的点有下面几项：
- Android：Flutter SDK中的Flutter引擎不支持
armeabi架构- Android：Flutter SDK中的
flutter.gradle连接脚本不支持非app名称的Application工程- Android：Flutter SDK中的
flutter.gradle连接脚本本地依赖存在flutter_shared资源文件不拷贝Bug- Android：解决上述几项须要代理
build.gradle构建脚本，以及在build.gradle构建脚本中定制化咱们的构建产物收集Task- IOS：Flutter Module中自动生成的.ios中的
podhelper.rbruby脚本使用了Pod中的post_install方法，致使Native工程不能使用或使用了的发生冲突，间接侵入了Native工程与耦合，限制性太强- IOS：Flutter Module中自动生成的
Podfile文件，须要添加咱们本身私有的Specs仓库进行定制化- IOS：解决
post_install问题后，Flutter SDK中的xcode_backend.sh连接脚本环境变量的读取问题
为了实现无侵入Flutter SDK，对于上述的这些问题的解决，咱们使用代理方式进行Bug的修改和定制化，下面是针对两个平台分别的实现策略
1. Android
在Android平台上述问题和定制化的解决策略，对于armeabi架构的支持，咱们能够经过脚本进行自动化，上面讲到flutterw的版本自动化管理，一样，咱们在里面加段armeabi架构的支持脚本，这样作得好处是后续不须要支持了能够直接移除，经过调用./flutterw armeabi便可自动添加armeabi架构的引擎
对于Flutter SDK中的flutter.gradle连接脚本的问题兼容，不会直接在源码中进行更改，而是把它拷贝出来，命名为flutter_proxy.gradle，而后在代理脚本中进行问题的修复，主要修复点为flutter_shared的支持与app硬编码名称的兼容，以下：
Task copySharedFlutterAssetsTask = project.tasks.create(name: "copySharedFlutterAssets${variant.name.capitalize()}", type: Copy) {
from(project.zipTree(chosenFlutterJar))
include 'assets/flutter_shared/*'
into "src/${variant.name}"
}
复制代码
再让copyFlutterAssetsTask任务依赖于它，而app硬编码名称的兼容，则更简单了，经过在Native工程中local.properties配置Module名，再在flutter_proxy.gradle脚本中加入读取该属性代码：
String appName = loadRootProjectProperty(project, "FLUTTER_APP_NAME", "app")
Task mergeAssets = project.tasks.findByPath(":${appName}:merge${variant.name.capitalize()}Assets")
复制代码
而对于build.gradle构建脚本的代理，咱们能够经过在执行Gradle构建时，经过-c命令进行settings.gradle的代理，进而代理掉build.gradle和指定Module中的build.gradle脚本，以下：
cd .android
./gradlew assembleDebug -c ../script/proxy/settings.gradle
复制代码
而经过代理的settings.gradle文件再进行build.gradle的代理：
getRootProject().buildFileName = 'build_proxy.gradle'
project(":flutter").buildFileName = "build_proxy.gradle"
复制代码
其中代理的Flutter/build.gradle中的脚本apply会改成修复的Flutter SDK中的脚本代理：
apply from: "${project.projectDir.parentFile.parentFile.absolutePath}/script/proxy/flutter_proxy.gradle"
复制代码
这样.android工程在构建时期能够彻底由咱们自主控制，包括加入一些产物收集插件、产物发布到远程插件等定制功能
不过这种方式须要执行构建命令时手动指定代理脚本，对于本地依赖时Native自动构建来讲，是不会指定的，全部基于这种方式，咱们再优化一下，由于Flutter Module中.android与.ios工程是经过Flutter SDK内部模版自动生成的，只要执行build|packages get等命令都会自动生成，首先想到是更改Flutter SDK内部工程模版，在Flutter SDK的packages/flutter_tools/templates目录下，不过这与咱们无侵入Flutter SDK违背了，因此不能选取这种方式
回想咱们的Flutter SDK版本一致性管理是经过flutterw脚本进行自动化的，而最终会连接调用到原生Flutter SDK中的命令，因此，咱们能够在flutterw中加入脚本，用于在.android与.ios工程生成后，进行内部脚本文件的替换，把build.gradle和settings.gradle脚本内容直接替换为咱们的代理脚本的内容，这样既不侵入Flutter SDK，在后续维护起来也方便，后续不须要这个功能了，只须要把这段脚本代码注释就行了，随即又恢复原生的构建脚本了，flutterw脚本执行过程以下：
function main() {
# ...
link_flutter "$@"
inject_proxy_build_script
# ...
}
复制代码
inject_proxy_build_script这个Shell函数会把对应脚本进行咱们的脚本替换掉，当前函数内部也有对应判断，由于flutterw主要用于Flutter SDK版本一致性管理，这里仅对Flutter Module工程生效。因此这种方式无论是在本地依赖构建下仍是经过命令行构建均可以完美支持
2. IOS
在IOS平台上述问题和定制化的解决策略，对于IOS主要是对Podfile与podhelper.rb脚本进行支持，而对Podfile的支持，这个比较简单，在Podfile头部经过脚本注入咱们本身私有的Specs仓库便可：
source 'https://***/XXSpecs.git'
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
...
复制代码
这个工做一样在flutterw执行后进行兼容，后续不须要了能够直接注释，这个自动注入脚本也仅对Flutter Module工程生效
而podhelper.rb脚本的兼容，主要是在进行本地依赖时，内部已经用了post_install函数，该函是在pod install后执行，这会与Native已经使用了该函数的发生冲突并报错，因此咱们经过flutterw脚本的执行后默认注释掉该脚本中的post_install使用处，可是确定不能无缘无故注释掉，咱们要了解这段的做用，其实就是设置环境变量，为后续xcode_backend.sh脚本的构建执行作准备，而注释掉怎么用另一种方式恢复环境变量的设置这个后面再讲，注释后podhelper.rb脚本代码片断为：
# post_install do |installer|
# installer.pods_project.targets.each do |target|
# target.build_configurations.each do |config|
# config.build_settings['ENABLE_BITCODE'] = 'NO'
# xcconfig_path = config.base_configuration_reference.real_path
# File.open(xcconfig_path, 'a+') do |file|
# file.puts "#include \"#{File.realpath(File.join(framework_dir, 'Generated.xcconfig'))}\""
# end
# end
# end
# end
复制代码
最终在flutterw自动支持上述处理脚本执行流程为：
function main() {
# ...
link_flutter "$@"
# ...
podfile_support
podhelper_support
collect_ios_product "$@"
}
复制代码
函数内部判断仅针对Flutter Module工程生效，毕竟其它Flutter Plugin工程不须要这种处理
2. 本地依赖无侵入流程
咱们要作到只经过一个属性配置文件，在配置文件中经过配置开发来打开或关闭本地的Flutter Module连接依赖，只按官方的依赖方式确定是不行的，无论是Android仍是IOS，都会直接侵入Native工程，影响其它无Flutter环境同窗的开发且影响打包平台上的打包。因此，确定得作优化，咱们在官方这种依赖方式中加一层，做为代理层，而代理层主要作的工做是判断本地是否有对应的属性配置文件且属性值是否符合本地依赖Flutter Module的条件，若是是则进行本地Flutter Module的依赖，若是不是则Return掉，默认不作任何处理
因此经过这种代理方式即不影响Native工程原先的开发流程，对其它业务开发同窗和打包平台也是透明的
对于代理层的实现，Android与IOS平台各不同
1. Android
Android是经过一个Gradle脚本进行自动管理的，这个Gradle脚本主要在settings.gradle和build.gradle中作local.properties配置文件的属性值校验，决定是否开启本地Flutter Module连接的
2. IOS
IOS则较为复杂一些，由于涉及到Podfile中的ruby执行脚本代理与Build Phases时期的Shell脚本代理，因此得写两种类型的代理脚本：Ruby和Shell，代理脚本的最终执行仍是会调用被代理的脚本，只是在调用前作一层包装逻辑判断。而IOS中自己没有本地配置文件，因此咱们新建一个IOS的本地配置文件为local.xcconfig，这个配置文件不随版本进行管理，会gitignore掉，因而，在IOS中Podfile最终调用的脚本是：
eval(File.read(File.join('./', 'FlutterSupport', 'podhelper_proxy.rb')), binding)
复制代码
而在Build Phases调用的是：
chmod +x "${SRCROOT}/FlutterSupport/xcode_backend_proxy.sh"
"${SRCROOT}/FlutterSupport/xcode_backend_proxy.sh" flutterBuild
复制代码
而刚刚上面说到的podhelper.rb脚本中post_install函数被注释掉后怎么用另外一种方式进行替换，咱们知道这段函数主要就是提供在IOS构建阶段时执行xcode_backend.sh的环境变量的，好比会获取FLUTTER_ROOT等属性值，这些环境变量由Flutter Module中Generated.xcconfig来提供，而若是咱们把这个文件的内容经过脚本拷贝到IOS工程下对应构建配置的xcconfig中，如debug.xcconfig、release.xcconfig，这种方式可行，不过会侵入Native工程，致使Native工程中多了这些变量，并且不优雅，咱们要作到的是保证无侵入性
既然咱们已经经过代理脚本进行代理，那么这些环境变量咱们彻底能够获取出来，经过Shell脚本的特性，子Shell会继承于父Shell中export的环境变量值，因此，在代理Shell脚本中再加段下面代码：
function export_xcconfig() {
export ENABLE_BITCODE=NO
if [[ $# != 0 ]]; then
local g_xcconfig=$1/.ios/Flutter/Generated.xcconfig
if [[ -f "$g_xcconfig" ]]; then
# no piping.
while read -r line
do
if [[ ! "$line" =~ ^// ]]; then
export "$line"
fi
done < $g_xcconfig
fi
fi
}
复制代码
其中注意不能使用管道，管道会在另一个Shell进程
3. 远程依赖产物打包流程
Flutter的远程产物依赖，Android是经过Aar依赖，IOS是经过.a和.framework静态库进行依赖，要进行这些远程依赖很简单，关键是如何打包获取这些依赖的产物以及上传到远程，由于按照现有组件化的打包，除了聚合层Flutter Module中有对应的flutter-debug.aar和App.framework、flutter_assets等产物的生成，其中业务组件和基础组件中，也有对应的打包产物，这些打包产物会对应各自平台打包不一样类型产物，Android仍是aar，而IOS则是.a静态库了，下面就分别讲下Android与IOS的打包流程
1. Android
Android的打包比较简单，经过在Flutter Module中的.android子工程下执行./gradlew assembleRelease，则会在对应Flutter中Android子工程的build目录下输出对应aar产物，而重点是怎么获取依赖的各组件（Flutter Plugin）中的产物，则是经过.flutter-plugins文件，该文件是在packages get时自动生成的，里面包含了该Flutter工程经过Pub所依赖的库，咱们能够解析这个文件，来获取对应依赖库的产物
2. IOS
IOS上的打包相比Android来讲更复杂一些，咱们借助.ios/Runner来打包出静态库等产物，因此还须要设置签名，经过在Flutter Module中直接执行./flutterw build ios --release，该命令会自动执行pod install，因此咱们没必要再单独执行它，IOS中构建出的产物获取也相对繁琐些，除了获取Flutter的相关产物，还须要获取所依赖的各组件的静态库以及头文件，须要获取的产物以下：
Flutter.framework App.framework FlutterPluginRegistrant flutter_assets 全部依赖的Plugin的
.a静态库以及头文件
其中Flutter.framework为Flutter引擎，相似Android中的flutter.so，而App.framework则是Flutter中Dart编译后的产物（Debug模式下它仅为一个空壳，具体Dart代码在flutter_assets中，Release模式下为编译后的机器指令），FlutterPluginRegistrant是全部插件Channel的注册表，也是自动生成的，flutter_assets含字体等资源，剩下一些.a静态库则是各组件在IOS平台层的实现了
而收集IOS产物除了在.ios/Flutter目录下收集*.framework静态库和flutter_assets外，剩下的就是收集.a静态库以及对应的头文件了，而这些产物则是在构建Runner工程后，在Flutter Module下的
build/ios/$variant-iphoneos
复制代码
目录下，variant对应所构建变体名，咱们仍是经过解析.flutter-plugins文件，来获取对应所依赖Flutter插件的名称，进而在上述的输出目录下找到对应的.a静态库，可是对应的头文件而不在对应.a静态库目录下，因此对于头文件单独获取，由于解析了.flutter-plugins获取到了KV键值对，对应的V则是该Flutter插件工程地址，因此头文件咱们从里面获取
最后还须要获取FlutterPluginRegistrant注册表的静态库以及头文件
3. 产物收集与传递依赖
对于经过Flutter Module聚合层构建出来的产物，咱们进行收集后再聚合到单独的产物输出目录下，固然这一切都是经过脚本自动作掉的
在Android上，经过Gradle插件Hook assembleTask：
collectAarTask.dependsOn assembleTask
assembleTask.finalizedBy collectAarTask
复制代码
这样当执行完./gradlew assemble${variant}命令后则会自动进行产物收集
在IOS上，经过flutterw脚本，在构建完后判断构建命令是不是IOS构建命令，进而自动收集构建后的产物：
function collect_ios_product() {
if [[ $# != 0 && $# > 2 ]]; then
if [[ "$1" = "build" && "$2" = "ios" ]]; then
# do collect...
fi
fi
}
复制代码
对应.a静态库和头文件的收集关键脚本代码以下：
while read -r line
do
if [[ ! "$line" =~ ^// && ! "$line" =~ ^# ]]; then
array=(${line//=/ })
local library=$product_dir/${array[0]}/lib${array[0]}.a
if [[ -f "$library" ]]; then
local plugin=$dest_dir/plugins/${array[0]}
rm -rf $plugin
mkdir -p $plugin
cp -f $library $plugin
local classes=${array[1]}ios/Classes
for header in `find "$classes" -name *.h`; do
cp -f $header $plugin
done
else
echo "The static library $library do not exist!"
fi
fi
done < $flutter_plugins
复制代码
以下是Android与IOS的打包后产物收集后的目录结构以下：
对于传递依赖的支持，咱们知道单独的aar文件以及经过podspec声明这些静态库产物，是会丢失传递依赖的，丢失传递依赖可能致使咱们Native工程中没有使用到的一些三方库，而Flutter工程中引用了，而后App运行Crash，而保证传递依赖的方式，则是Android发布到远程Maven，最后经过远程依赖，上述产物只是本地依赖，IOS则是解析全部Flutter插件中的podspec文件，把它还原为JSON格式，经过解析dependencies对象，获取对应的依赖库命名以及版本号，最后在IOS远程产物的podspec配置文件中添加这些依赖
对于IOS的远程依赖，咱们知道单独建一个独立的Git仓库就能够解决，经过配置好podspec，便可在IOS Native端进行远程依赖，可是像Flutter.framework与App.framework这种大文件，若是直接上传到Git仓库中有些不太友好，好比能够上传到CDN中，而后经过podspec的spec.prepare_command特性，在pod库安装时候预先执行一段脚本把这两个产物拉下来，对于目前来讲，能够先传到Git中，这样比较直观与可控，便于版本的管理
4. Flutter混合开发工程化总体流程
9、后序
对于现有工程使用Flutter进行混合开发，坑点仍是有的，好比性能、页面栈管理等方面，只是目前还未踩到，加上目前Flutter上一些基础库不成熟，对于项目内的重要页面以及动态化强度比较高的页面，目前仍是不建议使用Flutter进行开发，若是要使用也须作好降级方案，相反可使用稍微轻量级点的页面，且在设计时对于Flutter与Native层的通讯，应该让Flutter做为消费层消费Native层提供的服务，Native端应作尽可能少的改动，最好仅增长一处页面路由的拦截器代码，在拦截器中经过Native与Flutter页面的映射关系，把Native的页面路由跳转替换为Flutter页面路由，这样能够保证Native与Flutter的零耦合
做者简介
zhengxiaoyong，@WeiDian，2016年加入微店，目前主要负责微店App的基础支撑开发工做。