组件化

前言

组件化方案目前有URL、Runtime、Protocol有三种，组件化方案采用基于Runtime的CTMediator

一、组件化的划分依据

1、组件化的划分跟粒度无关，只满足下列条件中的一种，即使它只有一个对象且不到50行代码，那就会把这部分组件化出来。
（1）这一部分是否能够自治，且相对独立。
（2）这一部分是否会被多个调用者调度。

2、组件化更多的是针对横向依赖下沉。业务相对于服务之间的依赖属于纵向依赖，把服务作为普通pod引入即可。业务和业务之间是横向依赖，必须组件化。

二、组件化注意事项

1、原先是delegate委托传值，组件化后调用需通过block回调来当中间人
2、target-action和category，相当于一对乔接口需要同一个人维护，比较不容易乱,一般一个组件就只有一个target
3、target-action是依赖于组件方，和组件方放同一个pod，命名域在被调用发，category封装成独立的pod，依赖中间人CTMediator，供调用方使用，命名域在调用方
4、cocoapods只是把图片复制过去，Xcode的asset机制就失效，外部要调用的话，只能使用图片的真实名字(即存放时的名字) [UIImage imageNamed:"图片存放名字"]
5、某个组件需要监听或者调用者需要监听某个通知的话，通知名放在组件中，外部要调用的话，通过category返回该通知名，方便回溯追踪
6、组件化方案是服务于基于OpenUrl的跨App调用
7、出于安全考虑，通过action是否有带native来区分action是否仅被本地组件调用，不能被跨app调用
8、针对于都继承同一个基类的情况下，如果能去掉基类，就去掉基类，如果实现不行的话，将基类独立出一个pod，各组件podspec依赖写该pod,有用到该组件的话，podfile也要写入基类pod

三、组件化的好处

1、各个组件都封装成独立的pod，pod引入到主工程的话，是以静态库形式提供的，所以会提高编译速度
2、以后业务变多和代码量变大的时候，其易于维护和排除问题的优点就会越发凸显
3、用已经封装好的组件pod，更易于快速出新产品