组件化的意义
当业务变得越来越复杂的时候，整个工程代码量随时间推移会越来越多。最大的影响是降低开发人员的开发效率，比如编译时间，包括合并代码的时间。组件化的过程中会把不同的业务拆分出来，每个独立的业务层的模块能够只依赖它自己直接相关的业务的情况下独立运行。如何理解直接依赖呢，我觉得可以从编译的角度去判断，经常会遇到的一种情况是A依赖B，B依赖C和D，C和D又依赖一堆其他的模块，为了让A能够运行起来，最后可能是依赖了大量的其他模块。现在组件化的目的并不只是把不同的业务模块化，而是希望A不直接依赖B，通过抽象或者其他方式来让A可以调用到B的方法，A只依赖一个中心化的组件提供的服务，来实现A可以不依赖B的情况下独立运行起来。至于中心化的组件要怎样通过A的请求上下文来找到对应的对象以及调用到对象的方法并返回给A正确的结果，这是组件化需要做的事情。
当我们完成了组件化之后好处除了可以提高开发效率，还可以减少开发工作。现在每个模块都更独立了更容易维护了，也不需要很关注其他模块B的细节，比如B引用了其他的模块C和D。每个人都只需要把注意力放到自己的业务上就可以了，工程也可以进行优化，比如把代码打成二进制包，减少编译时间或者直接只配置必要的组件通过壳工程进行开发，开发完成再通过pod发布新的版本。
方案
调研了一下组件化相关的实现方案，整体上有两种基本的思路。一种是基于NSInvocation实现的，因为NSInvocation可以动态调用某个对象的方法，相当于一个万能的方法，由上层对象传入的上下文对象来初始化NSInvocation，然后触发对象方法的调用，代表框架是CTMediator。另外一种思路是基于服务注册的思路，通过中心化的服务管理对象来注册和分发服务，通过接口来抽象方法本身，从而业务层不需要依赖具体的方法实现对象转而依赖接口，而调用方通过之前注册的映射动态创建实际的组件对象进行调用，代表框架是BeeHive。这篇文章，主要是分析CTMediator相关的对象的封装以及接口设计，之后对BeeHive会单独进行分析 算是对这个主题的总结和学习。
本地调用
eg:点击ViewController中的table某一行，跳转到AViewController。通过这个例子来分析一下CTMediator是怎么来实现Client代码对组件方法的调用：
ViewController.m:
#import <CTMediator/CTMediator.h>
#import <A_Category/CTMediator+A.h>
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
if (indexPath.row == 0) {
UIViewController *viewController = [[CTMediator sharedInstance] A_Category_Objc_ViewControllerWithCallback:^(NSString *result) {
NSLog(@"%@", result);
}];
[self.navigationController pushViewController:viewController animated:YES];
}
}
对于ViewController对象来说，目的是为了能跳转到B页面，但是没有直接引用B的头文件，而是依赖了两个跟CTMediator相关的头文件 <CTMediator/CTMediator.h> 和 <A_Category/CTMediator+A.h>。依赖前者是必须的，因为在ViewController需要访问CTMediator对象，而后者是因为调用的A_Category_Objc_ViewControllerWithCallback方法，而这个方法是定义在后者的。
CTMediator+A.h
#import <CTMediator/CTMediator.h>
#import <UIKit/UIKit.h>
@interface CTMediator (A)
- (UIViewController *)A_Category_Objc_ViewControllerWithCallback:(void(^)(NSString *result))callback;
@end
CTMediator+A.m
#import "CTMediator+A.h"
@implementation CTMediator (A)
- (UIViewController *)A_Category_Objc_ViewControllerWithCallback:(void (^)(NSString *))callback
{
NSMutableDictionary *params = [[NSMutableDictionary alloc] init];
params[@"callback"] = callback;
return [self performTarget:@"A" action:@"Category_ViewController" params:params shouldCacheTarget:NO];
}
在CTMediator+A分类中，扩展CTMediator方法，这些方法是只与A组件相关的。在A_Category_Objc_ViewControllerWithCallback方法的具体实现中，对传进来的callback参数做了一层封装放到了params字典中，然后调用了CTMediator的方法performTarget:action:params:shouldCacheTarget。可以看到，前面两个参数是hardcode方式传入的，为什么这里可以hardcode，因为现在是在与A直接有关联的这个category中的，所以它能够把A相关的信息写死到这里。相对而言，问题不是很大。
CTMediator.h
@interface CTMediator : NSObject
+ (instancetype _Nonnull)sharedInstance;
// 远程App调用入口
- (id _Nullable)performActionWithUrl:(NSURL * _Nullable)url completion:(void(^_Nullable)(NSDictionary * _Nullable info))completion;
// 本地组件调用入口
- (id _Nullable )performTarget:(NSString * _Nullable)targetName action:(NSString * _Nullable)actionName params:(NSDictionary * _Nullable)params shouldCacheTarget:(BOOL)shouldCacheTarget;
- (void)releaseCachedTargetWithFullTargetName:(NSString * _Nullable)fullTargetName;
@end
CTMediator.m
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget
{
if (targetName == nil || actionName == nil) {
return nil;
}
NSString *swiftModuleName = params[kCTMediatorParamsKeySwiftTargetModuleName];
// generate target
NSString *targetClassString = nil;
if (swiftModuleName.length > 0) {
targetClassString = [NSString stringWithFormat:@"%@.Target_%@", swiftModuleName, targetName];
} else {
targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
}
NSObject *target = [self safeFetchCachedTarget:targetClassString];
if (target == nil) {
Class targetClass = NSClassFromString(targetClassString);
target = [[targetClass alloc] init];
}
// generate action
NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
SEL action = NSSelectorFromString(actionString);
if (target == nil) {
// 这里是处理无响应请求的地方之一，这个demo做得比较简单，如果没有可以响应的target，就直接return了。实际开发过程中是可以事先给一个固定的target专门用于在这个时候顶上，然后处理这种请求的
[self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
return nil;
}
if (shouldCacheTarget) {
[self safeSetCachedTarget:target key:targetClassString];
}
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];
@synchronized (self) {
[self.cachedTarget removeObjectForKey:targetClassString];
}
return nil;
}
}
}
- (id)safePerformAction:(SEL)action target:(NSObject *)target params:(NSDictionary *)params
{
NSMethodSignature* methodSig = [target methodSignatureForSelector:action];
if(methodSig == nil) {
return nil;
}
const char* retType = [methodSig methodReturnType];
if (strcmp(retType, @encode(void)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
return nil;
}
if (strcmp(retType, @encode(NSInteger)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
NSInteger result = 0;
[invocation getReturnValue:&result];
return @(result);
}
if (strcmp(retType, @encode(BOOL)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
BOOL result = 0;
[invocation getReturnValue:&result];
return @(result);
}
if (strcmp(retType, @encode(CGFloat)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
CGFloat result = 0;
[invocation getReturnValue:&result];
return @(result);
}
if (strcmp(retType, @encode(NSUInteger)) == 0) {
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setArgument:¶ms atIndex:2];
[invocation setSelector:action];
[invocation setTarget:target];
[invocation invoke];
NSUInteger result = 0;
[invocation getReturnValue:&result];
return @(result);
}
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
return [target performSelector:action withObject:params];
#pragma clang diagnostic pop
}
CTMediator中的performTarget:action:params:shouldCacheTarget 这个万能方法核心步骤其实就只有3步:
- 找到target，生成target对象
- 找到target对象的方法
- 调用safePerformAction:target:params:通过NSInvocation动态调用方法
除了这3步，剩下的主要是对于一些对象的缓存处理以及1)和2)失败的情况下的异常处理。通过CTMediator处理之后，最后会调用到Target_A的Action_Category_ViewController方法。
TargetA.h:
@interface Target_A : NSObject
@end
TargetA.m:
#import "Target_A.h"
#import "AViewController.h"
- (UIViewController *)Action_Category_ViewController:(NSDictionary *)params
{
typedef void (^CallbackType)(NSString *);
CallbackType callback = params[@"callback"];
if (callback) {
callback(@"success");
}
AViewController *viewController = [[AViewController alloc] init];
return viewController;
}
Target_A算是最终落地的对象，在Action_Category_ViewController方法中，主要是解析了params参数从里面获取对应的参数信息。这部分参数也是写死的，也是同样的道理，Target_A已经完全属于AViewController的域了，与A相关的信息写死问题不大。除了参数解析剩下的主要是回调处理以及AViewController的生成和返回。关于Target_A这个方法里的逻辑，对于不同的组件可能实现完全不同，但是可以抽象的理解为对参数的解析以及对目标组件初始化逻辑的封装。
URL调用
在上面这个例子中没有涉及url跳转这种例子的处理，需要单独说明一下，这里的URL调用既可能是远程调用，也有可能是本地调用。 先看一下接口及其实现:
CTMediator.h
// 远程App调用入口
- (id _Nullable)performActionWithUrl:(NSURL * _Nullable)url completion:(void(^_Nullable)(NSDictionary * _Nullable info))completion;
CTMediator.m
/*
scheme://[target]/[action]?[params]
url sample:
aaa://targetA/actionB?id=1234
*/
- (id)performActionWithUrl:(NSURL *)url completion:(void (^)(NSDictionary *))completion
{
if (url == nil) {
return nil;
}
NSMutableDictionary *params = [[NSMutableDictionary alloc] init];
NSString *urlString = [url query];
for (NSString *param in [urlString componentsSeparatedByString:@"&"]) {
NSArray *elts = [param componentsSeparatedByString:@"="];
if([elts count] < 2) continue;
[params setObject:[elts lastObject] forKey:[elts firstObject]];
}
// 这里这么写主要是出于安全考虑，防止黑客通过远程方式调用本地模块。这里的做法足以应对绝大多数场景，如果要求更加严苛，也可以做更加复杂的安全逻辑。
NSString *actionName = [url.path stringByReplacingOccurrencesOfString:@"/" withString:@""];
if ([actionName hasPrefix:@"native"]) {
return @(NO);
}
// 这个demo针对URL的路由处理非常简单，就只是取对应的target名字和method名字，但这已经足以应对绝大部份需求。如果需要拓展，可以在这个方法调用之前加入完整的路由逻辑
id result = [self performTarget:url.host action:actionName params:params shouldCacheTarget:NO];
if (completion) {
if (result) {
completion(@{@"result":result});
} else {
completion(nil);
}
}
return result;
}
在对url跳转的处理上，主要有两步:
- 按照 scheme://[target]/[action]?[params] 的方式解析url，获得target, action, params
- 转换成本地调用流程，也就是上面例子的那种方式
相当于CTMediator对于url这部分的处理，最终还是本地调用的方式，只不过封装了一层对于url解析的过程。
设计思想
根据上面这两种情况，我们可以画出整个CTMediator的架构图:
CTMediator.001.png
CTMediator组件自身主要还是对于本地调用的处理，因为URL调用最后也会被转化为对本地接口的调用。对于CTMediator自身，它所做的工作主要是对于某个对象方法调用的请求，按照固定的规则找到对应的target对象以及对应的selector，target对象以及selector的创建都是通过动态的方式生成的，最终也是通过NSInvocator来触发方法的动态调用。所以CTMediator相当于一个万能的方法调用组件，通过OC Runtime来实现动态化。
CTMediator组件的重要性自然是不必说的，现在主要说一下CTMediator+X扩展方法以及Target_X对象的意义：
1.CTMediator+X本身是真正对业务层的接口的封装，因为它是通过category来实现的，所以对业务层来说调用X组件的时候跟平时调用一个普通对象方法没什么区别，因为在category里有完整的方法声明，参数和返回值都是比较清楚的。如果没有这一层的封装，业务层直接调用CTMediator本身的方法是非常头疼的，因为涉及参数拼装，并且这样也导致必须要了解参数将被如何处理这些逻辑，但是这些本应该封装到X组件内部的。而对于CTMediator本身而言，它的意义在于创造了一个查找Target对象和Selector的上下文环境。
2.Target_X的意义在于方法调用之前准备工作，比如参数的解析，AViewController对象的创建等等，是方法调用之前的相关逻辑的封装和过滤。假设没有Target_X这一层存在，那么X组件内部那些原生的业务代码必定会耦合一些组件调用的参数解析的逻辑，这对于X组件内部业务变化是不利的，感觉解耦不够充分。
总体来看，正因为CTMediator+X的存在使得调用方可以很方便的调用X组件的方法，而因为有Target_X的存在，对于被调用方X组件来说，自身可以完全不了解任何组件调用的逻辑，只需要处理好本身的业务需求即可。架构设计本质上就是封装和代码分层。
工程结构
上面的图已经通过颜色区分了它们在项目中的结构，XViewController和Target_X是在一个pod之下的，因为这两必须在同一个域之下，Target_X的意义已经在上面说过了，它是需要知道XViewController初始化相关逻辑的。而CTMediator+A是需要单独列一个pod，它是依赖CTMediator，但是它并不需要放在XViewController的域之中，它只是CTMediator在XViewController对外接口的分类，专门给其他调用方使用。
CTMediator是完全独立的，列为单独一个pod。
网友评论