后端的启发 && 前端的尴尬
最近一直在看React Native的一些相关设计，对其Redux的设计模式很感兴趣。Redux其实是一种响应式的设计，跟移动端中的MVVM有点类似，都是基于对状态的监听和绑定。当然，Redux跟MVVM还是有很大区别的，Redux的数据流是单向的，MVVM的不是。然而，无论是Redux还是MVVM，都离不开模块间的消息传递，无论是传递数据还是传递变化状态。对后端有一定了解的都知道，后端架构非常复杂，其中就包含了消息分发的功能。
随着移动端项目规模越来越大，模块间状态管理越来越复杂，各个组件间通讯成本越来越高，如果还是采用传统的Delegate,target-action,Notification,KVO来进行状态管理，那么会使得状态管理非常离散，到处都是Delegate代码。而对于全局状态的管理，Delegate就显得力不从心了。所以，为了解决越来越高的组件间通讯成本，需要引入一种类似于后端架构中的消息分发器，用来做消息转发的中介者，而不是组件和组件间的直接通讯。简单说就是组件间通讯的统一管理。
怎么设计
在iOS中，如何设计一个消息分发中心呢？首先要思考以下几个问题：
- 一个消息体由什么组成
- 使用什么方式进行发送
- 如何对消息进行订阅
- 分发中心如何分发消息
- 是否需要先注册消息才能发送
- 消息太多是否会阻塞
- 如何减少对代码的入侵
Dispatch Cener 的设计
一个消息体，除了要包含消息内容外，还需要一个消息标识，作为消息的唯一标识，区分不同消息体。
YKMessage.h
@interface YKMessage : NSObject
/**
消息唯一标识
*/
@property (nonatomic, readonly) NSString *identify;
/**
消息内容
*/
@property (nonatomic, readonly) id context;
/**
消息初始化函数
@param identify 消息唯一标识
@param context 内容
@return 消息
*/
- (instancetype)initWithIdentify: (NSString *)identify context: (id)context;
YKMessage.m
@interface YKMessage()<NSCopying>
@property (nonatomic, readwrite) NSString *identify;
@property (nonatomic, readwrite) id context;
@end
@implementation YKMessage
- (instancetype)initWithIdentify: (NSString *)identify context: (id)context {
self = [super init];
if (self) {
_identify = [identify copy];
_context = [context copy];
}
return self;
}
- (id)copyWithZone:(NSZone *)zone {
YKMessage *message = [[[self class]allocWithZone:zone]init];
message.identify = self.identify;
message.context = self.context;
return message;
}
消息的发送：首先构造消息体，然后通过分发中心进行发送
YKMessage *message = [[YKMessage alloc]initWithIdentify:@"test" context:@[@"1",@"2"]];
[[YKDispatchCenter shared]dispatchMessage:message];
在需要接收消息的地方订阅消息：
[[YKDispatchCenter shared]subscribeWithBinder:self messageIdentify:@"test" handler:^(YKMessage *message, id ext) {
NSLog(@"dd");
}];
这里有人会好奇为什么要加入binder这个参数，绑定self。我解析一下：
每一个消息的订阅者，都有自己的生命周期和作用域，当这个消息订阅者被释放后，基于它的消息回调也应该被释放掉，不应再被执行。因此回调是否被执行，就要看绑定者是否被释放了。
那传入binder后，分发中心怎么知道binder是否已经被释放了？
这里就要说一下一个弱应用可变数组NSPointerArray。
平时使用NSMutableArray和NSArray的时候，其数组元素是不能为一个空值的，这是因为当数组元素被add进去的时候，该元素就被数组持有，内存引用计数会+1，而如果元素是空值的话，就会crash或报错。
但是，使用弱引用数组就不会有这种问题。弱引用数组添加元素的时候，会对元素进行一次弱引用，不会持有该元素，所以不会使元素的内存引用发生变化，因此即使add进一个空值，也不会crash或报错。
所以binder不会被消息分发中心持有，当binder被回收后，消息中心持有的弱引用数组中的binder弱引用也会变成空值，在执行回调前就可以通过这个来判断回调是否应该被执行了。
回到第四个问题：分发中心如何分发消息？
- (void)dispatchMessage: (YKMessage *)message {
if (message == nil) {
return;
}
if (![self.registerDictionary.allKeys containsObject:message.identify]) {
return;
}
[self dealMessage:[message copy]];
}
- (void)dealMessage: (YKMessage *)message {
// 实现异步发送通知
dispatch_async(self.serialQueue, ^{
[[NSNotificationCenter defaultCenter]postNotificationName:message.identify object:message];
});
}
- (BOOL)registerMessageWithIdentify: (NSString *)messageIdentify {
if ([self.registerDictionary.allKeys containsObject:messageIdentify]) {
return NO;
}
[self.registerDictionary setValue:@"" forKey:messageIdentify];
[[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(observerHandler:) name:messageIdentify object:nil];
return YES;
}
- (BOOL)unRegisterMessageWithIdentify: (NSString *)messageIdentify {
if (![self.registerDictionary.allKeys containsObject:messageIdentify]) {
return NO;
}
[self.registerDictionary removeObjectForKey:messageIdentify];
[self.actionDictionary removeObjectForKey:messageIdentify];
[[NSNotificationCenter defaultCenter]removeObserver:self name:messageIdentify object:nil];
return YES;
}
消息分发中心是基于通知来实现，在注册的时候将通知的发送者和接收者都绑定到自身上。通过发送通知和接收通知，来实现消息分发。
那为什么需要先注册消息才能发送呢？
首先，消息不是随便发就能发的。例如支付模块中，支付成功的消息必须是在支付模块中注册后才能发送，不能随便哪个模块就能直接发送支付成功的消息。在支付模块加载后注册支付成功的消息，在支付模块卸载后反注册支付成功消息，这样就能够控制消息发送的权限了。
其次，性能问题。有注册就有反注册，通过反注册销毁不需要维护的消息列表和通知观察者，减少性能消耗。
再次，业务问题。比如在某种情况下，不再需要某个消息了，所有这个消息的回调都不需要了。这时，通过反注册，就可以做到。
那消息太多是否会阻塞？
NSNotificationCenter在主线程中是同步的，当通知产生时，通知中心会一直等待所有观察者都收到且处理通知完毕后，才会返回发送通知的地方继续执行后面的代码。通常来说，如果消息太多，NSNotificationCenter会变慢。然而，这里通过创建一个serialQueue串行队列，并将消息的发送和接收放到这队列中执行，从而避免主队列的阻塞等待。
- (void)dealMessage: (YKMessage *)message {
// 实现异步发送通知
dispatch_async(self.serialQueue, ^{
[[NSNotificationCenter defaultCenter]postNotificationName:message.identify object:message];
});
}
- (void)observerHandler: (NSNotification *)notification {
// 实现异步接收通知
dispatch_async(self.serialQueue, ^{
YKMessage *object = (YKMessage *)notification.object;
if (object != nil) {
NSString *messageIdentify = object.identify;
[self actionAndCleanWithMessageIdentify:messageIdentify message:object doHandler:YES];
}
});
}
如果消息实在太多，还是会对性能有一定影响，但是这里对发送和接收通知进行异步操作，不会阻塞主线程。
那如何减少对代码的入侵？
// 订阅
[[YKDispatchCenter shared]subscribeWithBinder:self messageIdentify:@"test" handler:^(YKMessage *message, id ext) {
NSLog(@"dd");
}];
// 发送
YKMessage *message = [[YKMessage alloc]initWithIdentify:@"test" context:@[@"1",@"2"]];
[[YKDispatchCenter shared]dispatchMessage:message];
简洁的API设计，简单的使用，是减少入侵和耦合的最好方式。
代码
更多的问题
然而，这个消息分发中心并不完善，还有不少其他问题需要考虑：
- 如何做消息优先级区分
- 消息发送失败怎么办，是否支持重发
- ......
