iOS的组件化实践

随着工程的变大, 业务的复杂, 开发人员的增多, 如何提高成员间的开发效率和最大程度的复用代码, 成为了亟待解决的问题. 除了更加清晰的结构目录外, 模块化, 应该是一种比较优雅解决方案. 关于组件化我们要达成的一个目标就是重用高度抽象化的代码单元.

参考文章系列基本上可以代表业界目前对组件化的一些思考, 建议按照顺序阅读. 下面是我结合我司项目中的一些实际应用, 谈一下我对组件化的理解.

我司的组件化之路, 大致可以分为几个阶段, 下面我就项目的变化历程来分析我司的组件化之路.

大杂烩

最开始, 我们的项目所有代码都在工程里面, 每个具体的业务使用独立的文件夹进行分割, 看似十分整洁, 但是也有很多不便之处. 各个模块之间耦合性很强, 责任人不明确. 这个时候可以说完全没有组件化的概念, 十分混乱.

组件化的引入, 源于和另外一个项目的代码复用. 当时在做一个营销相关的业务, 由于效果十分好, 所以决定在另外一个项目中也接入这块业务. 然而, 并没有想象的那么简单. 由于跨项目, 后台完全不同, 牵涉到网络库调用, 公共组件的使用, 要想把这个业务单独拆分出去, 就必须把这个业务用到的网络库, 公共组件库也拆分出去, 难度非常之大. 这时候, 就想到了使用Cocoapods来管理一些工具类和公共组件, 于是就有了第二阶段.

非业务代码组件化

在这一阶段, 我们充分使用Cocoapods的模块化功能, 将一些通用的类, 工具类, 封装成私有的Pod(参考这里). 这样一来, 就把基础代码从项目中抽离出来, 其他的项目要想使用, 只需依赖我们的私有Pod就可以了. 那么上面想要拆分公共业务组件的想法就可以实现了.

然而, 随着业务的打通. 不同的项目之间需要调用的共同组件越来越多, 组件与组件之间如何进行交互, 组件与项目之间又如何进行交互, 这些问题又出来了. 于是, 又有了现在的完全组件化方案.

完全组件化

称之为完全组件化方案, 是因为我司目前采用的就是这样的解决方案, 并且暂时也找不到更加好的解决方案. 完全组件化方案, 实际还是在非业务代码组件化的基础上, 通过引入路由协议来实现的.

通过路由协议, 相当于我们通过一个中间层来转发我们组件与组件之间的通信, 这样就实现了组件之间的解耦, 而组件内部又是完整的业务逻辑, 属于高内聚, 低耦合.

至此, 就完成了我们的组件化之路, 解除组件之间相互引用的代码硬依赖, 规范了组件之间的通信接口, 各个组件本身就相当于一个黑盒, 可以独立开发.

其他组件化方案

可以将需要封装的代码打包成静态库, 静态库中把需要暴露出来的头文件选择性的暴露出来, 不过这样各个模块之间的耦合性还是比较高的.

参考文章:
1.蘑菇街App的组件化之路.

2.iOS应用架构谈组件化方案.

3.蘑菇街App的组件化之路.续.

4.iOS组件化方案探讨.