App 架构
App架构.png
工程拆分和团队协作方式
工程拆分和团队协作.png
概念
1. 组件化开发
- 主要是为了解决团队协作，工程拆分，应用结构组织和划分的能力
- 和动态能力没有必然联系
2. 动态组件化
- 组件化的进一步进化，可以实现运行期的组概念，组建的更新，降级，增删等
- 组件化的开发模式是必要条件
3. 插件化
- 关注拆分和线上插件的插拔
- 项目拆分是必要条件
4. 热更新
- 重点关注是线上bugfix 和 小功能升级
- 一般不支持四大组件更新（无法直接完成大量功能更新）
- Android上主要是一些hack方案
5. 动态化的能力
- 热更新和插件化本质上是一种hack方案，多多少少会面临适配问题，国内厂商改造系统的风气，适配问题更多。
- 类似RN，Weex，Flutter是另一种形式的动态化能力，通过抽象层实现动态化，几乎不存在hack的问题
6. hotfix
线上的bugfix，进一步讲是：运行中的app可以修复bug，不用等到下次启动修复
应用插件化可能遇到的问题
- 打包流程改造的问题
- 适配问题
- 版本管理问题，各个插件依赖版本的问题（动态）
- 应用路径比较长，拆分是先决条件
- 底层API变动的问题（线上动态的情况）
- 集成和构建工具的问题
建议路径（组件化开发 + 热更新能力）
- 工程上微信的fake module
- 工程上简单，不需要改造编译流程，集成流程
- 不需要复杂的基础设置建设（maven管理等）
- Components没有版本的概念，热更新整体升级，简单直白的升级逻辑
- 拆分是渐进的，不拆分也可以做热更新
- 热更新对项目拆分没有要求
- 和现有的开发模式最接近，没有学习成本
- 配合热更新可以做紧急版本的发布，线上严重bugfix
- 结合一定的抽象和内置占位组建，可以实现大部分的业务功能更新
- 配合freeline／fastdex 可以解决编译慢的问题
- 支持渐进拆分
- 拆分可以到非常小的粒度
整体上来说：
最简单的方案，技术挑战最小，项目结构也能进一步清晰化，可以快速的集成热更新能力，满足现在和未来可预期一段时间内的发布需求
目标
高效的开发高质量的应用
高效：
- 开发效率上的高效
- 团队协作的高效
- 测试的高效
- 新功能，业务交付用户的高效
- 线上运维的高效
- 运营的高效
高质量：
（从终端用户角度出发定义）
- 用户体验良好（界面的卡顿，视频的卡顿）
- 资源消耗合理（电量，内存，cpu，发热等等）
- 崩溃率／ANR率／黑屏率
- 可以衡量的线上终端用户感受到的质量
- 质量问题的预防／卡口体系
要达到目标需要做到的：
- 技术债务
- App架构
- 工程拆分和团队合作
- 质量体系建设
- 自动化的测试体系
- 持续集成和持续交付系统
核心点：
- 清晰的，低耦合的app架构
- 工程化拆分，方便团队协作，降低摩擦和整体复杂度
- 持续交付的体系建设和质量保证体系建设
- 不断的积累稳定高效的基础类库
理念->提高层次，降低复杂度:
架构上降低设计复杂度，拆分降低团队协作复杂度，持续交付降低工程复杂度。基础类库，提高抽象层次。
网友评论