APP组件化实践(二):组件划分

题图

上篇分析了组件的通信方案，本篇继续来讨论如何将项目组件化。

一个组件化的项目，分以下三层： 组件化层次图

第一层：壳工程

壳工程就是最终交付项目（也可以是临时的体验包）的主工程，负责各个组件的初始化，并将它们组装在一起，管理整个项目的生命周期。

第二层：bundle 工程

bundle 工程即组件，这里沿用手机淘宝提出的概念，一个 bundle 应该包含自己的 UI、图片等资源、业务逻辑，可以独立运行，完全不依赖壳工程，也绝对不能互相依赖，这就与普通 Model 的划分有显著的不同。

这样拆分的组件，交与不同开发小组全权负责，各小组可以用自己熟悉的工具栈和开发方式，不必勉强配合一些“强制的条款”，从而释放自己的创造力。

有些方案提出，将图片等本地资源单独作为一个 bundle ，共用并不是划分一个组件的充分条件，如果这个图片库只是提供一些界面元素，供各个 bundle 共用，可以下沉到基础库中，方便用API方法直接调用，不必通过 Route 来间接传输。

第一层与第二层通过Route通信，包括页面跳转和异步回调。

第三层：基础库

将各个 bundle 都使用的库都放在这一层，如 AFNetworking 等，也可以是自己封装的工具库，如图片滤镜、Cache 等。当然，用于组件通信的 Route 库实际上也在这层，作为基础能力提供，不需要根据任何具体 Bundle 改动。

基础库都是被各个Bundle直接引用的，因此把哪些代码“下沉”到这一层，需要仔细斟酌，但并不模棱两可：成为一个基础库的显著特征是没有具体的业务逻辑。

因此网络API显得有些特殊：
网络API不可避免地包含了 Model，与业务线紧密相关，前文的组件化层次图中将API库放在基础库，是基于项目有统一的API设计、接口差异较小、Model 具有高共用性的情况，作为基础能力提供，可以减少代码冗余，但如果各个 bundle 是完全不同的业务线，API 规则差别较大，Model 为 Bundle 独立使用，则可以考虑直接将其放入各个 Bundle ，由各个业务小组独立维护，更符合组件化思想。

网络API的分治

基础库需要在项目中统一版本，毕竟，如果各个 Bundle 各自引入AFN 的不同版本，绝对是开发的灾难；如果 Bundle 有对基础库的扩充怎么办？一个建议是由 Bundle 各自添加自用的分类。

小结

本节通过对组件的划分讨论，说明了组件化的架构思想，想必你已经对组件化的各个角色有了进一步概念，接下来通过一个 Demo 来说明实践中的组件化是如何进行的，如果从本文中有所收获，点个小❤️让我知道：技术探索的路上有你陪伴。