随着需求的迭代，所有代码都在主仓库的模式已经无法满足现有的需求。例如：和其他团队共建组件，提高代码的复用率。业务快速接入其他App或者新App，获得新的增长点。
为了解决上述问题：我们决定开始拆分组件。将代码拆分成组件之后，基础组件可以和其他的团队共用共建。业务组件可以快速给其他的App接入。

1、什么是组件

组件是一个功能的合集，承担的是一个单一的，明确的功能。例如网络组件负责所有的网络请求逻辑，外部如果需要使用到网络请求的功能，那么就需要使用到网络组件提供的接口。

1.1、组件拆分的标准

组件分为四层：业务层、胶水层、基础层、三方库。上层可以依赖下层，下层和同层之间不能依赖。
基础层的组件要求是单一功能的组件，例如：网络请求，下载，图片加载等，单一职责。
业务层的组件或许应该叫做模块，其粒度会大一些，是App中的业务功能。例如：歌房，直播。
其中的胶水层比较特殊，他存在于业务层和基础层之间。他的存在是由于某些逻辑会在AB两个模块之间复用，但是又不属于基础逻辑，无法下沉到基础层。例如：一些歌房和直播共用的逻辑，比如连麦、运营活动等。

2、如何从主工程开始拆分组件库

很多项目一开始都是在主工程写自己的逻辑，同时可能会有一些其他的三方组件库通过 Pod 接入。但是随着业务的发展可能这种协作方式已经不能满足需求，这个时候就需要对主工程进行拆分，拆出一些组件库。

2.1、技术方案

2.1.1 拆完之后各个组件库之间如何通信？

如果是业务层或胶水层使用基础层，那么直接导入使用即可。如果是业务层使用胶水层，或者业务层和业务层之间通信，则需要通过组件化通信方案。胶水层使用业务层或者基础层使用胶水层和业务层是不被允许的。
目前业内有以下几种组件化的通信方案。

2.1.2路由 URL 统跳方案

//通过路由URL跳转到指定页面
//kRouteRoom = @"//Router/Room"
UIViewController *vc = [Router handleURL:kRouteRoom];  
if(vc) {  
    [self.navigationController pushViewController:vc animated:YES];
}

优点：支持scheme跳转，App内和App外可以使用同一套逻辑，同时可以和Android等保持一致。
缺点：需要维护一个url到组件的文档，每次更新一个组件或者一个跳转逻辑都需要同步更新文档。支持基本参数，如果使用复杂参数或者自定义模型需要转JSON然后通过字典传值。

2.1.3 基于反射的远程调用封装

Class manager = NSClassFromString(@"RoomManager");  
UIViewController *vc = [manager performSelector:@selector(getRoom)];  
//do something

优点：可以解除组件间的编译依赖。
缺点：需要hardcode。编译期间无法检查到错误，要在运行时才能暴露问题。

2.1.4 服务注册方案

//Room模块提供的所有对外服务都放在RoomModuleService中
@protocol RoomModuleService
- (UIViewController *_Nullable)getRoom;
...
@end
//Room模块提供实现RoomModuleService的对象, 
//并在+load方法中注册
@interface RoomModule : NSObject<RoomModuleService>
@end
@implementation RoomModule
+ (void)load {
    //注册服务
    [RouterManager registerService:@protocol(RoomModuleService) 
                        withModule:self.class]
}
//提供具体实现
- (UIViewController *_Nullable)getRoom{...}
@end

//将RoomModuleService放在某个公共模块中，对所有业务模块可见
//业务模块可以直接调用相关接口
...
id<RoomModuleService> module = [RouterManager objByService:@protocol(RoomModuleService)];  
UIViewController *vc = [module getRoom];

优点：可以解除组件间的编译依赖。编译期间可以检查到错误。
缺点：所有需要和其他组件通信且不能之间依赖的组件都需要依赖RouterManager。
目前笔者所在的团队使用了第三个方案，接下来的文章中都已第三个方案举例。

2.2、如何保证拆分之后的能接回主工程

拆分时先通过物理隔离拆出主要文件，然后抽出依赖文件，决定放入基础组件还是业务文件。拆分之后建议保证组件库的目录结构和主工程原有目录结构一致。这样合入的时候能通过Beyond Compare等对比工具确定代码变更，防止代码丢失。
拆分完组件库之后已Pod的方式接回主工程。对比验证和测试。

3、组件化之后带来的问题

3.1、多个组件库的资源重复问题

拆成组件之后各个组件使用资源的模式会发生变化，每个组件库会存放自己使用到的资源。但是有些资源其实可使用同一份，例如关闭按钮。

3.1.1统一资源库

创建一个Resource库统一管理所有的资源，所有的组件库都去这里获取资源。
优点：当前主工程中不会包含重复的资源。
缺点：组件库包含了自己不需要的资源。所有组件库获取资源的方式需要更改。

3.1.2公共资源库和组件资源库共存

创建一个Resource库提供通用的资源。每个组件库自己管理自己单独使用的资源。
优点：组件库中只包含了自己使用到资源+部分公共资源。
缺点：还是会存在资源重复的问题，而且每次添加资源需要判断放入哪里。后续业务变化的时候资源可能也需要迁移。

3.2、组件化之后如何防劣化

随着业务的更新，一开始拆分的组件会逐渐膨胀，也可能会出现一些不够合理的依赖。怎么防止出现不合理的依赖？

3.2.1、什么是不合理的依赖

组件化的终极目标是主工程壳工程话，所有的组件库可以单独编译。但是如果一个需求涉及到多个组件的变更还是会在主工程中开发。那么在这种情况下，由于主工程拥有所有的组件库和依赖，可能会导致在A组件中导入B组件的类或者文件。从而导致A依赖B。这就是不合理的依赖。

3.2.2、组件化的防劣化

我们可以在CI流程添加卡口。比如在CI流程中增加一个pipline，当打包机出包之后，分析每个组件库的符号。就可以知道每个库拥有的符号和依赖的符号。然后得出每个库之间的依赖关系，然后和podsepc中声明的依赖关系做比较。如果出现新增的依赖就直接报错需要人工处理。

4、组件库如何提供给其他的App使用

既然我们的业务都拆成了组件，那么怎么快速让其他的App接入并做差异化实现呢？

4.1、技术方案对比

4.1.1通过编译宏

组件库同过SubPod或者宿主App的Podfile注入一些环境编译宏来表明自己是哪个App。内部需要差异化的代码根据宏来区分

#if isAppA
//do something
#endif

优点：可以在一份文件中看到所有的App逻辑。改动小。
缺点：可能其他的库会定义同名宏。可能会改动到其他的App中使用的接口，但是没有提示，需要适配的时候才发现。

4.1.2每个差异化的点采用一个Adapter。

每个差异化的App接入不同的Adapter来实现不同的差异化。
优点：差异化隔离彻底。每次改动对其他模块的影响可知。
缺点：改动大。最小颗粒度为一个方法。

组件化的应用方案