19年初，准备尝试 Flutter 实现部分业务页面，一个因为 Native 主工程已经较为庞大，一个因为目前只有少部分人投入 Flutter 的尝试，因此不可能重建一个 Flutter 工程来实现整个主工程，而且因为少部分人尝试，所以也不可能每个人都安装 Flutter 环境，所以，在 Native 工程中引入 Flutter 过程中，最好能像引入 其它第三方组件一样通过 pod 引入 Flutter，而其他非 Flutter 的业务开发人员无需安装 Flutter 环境来实现无痕的嵌入使用
接下来我们就关于 Native 工程中引入 Flutter 的一些做法进行简单说明
-
简单的实现
-
新建了一个 test_flutter 的 Flutter 工程，用来实现相关的 flutter 业务，它的目录结构如下
由 Flutter 目录分别包含两个平台的 Native 工程的目录组成，我们通过flutter build ios --release后可以查看到 ios 的 Flutter 目录下包含了一些构建运行后的产物：App.framework- dart代码生成Flutter.framework- 引擎flutter_assets- 相关资源
而这也正是 Navtive 工程引入 Flutter 需要的依赖，所以很容易想到那就只要把这些中间产物作为组件内容，并通过 pod 引入即可 新建一个 product_flutter 的中间产物模块，将 build 后的中间产物，包括 ios 目录内的一些原生代码（包含一些 channel 代码，混合栈的构建代码等）作为模块的组成，上传至 git 仓库
在前两步完成后，考虑到参与 Flutter 项目的人员可能 Flutter 环境不一致等情况，还有就是每次都需要手动 build 并更新上传至 product_flutter 仓库，所以借助 ci 完成部分手动工作，同时 ci Flutter 环境单一，可以确保打出来的中间产物环境一致
在 ci 创建 test_flutter 的任务，设定脚本每天在凌晨进行一次打包后自动上传中间产物至 product_flutter（也可手动去 ci 点击进行打包），整个脚本目前很简单，主要也就是
#...
export PATH=/usr/local/bin:$PATH
export PATH=$PATH:$HOME/XXX/flutter/bin
echo "flutter begin"
flutter packages get
echo "pod install or update"
cd ios
if [ ! -d "$PWD/Pods"]; then
pod install
else
pod update
fi
cd -
echo "flutter release -- "
flutter clean
flutter build ios --release
# 接下来其它操作也仅仅就是将产物拷贝打tag并上传
-
题外话
- 目前是通过
ci 实现定时任务，打包后自动上传中间产物，也可以通过git hook判断 test_flutter 提交的新代码，然后自动触发 ci test_flutter 打包
采取哪种方式或者打包频次根据自身需要即可 - flutter 打包在不同模式下的中间产物具有差异
a. debug 模式下有JIT支持（所以支持热重载 HotReload），App.framework 只有几个简单的API，其Dart代码生成标记化的源代码，运行时编译，解释执行，存在于 flutter_assets 的 kernel_blob.bin 文件里
b. release 模式下是AOT支持，App.framework 是所有的 dart 代码（业务代码，第三方 package 代码，及所依赖的 flutter 框架代码等等）编译所成，Flutter.framework 则是 Flutter 架构中的 engine 部分，flutter_assets 是图片，字体等相关资源
-
莫名其妙
也不懂为啥突然想在大年初一写这个，也没完全规划好，写的也很简单，不过本身远程依赖这一步并不复杂～～权当作新年开关好了～～ON 一下～～