ios应用功能拆分之组件化详解

随着应用需求逐步迭代，应用的代码体积将会越来越大，为了更好的管理应用工程，我们开始借助CocoaPods版本管理工具对原有应用工程进行拆分。但是仅仅完成代码拆分还不足以解决业务之间的代码耦合，为了更好的让拆分出去的业务工程能够独立运行，必须进行组件拆分并且实现组件服务化。

小编的交流群659170228，欢迎大家入驻，一起交流学习

下面是一些实际项目中的组件问题

（1） 为什么要组件化？

• 解决人多（更好的协作）、需求多（更好的功能模块划分）的问题；

• 解决项目模块间的代码耦合问题；（坚决抵制业务组件间代码直接引用）

（2）如何拆分组件？

• 基础功能组件：（类似于性能统计、Networking、Patch、网络诊断等）

• 按功能分库，不涉及产品业务需求，跟库Library类似

• 通过良好的接口拱上层业务组件调用；

• 不写入产品定制逻辑，通过扩展接口完成定制；

• 基础UI组件：（例如下拉刷新组件、iCausel类似的组件）

• 产品内通用UI组件；（各个业务模块依赖使用，但需要保持好定制扩展的设计）

• 公共通用UI组件；（不涉及具体产品的视觉设计， 目前较少）

• 产品业务组件：（例如圈子、1元购、登录、客服MM等）

• 业务功能间相对独立，相互间没有Model共享的依赖；

• 业务之间的页面调用只能通过UIBus进行跳转；

• 业务之间的逻辑Action调用只能通过服务提供；

（3）组件化工程需要解决的问题？

• 组件化页面跳转（UIBus）方案要求：

• 能够传递普通参数（系统基础数据类型）和复杂参数（url无法负载的对象），不负责CustomModel的传递处理；

• 能够获取url对应的controller进行TabController的动态配置；

• 能够对controller的present方式进行定制；

• url的注册须用代码完成，必需去中心化处理；

• 组件服务化（ServiceBus）方案要求：

• 能够传递普通参数和复杂参数，尽量不使用CustomModel的传递；

• 通过接口文件的统一基础库进行依赖；（业务开发方开发阶段只需要依赖接口文件依赖库，在主项目集成测试阶段依赖所有业务组件进行测试）

• 接口和实现类的的对应注册须用代码完成，由中间件去控制服务实现类的生成；

（通用问题：复杂参数传递 key值的硬编码问题）

（4）组件维护问题？

• 组件服务接口的设计：

• 最小化原则；

• 命名规范；

  版本发布

（5）我的项目组件化应该做到什么程度？

个人认为组件化的程度取决于项目的大小，当一个项目一个人可以轻松开发和维护时，只需要项目架构保持如下图即可：

把基础层的部分抽成组件，用cocoapods来维护，实现基础层与表现层，业务层去耦合，业务层与表现层依然耦合。

当项目变的越来越大，功能模块越来越多，需要五到十几个人维护的时候，就需要明确组织里的每个人负责的功能模块，在代码层面也需要业务层和表现层区分开来，业务层和业务层之间也要区分开来，表现层与表现层之间也要区分开来，要想做到这些，需要做很多的工作，首先要划分好功能模块，保证一个模块的表现层和业务层代码在一个文件夹；然后一个模块下的表现层和业务层逻辑要有一个明显的区分；再引入一个中间件比如CTMediator，作者自己写的中间件基于CTMediator的ZZRouter，中间件用cocoapods来维护；每个模块根据中间件提供外部调用的接口，本模块调用外部模块，一律使用中间件来调，实现模块间的去耦合。中型项目的理想架构应该如下图：

中型项目理想架构

当一个app成为超级app需要多个团队共同协作开发的时候，对组件化的要求又更高了，这个时候需要实现模块的独立编译，以及在主项目中的静态和动态加载，同时又要保证模块间的通信，正在完善的BeeHive就是奔着这个目标去的。