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 来说明实践中的组件化是如何进行的,如果从本文中有所收获,点个小❤️让我知道:技术探索的路上有你陪伴。

推荐阅读更多精彩内容