Flutter技術解析與實戰——閑魚技術演進與創新-第1章（7）

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