一、什么是组件化
组件化就是将单一工程的项目按照功能职责或者业务职责划分成一个一个模块,模块间解耦调用.
二、组件化想解决的问题
当一个项目开发初期的时候,开发人员较少,业务较为简单,此时采用单一工程开发的模式,能保证开发效率.
当项目越来越大,开发人员越来越多,单一工程开发就会有一些弊端,诸如
- 代码耦合严重
- 提交容易出现冲突
- 编译时间太长导致开发效率低
- 代码冗余严重(相同功能代码可能反复被实现)
而组件化就是为了解决这些问题而出现的.
三、组件化的好处
- 加快编译速度,不需要编译整个项目(每个组件都有一个壳工程)
- 方便做针对性测试
- 代码解耦后更利率开发职责的划分
- 不容易出现代码提交冲突
四、组件化容易出现的问题
组件化看起来十分的棒,解决了很多问题,但不是所有APP都适合走组件化的路子,盲目的为了组件化而组件化反而会因为各种原因导致开发效率变低.
例如一个两三个人维护业务简单的项目,组件化的解耦调用可能会导致代码逻辑变复杂.
组件化粒度过细也会一个业务需求需要修改多个组件也容易让代码追踪变得困难,与对应组件负责人的沟通也会拖慢开发的进度.
我觉得只有项目到达一定规模后,开始出现相对独立的业务,团队人员开始增加,单一项目的开发模式成为了开发效率的掣肘,这个时候才是应该开始做组件化的时候.
五、常见的组件化方案
基于target-action的方式(CTMediator)
- 基于target-action的方式,通过类扩展生成对应模块入口类的类对象调用对应的action方法
基于router的方式(MGJRouter,HHRouter)
- 基于注册router的方式,在项目启动的时候去注册组件和对应的route,调用组件通过类openURL的方式,并传递复杂参数
不管是基于target-action还是基于router其实都是通过OC的反射机制(runtime)去获取对应的组件入口类调用对应的方法,从而达到解耦的目的
但是这也容易出现一个问题也是实际中遇到过的问题,就是当你新建一个组件,在主项目中引用,但是开发同事也不知道这个事,代码开发编译打包上线都是不会报错的,只有到线上功能无法使用了才会知道.
六、如何进行组件划分
- 个性化业务组件（直接业务层 拍卖功能模块 直播功能模块）
- 基础产品组件（通用业务层 类似支付模块 身份认证）
- 基础功能组件（单纯的功能组件 网络请求 crash手机 性能检测 埋点等）
我一直觉得组件化最大的难点在于组件拆分的粒度，基础功能组件的拆分尚且好说，单纯的功能模块有非常清晰的一个界定，但是涉及到业务的模块拆分则非常的麻烦。
拆的过细，一个业务需求可能会牵扯到多个模块，开发需要关注的不仅是自身负责的模块，开发效率降低，这也正是目前公司项目所遇到的问题。
拆的过粗，在项目的成长中可能这个模块慢慢又会变大后面又需要重新再拆。
七、拆分后如何组织引用
将拆分的模块作为cocoapods私有库的形式引入到项目中，每个模块都有自己的一个壳工程，用于单独提测模块。
八、对模块化的期盼
单一开发者负责自己对应的模块，模块有自己的壳子工程能单独提测，有自己的版本号，不依赖其他模块的开发进度。
模块功能上线稳定后当前版本作为基线版本，主项目新版需求开发前同步的所有模块稳定基线版本，下一版本的开发基于这个稳定基线去做。
