RAC中监听通知的坑！

在很多文章里面都介绍了RAC的用法，其中对于NSNotificationCenter的介绍实在太少了。只说用RAC来处理的话不用removeObserver，但是其实不然。

如果这个界面是被push过来的。 在viewDidLoad中，监听通知，使用RAC。 然后pop回去，再push进来。。。 结果就是这个通知被添加了多个观察者，而之前的已经被释放了。看似没问题，因为向nil发消息是没问题的，但是如果里面还有单例的访问，或是像上一篇文章说的，用->运算符的话，就会出现严重的问题。 就是说，viewDidLoad走几次，下次通知触发的时候就会走几遍block。

因为RAC的监听通知的实现原理是：

@implementation NSNotificationCenter (RACSupport)

- (RACSignal *)rac_addObserverForName:(NSString *)notificationName object:(id)object {
	@unsafeify(object);
	return [[RACSignal createSignal:^(id<RACSubscriber> subscriber) {
		@strongify(object);
		id observer = [self addObserverForName:notificationName object:object queue:nil usingBlock:^(NSNotification *note) {
			[subscriber sendNext:note];
		}];

		return [RACDisposable disposableWithBlock:^{
			[self removeObserver:observer];
		}];
	}] setNameWithFormat:@"-rac_addObserverForName: %@ object: <%@: %p>", notificationName, [object class], object];
}

@end
复制代码

就是订阅机制。subscribeNext就是订阅。常理之中，如何移除订阅呢？肯定是调用RACDisposable中的dispose方法。注意，[NSNotificationCenter defaultCenter] removeObserver是无效的。 因为我们订阅的是RAC的signal。

但是在RAC的实现里面，RACDisposable的确是创建了，却没有合适的时候调用dispose方法。所以下面的block根本就不会走，根本不会removeObserver！

[RACDisposable disposableWithBlock:^{
    [self removeObserver:observer];
}];
复制代码

它return给谁了？另外NSNotificationCenter是个单例，所以它的rac_willDeallocSignal肯定是程序结束的时候才会有，并且它的实现里面并没有订阅rac_willDeallocSignal。

我们想要移除这个观察者只有一个办法，就是把这个返回的RACSignal用RACDisposable来接收，在控制器的dealloc中，调用它的dispose方法。 但是这样做，得不偿失，这样控制器就要持有这个返回的结果。倒不如用系统原来的做法了。

RAC固然还是相当强大的，但是在需要监听通知的时候，不推荐使用RAC！

如果有什么不同意见，欢迎在评论区留言讨论~