1.3.3 iOS 依赖的Flutter 库的抽取
1．iOS 中的Flutter 依赖文件是如何产生的
执行编译命令“flutter build ios”，最终会执行Flutter 的编译脚本[xcode_backend.sh]，而这个脚本主要做了下面几件事：
获取各种参数，如project_path、target_path、build_mode 等，主要来自Generated.xcconfig 的各种定义。
删除Flutter 目录下的App.framework 和app.flx。
对比Flutter/Flutter.framework 与FLUTTER_ROOT/bin/cache/artifacts/engine {artifact_variant}目录下的Flutter.framework，若不相等，则用后者覆盖前者。
获取生成App.framework 命令所需参数， 包括build_dir 、local_engine_flag、preview_dart_2_flag 和aot_flags。
生成App.framework ， 并将生成的App.framework 和AppFrameworkInfo.plist 拷贝到Xcode 工程的Flutter 目录下。
2．iOS 的Flutter 依赖抽取实现
编译Flutter 工程，生成App.framework。
echo "===清理flutter 历史编译==="
./flutter/bin/flutter clean
echo "===重新生成plugin 索引==="
./flutter/bin/flutter packages get
echo "===生成App.framework 和flutter_assets==="
./flutter/bin/flutter build ios --release
将各插件打包为静态库。这里主要有两步：一是将插件打包成二进制库文件，二是将插件的注册入口打包成二进制库文件。
echo "===生成各个插件的二进制库文件==="
cd ios/Pods
#/usr/bin/env xcrun xcodebuild clean
#/usr/bin/env xcrun xcodebuild build -configuration Release
ARCHS='arm64 armv7' BUILD_AOT_ONLY=YES VERBOSE_SCRIPT_LOGGING=YES
-workspace Runner.xcworkspace -scheme Runner BUILD_DIR=../build/ios
-sdk iphoneos
for plugin_name in ${plugin_arr}
do
echo "生成lib${plugin_name}.a..."
/usr/bin/env xcrun xcodebuild build -configuration Release
ARCHS='arm64 armv7' -target ${plugin_name}
BUILD_DIR=../../build/ios -sdk iphoneos -quiet
/usr/bin/env xcrun xcodebuild build -configuration Debug
ARCHS='x86_64' -target ${plugin_name} BUILD_DIR=../../build/ios
-sdk iphonesimulator -quiet
echo "合并lib${plugin_name}.a..."
lipo -create
"../../build/ios/Debug-iphonesimulator/${plugin_name}/lib${plugin
_name}.a"
"../../build/ios/Release-iphoneos/${plugin_name}/lib${plugin_name
}.a" -o
"../../build/ios/Release-iphoneos/${plugin_name}/lib${plugin_name
}.a"
done
echo "===生成注册入口的二进制库文件==="
for reg_enter_name in "flutter_plugin_entrance"
"flutter_service_register"
do
echo "生成lib${reg_enter_name}.a..."
/usr/bin/env xcrun xcodebuild build -configuration Release
ARCHS='arm64 armv7' -target ${reg_enter_name}
BUILD_DIR=../../build/ios -sdk iphoneos
/usr/bin/env xcrun xcodebuild build -configuration Debug
ARCHS='x86_64' -target ${reg_enter_name} BUILD_DIR=../../build/ios
-sdk iphonesimulator
echo "合并lib${reg_enter_name}.a..."
lipo -create
"../../build/ios/Debug-iphonesimulator/${reg_enter_name}/lib${reg_
enter_name}.a"
"../../build/ios/Release-iphoneos/${reg_enter_name}/lib${reg_enter
_name}.a" -o
"../../build/ios/Release-iphoneos/${reg_enter_name}/lib${reg_enter
_name}.a"
done
将这些上传到远程仓库，并生成新的标签。对于纯Native 项目，只需要更新Pod 依赖即可。
1.3.4 Flutter 混合工程的持续集成流程
按上述方式，就可以解除Native 工程对Flutter 工程的直接依赖了，但是在日常开发中还存在一些其他问题：
- Flutter 工程更新，远程依赖库更新不及时。
- 版本集成时，容易忘记更新远程依赖库，导致版本没有集成最新的Flutter 功能。
- 多条线并行开发Flutter 时，版本管理混乱，容易出现远程库被覆盖的问题。
- 需要最少一名开发人员持续跟进发布，人工成本较高。
针对这些问题，闲鱼引入了CI 自动化框架，从两方面来解决：一方面是通过自动化降低人工成本，也减少人为失误；另一方面是用自动化的形式做好版本控制。
首先，在每次需要构建纯Native 工程之前，自动完成Flutter 工程对应的远程库的编译发布工作，整个过程不需要人工干预。其次，在开发测试阶段，采用五段式的版本号，最后一位自动递增产生，这样就可以保证测试阶段所有并行开发的Flutter 库的版本号不会产生冲突。最后，在发布阶段，采用三段式或四段式的版本号，可以和App 版本号保持一致，便于后续问题追溯。
整个流程如图1-18 所示。
图1-18
