Flutter工程化之iOS混编集成

混编过程中的问题

1. 由于笔者在搭建iOS项目过程中涉及了原本OC项目的迁移和通过Framework做了模块化分层，导致Podfile文件和主项目的.xcodeproj文件并不在同一层级，flutter的pod脚本存在路径引用不准确的问题，需要每次手动更改，这不太科学。
2. Flutter的插件在项目中失效的问题

集成过程

在flutter官网上推荐了iOS项目中两种混编方式：

1. 通过flutter tool中自带的脚本工具通过Cocoapods和Shell脚本去集成
2. flutter build ios-framework获取编译产物集成

笔者在采用两种集成方式的过程中，因为iOS项目结构设计导致这两种简单的集成方式都有些麻烦，所以在实践中更改和优化了集成方式，使之在笔者的项目中能够更加简单和快速的集成。

实际工程化中碰到的问题

iOS工程结构

1. 通过framework和workspace的方式去做了项目依赖的拆解
2. podfile和.workspace平级，.xcodeproj在深层

Flutter默认脚本添加的Script Phase

问题：在不更改flutter tool中相关脚本的前提下，添加的Script Phase中的脚本相对路径错误，如果只是开发，手动更改下路径就可以了，但是在考虑到CI中不能每次在pod install之后都去更改，所以在开发调试中采用该集成方式，结合flutter attach的方式去调试。

解决方式

通过编译相关的 xcframework + Cocoapods私有库的集成方式在CI中集成，这样QA的CI不需要配置flutter的相关依赖

1. 创建pod相关私有仓库
2. flutter build ios-framework 编译，将编译产物移到相关仓库：Engine、App和Plugins
3. iOS工程通过pods集成
4. CI通过pod install去集成和更新flutter模块

自动脚本化实现过程

iOS-Flutter混编的底层编译产物分析

# ios-framework   Produces .xcframeworks for a Flutter project and its plugins for integration into existing, plain Xcode projects.
flutter build ios-framework

根据flutter编译工具的提示： 上面的编译命令是打包flutter工程项目和插件的产物，在实际开发过程中可以发现是否引入了依赖Native的插件会导致贬义编译产物的不同。

未添加依赖原生插件

依赖了cached_network_image插件

根据上面的对比：

第一部分：基础的 Flutter Engine + Flutter App 编译后的产物 Flutter.xcframwork -- Flutter引擎的包 App.xcframework -- 工程项目对应的AOT的编译产物 第二部分：三方插件的注册中心 FlutterPluginRegistrant.xcframework -- 第三方插件的注册中心，其实是Native + iOS通信的集合 第三部分：依赖iOS Native的原生 FMDB.xcframwork path_provider_ios.xcframework sqflite.xcframework -- cached_network_image依赖的原生实现

根据上面的编译产物可以知道Flutter和App是编译后必有的包，后面的两个部分完全是服务于三方插件的，到这可以解答第二个问题：笔者App的混编过程中混编插件失效是因为笔者在NativeApp中重写了Flutter的容器，使用了FlutterEngineGroup动态创建多引擎去对应进入不同的功能模块，混合插件是因为重写过程中没有通过GeneratedPluginRegistrant注册插件，所以需要在Native的Flutter容器中注册插件，使之生效。

自动化混编思路

1. 将编译产物拆分成两个git私有仓库：

• flutter-engine-lib -- 存放Flutter.xcframwork ，其中包含了skia和dart virtual engine，因为在工程开发中Flutter会维持在稳定版本，所以这个私有仓库一般不需要变化

• flutter-libs: 包含下面在迭代过程中变化的编译包

  -- App.xcframework -- FlutterPluginRegistrant.xcframework -- 原生依赖Pod化后的依赖包

2. 在开发完成后编译iOS相关的frameworks，上传更新两个依赖库：

• 在不更新Flutter版本的时候，flutter-engine-lib一般不需要更新，主要是更新flutter-libs

3. 修改Native项目中的Podfile，添加两个私有仓库的依赖：

 # Flutter集成模块：Gitlab上的私有库只能内网拉取
 # Flutter Engine
 pod 'flutter-engine-lib', :git => 'http://xxx/xxx/flutter-engine-lib.git'
 # Flutter App + Plugin + Plugin loader
 pod 'flutter-lib', :git => 'http://xxx/xxx/flutter-libs.git', :commit=>'7b016680458fbcf9668d1dc6d851880dd69ce0c2'

在这为什么使用commit的hash作为flutter-libs的依赖，因为pod install的时候会有缓存，除了版本好，commit hash也能保证每次CI编译通过pod install来更新flutter-libs依赖产物

4. 脚本化完成上述过程：

#!/bin/bash

# project name
ios_project_name='flutter-libs'
# out path
ios_out_path='flutter-libs/frameworks'
# flutter lib git repo path
flutter_git_path='http://xxx/xxx/xxx/flutter-lib.git'

customEcho(){
  # echo -e "\E[1;32m""$1 \033[0m" 
  echo -e "\033[1;32m $1 \033[0m"
}

customEcho '\n0\. 请输入commit message'
read commit_message

customEcho '\n1\. 执行 flutter clean'
flutter clean || exit -1

customEcho '\n2\. 清空build文件夹'
rm -rf $ios_project_name
rm -rf build
echo '清空完成'

customEcho '\n3\. 生成 iOS frameworks'
flutter build ios-framework || exit -1 

customEcho "\n4\. 从 git 上克隆 frameworks 项目"
git clone $flutter_git_path  || exit -1 

customEcho "\n5\. 输出文件到 $ios_out_path"
rm -rf $ios_out_path
mkdir $ios_out_path

cp -r build/ios/framework/Release/App.xcframework $ios_out_path
# cp -r .ios/Flutter/App.framework $ios_out_path
echo 'App.xcframework搬运完成'

customEcho "\n6\. 提交文件到 git"
cd $ios_project_name
git add .
git commit -m $commit_message
git push -u origin master

customEcho "\n7\. 获取Flutter-lib仓库的commit-code"
commit_code=`git log  -1 | awk 'NR==1 { print substr($2,0) }'`

customEcho "\n8\. 删除该文件夹"
cd ..
rm -rf $ios_project_name

customEcho "\n9\. 粘贴下面的commit_code到Podfile中flutter-lib私有库的依赖提交号: "
echo -e "\033[1;31m $commit_code \033[0m" 

customEcho "\nAll Done."

完成！！！