iOS单例中 Block 回调一对多设计

起因：今天在开发过程中，小伙伴告诉我，我写的全局音乐播放器（单例模式实现）在多个地方同时接收监听状态 Block 时，除了最后一次接收有效以外，其它调用的地方都无法正常执行 Block 里代码。

需求背景

 播放器是通过代理委托来告知外部当前展示的 VC 类关于音乐播放信息，但需求迭代过程中新增了一个App全局页面展示的音乐悬浮窗，悬浮窗需要实时监听当前播放器的播放状态并更新 view ，而且保持原有 VC 类遵循播放器的代理并更新 view。原本通过代理委托一对一实现的场景被打破，现在要满足一对多的场景。产品最终要实现下面的效果：

效果图

解决方案选择

首先想到的第一个方案是，监听播放状态改用 Notification 通知。
 使用通知，实现起来简单，可以满足想要的结果，但也意味着外部每一处需要监听的播放状态，若是后续有更多的需要监听状态，肯定不能每一处都要添加Notification 通知。当初设计单例播放器的目的，就是 高内敛、低耦合，用通知的话实现方式太不优雅，肯定不能让小伙伴在所有要监听状态的地方都添加通知代码，决定放弃这个方案。
第二个方案，播放器单例代理改为一对多代理。
 原本播放器单例是通过代理一对一的形式实现的，如果是让单例的代理实现一对多呢？想起了之前看到的文章：多播代理，主要参考 iOS多播代理 文章。看了下多播代理实现目标，发现与自己的业务场景多少有些出入。播放器通过代理实现一对一的初衷，为了只让展示在用户前的 ViewController 去作为代理类去响应播放器的代理调用，UINavigationController 堆栈中被 topViewController 压在下面的 ViewController 没有必要继续去响应播放器的代理调用。再加上若采用该方案，意味着音乐播放器整体的消息传递方式要发生变动，工作量巨大。多播代理的方案也放弃了。
 回到现在已有的实现中，小伙伴在多处地方已经添加代码去接收这个 block，而且接收的对象都是普通对象，播放器本身是一个单例，分析下来，问题有了眉头——单例中的 block 若在外部多处接收，block 本身已有的代码块会被覆盖，最终就会造成前言提到的问题，只有最后一次可以接收到 block 的消息，其余全部失效。
 如果是让单例中的 block 也能够像多播代理实现一对多呢？
在网上搜罗了一番，发现了这篇文章 一个关于单例的 Block 回调设计 ，采用了 NSMapTable + NSPointerFunctionsWeakMemory 的组合方案来实现。

设计思路

整理了上面文章最终的实现思路：

1. block 持有者为单例中的 NSMapTable ，而非由注册 block 回调对象 observer 持有，并且单例播放器本身仅维护 block 映射关系；
2. 为了解决 block 自动释放问题，由 NSMapTable 来持有 block ，通过给 observer 绑定一个对象 DeallocWatcher ，利用 objc_setAssociatedObject 把 observer 与绑定对象 DeallocWatcher 进行关联，以此监听 DeallocWatcher 的 dealloc 释放，从而间接得知 observer 释放时机，达到 block 自动释放目的。
   文章中提到的间接监听释放时机，在 ReactiveCocoa 中的 onExit 方法也是类似的思路来实现。

实现步骤

1. 创建 NSMapTable 映射表

// key为 observer 注册对象，用 weak 属性表示不持有 observer，仅指向 observer
// value 为 observer 注册的 block 回调，使用 strong 属性意味着映射表要持有 block
self.blockTable = [[NSMapTable alloc] initWithKeyOptions:NSPointerFunctionsWeakMemory valueOptions:NSPointerFunctionsStrongMemory capacity:1];

2. 声明 observer 要绑定的对象 DeallocWatcher 类实现方法

@interface DeallocWatcher: NSObject

@property (nonatomic, copy) dispatch_block_t deallocCallback;

- (instancetype)initWithDeallocCallback:(dispatch_block_t)callback;

@end

@implementation DeallocWatcher

- (instancetype)initWithDeallocCallback:(dispatch_block_t)callback {
    self = [super init];
    if (self) {
        self.deallocCallback = callback;
    }
    return self;
}
// 关键代码，当该对象释放触发 dealloc 方法时，会去执行 callback 回调
- (void)dealloc
{
    if (self.deallocCallback) {
        self.deallocCallback();
    }
}

@end

3. 给 observer 添加关联绑定对象 watch，并添加至映射表中。

- (void)addObserver:(id)observer callback:(isPlayingChangedBlock)callback {
// 这里要打破循环引用，因为关联代码中 watch 被 observer 持有，而 watch 中的 callback 去调用了 observer
    __weak typeof (observer) weakObserver = observer;
  DeallocWatcher *watch = [[DeallocWatcher alloc] initWithDeallocCallback:^{
    __strong typeof (observer) strongObserver = weakObserver;
    [self removeObserver:strongObserver];
  }];
  [self.blockTable setObject:callback forKey:observer];
// 将 observer 与 watch 进行绑定关联，key 则使用 observer 指针指向的内存地址
  objc_setAssociatedObject(observer,(__bridge const void * _Nonnull)([NSString stringWithFormat:@"%p", observer]), watch, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

4. observer 自动释放（后续更正：此处代码已经没必要执行。原因：当 watch 的 block 中执行 remove 方法时，这里 observer 已经释放了，手动关联的watch对象只是触发了dealloc回调，映射表中因为以observer为key弱引用存储，也在表中删除了该key值以及value值）

- (void)removeObserver:(id)observer {
  [self.blockTable removeObjectForKey:observer];
  objc_setAssociatedObject(observer, (__bridge const void * _Nonnull)([NSString stringWithFormat:@"%p", observer]), nil, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

5. 映射表中 block 的触发调用方法。
   下面代码就是项目中是否正在播放状态的成员变量 set 方法。每当 isPlaying 发生变化时，都会将映射表中的 block 执行一遍，最终达到单例中的 block 实现一对多的目的。

- (void)setIsPlaying:(BOOL)isPlaying{
  _isPlaying = isPlaying;

  [[[self.blockTable objectEnumerator] allObjects] enumerateObjectsUsingBlock:^(isPlayingChangedBlock callback, NSUInteger idx, BOOL * _Nonnull stop) {
    callback(isPlaying);
  }];
}

---

应小伙伴要求demo查看，我花了十来分钟写了个简易demo，有兴趣的可以去下载了。链接：https://github.com/RoganZheng/Block-one-to-many-demo-in-a-single-case

后续文章，凡是涉及到实践代码的内容，我会注意提供相关代码demo链接。