iOS消息分发中心的实现

后端的启发 && 前端的尴尬

最近一直在看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设计，简单的使用，是减少入侵和耦合的最好方式。

代码

项目代码
Demo代码

更多的问题

然而，这个消息分发中心并不完善，还有不少其他问题需要考虑：

• 如何做消息优先级区分
• 消息发送失败怎么办，是否支持重发
• ......