消失的四分之三月小姐姐复习了一下之前写的好几十篇文章，发现写时一时爽，写后火葬场。终于开始恢复更新啦~
KVOController
Git：https://github.com/facebook/KVOController
KVOController builds on Cocoa's time-tested key-value observing implementation. It offers a simple, modern API, that is also thread safe. Benefits include:

• Notification using blocks, custom actions, or NSKeyValueObserving callback.
• No exceptions on observer removal.
• Implicit observer removal on controller dealloc.
• Thread-safety with special guards against observer resurrection

1. 获取一个KVOController实例 我们可以直接从自己拿到一个KVOController，因为KVOController给NSObject加了一个category：

#import "NSObject+FBKVOController.h"#import #if !__has_feature(objc_arc) #error This file must be compiled with ARC. Convert your project to ARC or specify the -fobjc-arc flag. #endif#pragma mark NSObject Category -NS_ASSUME_NONNULL_BEGINstatic void *NSObjectKVOControllerKey = &NSObjectKVOControllerKey; static void *NSObjectKVOControllerNonRetainingKey = &NSObjectKVOControllerNonRetainingKey; @implementation NSObject (FBKVOController)- (FBKVOController *)KVOController { id controller = objc_getAssociatedObject(self, NSObjectKVOControllerKey); // lazily create the KVOController if (nil == controller) { controller = [FBKVOController controllerWithObserver:self]; self.KVOController = controller; }return controller; }- (void)setKVOController:(FBKVOController *)KVOController { objc_setAssociatedObject(self, NSObjectKVOControllerKey, KVOController, OBJC_ASSOCIATION_RETAIN_NONATOMIC); }- (FBKVOController *)KVOControllerNonRetaining { id controller = objc_getAssociatedObject(self, NSObjectKVOControllerNonRetainingKey); if (nil == controller) { controller = [[FBKVOController alloc] initWithObserver:self retainObserved:NO]; self.KVOControllerNonRetaining = controller; }return controller; }- (void)setKVOControllerNonRetaining:(FBKVOController *)KVOControllerNonRetaining { objc_setAssociatedObject(self, NSObjectKVOControllerNonRetainingKey, KVOControllerNonRetaining, OBJC_ASSOCIATION_RETAIN_NONATOMIC); }@end

可以看到其实就是创建了一个FBKVOController然后作为关联对象保存给了self。注意这里可以拿到两种controller，一个是KVOController，另一种是KVOControllerNonRetaining，他们的区别就是在alloc init的时候传入的retainObserved是YES还是NO。
2. FBKVOController初始化 上面的retainObserved到底是啥呢我们现在来看看~

@implementation FBKVOController { NSMapTable *> *_objectInfosMap; pthread_mutex_t _lock; }#pragma mark Lifecycle -+ (instancetype)controllerWithObserver:(nullable id)observer { return [[self alloc] initWithObserver:observer]; }- (instancetype)initWithObserver:(nullable id)observer retainObserved:(BOOL)retainObserved { self = [super init]; if (nil != self) { _observer = observer; NSPointerFunctionsOptions keyOptions = retainObserved ? NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPointerPersonality : NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality; _objectInfosMap = [[NSMapTable alloc] initWithKeyOptions:keyOptions valueOptions:NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPersonality capacity:0]; pthread_mutex_init(&_lock, NULL); } return self; }- (instancetype)initWithObserver:(nullable id)observer { return [self initWithObserver:observer retainObserved:YES]; }- (void)dealloc { [self unobserveAll]; pthread_mutex_destroy(&_lock); }

每个FBKVOController对象会有两个成员变量：一个是_lock防止对table的多线程操作；一个是NSMapTable记录了被监听对象以及监听了他的哪些属性的infos。
我们默认初始化方法initWithObserver其实最后也是调到了initWithObserver:(nullable id)observer retainObserved:(BOOL)retainObserved，并且默认是retain的~
在初始化的时候，先init了_objectInfosMap，如果retainObserved为YES，那么_objectInfosMap的key就是NSPointerFunctionsStrongMemory的，反之则是NSPointerFunctionsWeakMemory，也就是map不持有key的强引用。然后init了一下lock。
然后下面正好看到了dealloc，里面也很简单就是调用了自己的unobserveAll方法，以及destroy了锁~
3. 如何addObserver 我们使用的observe方法是做了什么呢？

- (void)observe:(nullable id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block { NSAssert(0 != keyPath.length && NULL != block, @"missing required parameters observe:%@ keyPath:%@ block:%p", object, keyPath, block); if (nil == object || 0 == keyPath.length || NULL == block) { return; }// create info _FBKVOInfo *info = [[_FBKVOInfo alloc] initWithController:self keyPath:keyPath options:options block:block]; // observe object with info [self _observe:object info:info]; }

其实这里就是创建了一个_FBKVOInfo，其实就是一个model类用于记录keyPath之类的：

@implementation _FBKVOInfo { @public __weak FBKVOController *_controller; NSString *_keyPath; NSKeyValueObservingOptions _options; SEL _action; void *_context; FBKVONotificationBlock _block; _FBKVOInfoState _state; }========================== - (instancetype)initWithController:(FBKVOController *)controller keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block { return [self initWithController:controller keyPath:keyPath options:options block:block action:NULL context:NULL]; }- (instancetype)initWithController:(FBKVOController *)controller keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(nullable FBKVONotificationBlock)block action:(nullable SEL)action context:(nullable void *)context { self = [super init]; if (nil != self) { _controller = controller; _block = [block copy]; _keyPath = [keyPath copy]; _options = options; _action = action; _context = context; } return self; }

然后调用了内部的_observe：

- (void)_observe:(id)object info:(_FBKVOInfo *)info { // lock pthread_mutex_lock(&_lock); NSMutableSet *infos = [_objectInfosMap objectForKey:object]; // check for info existence _FBKVOInfo *existingInfo = [infos member:info]; if (nil != existingInfo) { // observation info already exists; do not observe it again// unlock and return pthread_mutex_unlock(&_lock); return; }// lazilly create set of infos if (nil == infos) { infos = [NSMutableSet set]; [_objectInfosMap setObject:infos forKey:object]; }// add info and oberve [infos addObject:info]; // unlock prior to callout pthread_mutex_unlock(&_lock); [[_FBKVOSharedController sharedController] observe:object info:info]; }

之前我们创建的_lock其实就是在这里用的~ 感觉所有lock几乎都是给set map之类的操作用的0.0
上面这段其实就是把我们刚才创建的_FBKVOInfo存起来。_objectInfosMap这个map是以object为key的，然后value是一个set，存了这个target所有加的KVOInfo，如果这个set里面已经包含了要加的info就会直接return，如果没有就加到set里然后调用[[_FBKVOSharedController sharedController] observe:object info:info]; }：

- (void)observe:(id)object info:(nullable _FBKVOInfo *)info { if (nil == info) { return; }// register info pthread_mutex_lock(&_mutex); [_infos addObject:info]; pthread_mutex_unlock(&_mutex); // add observer [object addObserver:self forKeyPath:info->_keyPath options:info->_options context:(void *)info]; if (info->_state == _FBKVOInfoStateInitial) { info->_state = _FBKVOInfoStateObserving; } else if (info->_state == _FBKVOInfoStateNotObserving) { // this could happen when `NSKeyValueObservingOptionInitial` is one of the NSKeyValueObservingOptions, // and the observer is unregistered within the callback block. // at this time the object has been registered as an observer (in Foundation KVO), // so we can safely unobserve it. [object removeObserver:self forKeyPath:info->_keyPath context:(void *)info]; } }

上面其实就是_FBKVOSharedController有一个hashtable用于记录infos，是weak memory的哈，这里先把info加进去，然后给object真正的add KVO啦~~ 最后改一下state~~
这里比较神奇的是为啥会有info->_state == _FBKVOInfoStateNotObserving的情况，看注释其实就是如果是initial的那种KVO，在add的时候就会回调了，也就是[object addObserver:self forKeyPath:info->_keyPath options:info->_options context:(void *)info]这一行，那么如果在回调里面又remove了KVO，到下面的时候这个state就已经是_FBKVOInfoStateNotObserving了~

需要注意的是add KVO的时候info做为context哦

我们终于看完了怎么加的，然后来看下如何回调的~ 因为上面加监听的时候observer是self，也就是_FBKVOSharedController，所以会回调下面的：

- (void)observeValueForKeyPath:(nullable NSString *)keyPath ofObject:(nullable id)object change:(nullable NSDictionary *)change context:(nullable void *)context { NSAssert(context, @"missing context keyPath:%@ object:%@ change:%@", keyPath, object, change); _FBKVOInfo *info; { // lookup context in registered infos, taking out a strong reference only if it exists pthread_mutex_lock(&_mutex); info = [_infos member:(__bridge id)context]; pthread_mutex_unlock(&_mutex); }if (nil != info) {// take strong reference to controller FBKVOController *controller = info->_controller; if (nil != controller) {// take strong reference to observer id observer = controller.observer; if (nil != observer) {// dispatch custom block or action, fall back to default action if (info->_block) { NSDictionary *changeWithKeyPath = change; // add the keyPath to the change dictionary for clarity when mulitple keyPaths are being observed if (keyPath) { NSMutableDictionary *mChange = [NSMutableDictionary dictionaryWithObject:keyPath forKey:FBKVONotificationKeyPathKey]; [mChange addEntriesFromDictionary:change]; changeWithKeyPath = [mChange copy]; } info->_block(observer, object, changeWithKeyPath); } else if (info->_action) { #pragma clang diagnostic push #pragma clang diagnostic ignored "-Warc-performSelector-leaks" [observer performSelector:info->_action withObject:change withObject:object]; #pragma clang diagnostic pop } else { [observer observeValueForKeyPath:keyPath ofObject:object change:change context:info->_context]; } } } } }

这里其实就是回调observeValueForKeyPath的时候可以直接从里面拿context，然后把context转为info，得到kvocontroller以及info->_block，为了防止监听了同一个object的多个keyPath，它在回调的时候往change字典里面塞了一个FBKVONotificationKeyPathKey为key的path。
到这里就完整的进行了改变属性触发回调block了~ 下面来看下remove以及自动remove~

文章图片
监听实现 4. removeObserver 我们可以手动调用removeObserver：

- (void)unobserve:(nullable id)object keyPath:(NSString *)keyPath { // create representative info _FBKVOInfo *info = [[_FBKVOInfo alloc] initWithController:self keyPath:keyPath]; // unobserve object property [self _unobserve:object info:info]; }- (void)unobserve:(nullable id)object { if (nil == object) { return; }[self _unobserve:object]; }- (void)unobserveAll { [self _unobserveAll]; }

如果传入了keyPath，那么会创建一个_FBKVOInfo哈~ 也可以只取消某个某个被观察者的所有KVO，还可以取消这个KVOController的所有观察，这里每个NSObject会有自己的KVOController哈

- (void)_unobserve:(id)object info:(_FBKVOInfo *)info { // lock pthread_mutex_lock(&_lock); // get observation infos NSMutableSet *infos = [_objectInfosMap objectForKey:object]; // lookup registered info instance _FBKVOInfo *registeredInfo = [infos member:info]; if (nil != registeredInfo) { [infos removeObject:registeredInfo]; // remove no longer used infos if (0 == infos.count) { [_objectInfosMap removeObjectForKey:object]; } }// unlock pthread_mutex_unlock(&_lock); // unobserve [[_FBKVOSharedController sharedController] unobserve:object info:registeredInfo]; }

我们移除某个特定观察者的监听keyPath的时候，它是从_objectInfosMap里面先找到这个被监听这的info set，然后找到我们要取消的set拿出去，也就是删除掉记录，最后调用[[_FBKVOSharedController sharedController] unobserve:object info:registeredInfo]：

- (void)unobserve:(id)object info:(nullable _FBKVOInfo *)info { if (nil == info) { return; }// unregister info pthread_mutex_lock(&_mutex); [_infos removeObject:info]; pthread_mutex_unlock(&_mutex); // remove observer if (info->_state == _FBKVOInfoStateObserving) { [object removeObserver:self forKeyPath:info->_keyPath context:(void *)info]; } info->_state = _FBKVOInfoStateNotObserving; }

_FBKVOSharedController也是把info先从记录移除，然后removeObserver并改一下info->_state。这里为了防止已经被移除的仍旧执行remove会判断一下state~
移除某个被观察者的所有监听之诶的其实就是循环遍历infos，然后执行上面的移除~
我们上面其实很多地方都在判断这个info是不是已经添加了，之所以可以这么做，是因为info有覆写等同性：

- (NSUInteger)hash { return [_keyPath hash]; }- (BOOL)isEqual:(id)object { if (nil == object) { return NO; } if (self == object) { return YES; } if (![object isKindOfClass:[self class]]) { return NO; } return [_keyPath isEqualToString:((_FBKVOInfo *)object)->_keyPath]; }

也就是对于info而言只要监听的keyPath是同一个，就可以被认为是相等的哈~~

• 此外为什么_FBKVOSharedController还要有个infos集合呢？明明kvocontroller已经用map+set的方式记录了被观察者们的info了吖。

这里其实是因为KVO被触发的时候回调的是_FBKVOSharedController的方法，然后这个时候传入的context就是info其实，但是作者从infos里面找了一下是不是在infos里面，如果不是就return了相当于。

_infos = [infos initWithOptions:NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality capacity:0];

我猜之所以不能拿着context转为info直接用，大概因为infos是weak memory的，如果这个info已经由于某些原因被回收了，那么这个时候我们就在infos里面找不到了，虽然我觉得这个猜测不是很合理叭，如果有知道为啥不能拿着context直接用的朋友欢迎探讨啊~

另外一个问题是，为啥info重写了isEqual以及hash改为了看keyPath的情况下，如果监听了两个不同的对象的相同keyPath属性，所创建的两个info都可以加入到infos的hashTable呢，明明他俩是equal的啊？
这个原因是，其实这里的infos的等同性判断是由NSPointerFunctionsObjectPointerPersonality定义的，也就是不仅仅要hash和isEqual一样，pointer地址的shift的hash也要一样。

• 我理解的之所以info要重写等同性，是为了在FBKVOController的- (void)_observe:(id)object info:(_FBKVOInfo *)info里面可以获取重复加入的对相同object监听的相同keyPath的existingInfo，防止重复的keyPath监听。但这个_FBKVOSharedController单例里面的infos是公用的，并且不想让它keep住info的指针就用了weak的HashTable，但对于不同的被监听object即使是相同keyPath的info也应该可以加入，所以等同性就增加了NSPointerFunctionsObjectPersonality来判断pointer也得偏移hash一样才不能重复加入。

※ 自动移除监听 KVOController的一个好处就是我们可以不用必须手动unobserve，在对象dealloc的时候会自动移除所有监听：

// FBKVOController - (void)dealloc { [self unobserveAll]; pthread_mutex_destroy(&_lock); }

也就是其实是依赖于KVOController被回收的时候去unObserveAll的，而KVOController其实是NSObject的一个fake属性，存在了它的关联dict里。
我们init KVOController的时候有一个属性是要不要保留被观察者的强指针，如果是需要的话也就是retain的方式，就会用strong key的map来保存被观察者；如果是non retain的方式，就会用weak key的map来保存被观察者。
先考虑一下retain的方式会有什么问题，KVOController会持有_objectInfosMap，_objectInfosMap强持有了被观察的对象，如果我们是用self监听self，那么这个时候self就会持有一个KVOController，KVOController又持有了self，这个时候self是无法被释放掉的，那么KVOController也自然不能被释放。这种情况就需要我们在对象即将销毁的时候手动的unobserveAll或者取消对这个对象的所有观察
现在考虑一下non-retain的KVOController，还是上面那个case的话，_objectInfosMapweak持有了被观察的对象，这个时候即使self观察了self，也不会被KVOController持有，那么self是可以释放的，然后就可以释放KVOController了，KVOController在释放走dealloc的时候就会自动的unobserveAll了。
我之前有写关于non-retain的KVOController可能有点问题，如果dealloc的时候被观察的object已经是nil了，unobserveAll的时候就不能把之前添加的observer移除，那么在observer监听对象销毁以后，再次触发了监听对象的KVO事件，会导致程序崩溃。

但上面这个我并没有复现，好像是其实observer监听者是被unsafe指针引用的，如果不removeObserver也是可以正常释放的（这点是肯定的），但是如果你再改它监听的东西，触发KVO回调就会crash。所以比较妥的方式还是要removeObserver的

虽然iOS9及以上notification已经可以不用手动remove就会自动移除，但之前的应该也是类似的思路会unsafe keep观察者，如果再次触发通知会crash叭。
anyway手动移除也好，自动移除也好，不要内存泄漏以及crash就好~
5. 等同性option hashtable判断是不是同一个object有很多可选的option，默认的的那种是判断use -hash and -isEqual, object description是不是一致，其他的可以看注释哈，感觉还是英文说得更清楚~

// Personalities are mutually exclusive // default is object.As a special case, 'strong' memory used for Objects will do retain/release under non-GC NSPointerFunctionsObjectPersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (0UL << 8),// use -hash and -isEqual, object description NSPointerFunctionsOpaquePersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (1UL << 8),// use shifted pointer hash and direct equality NSPointerFunctionsObjectPointerPersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (2UL << 8),// use shifted pointer hash and direct equality, object description NSPointerFunctionsCStringPersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (3UL << 8),// use a string hash and strcmp, description assumes UTF-8 contents; recommended for UTF-8 (or ASCII, which is a subset) only cstrings NSPointerFunctionsStructPersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (4UL << 8),// use a memory hash and memcmp (using size function you must set) NSPointerFunctionsIntegerPersonality API_AVAILABLE(macos(10.5), ios(6.0), watchos(2.0), tvos(9.0)) = (5UL << 8),// use unshifted value as hash & equality

我试了一下default的是hash和isEqual决定的，好像木有和description相关哈~
如果加了NSPointerFunctionsOpaquePersonality就即使hash和isEqual相同也会重复加入的，因为指针不同
KVOController用单例作为观察者都回调到一个对象上就比较舒服，你就不用覆写或者hock了，只要记录了回调回来以后要执行神马就OK啦~ 这个库真的是比较精炼的~~ 有时间可以康康吖~~ （P.S.鸣谢周六晚上被我问问题到12点的小哥哥，我真的不是故意的。。

【[iOS]|[iOS] KVOController源码分析】Reference：
https://www.jianshu.com/p/1f7d70ff2002

推荐阅读

• 

  什么是对公负债业务
• 

  做生鲜电商需要办什么营业执照
• 

  威能壁挂炉代码百度如何解决
• 

  拍鸟用什么相机好
• 

  荒野行动物品怎么拆分 如何分开扔掉道具
• 

  黄雅琼个人资料介绍 黄雅琼个人资料介绍
• 

  怎样做稻谷酒
• 

  天山雪菊哪里买 天山雪菊多少钱才能买到
• 

  鹅蛋和什么东西不能吃
• 

  电池容量|骁龙870基本“零差评”，这四款价格两千左右，入手用三年
• 

  mongodb数据库迁移到另一台服务器 mongodb 迁移数据
• 

  紫叶草怎么种植 紫叶草怎么养
• 

  补办车牌号一般几天可以下来
• 

  3m汽车膜分几个档次 汽车贴膜什么牌子好
• 

  前端|实习生 Git 不熟练，还没脸去问是种什么体验
• 

  开发转数据分析,数据分析好还是大数据开发好
• 

  熊童子多肉服盆的注意事项有哪些 多肉熊童子用什么盆好看
• 

  地板出汗怎么办 地板如何去汗，地板如何去汗渍
• 

  冠状沟白色污垢是什么
• 

  mysql中的锁指的是什么 mysql导致锁的原因

• 2020-04-07vue中Axios的封装和API接口的管理
• iOS中的Block
• Android事件传递源码分析
• 记录iOS生成分享图片的一些问题，根据UIView生成固定尺寸的分享图片
• 2019-08-29|2019-08-29 iOS13适配那点事
• Hacking|Hacking with iOS: SwiftUI Edition - SnowSeeker 项目（一）
• iOS面试题--基础
• Quartz|Quartz 源码解析(四) —— QuartzScheduler和Listener事件监听
• [源码解析]|[源码解析] NVIDIA HugeCTR，GPU版本参数服务器---(3)
• ffmpeg源码分析01（结构体）