背景
此篇文章, 主要针对想要在原有 Native 工程的基础上集成 Flutter 的需求, 所提供的混编方案的探讨.
官方方案的优缺点
(1) 优点:
不需要每次 Run 起来之后, 先进行 同步 flutter 代码 (组件化 Flutter 后, 因为组件化后 flutter 代码已经变为 framework, 所以每次进来需要先热更新同步代码)
不需要单独搞一个组件进行集成, 管理组件的版本, 发布等.
(2) 缺点:
会非常耦合工程, 需要修改工程配置, 添加 BUILD PHASE 调用 flutter 中 xcode_backend.sh 脚本 去编译 Flutter.
如果使用 pod 管理, 那么还需修改 xcconfig 配置.
因为需要调用 Flutter 的编译脚本, 所以这种方式集成后, 团队内所有组员电脑和打包机, 都必须安装 Flutter 环境才能编译成功.
Flutter 组件化混编方案
(1) 优点:
不需修改 原有 xcconfig 配置.
不需要添加 Run Script 脚本.
运行不需要依赖 Flutter 环境.
(2) 缺点
需要单独管理一个 flutter 私有索引库.
开发加载 Flutter 页面 首次需要热更新 进行刷新同步 Flutter 代码.
(3) 混编方案 实现核心思想
通过查看 Flutter 编译脚本 xcode_backend.sh 和 测试单独引入编译产物, 发现其实 只要拥有 Flutter 的编译产物, 项目就可以接入 Flutter 的功能.
所以说只要把 Flutter 编译好的产物, 放在工程里, 那么就无需配置每次调用 xcode_backend.sh 脚本, 也无需强耦合 Flutter 环境, 不需要所有组员安装 Flutter 环境, 只需要有发布开发需求的同学进行安装即可.
这就是 Flutter 组件化的实现核心点.
(4)Flutter 核心编译产物
App.framework:dart 业务源码相关文件, 在 Debug 模式下就是一个很小的空壳, 在 Release 模式下包含全部业务逻辑.
flutter_assets:Flutter 依赖的静态资源, 如字体, 图片等.
Flutter.framework:Flutter 库和引擎.
目录
Flutter 组件化 - 混编方案
Flutter 组件化 - 断点调试
Flutter 组件化 - 发布更新
Flutter 组件化 - 一些坑点
一, Flutter 组件化 - 混编方案
- Pod::Spec.new do |s|
- s.name = "FlutterSDK"
- s.vendored_frameworks = 'Framework/.framework', 'Framework/engine/.framework'
- s.resources = 'Framework/flutter_assets'
- end
来源: http://www.bubuko.com/infodetail-3061843.html