题图
上篇分析了组件的通信方案, 本篇继续来讨论如何将项目组件化.
一个组件化的项目, 分以下三层:
组件化层次图
第一层: 壳工程
壳工程就是最终交付项目 (也可以是临时的体验包) 的主工程, 负责各个组件的初始化, 并将它们组装在一起, 管理整个项目的生命周期.
第二层: bundle 工程
bundle 工程即组件, 这里沿用手机淘宝提出的概念, 一个 bundle 应该包含自己的 UI, 图片等资源, 业务逻辑, 可以独立运行, 完全不依赖壳工程, 也绝对不能互相依赖, 这就与普通 Model 的划分有显著的不同.
这样拆分的组件, 交与不同开发小组全权负责, 各小组可以用自己熟悉的工具栈和开发方式, 不必勉强配合一些 "强制的条款", 从而释放自己的创造力.
有些方案提出, 将图片等本地资源单独作为一个 bundle , 共用并不是划分一个组件的充分条件, 如果这个图片库只是提供一些界面元素, 供各个 bundle 共用, 可以下沉到基础库中, 方便用 API 方法直接调用, 不必通过 Route 来间接传输.
第一层与第二层通过 Route 通信, 包括页面跳转和异步回调.
第三层: 基础库
将各个 bundle 都使用的库都放在这一层, 如 AFNetworking 等, 也可以是自己封装的工具库, 如图片滤镜, Cache 等. 当然, 用于组件通信的 Route 库实际上也在这层, 作为基础能力提供, 不需要根据任何具体 Bundle 改动.
基础库都是被各个 Bundle 直接引用的, 因此把哪些代码 "下沉" 到这一层, 需要仔细斟酌, 但并不模棱两可: 成为一个基础库的显著特征是没有具体的业务逻辑.
因此网络 API 显得有些特殊:
只要是互联网 App, 网络 API 是必不可少的, 前文的组件化层次图中将 API 库放在基础库, 是基于项目有统一的 API 设计, 接口差异较小的情况, 将 API 作为基础能力提供, 可以减少代码冗余, 但如果各个 bundle 是完全不同的业务线, API 规则差别较大, 反而直接将其放入各个 bundle , 由各个业务小组独立维护, 更符合组件化思想.
网络 API 的分治
基础库需要在项目中统一版本, 毕竟, 如果各个 Bundle 各自引入 AFN 的不同版本, 绝对是开发的灾难; 如果 Bundle 有对基础库的扩充怎么办? 一个建议是由 Bundle 各自添加自用的分类.
小结
本节通过对组件的划分讨论, 说明了组件化的架构思想, 想必你已经对组件化的各个角色有了进一步概念, 接下来通过一个 Demo 来说明实践中的组件化是如何进行的, 如果从本文中有所收获, 点个小让我知道: 技术探索的路上有你陪伴.
来源: http://www.jianshu.com/p/1e7069678a14