之前写了一篇 Flutter远程依赖简单实践，比较初期的一些实践操作，虽能正常运行使用，但还是存在一些不便的问题，特别是 远程 plugins 的 pod 引用依赖了脚本，导致非 flutter 开发人员接入繁琐，为此进行了一些优化
flutter 的远程依赖我们希望达到的效果：
1. 根据环境自动切换产物依赖，即 Debug 及 Release 环境下无需重新 pod install 也无需手动切换
2. plugins 的依赖无需依靠脚本，看有哪些 plugins，同时不影响头文件引入代码的使用
鉴于以上两点主要诉求，对之前 Flutter远程依赖简单实践 进行了一些操作优化，主要是产物形式有些变化，这篇就只进行步骤的详情说明了
-
产物收集
产物收集主要涉及就是 工程开发的相关原生代码， Debug 及 Release 环境下的 App.framework、Flutter.framework、flutter开发工程里所有引用的plugin，即工程文件夹的.flutter-plugins文件中的所有plugin
产物收集过程很类似，其实就是分别 Debug 及 Release环境下进行 模拟器及真机编译 ，且解析 flutter-plugins 文件，对 plugin的pluginX.a进一步包装成 pluginX.framework（方便引用），然后收集所有相关的产物，并对 .podspec 文件的版本自动+1
因为过程基本一致，所以我们就说下 Debug 环境下的处理，Release 环境只有 build 指令不同而已
Debug 环境下的产物收集
1. Debug环境下进行编译
#分别进行真机编译及模拟器编译
#编译前先进行 clean
flutter clean
flutter build ios --debug --no-simulator
#Debug 模拟器编译
flutter clean
flutter build ios --debug --simulator
2. 分别收集不同的产物
#收集iOS平台相关源码，同时包括plugin注册文件
#target_source_dir iOS业务代码收集后目标地址，res_source_dir iOS业务代码flutter工程中的源码地址
if [ -d "$target_source_dir" ]; then
rm -rf $target_source_dir
fi
cp -rf $res_source_dir .
cp {$res_source_runner_dir/GeneratedPluginRegistrant.h,$res_source_runner_dir/GeneratedPluginRegistrant.m} $target_source_dir
#收集 Flutter.framework 及 App.framework 等，target_debug_dir 产物收集后目标地址，res_dir 产物生成的文件夹，即 flutter工程地址/ios/Flutter 这里
if [ -d "$target_debug_dir" ]; then
rm -rf $target_debug_dir
fi
mkdir -p $target_debug_dir
cp -R $res_dir/* $target_debug_dir
#收集 plugins 的 .a产物及
while read -r line
do
if [[ ! "$line" =~ ^// && ! "$line" =~ ^# ]]; then
array=(${line//=/ })
pluginName=${array[0]}
iosClasses=${array[1]}ios/Classes
if [ -d $iosClasses ]; then
plugin=$target_plugins/$pluginName
if [ ! -d $plugin ]; then
mkdir $plugin
fi
cp -R $res_plugins_build/$pluginName/lib${pluginName}.a $plugin/lib${pluginName}_${target_plagin_suffix}.a
fi
fi
done < $res_plugins
3. 合并 Debug 的真机及模拟器相关产物
#合并 App.framework
lipo -create $res_dir/App.framework/App $target_debug_dir/App.framework/App -output $target_debug_dir/App.framework/App
# 包装 pluagins 的 .a 产物为 .framework
mkdir -p $pluginName.framework/Versions/A/Headers
mkdir -p $pluginName.framework/Versions/A/Resources
# == 软链接
ln -s A $pluginName.framework/Versions/Current
ln -s Versions/Current/Headers $pluginName.framework/Headers
ln -s Versions/Current/Resources $pluginName.framework/Resources
ln -s Versions/Current/$pluginName $pluginName.framework/$pluginName
#== 合并
lipo -create \
$plugin/lib${pluginName}_debug_os.a \
$plugin/lib${pluginName}_debug_simulator.a \
-o $pluginName.framework/Versions/A/$pluginName
#== 收集头文件
for header in `find "$iosClasses" -name *.h`; do
cp -f $header $pluginName.framework/Versions/A/Headers/
done
4. .podspec 版本自动 +1
newVersion=$(echo ${lastVersion} | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{if(length($NF+1)>length($NF))$(NF-1)++; $NF=sprintf("%0*d", length($NF), ($NF+1)%(10^length($NF))); print}')
gsed -i "s/${line}/s.version='${newVersion}'/g" $podPath
Release 环境下的产物收集
Release 产物同 Debug 大同小异，只是编译命令的不同
flutter clean
flutter build ios --release --no-simulator
-
flutter远程引用
pod 'LYFlutter', :podspec => "http://.../LYFlutter.podspec"
pod 'Flutter_Debug', :podspec => "http://.../Flutter_Debug.podspec", :configurations => ['Debug']
pod 'Flutter_Release', :podspec => "http://.../Flutter_Release.podspec", :configurations => ['Release']
这是优化后的远程组件依赖，可能有更好的做法，目前对我们来说确是相对较便利的，完整的收集脚本👇这里
flutter本地引用依然如上一篇文字所示
网友评论