Flutter远程组件最佳实践

  之前写了一篇 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本地引用依然如上一篇文字所示