工程结构设计
方案1 以flutter壳工程为主
image.png
- 把所有原生代码copy到flutter-tms工程的ios和android目录下
- 大量工程配置
- 即使没有flutter代码，也会启动flutter引擎
- 调试复杂
方案2 flutter工程作为依赖产物
image.png
- 以flutter官方推荐的module方式引入
- flutter代码不变，只生成了一次产物，原生调试不受影响
-
一开始flutter代码很少，原生不受影响，基本独立，随着原生模块的逐渐迁移，工程逐渐迁移到以flutter为主，最终把原生工程去掉，会变成类ump工程的形式，到此改造完成
image.png
| flutter壳工程 | flutter依赖产物 | |
|---|---|---|
| 集成方式 | 源码copy | 原生工程配置 |
| 调试 | 依赖严重 | 独立调试 |
| 运行性能 | 每次启动引擎 | 实际使用才会启动引擎 |
| 工程改造 | 一步到位 | 持续改造 |
路由设计
image.png
由native页面为主，flutter页面无或者很少过度到以flutter页面为主
image.png
- 以channel为核心的路由交换机制
- native侧和flutter侧同时维护路由表
- 可以使用flutterBoost
混合栈设计
| 多引擎 | 单引擎 | |
|---|---|---|
| 内存 | 多 | 少 |
| 通信 | 复杂 | 简单 |
| 动画交互 | 易管理 | 难管理 |
- 选择使用单引擎方式
- 由于过度时期以native为主可以使用flutterBoost，之后项目逐渐迁移以flutter为主后，混合栈使用自己实现的以flutter为主的混合栈方案。
- 自己的混合栈方案思路和flutterBoost一致，但是管理会放在flutter侧
image.png
image.png
