随着需求的迭代，所有代码都在主仓库的模式已经无法满足现有的需求。例如：和其他团队共建组件，业务快速接入其他App或者新App。
为了解决上述问题：我们决定开始拆分组件。将代码拆分成组件之后，基础组件可以和其他的团队共用共建。业务组件可以快速给其他的App接入。
1、从主工程开始拆分组件库
很多项目一开始都是在主工程写自己的逻辑，同时可能会有一些其他的三方组件库通过 Pod 接入。但是随着业务的发展可能这种协作方式已经不能满足需求，这个时候就需要对主工程进行拆分，拆出一些组件库。
1.1、技术方案对比
拆完之后各个组件库之间如何通信？目前业内有以下几种组件化的拆分方式。
1.1.1路由 URL 统跳方案
//通过路由URL跳转到指定页面
//kRouteRoom = @"//Router/Room"
UIViewController *vc = [Router handleURL:kRouteRoom];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
优点：支持scheme跳转，App内和App外可以使用同一套逻辑，同时可以和Android等保持一致。
缺点：需要维护一个url到组件的文档，每次更新一个组件或者一个跳转逻辑都需要同步更新文档。支持基本参数，如果使用复杂参数或者自定义模型需要转JSON然后通过字典传值。
1.1.2 基于反射的远程调用封装
Class manager = NSClassFromString(@"RoomManager");
UIViewController *vc = [manager performSelector:@selector(getRoom)];
//do something
优点：可以解除组件间的编译依赖。
缺点：需要hardcode。编译期间无法检查到错误，要在运行时才能暴露问题。
1.1.3 服务注册方案
//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。
目前笔者所在的团队使用了第三个方案，接下来的文章中都已第三个方案举例。
1.2、具体拆分的标准
确定技术方案之后就是如何来拆分，组件化的目的是为了解耦，从类的级别上升到了业务的级别。首先组件可以简单分为两类，基础组件、业务组件。业务组件可以直接依赖基础组件。业务组件之间必须使用RouterManager来通信。
基础组件：提供基础能力，为各个业务组件服务。变更较少。
业务组件：以业务为维度，依赖基础组件提供的能力。变更频繁。
1.3、如何保证拆分之后的能接回主工程
拆分时先通过物理隔离拆出主要文件，然后抽出依赖文件，决定放入基础组件还是业务文件。拆分之后建议保证组件库的目录结构和主工程原有目录结构一致。这样合入的时候能通过Beyond Compare等对比工具确定代码变更，防止代码丢失。
拆分完组件库之后已Pod的方式接回主工程。对比验证和测试。
2、组件化之后带来的问题
2.1、多个组件库的资源重复问题
拆成组件之后各个组件使用资源的模式会发生变化，每个组件库会存放自己使用到的资源。但是有些资源其实可使用同一份，例如关闭按钮。
2.2.1统一资源库
创建一个Resource库统一管理所有的资源，所有的组件库都去这里获取资源。
优点：当前主工程中不会包含重复的资源。
缺点：组件库包含了自己不需要的资源。所有组件库获取资源的方式需要更改。
2.2.2公共资源库和组件资源库共存
创建一个Resource库提供通用的资源。每个组件库自己管理自己单独使用的资源。
优点：组件库中只包含了自己使用到资源+部分公共资源。
缺点：还是会存在资源重复的问题，而且每次添加资源需要判断放入哪里。后续业务变化的时候资源可能也需要迁移。
2.2、组件化之后如何防劣化
随着业务的更新，一开始拆分的组件会逐渐膨胀，也可能会出现一些不够合理的依赖。怎么防止出现不合理的依赖？CR
3、组件库如何提供给其他的App使用
既然我们的业务都拆成了组件，那么怎么快速让其他的App接入并做差异化实现呢？
3.1、技术方案对比
3.1.1通过编译宏
组件库同过SubPod或者宿主App的Podfile注入一些环境编译宏来表明自己是哪个App。内部需要差异化的代码根据宏来区分
#if isAppA
//do something
#endif
优点：可以在一份文件中看到所有的App逻辑。改动小。
缺点：可能其他的库会定义同名宏。可能会改动到其他的App中使用的接口，但是没有提示，需要适配的时候才发现。
3.1.2每个差异化的点采用一个Adapter。
每个差异化的App接入不同的Adapter来实现不同的差异化。
优点：差异化隔离彻底。每次改动对其他模块的影响可知。
缺点：改动大。最小颗粒度为一个方法。
网友评论