FBKVOController是一个简单易用的键值观察框架，KVOController 对于 Cocoa 中 KVO 的封装非常的简洁和优秀，我们只需要调用一个方法就可以完成一个对象的键值观测，同时不需要处理移除观察者等问题，能够降低我们出错的可能性。
本文参考了:如何优雅地使用 KVO。
KVOController的简单使用
@interface ViewController ()
@property (nonatomic,assign) NSUInteger index;
@property (nonatomic,strong) dispatch_source_t timer;
@property (nonatomic,strong) FBKVOController *KVOController;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
_timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(_timer, DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC, 0);
dispatch_source_set_event_handler(_timer, ^{
self.index++;
});
dispatch_resume(_timer);
typeof(self) weakSelf = self;
self.KVOController = [FBKVOController controllerWithObserver:self];
[self.KVOController observe:self keyPath:@"index" options:NSKeyValueObservingOptionNew block:^(id _Nullable observer, id _Nonnull object, NSDictionary<NSString *,id> * _Nonnull change) {
NSLog(@"%lu",(unsigned long)weakSelf.index);
}];
}
打印结果
2017-11-13 17:36:12.159778+0800 KVOController[14165:1523330] 1
2017-11-13 17:36:13.157070+0800 KVOController[14165:1523330] 2
2017-11-13 17:36:14.156000+0800 KVOController[14165:1523330] 3
2017-11-13 17:36:15.156487+0800 KVOController[14165:1523330] 4
2017-11-13 17:36:16.156946+0800 KVOController[14165:1523330] 5
2017-11-13 17:36:17.156922+0800 KVOController[14165:1523330] 6
FBKVOController和KVO对比：
KVO
1.KVO需要手动移除观察者，且移除观察者的时机必须合适；
2.注册观察者的代码和事件发生处的代码上下文不同，传递上下文是通过void *指针；
3.需要重写-observeValueForKeyPath:ofObject:change:context:方法，比较麻烦；
4.在复杂的业务逻辑中，准确判断被观察者相对比较麻烦，有多个被观测的对象和属性时，需要在方法中写大量的 if 进行判断；FBKVOController
1.不需要手动移除观察者；
2.实现KVO与事件发生处的代码上下文相同，不需要跨方法传参数；
3.使用block来替代方法能够减少使用的复杂度，提升使用KVO的体验；
4.每一个keyPath会对应一个属性，不需要在 block 中使用if判断keyPath；FBKVOController实现了观察者和被观察者的角色反转，系统的
KVO是被观察者添加观察者，而FBKVOController实现了观察者主动去添加被观察者，实现了角色上的反转，其实就是用的比较方便。
// FBKVOController
typeof(self) weakSelf = self;
self.KVOController = [FBKVOController controllerWithObserver:self];
[self.KVOController observe:self keyPath:@"index" options:NSKeyValueObservingOptionNew block:^(id _Nullable observer, id _Nonnull object, NSDictionary<NSString *,id> * _Nonnull change) {
NSLog(@"%lu",(unsigned long)weakSelf.index);
}];
// KVO
[self addObserver:self
forKeyPath:@"index"
options:NSKeyValueObservingOptionNew
context:nil];
源码解析
FBKVOController框架有两个类，其实只是对 Cocoa 中 KVO 的封装，分别是KVOController和NSObject+FBKVOController。先来看一下NSObject+FBKVOController的实现。
NSObject+FBKVOController.h
@interface NSObject (FBKVOController)
@property (nonatomic, strong) FBKVOController *KVOController;
@property (nonatomic, strong) FBKVOController *KVOControllerNonRetaining;
@end
从名字可以看出KVOControllerNonRetaining在使用时并不会持有被观察的对象，与它相比，KVOController 就会持有该对象了。
- (FBKVOController *)KVOController {
id controller = objc_getAssociatedObject(self, NSObjectKVOControllerKey);
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);
}
两者的 setter方法都只是使用 objc_setAssociatedObject按照键值简单地存一下，而 getter中不同的其实也就是对于FBKVOController的初始化了。
KVOController 的初始化
KVOController 是整个框架中提供 KVO 接口的类，作为 KVO 的管理者，其必须持有当前对象所有与 KVO 有关的信息，而在 KVOController 中，用于存储这个信息的数据结构就是 NSMapTable。为了使 KVOController 达到线程安全，它还必须持有一把 pthread_mutex_t 锁，用于在操作 _objectInfosMap 时使用。
- (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;
}
在初始化方法中，根据retainObserved决定是强引用还是弱引用被观察者，KVOController 和 KVOControllerNonRetaining 的区别就体现在生成的 NSMapTable 实例时传入的是 NSPointerFunctionsStrongMemory 还是 NSPointerFunctionsWeakMemory 选项。最后初始化pthread_mutex_t 锁。
KVO 的过程
使用KVOController实现键值观测时会调用实例方法-observe:keyPath:options:block来注册成为某个对象的观察者，监控属性的变化：
- (void)observe:(nullable id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block {
_FBKVOInfo *info = [[_FBKVOInfo alloc] initWithController:self keyPath:keyPath options:options block:block];
[self _observe:object info:info];
}
数据结构 _FBKVOInfo
上面的方法中就涉及到另外一个私有的数据结构_FBKVOInfo，这个类中包含着所有与 KVO 有关的信息：
{
@public
__weak FBKVOController *_controller;
NSString *_keyPath;
NSKeyValueObservingOptions _options;
SEL _action;
void *_context;
FBKVONotificationBlock _block;
_FBKVOInfoState _state;
}
_FBKVOInfo在KVOController中充当的作用仅仅是一个数据结构，我们主要用它来存储整个 KVO 过程中所需要的全部信息，_FBKVOInfo重写了-isEqual:方法用于对象之间的判等以及方便NSMapTable的存储。其中的state表示当前的 KVO 状态。
typedef NS_ENUM(uint8_t, _FBKVOInfoState) {
_FBKVOInfoStateInitial = 0,
_FBKVOInfoStateObserving,
_FBKVOInfoStateNotObserving,
};
observe 的过程
-observer:keyPath:options:block:初始化了一个名为_FBKVOInfo的对象：
- (void)observe:(nullable id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block {
_FBKVOInfo *info = [[_FBKVOInfo alloc] initWithController:self keyPath:keyPath options:options block:block];
[self _observe:object info:info];
}
在创建了_FBKVOInfo之后执行了另一个私有方法-_observe:info:：
- (void)_observe:(id)object info:(_FBKVOInfo *)info {
pthread_mutex_lock(&_lock);
NSMutableSet *infos = [_objectInfosMap objectForKey:object];
_FBKVOInfo *existingInfo = [infos member:info];
if (nil != existingInfo) {
pthread_mutex_unlock(&_lock);
return;
}
if (nil == infos) {
infos = [NSMutableSet set];
[_objectInfosMap setObject:infos forKey:object];
}
[infos addObject:info];
pthread_mutex_unlock(&_lock);
[[_FBKVOSharedController sharedController] observe:object info:info];
}
这个私有方法通过自身持有_objectInfosMap
来判断当前对象、属性以及各种上下文是否已经注册在表中存在了，在这个
_objectInfosMap中保存着对象以及与对象有关的_FBKVOInfo集合：
在操作了当前KVOController持有的_objectInfosMap之后，才会执行私有的_FBKVOSharedController类的实例方法-observe:info:：
- (void)observe:(id)object info:(nullable _FBKVOInfo *)info {
pthread_mutex_lock(&_mutex);
[_infos addObject:info];
pthread_mutex_unlock(&_mutex);
[object addObserver:self forKeyPath:info->_keyPath options:info->_options context:(void *)info];
if (info->_state == _FBKVOInfoStateInitial) {
info->_state = _FBKVOInfoStateObserving;
} else if (info->_state == _FBKVOInfoStateNotObserving) {
[object removeObserver:self forKeyPath:info->_keyPath context:(void *)info];
}
}
_FBKVOSharedController才是最终调用 Cocoa 中的-observe:forKeyPath:options:context:方法开始对属性的监听的地方；同时，在整个应用运行时，只会存在一个_FBKVOSharedController实例：
+ (instancetype)sharedController {
static _FBKVOSharedController *_controller = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
_controller = [[_FBKVOSharedController alloc] init];
});
return _controller;
}
这个_FBKVOSharedController单例会在 KVO 的回调方法中将事件分发给 KVO 的观察者。
- (void)observeValueForKeyPath:(nullable NSString *)keyPath
ofObject:(nullable id)object
change:(nullable NSDictionary<NSString *, id> *)change
context:(nullable void *)context {
_FBKVOInfo *info;
pthread_mutex_lock(&_mutex);
info = [_infos member:(__bridge id)context];
pthread_mutex_unlock(&_mutex);
FBKVOController *controller = info->_controller;
id observer = controller.observer;
if (info->_block) {
NSDictionary<NSString *, id> *changeWithKeyPath = change;
if (keyPath) {
NSMutableDictionary<NSString *, id> *mChange = [NSMutableDictionary dictionaryWithObject:keyPath forKey:FBKVONotificationKeyPathKey];
[mChange addEntriesFromDictionary:change];
changeWithKeyPath = [mChange copy];
}
info->_block(observer, object, changeWithKeyPath);
} else if (info->_action) {
[observer performSelector:info->_action withObject:change withObject:object];
} else {
[observer observeValueForKeyPath:keyPath ofObject:object change:change context:info->_context];
}
}
在这个-observeValueForKeyPath:ofObject:change:context:回调方法中，_FBKVOSharedController会根据 KVO 的信息_KVOInfo选择不同的方式分发事件，如果观察者没有传入 block 或者选择子，就会调用观察者 KVO 回调方法。
如何 removeObserver
在使用 KVOController 时，我们并不需要手动去处理 KVO 观察者的移除，因为所有的 KVO 事件都由私有的_KVOSharedController来处理；
当每一个KVOController对象被释放时，都会将它自己持有的所有 KVO 的观察者交由_KVOSharedController的-unobserve:infos:
- (void)unobserve:(id)object infos:(nullable NSSet<_FBKVOInfo *> *)infos {
pthread_mutex_lock(&_mutex);
for (_FBKVOInfo *info in infos) {
[_infos removeObject:info];
}
pthread_mutex_unlock(&_mutex);
for (_FBKVOInfo *info in infos) {
if (info->_state == _FBKVOInfoStateObserving) {
[object removeObserver:self forKeyPath:info->_keyPath context:(void *)info];
}
info->_state = _FBKVOInfoStateNotObserving;
}
}
该方法会遍历所有传入的_FBKVOInfo，从其中取出keyPath并将_KVOSharedController移除观察者。
除了在KVOController析构时会自动移除观察者，我们也可以通过它的实例方法-unobserve:keyPath:操作达到相同的效果；功能的实现过程其实都是类似的，都是通过-removeObserver:forKeyPath:context:方法移除观察者：
- (void)unobserve:(id)object info:(nullable _FBKVOInfo *)info {
pthread_mutex_lock(&_mutex);
[_infos removeObject:info];
pthread_mutex_unlock(&_mutex);
if (info->_state == _FBKVOInfoStateObserving) {
[object removeObserver:self forKeyPath:info->_keyPath context:(void *)info];
}
info->_state = _FBKVOInfoStateNotObserving;
}
不过由于这个方法的参数并不是一个数组，所以并不需要使用for循环，而是只需要将该_FBKVOInfo对应的 KVO 事件移除就可以了。
KVO
KVO的使用非常简单，使用KVO的要求是对象必须能支持kvc机制——所有NSObject的子类都支持这个机制。拿上面的渐变导航栏做，我们为tableView添加了一个监听者controller，在我们滑动列表的时候，会计算当前列表的滚动偏移量，然后改变导航栏的背景色透明度。
//添加监听者
[self.tableView addObserver: self forKeyPath: @"contentOffset" options: NSKeyValueObservingOptionNew context: nil];
/**
* 监听属性值发生改变时回调
*/
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSString *,id> *)change context:(void *)context
{
CGFloat offset = self.tableView.contentOffset.y;
CGFloat delta = offset / 64.f + 1.f;
delta = MAX(0, delta);
[self alphaNavController].barAlpha = MIN(1, delta);
}
毫无疑问，kvo是一种非常便捷的回调方式，但是编译器是怎么完成监听这个任务的呢？先来看看苹果文档对于KVO的实现描述
Automatic key-value observing is implemented using a technique called isa-swizzling... When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class ..
简要的来说，在我们对某个对象完成监听的注册后，编译器会修改监听对象（上文中的tableView）的isa指针，让这个指针指向一个新生成的中间类。从某个意义上来说，这是一场骗局。
typedef struct objc_class *Class;
typedef struct objc_object {
Class isa;
} *id;
这里要说明的是isa这个指针，isa是一个Class类型的指针，对象的首地址一般是isa变量，同时isa又保存了对象的类对象的首地址。我们通过object_getClass方法来获取这个对象的元类，即是对象的类对象的类型(正常来说，class方法内部的实现就是获取这个isa保存的对象的类型，在kvo的实现中苹果对被监听对象的class方法进行了重写隐藏了实现)。class方法是获得对象的类型，虽然这两个返回的结果是一样的，但是两个方法在本质上得到的结果不是同一个东西
在oc中，规定了只要拥有isa指针的变量，通通都属于对象。上面的objc_object表示的是NSObject这个类的结构体表示，因此oc不允许出现非NSObject子类的对象（block是一个特殊的例外）*
当然了，苹果并不想讲述更多的实现细节，但是我们可以通过运行时机制来完成一些有趣的调试。
苹果的黑魔法
根据苹果的说法，在对象完成监听注册后，修改了被监听对象的某些属性，并且改变了isa指针，那么我们可以在监听前后输出被监听对象的相关属性来进一步探索kvo的原理。为了保证能够得到对象的真实类型，我使用了object_getClass方法，这个方法在runtime.h头文件中
NSLog(@"address: %p", self.tableView);
NSLog(@"class method: %@", self.tableView.class);
NSLog(@"description method: %@", self.tableView);
NSLog(@"use runtime to get class: %@", object_getClass(self.tableView));
[self.tableView addObserver: self forKeyPath: @"contentOffset" options: NSKeyValueObservingOptionNew context: nil];
NSLog(@"===================================================");
NSLog(@"address: %p", self.tableView);
NSLog(@"class method: %@", self.tableView.class);
NSLog(@"description method: %@", self.tableView);
NSLog(@"use runtime to get class %@", object_getClass(self.tableView));
在看官们运行这段代码之前，可以先思考一下上面的代码会输出什么。
2015-12-12 23:02:33.216 LXDAlphaNavigationController[1487:63171] address: 0x7f927a81d200
2015-12-12 23:02:33.216 LXDAlphaNavigationController[1487:63171] class method: UITableView
2015-12-12 23:02:33.217 LXDAlphaNavigationController[1487:63171] description method: <UITableView: 0x7f927a81d200; frame = (0 0; 320 568); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x7f927971f9a0>; layer = <CALayer: 0x7f9279706f50>; contentOffset: {0, 0}; contentSize: {600, 0}>
2015-12-12 23:02:33.217 LXDAlphaNavigationController[1487:63171] use runtime to get class: UITableView
2015-12-12 23:02:33.217 LXDAlphaNavigationController[1487:63171] ===================================================
2015-12-12 23:02:33.218 LXDAlphaNavigationController[1487:63171] address: 0x7f927a81d200
2015-12-12 23:02:33.218 LXDAlphaNavigationController[1487:63171] class method: UITableView
2015-12-12 23:02:33.218 LXDAlphaNavigationController[1487:63171] description method: <UITableView: 0x7f927a81d200; frame = (0 0; 320 568); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x7f927971f9a0>; layer = <CALayer: 0x7f9279706f50>; contentOffset: {0, 0}; contentSize: {600, 0}>
2015-12-12 23:02:33.230 LXDAlphaNavigationController[1487:63171] use runtime to get class NSKVONotifying_UITableView
除了通过object_getClass获取的类型之外，其他的输出没有任何变化。class方法跟description方法可以重写实现上面的效果，但是为什么连地址都是一样的。
这里可以通过一句小代码来说明一下：
NSLog(@"%@, %@", self.class, super.class);
上面这段代码不管你怎么输出，两个结果都是一样的。这是由于super本质上指向的是父类内存。这话说起来有点绕口，但是我们可以通过对象内存图来表示：
每一个对象占用的内存中，一部分是父类属性占用的；在父类占用的内存中，又有一部分是父类的父类占用的。前文已经说过isa指针指向的是父类，因此在这个图中，Son的地址从Father开始，Father的地址从NSObject开始，这三个对象内存的地址都是一样的。通过这个，我们可以猜到苹果文档中所提及的中间类就是被监听对象的子类。并且为了隐藏实现，苹果还重写了这个子类的class方法跟description方法来掩人耳目。另外，我们还看到了新类相对于父类添加了一个NSKVONotifying_前缀，添加这个前缀是为了避免多次创建监听子类，节省资源
怎么实现类似效果
既然知道了苹果的实现过程，那么我们可以自己动手通过运行时机制来实现KVO。runtime允许我们在程序运行时动态的创建新类、拓展方法、method-swizzling、绑定属性等等这些有趣的事情。
在创建新类之前，我们应该学习苹果的做法，判断当前是否存在这个类，如果不存在我们再进行创建，并且重新实现这个新类的class方法来掩盖具体实现。基于这些原则，我们用下面的方法来获取新类
- (Class)createKVOClassWithOriginalClassName: (NSString *)className
{
NSString * kvoClassName = [kLXDkvoClassPrefix stringByAppendingString: className];
Class observedClass = NSClassFromString(kvoClassName);
if (observedClass) { return observedClass; }
//创建新类，并且添加LXDObserver_为类名新前缀
Class originalClass = object_getClass(self);
Class kvoClass = objc_allocateClassPair(originalClass, kvoClassName.UTF8String, 0);
//获取监听对象的class方法实现代码，然后替换新建类的class实现
Method classMethod = class_getInstanceMethod(originalClass, @selector(class));
const char * types = method_getTypeEncoding(classMethod);
class_addMethod(kvoClass, @selector(class), (IMP)kvo_Class, types);
objc_registerClassPair(kvoClass);
return kvoClass;
}
另外，在判断是否需要中间类来完成监听的注册前，我们还要判断监听的属性的有效性。通过获取变量的setter方法名（将首字母大写并加上前缀set），以此来获取setter实现，如果不存在实现代码，则抛出异常使程序崩溃。
SEL setterSelector = NSSelectorFromString(setterForGetter(key));
Method setterMethod = class_getInstanceMethod([self class], setterSelector);
if (!setterMethod) {
@throw [NSException exceptionWithName: NSInvalidArgumentException reason: [NSString stringWithFormat: @"unrecognized selector sent to instance %p", self] userInfo: nil];
return;
}
Class observedClass = object_getClass(self);
NSString * className = NSStringFromClass(observedClass);
//如果被监听者没有LXDObserver_，那么判断是否需要创建新类
if (![className hasPrefix: kLXDkvoClassPrefix]) {
observedClass = [self createKVOClassWithOriginalClassName: className];
object_setClass(self, observedClass);
}
//重新实现setter方法，使其完成
const char * types = method_getTypeEncoding(setterMethod);
class_addMethod(observedClass, setterSelector, (IMP)KVO_setter, types);
在重新实现setter方法的时候，有两个重要的方法：willChangeValueForKey和didChangeValueForKey，分别在赋值前后进行调用。此外，还要遍历所有的回调监听者，然后通知这些监听者：
static void KVO_setter(id self, SEL _cmd, id newValue)
{
NSString * setterName = NSStringFromSelector(_cmd);
NSString * getterName = getterForSetter(setterName);
if (!getterName) {
@throw [NSException exceptionWithName: NSInvalidArgumentException reason: [NSString stringWithFormat: @"unrecognized selector sent to instance %p", self] userInfo: nil];
return;
}
id oldValue = [self valueForKey: getterName];
struct objc_super superClass = {
.receiver = self,
.super_class = class_getSuperclass(object_getClass(self))
};
[self willChangeValueForKey: getterName];
void (*objc_msgSendSuperKVO)(void *, SEL, id) = (void *)objc_msgSendSuper;
objc_msgSendSuperKVO(&superClass, _cmd, newValue);
[self didChangeValueForKey: getterName];
//获取所有监听回调对象进行回调
NSMutableArray * observers = objc_getAssociatedObject(self, (__bridge const void *)kLXDkvoAssiociateObserver);
for (LXD_ObserverInfo * info in observers) {
if ([info.key isEqualToString: getterName]) {
dispatch_async(dispatch_queue_create(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
info.handler(self, getterName, oldValue, newValue);
});
}
}
}
所有的监听者通过动态绑定的方式将其存储起来，但这样也会产生强引用，所以我们还需要提供释放监听的方法：
- (void)LXD_removeObserver:(NSObject *)object forKey:(NSString *)key
{
NSMutableArray * observers = objc_getAssociatedObject(self, (__bridge void *)kLXDkvoAssiociateObserver);
LXD_ObserverInfo * observerRemoved = nil;
for (LXD_ObserverInfo * observerInfo in observers) {
if (observerInfo.observer == object && [observerInfo.key isEqualToString: key]) {
observerRemoved = observerInfo;
break;
}
}
[observers removeObject: observerRemoved];
}
虽然上面已经粗略的实现了kvo，并且我们还能自定义回调方式。使用target-action或者block的方式进行回调会比单一的系统回调要全面的多。但kvo真正的实现并没有这么简单，上述代码目前只能实现对象类型的监听，基本类型无法监听，况且还有keyPath可以监听对象的成员对象的属性这种更强大的功能。
尾言
对于基本类型的监听，苹果可能是通过void *类型对对象进行桥接转换，然后直接获取内存，通过type encoding我们可以获取所有setter对象的具体类型，虽然实现比较麻烦，但是确实能够达成类似的效果。
钻研kvo的实现可以让我们对苹果的代码实现有更深层次的了解，这些知识涉及到了更深层次的技术，探究它们对我们的开发视野有着很重要的作用。同时，对比其他的回调方式，KVO的实现在创建子类、重写方法等等方面的内存消耗是很巨大的，因此博主更加推荐使用delegate、block等回调方式，甚至直接使用method-swizzling来替换这种重写setter方式也是可行的。
ps:昨天有人问我说为什么kvo不直接通过重写setter方法的方式来进行回调，而要创建一个中间类。诚然，method_swizzling是一个很赞的机制，完全能用它来满足监听需求。但是，如果我们要监听的对象是tableView呢？正常而言，一款应用中远不止一个列表，使用method_swizzling会导致所有的列表都添加了监听回调，先不考虑这可能导致的崩溃风险，所有继承自tableView的视图（包括自身）的setter都受到了影响。而使用中间类却避免了这个问题
