前言
随着我们业务发展，参与业务开发的同学也逐渐增多。为了适应新要求，需要对旧的架构做一次升级。组件化是架构升级中的重要一步，将业务模块进行组件化，将各个业务的逻辑和依赖梳理清楚，才能有效降低业务迭代带来的复杂度，为后续更复杂的优化做铺垫。
正文
问题背景
iOS的App架构早期设计分为三层：业务模块层、基础业务层、基础功能层。
业务模块层承载具体业务模块，基础业务层封装业务基础能力，基础功能层桥接依赖的Pod库。 随着业务的发展，SSCommon基础功能层接入越来越多的功能库，SSFoundation基础业务层沉淀出来BDNovelKit、BDNovelWidget、阅读器SDK和听书SDK，SSApp业务模块层也在不断生成新的功能模块。
经历多个版本的迭代，存在几个较为明显的问题： 业务模块依赖无抽象，以主Tab和分类业务模块为例，既没有主Tab要求分类业务模块实现的TabProtocol，也没有分类业务模块要求宿主实现的Delegate； 层级界限不清晰，当新增某个功能业务时，对应数据结构类型、业务组件等全部放在业务模块层； 业务模块调用不规范，比如说在书城模块需要使用其他业务模块（搜索、有声、金币）时，会直接引入的对应业务模块实例；
问题解决
组件化的目标是逻辑内聚、依赖抽象。 将复杂的工程，拆分为若干个独立的组件，将复杂的逻辑内聚，仅对外暴露接口，降低整个工程的复杂度。同时也是方便后续工程进行拆分，对于部分业务进行子仓化，部分通用的基础组件甚至可以多App复用。
通用基础层
使用范围不局限于App的基础库，既有公司提供的Heimdallr，也有自己维护的BDReader。
业务基础层
仅服务于自己业务，会被上层业务直接使用，包括SSBook这种业务基础数据结构，也有业务通用的SSBaseView，这些代码会封装到若干个Pod库。
业务接口层
业务接口层主要是描述每个业务组件的接口，调用组件应该通过接口去调用，接口层是组件生成必备。
业务实现层
业务实现层是接口层的具体实现，组件化之后的业务组件主要逻辑放在这里，实现层是组件生成必备。
主App
目前整个App大部分逻辑都是放在这里，随着组件化的推进，逐渐沉淀部分逻辑到业务实现层、业务接口层和业务基础层。
具体组件
以分类组件为例，这是分类组件的大致构成。
SSCategoryImp可以直接使用业务基础层的SSBook和SSBaseView，也可以使用通用基础层的BDALog和Heimdallr。 主App会通过SSCategoryInterface去调用分类组件，同时也会实现一个SSCategoryDelegate，作为分类部分功能的回调。
标准实现
组件内部也要分层，便于后续组件管理，以及组件间能力复用。分层建议包括组件接口层、组件实现层、组件基础层、组件数据层。 组件接口层：存放组件对外提供能力的抽象接口； 组件实现层：存放组件对接口实现的具体代码； 组件基础层：存放组件对外提供的业务UI能力；这部分复用组件较多之后，需要下沉到App的业务基础层； 组件数据层：存放组件对外提供的业务Model；这部分复用组件较多之后，需要下沉到App的业务基础层；
问题延伸
模块化
在我们的工程里，模块化指的是将业务功能模块拆分成若干个功能模块，模块可以在多个业务中复用。比如说某个书评业务使用评论组件、点赞组件、气泡组件等进行模块化编程。模块化编程可以有效提供代码的复用率，同时也便于沉淀组件。
代码分仓
直接分仓会存在增加开发成本和维护成本的问题，短期组件化会有较多改动。但是分仓又是一种比较好的物理隔离方式，可以减慢代码劣化，同时也比较方便管理依赖。待组件化成熟之后，再进行代码分仓。 业务基础层可以直接沉库，方便建立明确的层级关系。
组件通信
组件通信其实就是组件A调用组件B的某个功能，这里有几种方式，以分类组件和播放组件为例。 接口调用：分类组件有业务逻辑需要感知当前正在播放的书籍id，那么应该通过播放组件提供的抽象接口（而不是播放器实例），拿到这个书籍id； 依赖注入：分类组件描述需要依赖外部实现的能力并提供注入接口，然后外部组件再主动通过接口注入该能力的实现； 消息通知：播放组件在切换当前播放书籍时，可以通过消息通知所有关注的业务组件，业务组件Register的Message是在业务基础层；
落地规划
阶段一 基建准备
工程梳理，明确基础业务层范围，业务基础层搭建； 接口层实现和组件注册机制； 基础工具支持准备，组件调用能力；
阶段二 show case
业务落地，以某个业务做组件化，打造show case； 组件化结构合理，包括接口、数据和实现； 搭建配套的检查、review、多仓合码等机制；
阶段三 业务组件推进
降低改造成本，并逐步推广到多个业务；
组件化思考
分仓实现有哪些问题？
依赖版本管理问题，组件本身需要和主端App保持一致依赖版本号。 拆分组件之后，如果使用分仓隔离，则不能直接操作组件，需要引入多仓开发。
组件有哪些类型？
按照使用范围有： 通用组件，多端App都能用的组件； 业务组件，只有当前业务使用的组件；
按照内容区分： 功能组件，业务的具体业务组件，着重点在于逻辑内聚，代码隔离； 基础组件，业务的基础功能组件，着重点在于功能的重复利用；
业务组件由哪些组成？
代码 资源 依赖 抽象。 代码：承载具体业务逻辑的.h/.m； 资源：业务使用的图片等其他资源； 依赖：组件需要主App实现的能力； 抽象：组件提供给主App使用的能力，也就是接口层，接口层包括方法和数据类型；
业务组件的有哪些实现方式？
Development Pods，组件代码和主工程代码同仓； Pod库，类似第三方库，代码分仓； 子工程依赖，业务组件单独成为一个工程，被主工程依赖，代码同仓； 文件夹分隔，同一个主工程，用不同文件夹分隔，通过添加文件夹Reviewer来避免劣化，代码同仓；
所有的代码分仓，都需要考虑业务组件和主App的依赖版本一致问题，有些成熟业务会有业务组件容器化的解决方案，可以把业务组件和主App的pod版本对齐。 代码分仓带来了另外一个问题是工程配置、宏定义、xcconfig等不同步，需要及时打通和更新。
比较好的实践是综合上述的过程： 1、先梳理依赖，再用文件夹做简单分隔； 2、对应文件夹用Development Pods进行分隔，这一步也可以用子工程来实现；devPod相对简单，但是无法完全隔离；子工程可以物理隔离，但是维护相对麻烦； 3、Pod子仓，明确组件的subspec和podspec依赖；
业务组件如何感知App生命周期？
目前并不打算让主App对系统事件进行封装，App生命周期、Push处理、系统事件处理等由主App处理，各个组件可以直接去监听系统的事件。但有些事件只会回调到主App，那么再由主App分发事件。 待到组件化足够成熟，可以把主App再拆出若干个负责事件转发的底层组件，作为通用的依赖（容器层）。
接口层如何屏蔽具体的实例？
需要有组件的接口和绑定方法，这里用到了一个公司内部提供的库来实现，基本原理还是通过MachO段来做绑定。 组件外通过GET_PROTOCOL(SSProtocol)和GET_PROTOCOL_CLASS(SSxxProtocol) 两种方式来调用，组件内通过BIND_PROTOCOL_SERVICE(SSProtocol, SSxxImpl)来绑定接口和实现。
总结
网上关于组件化的文章非常多，这里主要介绍我们业务的思考和落地过程。 架构优化是一件持之以恒的事情，技术方案总是可以持续完善。最初的设计不用太复杂，逻辑清晰便于演进架构，能解决当下协作痛点，适应业务迭代的节奏，就是一个好的解决方案。
代码架构，合久必分，分久必合。
