Flutter提供了Flutter Module工程让原生开发者可以在原生工程中集成显示Flutter页面，但在实际多人开发场景中，Flutter工程师和iOS工程师分别负责属于他们技术领域的项目（当然个人开发者可以一个人负责iOS和flutter两个工程），如果仍然采用直接导入Flutter Module的方式，iOS工程师不仅需要配置flutter环境，还需要与flutter工程师统一版本，这显然不符合多人开发原则。所以我们需要提供一个包含了flutter环境的库，让iOS开发者可以直接集成flutter工程，而不需要配置flutter的环境。
生成flutter工程Framework
关于这个痛点，flutter也提供了工具生成Framework给iOS工程集成。
首先使用终端进入到已有的flutter module，执行命令
flutter build ios-framework --output=../flutter_framework
--output=../flutter_framework 是指定输出路径，可以将‘=’后面修改为其他目标路径
执行之后，在flutter_framework中会生成Debug、Profile、Release3个文件夹，分别对应Flutter的Debug、Release、Profile四种运行的模式的库。
关于flutter的四种模式解释，这四种模式在build的时候是完全独立的，他们分别有以下特征
Debug：Debug模式可以在真机和模拟器上运行，会打开所有的断言，包括debugging信息、debugger aids和服务拓展，优化了快速develop/run循环，但是没有优化执行速度，二进制大小和部署。我们常用的命令flutter run就是以这种模式运行的。
Release：只能在真机上运行，不能在模拟器上运行，会关闭所有断言和debugging信息，关闭所有debugger工具。优化了快速启动、快速执行和减小包体积。禁用所有debugging aids和服务扩展。这个模式是为了部署给最终的用户使用。
Profile：只能在真机上运行，基本和Release模式一直，是一种介于Debug和Release之间的模式，除了启用服务扩展和tracing，以及一些为了最低限度支持tracing运行的东西。
打开这3个文件夹的任何一个，可以看每一个模式都生成了App.framework和Flutter.framework两个库，其中Flutter.framework便是包含Flutter环境的框架，而App.framework是项目flutter模块的库。
接下来，便是将这两个库集成到iOS工程中。
将App.framework和Flutter.framework集成到iOS项目中
可以直接将App.framework和Flutter.framework两个库直接拉到项目中。
F6381981-D626-4F2C-8175-C6918582910D.png
然后记得在工程配置的General的Frameworks,Libraries and Embedded Content 设置中，将Embed修改为Embed & Sign。
B8B4D27B-DBAF-4DBB-BA3F-6BE6B47A87DB.png
编译通过后，可以测试拉起flutter页面。
#import "ViewController.h"
#import <Flutter/FlutterViewController.h>
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
}
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
FlutterViewController *flutterVC = [[FlutterViewController alloc] init];
[self presentViewController:flutterVC animated:YES completion:nil];
}
E93E8B8C-E458-40F5-AF09-A77C08F78898.png
通过cocoapods集成Flutter.framework
和App.framework不同，Flutter.framework除非版本升级是不会发生变化的，我们没必要每次生成flutter模块的库时都编译生成Flutter.framework，我们可以只编译flutter业务模块代码，而提供一个Podspec让iOS端通过cocoapods集成进项目中。
命令如下，同理output的路径可以更改。
flutter build ios-framework --cocoapods --output=../flutter_framework_cocoapods
执行完成后同样会在目标路径生成Debug、Profile和Release三个文件夹，但是内容不再是两个framework，而是一个App.framework和cocoapods的集成脚本Flutter.podspec,而不需要频繁变化的Flutter.framework则可以通过cocoapods自动集成到项目中。
而iOS远程工程的Podfile可以这么编写
target 'iOSMisFlutterPods' do
# Comment the next line if you don't want to use dynamic frameworks
use_frameworks!
# Pods for iOSMisFlutterPods
# podspec 路径根据实际情况
pod 'Flutter', :podspec => '../flutter_framework_cocoapods/Debug/Flutter.podspec'
end
执行pod install，Flutter.framework便通过cocoapods的方式集成到项目中，此时只需要导入App.framework即可。
当然，App.framework可以通过cocoapods的方式集成到项目中，这需要开发者自己编写集成脚本podspec文件，这里就不赘述，毕竟每个项目的flutter模块都不尽相同。
混合工程自动化
如果flutter工程师每次都要自己导出framework工程也是一个麻烦的过程，我们可以在自己的git服务器上添加一个脚本，但发生push操作时便会执行脚本，生成framework供原生工程集成。
示例如下：
name: FlutterCI #CI名称
on: [push] #触发条件push操作！
jobs:
check:
name: Test on ${{ matrix.os }}
#运行在哪个平台这里是MacOS平台
runs-on: macos-latest
steps:
- uses: actions/checkout@v1#固定写法
#三方flutter的Action，它可以在服务器配置一个Flutter环境
- uses: subosito/flutter-action@v1
with:
flutter-version: '1.17.1'
channel: 'stable'
#想让我们CI做的事情！
- run: cd flutter_model && flutter build ios-framework --cocoapods --output=../NativeDemo/Flutter #输出路径根据项目而定
- run: |
git add .
git commit -m 'update flutter framework'
- name: Push changes
uses: ad-m/github-push-action@master
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
网友评论