Flutter与iOS原生的混合工程

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 }}