摘要：一背景业务组件化或者叫模块化作为移动端应用架构的主流方式之一，近年来一直是业界积极探索和实践的方向。有赞移动团队自年起也在不断尝试各种组件化方案，在有赞微商城，有赞零售，有赞美业等多个应用中进行了实践。相比组件，个人感觉称之为模块更为合适。
一、背景
业务组件化（或者叫模块化）作为移动端应用架构的主流方式之一，近年来一直是业界积极探索和实践的方向。有赞移动团队自16年起也在不断尝试各种组件化方案，在有赞微商城，有赞零售，有赞美业等多个应用中进行了实践。我们踩过一些坑，也收获了很多宝贵的经验，并沉淀出 iOS 相关框架 Bifrost (雷神里的彩虹桥)。在过程中我们深刻体会到“没有绝对正确的架构，只有最合适的架构”这句话的意义。很多通用方案只是组件化的冰山一角，实际落地过程中还有相当多的东西需要考量。
本文并不准备对组件化架构设计方案给出一份标准答案，而是希望通过我们的实践经验和思考分析，提供一种思路，对遇到类似问题的同学能有所启发。
注：
区别于功能模块/组件（比如图片库，网络库），本文讨论的是业务模块/组件（比如订单模块，商品模块）相关的架构设计。
相比组件（Component），个人感觉称之为模块（Module）更为合适。组件强调物理拆分，以便复用；模块强调逻辑拆分，以便解耦。而且如果用过 Android Studio, 会发现它创建的子系统都叫 Module. 但介于业界习惯称之为组件化，所以我们继续使用这个术语。本文下面所用名词，“模块”等同于“组件”。
二、什么是业务模块化（组件化）传统的 App 架构设计更多强调的是分层，基于设计模式六大原则之一的单一职责原则，将系统划分为基础层，网络层，UI层等等，以便于维护和扩展。但随着业务的发展，系统变得越来越复杂，只做分层就不够了。App 内各子系统之间耦合严重, 边界越来越模糊，经常发生你中有我我中有你的情况（图一）。这对代码质量，功能扩展，以及开发效率都会造成很大的影响。此时，一般会将各个子系统划分为相对独立的模块，通过中介者模式收敛交互代码，把模块间交互部分进行集中封装, 所有模块间调用均通过中介者来做（图二）。这时架构逻辑会清晰很多，但因为中介者仍然需要反向依赖业务模块，这并没有从根本上解除循坏依赖等问题。时不时发生一个模块进行改动，多个模块受影响编译不过的情况。进一步的，通过技术手段，消除中介者对业务模块依赖，即形成了业务模块化架构设计（图三）。
业务模块化设计通过对各业务模块的解耦改造，避免循环双向依赖，达到提升开发效率和质量的目的。但业务需求的依赖是无法消除的，所以模块化方案首先要解决的是如何在无代码依赖的情况下实现跨模块通信的问题。iOS 因为其强大的运行时特性，无论是基于 NSInvocation 还是基于 peformSelector 方法, 都可以很很容易做到这一点。但不能为了解耦而解耦，提升质量与效率才是我们的目的。直接基于 hardcode 字符串 + 反射的代码明显会极大损害开发质量与效率，与目标背道而驰。所以，模块化解耦需求的更准确的描述应该是“如何在保证开发质量和效率的前提下做到无代码依赖的跨模块通信”。
目前业界常见的模块间通讯方案大致如下几种：
基于路由 URL 的 UI 页面统跳管理。
基于反射的远程接口调用封装。
基于面向协议思想的服务注册方案。
基于通知的广播方案。
根据具体业务和需求的不同，大部分公司会采用以上一种或者某几种的组合。
3.1 路由 URL 统跳方案统跳路由是页面解耦的最常见方式，大量应用于前端页面。通过把一个 URL 与一个页面绑定，需要时通过 URL 可以方便的打开相应页面。
//通过路由URL跳转到商品列表页面
//kRouteGoodsList = @"//goods/goods_list"
UIViewController *vc = [Router handleURL:kRouteGoodsList];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
当然有些场景会比这个复杂，比如有些页面需要更多参数。
基本类型的参数，URL 协议天然支持：
//kRouteGoodsDetails = @“//goods/goods_detail?goods_id=%d”
NSString *urlStr = [NSString stringWithFormat:@"kRouteGoodsDetails", 123];
UIViewController *vc = [Router handleURL:urlStr];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
复杂类型的参数，可以提供一个额外的字典参数 complexParams, 将复杂参数放到字典中即可：
+ (nullable id)handleURL:(nonnull NSString *)urlStr
complexParams:(nullable NSDictionary*)complexParams
completion:(nullable RouteCompletion)completion;
上面方法里的 completion 参数，是一个回调 block, 处理打开某个页面需要有回调功能的场景。比如打开会员选择页面，搜索会员，搜到之后点击确定，回传会员数据：
//kRouteMemberSearch = @“//member/member_search”
UIViewController *vc = [Router handleURL:urlStr complexParams:nil completion:^(id _Nullable result) {
//code to handle the result
...
}];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
考虑到实现的灵活性，提供路由服务的页面，会将 URL 与一个 block 相绑定。block 中放入所需的初始化代码。可以在合适的地方将初始化 block 与路由 URL 绑定，比如在 +load 方法里：
+ (void)load {
[Router bindURL:kRouteGoodsList
toHandler:^id _Nullable(NSDictionary * _Nullable parameters) {
return [[GoodsListViewController alloc] init];
}];
}
更多路由 URL 相关例子，可以参考 Bifrost 项目中的 Demo.
URL 本身是一种跨多端的通用协议。使用路由URL统跳方案的优势是动态性及多端统一 (H5, iOS，Android，Weex/RN); 缺点是能处理的交互场景偏简单。所以一般更适用于简单 UI 页面跳转。一些复杂操作和数据传输，虽然也可以通过此方式实现，但都不是很效率。
目前天猫和蘑菇街都有使用路由 URL 作为自己的页面统跳方案，达到解耦的目的。
当无法 import 某个类的头文件但仍需调用其方法时，最常想到的就是基于反射来实现了。例：
Class manager = NSClassFromString(@"YZGoodsManager"); NSArray *list = [manager performSelector:@selector(getGoodsList)]; //code to handle the list ...
但这种方式存在大量的 hardcode 字符串。无法触发代码自动补全，容易出现拼写错误，而且这类错误只能在运行时触发相关方法后才能发现。无论是开发效率还是开发质量都有较大的影响。
如何进行优化呢？这其实是各端远程调用都需要解决的问题。移动端最常见的远程调用就是向后端接口发网络请求。针对这类问题，我们很容易想到创建一个网络层，将这类“危险代码”封装到里面。上层业务调用时网络层接口时，不需要 hardcode 字符串，也不需要理解内部麻烦的逻辑。
类似的，我可以将模块间通讯也封装到一个“网络层”中（或者叫消息转发层）。这样危险代码只存在某几个文件里，可以特别地进行 code review 和联调测试。后期还可以通过单元测试来保障质量。模块化方案中，我们可以称这类“转发层”为 Mediator (当然你也可以起个别的名字)。同时因为 performSelector 方法附带参数数量有限，也没有返回值，所以更适合使用 NSInvocation 来实现。
//Mediator提供基于NSInvocation的远程接口调用方法的统一封装
- (id)performTarget:(NSString *)targetName
action:(NSString *)actionName
params:(NSDictionary *)params;
//Goods模块所有对外提供的方法封装在一个Category中
@interface Mediator(Goods)
- (NSArray*)goods_getGoodsList;
- (NSInteger)goods_getGoodsCount;
...
@end
@impletation Mediator(Goods)
- (NSArray*)goods_getGoodsList {
return [self performTarget:@“GoodsModule” action:@"getGoodsList" params:nil];
}
- (NSInteger)goods_getGoodsCount {
return [self performTarget:@“GoodsModule” action:@"getGoodsCount" params:nil];
}
...
@end
然后各个业务模块依赖Mediator, 就可以直接调用这些方法了。
//业务方依赖Mediator模块，可以直接调用相关方法 ... NSArray *list = [[Mediator sharedInstance] goods_getGoodsList]; ...
这种方案的优势是调用简单方便，代码自动补全和编译时检查都仍然有效。
劣势是 category 存在重名覆盖的风险，需要通过开发规范以及一些检查机制来规避。同时 Mediator 只是收敛了 hardcode, 并未消除 hardcode, 仍然对开发效率有一定影响。
业界的 CTMediator 开源库，以及美团都是采用类似方案。
3.3 服务注册方案有没有办法绝对的避免 hardcode 呢？如果接触过后端的服务化改造，会发现和移动端的业务模块化很相似。Dubbo 就是服务化的经典框架之一。它是通过服务注册的方式来实现远程接口调用的。即每个模块提供自己对外服务的协议声明，然后将此声明注册到中间层。调用方能从中间层看到存在哪些服务接口，然后直接调用即可。例：
//Goods模块提供的所有对外服务都放在GoodsModuleService中 @protocol GoodsModuleService - (NSArray*)getGoodsList; - (NSInteger)getGoodsCount; ... @end //Goods模块提供实现GoodsModuleService的对象, //并在+load方法中注册 @interface GoodsModule : NSObject@end @implementation GoodsModule + (void)load { //注册服务 [ServiceManager registerService:@protocol(service_protocol) withModule:self.class] } //提供具体实现 - (NSArray*)getGoodsList {...} - (NSInteger)getGoodsCount {...} @end //将GoodsModuleService放在某个公共模块中，对所有业务模块可见 //业务模块可以直接调用相关接口 ... id module = [ServiceManager objByService:@protocol(GoodsModuleService)]; NSArray *list = [module getGoodsList]; ...
这种方式的优势也包括调用简单方便。代码自动补全和编译时检查都有效。实现起来也简单，协议的所有实现仍然在模块内部，所以不需要写反射代码了。同时对外暴露的只有协议，符合团队协作的“面向协议编程”的思想。劣势是如果服务提供方和使用方依赖的是公共模块中的同一份协议（protocol）, 当协议内容改变时，会存在所有服务依赖模块编译失败的风险。同时需要一个注册过程，将 Protocol 协议与具体实现绑定起来。
业界里，蘑菇街的 ServiceManager 和阿里的 BeeHive 都是采用的这个方案。
3.4 通知广播方案基于通知的模块间通讯方案，实现思路非常简单, 直接基于系统的 NSNotificationCenter 即可。
优势是实现简单，非常适合处理一对多的通讯场景。
劣势是仅适用于简单通讯场景。复杂数据传输，同步调用等方式都不太方便。
模块化通讯方案中，更多的是把通知方案作为以上几种方案的补充。
除了模块间通讯的实现，业务模块化架构还需要考虑每个模块内部的设计，比如其生命周期控制，复杂对象传输，重复资源的处理等。可能因为每个公司都有自己的实际场景，业界方案里对这些问题描述的并不是很多。但实际上他们非常重要，有赞在模块化过程中做了很多相关思考和尝试，会在后面环节进行介绍。
四、有赞的模块化实践有赞移动自 16 年起开始实践业务模块化架构方式，大致经历了 2016 年的尝试+摸索，2017 年的思考+优化以及 2018 年的成熟+沉淀几个阶段。期间有过对已有 App 的模块化改造，也试过直接应用于新起项目。模块化方案经历过几次改版，踩过一些坑，也收获了很多宝贵的经验。
4.1 v1.0: 尝试+摸索16 年，有赞微商城、有赞收银等 App 经历了初期的功能快速迭代，内部依赖混乱，耦合严重，急需优化重构。传统的 MVVM、MVP 等优化方式无法从全局层面解决这些问题。后来在 InfoQ 的"移动开发前线"微信群里听了蘑菇街的组件化方案分享，非常受启发。不过当时还是有一些顾虑，比如微商城和收银当时都属于中小型项目，每端开发人员都只有 4-6 人。业务模块化改造后会形成一定的开发门槛，带来一定的开发效率下降。小项目适合模块化改造吗？其收益是否能匹配付出呢？但考虑到当时 App 各模块边界已经稳定，即使模块化改造出现问题，也可以用很小的代价将其降级到传统的中介者模式，所以改造开始了。
4.1.1 模块间通信方式设计首先是梳理我们的模块间通信需求，主要包括以下三种：
UI 页面跳转。比如IM模块点击用户头像打开会员模块的用户详情页。
动作执行及复杂数据传输。比如商品模块向开单模块传递商品数据模型并进行价格计算。
一对多的通知广播。比如 logout 时账号模块发出广播，各业务模块进行 cache 清理及其它相应操作。
我们选择了路由 URL + 远程接口调用封装 + 广播相结合的方式。
对于远程接口调用的封装方式，我们没有完全照抄 Mediator 方案。当时非常期望保留模块化的编译隔离属性。比如当 A 模块对外提供的某个接口发生变化时，不会引发依赖这个接口的模块的编译错误。这样可以避免依赖模块被迫中断手头的工作先去解决编译问题。当时也没有采用Beehive的服务注册方式，也是因为同样的原因。 经过讨论，当时选择参考网络层封装方式，在每个模块中设计一个对外的“网络层” ModuleService。将对其它模块的接口的反射调用，放入各个模块的 ModuleService 中。
同时，我们希望各业务模块不需要去理解所依赖模块的内部复杂实现。比如 A 模块依赖 D 模块的 class D1 的接口 method1， class D2 的接口method2, class D3 的接口 method3. A 需要了解 D 模块的这些内部信息才能完成反射功能的实现。如果 D 模块中这些命名有所变化，还会出现调用失败。所以我们对各个模块使用外观（Facade）模式进行重构。D 模块创建一个外观层 FacadeD. 通过 FacadeD 对象对外提供所有服务，同时隐藏内部复杂实现。调用方也只需要理解 FacadeD 的头文件 包含哪些接口即可。
外观（Facade）模式: 为子系统中的一组接口提供一个一致的界面， Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。
另外，为什么还需要路由 URL 呢？
其实从功能角度，远程接口的网络层，完全可以取代路由 URL 实现页面跳转，而且没有路由 URL 的一些 hardcode 的问题。而且路由 URL 和
远程接口存在一定的功能重合，还会造成后续实现新功能时，分不清应选择路由 URL 还是选择远程接口的困惑。这里选择支持路由 URL 的主要原因是我们存在动态化且多端统一的需求。比如消息模块下发的各种消息数据模型完全是动态的。后端配好展示内容以及跳转需求后，客户端不需要理解具体需求，只需要通过统一的路由跳转协议执行跳转动作即可。
每个模块除了 Facade 模式改造之外，还需要考虑以下问题：
合适的注册及初始化方式。
接收并处理全局事件。
App 层和 Common 层设计。
模块编译产出以及集成到 App 中的方式。
因为考虑到每个 App 中业务模块数量不会很多（我们几个 App 内大多是20个左右），所以我们为每个模块创建了一个 Module 对象并令其为单例。在 +load 方法中将自身注册给模块化 SDK Bifrost. 经测试，这里因为单例造成的内存占用以及 +load 方法引起的启动速度影响都微乎其微。模块需要监听的全局事件主要为 UIApplicationDelegate 中的那些方法。所以我们定义了一个继承 UIApplicationDelegate 的协议 BifrostModuleProtocol，令每个模块的 Module 对象都服从这个协议。App 的 AppDelegate对象，会轮询所有注册了的业务模块并进行必要的调用。
