KVO知识小结

1.认识KVO

KVO类似于观察者模式，我们利用简单的代码来了解什么是KVO。

1
2
3
4
5
6
7
8
9
10
11
12
13
//  注册一个Person类
#import <Foundation/Foundation.h>

@interface Person : NSObject
@property (nonatomic,copy) NSString *name;
@end

// 再注册一个Dog类
#import <Foundation/Foundation.h>

@interface Dog : NSObject
@property (nonatomic,copy  ) NSString *name;
@end

我们在ViewController中引入头文件，并创建两个全局的属性。我们希望Person作为Dog的观察者，当Dog的name属性发生变化的时候，Person可以第一时间知道。这时我们就可以运用KVO的技术。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 Person *p = [Person new];
 self.p = p;
 Dog *dog = [Dog new];
 self.dog = dog;

// 成为其他对象的观察者要进行注册
// KeyPath代表监听对象的具体属性
// Observe就是观察者喽
// Options可以指定管擦得值得新旧等
// Context可以是任何对象，可以向观察者传递信息，也可以用指定的标识对不同的观察者进行区分
 [dog addObserver:p
       forKeyPath:@"name"
          options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld)
          context:nil];

 dog.name = @"旺财";

监听选项Options是由枚举NSKeyValueObservingOptions定义的，他决定了哪些值可以被传入到观察者内部实现的方法中。

定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
enum {
	   // 提供新值
   	NSKeyValueObservingOptionNew = 0x01,
   	
   	// 提供旧值
   	NSKeyValueObservingOptionOld = 0x02,
   	
   	// 添加观察者时立即发送一个通知给观察者，
   	// 并且是在注册观察者方法返回之前
   	NSKeyValueObservingOptionInitial = 0x04,
   	
   	// 如果指定，则在每次修改属性时，会在修改通知被发送之前预先发送一条通知给观察者，
   	// 这与-willChangeValueForKey:被触发的时间是相对应的。
   	// 这样，在每次修改属性时，实际上是会发送两条通知。
   	NSKeyValueObservingOptionPrior = 0x08 
};
typedef NSUInteger NSKeyValueObservingOptions;
//  选项值可以支持多个选项

注册之后，我们要在观察者内部实现如下方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 此时，当被观察者的属性发生变更，观察者就会自动调用如下方法
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    
    // keyPath被观察的属性值
    NSLog(@"keyPath = %@",keyPath);
    
    // object被观察的对象
    NSLog(@"object = %@",object);
    
    // 被观察属性值得变化，后面还会讲
    NSLog(@"change = %@",change);
    
    // 上下文，也可以是任意的额外数据
    // 这个Context的作用十分重要，我在后面会强调
    NSLog(@"context = %@",context);
}
// 我们通过这个方法，可以得到一些关键信息

Change选项，它记录了被监听属性的变化情况。可以通过key来获取值：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// 属性变化的类型，是一个NSNumber对象，包含NSKeyValueChange枚举相关的值
NSString *const NSKeyValueChangeKindKey;

// 属性的新值。当NSKeyValueChangeKindKey是 NSKeyValueChangeSetting，
// 且添加观察的方法设置了NSKeyValueObservingOptionNew时，我们能获取到属性的新值。
// 如果NSKeyValueChangeKindKey是NSKeyValueChangeInsertion或者NSKeyValueChangeReplacement，
// 且指定了NSKeyValueObservingOptionNew时，则我们能获取到一个NSArray对象，包含被插入的对象或
// 用于替换其它对象的对象。
NSString *const NSKeyValueChangeNewKey;

// 属性的旧值。当NSKeyValueChangeKindKey是 NSKeyValueChangeSetting，
// 且添加观察的方法设置了NSKeyValueObservingOptionOld时，我们能获取到属性的旧值。
// 如果NSKeyValueChangeKindKey是NSKeyValueChangeRemoval或者NSKeyValueChangeReplacement，
// 且指定了NSKeyValueObservingOptionOld时，则我们能获取到一个NSArray对象，包含被移除的对象或
// 被替换的对象。
NSString *const NSKeyValueChangeOldKey;

// 如果NSKeyValueChangeKindKey的值是NSKeyValueChangeInsertion、NSKeyValueChangeRemoval
// 或者NSKeyValueChangeReplacement，则这个key对应的值是一个NSIndexSet对象，
// 包含了被插入、移除或替换的对象的索引
NSString *const NSKeyValueChangeIndexesKey;

// 当指定了NSKeyValueObservingOptionPrior选项时，在属性被修改的通知发送前，
// 会先发送一条通知给观察者。我们可以使用NSKeyValueChangeNotificationIsPriorKey
// 来获取到通知是否是预先发送的，如果是，获取到的值总是@(YES)
NSString *const NSKeyValueChangeNotificationIsPriorKey;

NSKeyValueChangeKindKey的值取自于NSKeyValueChange，这是一个枚举值，定义如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum {
	// 设置一个新值。被监听的属性可以是一个对象，也可以是一对一关系的属性或一对多关系的属性。
   	NSKeyValueChangeSetting = 1,
   	
   	// 表示一个对象被插入到一对多关系的属性。
   	NSKeyValueChangeInsertion = 2,
   	
   	// 表示一个对象被从一对多关系的属性中移除。
   	NSKeyValueChangeRemoval = 3,
   	
   	// 表示一个对象在一对多的关系的属性中被替换
   	NSKeyValueChangeReplacement = 4
};
typedef NSUInteger NSKeyValueChange;

注意，观察者在不需要使用的时候一定要移除，否则会产生崩溃

1
2
3
4
- (void)dealloc {

    [self.dog removeObserver:self.p forKeyPath:@"name"];
}

通过上面简要的代码示例，我们可以得知，时运观察者只需要实现简单的几步。

  1. 注册观察者
  2. 观察者实现相应的方法
  3. 移除观察者

2.KVC和KVO的实现原理

KVC和KVO是基于强大的Runtime来实现的。其中使用到的技术就是isa-swilling,isa-swilling这项技术也是一个重点，我们会在后续的Runtime部分会讲到。如果有看到此处不明白的同学也请保持耐心。

网上有一篇文章针对实现原理写的很好，链接在此。

整体来说就是，当某个类的对象第一次被观察时，系统会在运行期间动态的为这个类创建一个派生类，假如被监听类名为ClassA，那么派生类的名称就为NSKVONotifying_ClassA。

1.原有对象的isa指针会指向全新的派生类，派生类为了混淆，避免别人知道他不是原来的类，所以派生类重写了Class的类方法。

2.同时重写了Dealloc方法，用于资源的销毁处理。

3.还重写了_isKVOA,这个是一个标记，用于标示这个类是遵守KVO机制的。

4.最关键的是重写了被监听属性的Setter方法，这是实现KVO的关键。至于为什么，后面会讲解到。

简单的画了张图，可能会有助于理解。

我们上面讲重写了被观察对象属性的Setter方法是十分关键的，这就要说起另外两个十分重要的方法

1
2
3
4
5
6
7
8
9
10
11
12
// 在属性值即将被修改的时候，会调用这个方法
- (void)willChangeValueForKey:(NSString *)key;

// 在属性值已经被修改的时候，会调用这个方法
- (void)didChangeValueForKey:(NSString *)key;

// didChangeValueForKey:方法会显式的调用
- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object 
                        change:(NSDictionary<NSKeyValueChangeKey,id> *)change 
                       context:(void *)context {
                       }

其实我个人猜测，重写Setter方法内部应该这样实现的

1
2
3
[self willChangeValueForKey:@"name"];
[super setName:name];
[self didChangeValueForKey:@"name"];

说到这里，相信你应该完整的明白KVO的实现机制了。

1
2
// 这才是KVO机制触发的关键
- (void)didChangeValueForKey:(NSString *)key;

3.调用KVO的三种方法

综合上面KVO的实现原理，我们可以得出如下结论：

1.使用了KVC

使用了KVC，如果有访问器方法，则运行时会在访问器方法中调用will/didChangeValueForKey:方法；
没用访问器方法，运行时会在setValue:forKey方法中调用will/didChangeValueForKey:方法。

2.有访问器方法

运行时会重写访问器方法调用will/didChangeValueForKey:方法。
因此，直接调用访问器方法改变属性值时，KVO也能监听到。

3.直接调用

显式调用will/didChangeValueForKey:方法。

4.KVO自动通知、手动通知

通常意义下我们使用的都是自动通知，注册观察者之后，当触发will/didChangeValueForKey:方法后，观察者对象的- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context { }方法会被调用。

如果像实现手动通知，我们需要借助一个额外的方法

1
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key

这个方法默认返回YES,用来标记Key指定的属性是否支持KVO，如果返回值为NO，则需要我们手动更新。

我们还是用我们最上面的例子，监听Person的name属性，不过这次我们采取手动通知的方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#import "Person.h"

@implementation Person

+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key {

    BOOL automaic = NO;
    if ([key isEqualToString:@"name"])
    {
        automaic = NO;
    }
    else
    {
        // 此处需要注意，没有被处理的其他属性要调用父类的原有方法
        automaic = [super automaticallyNotifiesObserversForKey:key];
    }
    return automaic;
}
@end

这样我们就已经标记好当Person的name属性发生改变时，手动发送通知，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@implementation Person

- (void)setName:(NSString *)name {
    
    if(name != _name)// 加一处判断，如果值相同，就无需发送通知了
    {   
        // 我们需要在值修改前调用`will...`方法
        [self willChangeValueForKey:@"name"];
        _name = name;
        // 我们还需要在修改后调用`did...`方法，显式调用观察者的方法
        [self didChangeValueForKey:@"name"];
    }
}
@end

手动发送通知一对一的操作方法如上，如果是一对多的案例，则可以使用如下方法

1
2
3
4
5
- (void)willChange:(NSKeyValueChange)change valuesAtIndexes:(NSIndexSet *)indexes forKey:(NSString *)key
- (void)didChange:(NSKeyValueChange)change valuesAtIndexes:(NSIndexSet *)indexes forKey:(NSString *)key
  
- (void)willChangeValueForKey:(NSString *)key withSetMutation:(NSKeyValueSetMutationKind)mutationKind usingObjects:(NSSet *)objects
- (void)didChangeValueForKey:(NSString *)key withSetMutation:(NSKeyValueSetMutationKind)mutationKind usingObjects:(NSSet *)objects

5.注册依赖键

实际开发过程中可能会遇到这种场景，某个变量的值取决于其他的值。

我们还是看一个例子吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// 声明一个Person类，有三个属性
#import <Foundation/Foundation.h>

@interface Person : NSObject

@property (nonatomic,copy) NSString *fullName;
@property (nonatomic,copy) NSString *firstName;
@property (nonatomic,copy) NSString *lastName;

@end

// 其中 fullName 取决于 firstName 和 lastName的值.
// 同时如果 firstName 和 lastName发生改变的话,fullName也会受到影响。

#import "Person.h"

@implementation Person

// 注册 fullName依赖于 firstName 和 lastName
+ (NSSet<NSString *> *)keyPathsForValuesAffectingFullName {

    return [NSSet setWithObjects:@"firstName",@"lastName",nil];
}

- (NSString *)fullName {

    NSString *tempName = _fullName;
    
    if (_firstName || _lastName)
    {
        tempName = [NSString stringWithFormat:@"%@-%@",_firstName,_lastName];
    }

    return tempName;
}

回到Controller：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
- (void)viewDidLoad {
    
    [super viewDidLoad];
    
    Person *p = [Person new];
    self.p = p;
    
    [self.p  addObserver:self
        forKeyPath:NSStringFromSelector(@selector(name))
           options:NSKeyValueObservingOptionOld | NSKeyValueObservingOptionNew
           context:ContextMark];
    
    self.p.fullName = @"lilei";
    NSLog(@"fullName = %@",self.p.fullName);
    
    self.p.firstName = @"lala";
    NSLog(@"fullName = %@",self.p.fullName);

    self.p.lastName = @"papa";
    NSLog(@"fullName = %@",self.p.fullName);
}

// 打印结果如下
fullName = lilei
fullName = lala-(null)
fullName = lala-papa

6.KVO使用中的”坑”

最近我在看这方面资料的时候，发现大家都以 tableView和ContentOffset作为例子。咱们就用这个最常见的控件来说明一下吧。

1.keyPath为字符串

众所周知，KVO里面的KeyPath是NSString类型，结合Obj-C动态语言的特性，在编译时是不做检查的，只有运行到执行的时候，才会动态的去方法列表、实例变量列表中去查找，所以一旦我们写错了KeyPath，不运行的时候很难发现。

基于这个问题，我们用以下的方法规避

1
2
// 这样就不会写错了
NSStringFromSelector(@selector(contentSize))
2.多层继承、共用同一个回调方法

假如父类的控制器监听了tableView的ContentOffset属性，同时该控制器还监听了其他控件的一些属性，但是同一个对象或者控制器作为多个对象属性的观察者，实际上最后调用的都是同一个回调方法- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context { }，这样写极其容易混淆，所以我们为了解决这个问题，把代码写成如下的样子

1
2
3
4
5
6
7
8
9
10
- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object
                        change:(NSDictionary *)change 
                       context:(void *)context
{
    if (object == _tableView && [keyPath isEqualToString:@"contentOffset"]) 
    {
        [self doSomethingWhenContentOffsetChanges];
 　　} 
}

但是光这样写是不全面的，因为当前的这个类很可能有父类，并且它的父类可能绑定了一些其他的KVO,上面的代码只有一个条件判断，一旦不成立，此次KVO的触发操作也就断了。而当前类无法捕捉的这个KVO事件很可能就在它的父类里，或者是父类的父类，上述操作，将这一链条截断，所以正确的方法应该如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object
                        change:(NSDictionary *)change 
                       context:(void *)context
{
    if (object == _tableView && [keyPath isEqualToString:@"contentOffset"]) 
    {
        [self doSomethingWhenContentOffsetChanges];
 　　} 
 　　else
 　　{
 　　    [super observeValueForKeyPath:keyPath 
 　　                         ofObject:object 
 　　                           change:change 
 　　                          context:context];
 　　}
}

这样做这一链条就完整的保留了。

3.观察者的注销

上面的方法做完之后还是有隐患的。我们知道KVO不用的时候是需要注销的。我们知道当你对同一个KVO注销两次的时候，系统默认是抛出异常的。

你可能会好奇，什么时候我会对同一个Observer注销多次呢？

这个时候我们可以想一下我们注销Observer的时机，是不是多在Dealloc方法中？

在Obj-C中，有很多系统的方法被重写时需要调用super xxxxxxx等方法，这是Obj-C的继承关系决定的。

例如：

1
2
3
4
5
6
7
8
9
10
11
// 在重写init方法时，我们要调用一下父类的init方法
- (instancetype)init {

    [super init];
}

// 布局子控件时，要调用一下父类的layoutSubviews方法
- (void)layoutSubviews {

    [super layoutSubviews];
}

还有些方法，不需要调用父类的方法，自动就会帮你调用，就如我们所说的Dealloc。其实只有在ARC模式下才不需要调用父类，MRC下的Dealloc还是要手动调用super dealloc的。

所以我们在注销观察者的时候就这么写

1
2
3
4
- (void)dealloc {

    [_tableView removeObserver:self forKeyPath:@"contentOffset"];
}

假设我们有三个类 ClassA（父类），ClassB（子类），ClassC（孙子类）。这三个类都作为观察者，观察tableView的contentOffset属性。

如果我们在ClassC（孙子类）的Dealloc方法中释放观察者

1
2
3
4
- (void)dealloc {

    [_tableView removeObserver:self forKeyPath:@"contentOffset"];
}

当ClassC（孙子类）的Dealloc执行完毕后，就会自动去ClassB（子类）的Dealloc方法中，释放观察者

1
2
3
4
- (void)dealloc {

    [_tableView removeObserver:self forKeyPath:@"contentOffset"];
}

这个时候就出现崩溃了，因为我们在前面提到过这样会导致相同的removeObserver被执行两次，于是导致crash。

4.正确写法

针对这种类型的Crash，我们就要谈一下在注册Observer似的一个关键的参数Context，之前我是不知道这个Context是做啥用的，对于KVO的使用只是流于表面，所以对于这个神秘的Context的作用一直没有深究，现在我们将使用Context来为每一个Observer做区分，避免多次调用相同的removeObserver。

KVO的三个关键方法

1
2
3
4
5
6
7
8
9
10
//  注册观察者
- (void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options context:(nullable void *)context;

// 观察者响应方法
- (void)observeValueForKeyPath:(nullable NSString *)keyPath ofObject:(nullable id)object change:(nullable NSDictionary<NSKeyValueChangeKey, id> *)change context:(nullable void *)context;

// 移除观察者（有两个方法）
- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath context:(nullable void *)context NS_AVAILABLE(10_7, 5_0);

- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath;

相比细心的同学已经看出来了，我们在注册、响应、移除的三个步骤里，都可以找到Context这个关键字。所以为了保持注册、响应、移除的一致性，正确的写法应该如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 首先我们应在使用KVO的类中，创建一个独一无二的Context，用来和其他类进行区分
static Void *ContextMark = &ContextMark;

// 接下来注册的时候用
 [_tableView addObserver:self
              forKeyPath:NSStringFromSelector(@selector(contentSize))
                 options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld)
                 context:ContextMark];
                 
// 响应的时候用
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    
    if (context == ContextMark)
    {
        // do someThing
    }
    else
    {
        [super observeValueForKeyPath:keyPath ofObject:object change:change context:context];
    }
}

// 注销的时候用
- (void)dealloc {
    [_tableView removeObserver:self 
                    forKeyPath:NSStringFromSelector(@selector(contentSize)) 
                       context:ContextMark];
}

如果还不放心，也可以使用@try @catch去捕获异常

7.总结

KVO这套 API 真麻烦~

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

iOS工程师<br><br>业余学习前端<br> <br>最近喜欢上了骑摩托<br><br>欢迎来撩<br>带你兜风