1. 前言
1.1. 什么是工程化
随着 App 越来越复杂、团队人数增加，如果没有工程化手段，会出现以下问题：
- 代码混乱，缺乏规范；
- 构建慢，依赖不清晰；
- 模块间强耦合，影响复用；
- 无法持续集成，测试滞后；
- 难以多端统一（iOS / Android）；
工程化的本质就是"让 App 的开发和演进可以规模化、自动化、低风险、高效率地进行"。
其中主要包括：流程标准化、工具自动化、模块解耦、团队协作效率等。
| 方向 | 工程化目标 |
|---|---|
| 标准化 | 规范目录结构、命名、提交、代码风格 |
| 模块化 | 拆分功能模块，解耦业务逻辑 |
| 自动化 | 自动构建、测试、打包、发版 |
| 配置管理 | 多环境配置、灰度发布、A/B 测试支持 |
| 统一依赖管理 | 管理第三方依赖和私有组件依赖 |
| CI/CD | 自动化测试 + 发布流程 |
1.1.1. 总结一句话
App 的工程化是让移动开发从"手工手艺"转向"流程+工具+平台"的工程体系，它通过标准化、模块化、自动化等手段，大幅提升开发效率、降低出错率，实现 App 的高质量可持续演进。
2. Flutter的模块化
2.1. 业务&团队背景
这里我们聊的是大规模应用开发的场景，比如公司有一个App（混合栈），有100人10个团队开发，团队的人在天南地北，每个团队都有自己独立的业务，并且使用Flutter开发，更糟糕的是所有业务都在一个git仓库下的一个flutter module开发。其实还可以更复杂一下，公司有10个App，这些flutter业务需要再不同App里运行，也就是我们平时所说的业务在不同App之间移植。但这里我们只讨论一个App（混合栈）多Flutter业务的场景。
2.2. 模块化设计
2.2.1. 设计范围
如果你是这个研发团队的顶层移动端架构师，应该怎么设计Flutter模块化开发的架构？这里我们只讨论模块化设计，不谈流程。可以理解为：
- 模块代码如何划分和拆分
- Git仓库怎么设计
- 单个模块如何在稳开发阶段拥有稳定的环境调试代码
- 单模块如何打包发布
- 单模块如何集成到App中
- 如何打App整包
这些都是工程化的基础。
2.2.2. 问题定义
2.2.3. 问题一：发布节奏冲突
比如：
- A 团队要 紧急发布修复，但 B 团队的代码也刚提交，还没测试完成
- Flutter 是整个 module 一起打包产物，没法单独发布 A 的改动
📌 结果：
- 要么等 B 测试完一起发（A 被拖延）
- 要么回滚 B 的代码再发（操作麻烦，容易出错）
2.2.4. ❗️问题二：代码冲突频繁
比如：
- 大家改
pubspec.yaml、main.dart、一些通用 widget，很容易出现合并冲突 - CI 配置、热更新脚本、资源文件可能互相影响
2.2.5. flutter module代码量庞大，构建速度慢
2.2.6. ❗️问题三：构建体积和性能难优化
- 各团队业务不相关，打成一个大 module，会让产物体积变大、初始化时间长
2.2.7. ❗️问题四：职责不清晰、难以独立开发测试
- 团队之间有耦合，没法独立测试自己的功能
- 不利于新团队加入，难上手
2.2.8. 解决思路
| 问题 | 解决方向 | 具体做法 |
|---|---|---|
| 发布节奏冲突 | 模块拆分 + 共享基础库 | - 多个独立 Flutter Package，并分别建立独立的git库。分别独立打包发布到私有pub |
| 代码冲突频繁 | 代码仓库拆分 + 公共库抽取 | - 各团队维护独立代码仓库，减少合并冲突- 抽取公共组件、工具为独立 Flutter Package- 统一依赖版本管理，避免依赖冲突 |
| ##### 构建速度慢 | 拆分为不同package | 拆分为不同package，通过pub发布 |
| 构建体积和性能难优化 | 多模块拆分 + 基础动态库抽离 + 按需加载 | - 多模块按业务拆分，减少单模块体积- Flutter Engine 和公共依赖抽离成基础动态库，减少重复- 按需动态加载模块，优化启动性能 |
| 职责不清晰、难独立测试 | 业务模块边界清晰 + 独立测试环境 + 集成层管理 | - 设计清晰模块边界和职责- 每个模块独立运行、调试和测试支持- Native App 作为统一集成层，统一管理 Flutter Engine 和模块调用 |
2.2.9. 设计
