组件化架构的由来
随着应用版本和产品需求的不断迭代，业务性的代码将会越来越多，为了更好的管理应用工程，我们可以使用CocoaPods版本管理工具对原有应用工程进行拆分。但是仅仅完成代码拆分还不足以解决业务之间的代码耦合，为了更好的让拆分出去的业务工程能够独立运行，还必须对组件拆分的颗粒度有很好的把控。
在准备做组件化的时候，需要对它有充足的认识和思考，下面是一些很好的文章：
组件化方案
组件化其实并不复杂，它本质上是一种app架构思路，搭建组件化不是难点，难在组件化改造的时候，真正写起代码会出现不少棘手的问题。组件化是一种app架构，它的发展也是沿着正常的技术发展脉络来的，也是为了以追求高复用，高可维护性的目的的代码封装，区别是组件化是对整个 app的再次封装。下面介绍三种常规的方案：
1. target - action
casatwy为我们提供了一个 Demo，通过这个Demo可以很好的理解casatwy的设计思路
在CTMediator中定义远程调用和本地调用的两个方法，其他业务相关的调用由Category完成。
// 远程App调用入口
- (id)performActionWithUrl:(NSURL *)url completion:(void(^)(NSDictionary *info))completion;
// 本地组件调用入口
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params;
以一个简单的页面跳转为例，来看一下它的实现方式
首先页面间的交互没有import对应的Controller，而是通过在CTMediator中定义的Category完成，根据Category定义的方法实现了跳转的同时达到了页面解藕的目的
UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail];
[self.navigationController pushViewController:viewController animated:YES];
组件调用时，在CTMediator中定义的ModuleA的Category，对外提供了一个获取控制器并跳转的功能
UIViewController *viewController = [self performTarget:kCTMediatorTargetA
action:kTargetController
params:@{@"key":@"value"}
shouldCacheTarget:NO];
这里需要注意传递几个参数，使用时要对应
taegetName //抛出对象类的名称 只需要传递Target_后面的部分
actionName //控制器名称
params //跳转需要的参数
shouldCacheTarget //是否缓存,方便经常使用
由于这种方式主要调用了下述方法完成
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget
来看一下它内部的实现方式
1.首先通过 runtime 方法 NSClassFromString( ) 去找到我们即将跳转的 Controller;
// generate target
NSString *targetClassString = nil;
if (swiftModuleName.length > 0) {
targetClassString = [NSString stringWithFormat:@"%@.Target_%@", swiftModuleName, targetName];
} else {
targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
}
NSObject *target = self.cachedTarget[targetClassString];
if (target == nil) {
Class targetClass = NSClassFromString(targetClassString);
target = [[targetClass alloc] init];
}
2.生成目标 Controller 需要实现的方法 action
// generate action
NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
SEL action = NSSelectorFromString(actionString);
3.通过 respondsToSelector 判断 Controller 是否可以实现方法 action，能够实现的话则返回目标 Controller，否则要做一些相应的容错处理
if ([target respondsToSelector:action]) {
return [self safePerformAction:action target:target params:params];
} else {
// 这里是处理无响应请求的地方，如果无响应，则尝试调用对应target的notFound方法统一处理
SEL action = NSSelectorFromString(@"notFound:");
if ([target respondsToSelector:action]) {
return [self safePerformAction:action target:target params:params];
} else {
// 这里也是处理无响应请求的地方，在notFound都没有的时候，这个demo是直接return了。实际开发过程中，可以用前面提到的固定的target顶上的。
[self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
[self.cachedTarget removeObjectForKey:targetClassString];
return nil;
}
}
由于casatwy的方案中使用performTarget的方式进行调用，所以涉及到很多硬编码字符串的问题，casatwy采取定义常量字符串来解决这个问题，这样管理也更方便。
NSString * const kCTMediatorTargetA = @"A";
NSString * const kCTMediatorActionNativFetchDetailViewController = @"nativeFetchDetailViewController";
NSString * const kCTMediatorActionNativeNoImage = @"nativeNoImage";
NSString * const kCTMediatorActionShowAlert = @"showAlert";
NSString * const kCTMediatorActionCell = @"cell";
以上是这种方式实现组件跳转的链路方式,当然也不仅限于支持页面的跳转，对于所需的响应事件在Category中有对应的方法即可。该模式的特点：中间层代码量少、对项目的侵入性低。
它是把相关参数组合生成控制器对象，并对传参以字典的方式封装一起。我们做组件化时尽可能只暴露当前组件模块所需要的参数，需要组件化的模块都是单独的模块，组件内部的实现与外界无关，都是通过外部传入的必须参数来构建组件的内容，以减少耦合的可能性。
2. url-block
这是蘑菇街中应用的一种页面间调用的方式，通过在启动时注册组件提供的服务，把调用组件使用的url和组件提供的服务block对应起来，保存到内存中。在使用组件的服务时，通过url找到对应的block，然后获取服务。
注册：
[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
NSNumber *id = routerParameters[@"id"];
// create view controller with id
// push view controller
}];
调用：
[MGJRouter openURL:@"mgj://detail?id=404"]
蘑菇街为了统一iOS和Android的平台差异性，专门用后台来管理url，然后针对不同的平台，生成不同类型的文件，来方便使用。
使用url-block的方案的确可以组建间的解耦，但是还是存在其它明显的问题，比如：
- 需要在内存中维护url-block的表，组件多了可能会有内存问题
- url的参数传递受到限制，只能传递常规的字符串参数，无法传递非常规参数， 如UIImage、NSData等类型
- 没有区分本地调用和远程调用的情况，尤其是远程调用，会因为url参数受限，导致一些功能受限
- 组件本身依赖了中间件，且分散注册使的耦合较多
3. JLRoutes + Objection
这种方式分为两个步骤
第一步是业务的模块化
每个模块单独分类，模块一般由七个部分组成，所有的资源文件和功能性代码分别独立开来。以方便后期的维护，模块相互之间也是独立的
简述一下各个模块的功能
DTO //数据模型
Module //继承JSObjectionModule，该类实现了module的注册，以及class和protocol的绑定。
Presenter //网络请求
Resource //用来存在资源文件，如Bundle，Images等
View //用来存在View或者Cell
ViewContoller
项目中截图如下
需要注意的是 Protocol文件夹 一般模块的 protocol 文件不存放在当前模块，而是把所有的模块 protocol 统一存在在一起，以方便管理，这里只是用来说明。
第二步是模块与模块之间的交互
交互采用的是Routes + Objection
模块之间的交互通过import protocol 文件的方式
文件中Objection绑定生成的对像来完成，如上示意图中，模块A通过路由传值给模块B，模块B生成Object对象在路由中完成交互，当然这种方式不局限在路由中完成。
代码如下
protocol 文件中Objection绑定生成的对像
// 这个宏返回控制器对象
#define APPCONTEXT_GET_ProductDetails(productDetails) \
UIViewController <ProductDetailsProtocol> *productDetails = [[JSObjection defaultInjector] getObject:@protocol(ProductDetailsProtocol)];
页面的交互方式
APPCONTEXT_GET_ProductDetails(productDetails)//控制器对象
productDetails.btnTitle = [[_dataArray objectAtIndex:indexPath.row] firstObject];
[self.navigationController pushViewController:productDetails animated:YES];
4.小结
组件化是功能重用的基石业务组件类似一个个积木一样，我们可以用积木搭建出不同的房子，同理我们也可以创建多个不同的APP。我们只需要维护好每个组件，需要用到该组件的功能时，一建引用集成就可以了。当然，组件化并不是说只有好处没有坏处，例如：组件化开发前期可能要花费更多的时间来进行模块拆分；组件化可能会带来更多重复的代码。组件化需要良好的架构设计，包括怎么拆分业务，组件之间怎么通信等等，需要有个高水平的架构师统筹全局，我们并不要为了组件化而组件化，我们要根据实际情况来决定。
5.参考文章及知名APP组件化方案
作者 ZJL
2019 年 06月 17日
