组件化

说明

采用组件化，是为了组件能单独开发，单独开发是结果。要让组件能单独开发，组件必须职责单一，职责单一需要用到重构和解耦的技术，所以重构和解耦是过程。

如果我们每个组件都只是单向依赖其他组件，各个组件之间也就没有必要解耦。再换个角度说，如果一个组件职责不单一，即使跟其他组件解耦了，组件依然不能很好的工作。如何解耦只是重构过程中可选手段，代码设计的原则如依赖倒置、接口隔离、里氏替换，都可以指导我们写出好的组件。

图解

一般来讲，App的组件可以分为三层，上层业务组件、中层UI组件、底层SDK组件

具体实现

• 业务组件解耦
  上层业务组件之间的解耦，采用依赖注入的方式实现。每个模块都声明一个自己依赖的协议，在App集成方里去实现这些协议。

  
  

使用依赖注入，APP集成方统一去管理各个模块的依赖，每个模块也能单独编译，是业务层解耦的最佳实践。

• 包管理

  1.要解除循环依赖，引入包管理技术cocoapods会让我们更有效率。pod不允许组件间有循环依赖，若有pod install时就会报错
  2.cocoapods，提供私有pod repo，使用时把自己的组件放在私有pod repo里，然后在Podfile里直接通过pod命令集成。一个组件对应一个私有pod，每个组件依赖自己所需要的三方库。多个组件联合开发的时候，可以再一个podspec里配置子模块，这样在每个组件自己的podspec里，只需要把子模块里的pod依赖关系拷贝过去就行了。
  3.在多个组件集成时会有版本冲突的问题。比如登录组件（L）、广告组件（A）都依赖了埋点组件（O），L依赖O的1.1版本，A依赖O的1.2版本，这时候集成就会报错。为了解决这个错误，在组件间依赖时，不写版本号，版本号只在APP集成方写。即podfile里引用所有组件，并写上版本号，.podspec里不写版本号。
  4.这样做既可以保证APP集成方的稳定性，也可以解决组件依赖的版本冲突问题。这样做的坏处是，所有组件包括App集成方，在使用其他组件时，都必须使用其他组件最新的API，这会造成额外的升级工作量。如果不想接受组件升级最新api的成本，可以私有化一个三方库自己维护。
  

组件拆分原则

对老工程的组件拆分，我的办法是，从底层开始拆。SDK> 模块 > 业务 。如果App没有SDK可以抽离，就从模块开始拆，不要为了抽离SDK而抽离。常见的误区是，大家一拿到代码就把公共函数提出来作为共用框架，起的名字还特别接地气，如XXCommon。

事实上，这种框架型SDK，是最鸡肋的组件，原因是它实用性很小，无非就是减少了点冗余代码。而且在架构能力不强的情况下，它很容易变成“垃圾堆”，什么东西都想往里面放，后面越来越庞大。所以，开始拆分架构的时候，尽量以业务优先，比如先拆分享模块。

如果两个组件中有共同的函数，前期不要想着提出来，改个名字让它冗余是更好的办法。如果共同耦合的是一个静态库，可以利用动态库的隔离性封装静态库，具体方法可以网上找。