本篇會對KVO的實現(xiàn)進行探究，不涉及太多KVO的使用方法，但是會有一些使用時的思考。

一、使用上的疑問

1.keyPath是什么

當我們使用@property時候，keyPath是指的是我們的屬性名，實例變量或者是存取方法？

:point_down: 對一個屬性值使用@synthesize重新定義了存儲變量

```

# import"Person.h"

@interface Student:Person

@property(nonatomic,strong)NSString* mark;

@end

@implementation ?Student

@synthesizemark = abc;

- (void)setMark:(NSString*)newMark {

?abc = newMark;

}

- (NSString*)mark {

returnabc;

}

main() {?

Student *stu = [[Student alloc] init];?

stu.mark =@"65";

?StudentKvoObserver *stuObserver = [[StudentKvoObserver alloc] initWithStudent:stu]; [stuObserver addObserverForKeyPath:@"mark"];

```

// 重命名get方法stu.mark =@"85";}

實際結果是，能夠監(jiān)聽到mark值的變化，反之，我將mark替換成真正的實例變量abc時，無法獲取狀態(tài)。

現(xiàn)在想想其實答案早就存在了，我們不做顯示的@synthesize的指定時，其實等價于 @synthesize mark = _mark; ，由此看來keyPath實際指的并不是真正存儲你數(shù)據(jù)的變量。

2.KVO是否能夠繼承

我是否能夠監(jiān)聽我父類里的屬性，哪怕他并沒有暴露出來？通過某些手段得（猜）到了keyPath，然后去監(jiān)聽它甚至是KVC修改他的值。

子類繼承父類的一個屬性，當這個屬性被改變時，KVO能否觀察到？

子類繼承父類的一個未暴露的屬性，當這個屬性被改變時，KVO能否觀察到？

子類繼承父類屬性并重寫了它的setter方法，當這個屬性被改變時，KVO能否觀察到？

// Person類@interfacePerson:NSObject

@property(nonatomic,strong)NSString*firstName;

@property(nonatomic,strong)NSString*lastName;

@property(nonatomic,strong,readonly)NSString*fullName;

- (void)setNewInnerName:(NSString*)str;

@end

@interfacePerson()

@property(nonatomic,strong)NSString*innerName;

@end@implementationPerson

- (void)setNewInnerName:(NSString*)str {

self.innerName = str;// 通過get、set訪問 觸發(fā)KVO

// [self setValue:str forKey:@"innerName"];

// KVC方式,其實調用的也是setter方法 觸發(fā)KVO

// _innerName = str;

// 直接訪問成員變量，不觸發(fā)KVO}

// Student類

@interface ?Student:Person

@end

@implementationStudent

- (void)setFirstName:(NSString*)firstName {

NSLog(@"重寫的setFirstName方法");

}

@end

// 執(zhí)行文件

main() {

?Person *p = [[Person alloc] init];?

p.firstName =@"zhao";?

p.lastName =@"zhiyu";

?PersonKvoObserver *personKvoObserver = [[PersonKvoObserver alloc]initWithPerson:p];?

[personKvoObserver addObserverForKeyPath:@"fullName"];

// 屬性關聯(lián)

[personKvoObserver addObserverForKeyPath:@"innerName"];

// 內部屬性

p.firstName =@"zhao1";

?[p setNewInnerName:@"newInnerNmame"];

// 沒有暴露的屬性的get、set方法被調用時，也會發(fā)送通知// 子類的屬性監(jiān)聽

Student *stu = [[Student alloc] init];

?stu.firstName =@"stu";?

stu.lastName =@"dent";

?StudentKvoObserver *stuObserver = [[StudentKvoObserver alloc] initWithStudent:stu]; [stuObserver addObserverForKeyPath:@"fullName"];// 子類繼承屬性依舊被監(jiān)聽[stuObserver addObserverForKeyPath:@"firstName"];// 重寫方法,不加super,依舊會監(jiān)聽kvo[stuObserver addObserverForKeyPath:@"innerName"];??

stu.firstName =@"stu1";

stu.lastName =@"dent1";

?[stu setNewInnerName:@"newInnerNmame"];

// 沒有暴露的屬性的get、set方法被調用時，也會發(fā)送通知}

通過上面的例子，我們能看出幾點：

①通過KVO，能觀察父類的屬性值。

②只要知道了keyPath，不管有沒有暴露方法，依舊可以通過KVO方式觀察值的變化，而且同屬性一樣，可以被繼承。

③子類重寫父類的set方法，也并不會影響KVO的觀察。

從這兒開始就有點好奇了，這個KVO是否通過子類化的方法實現(xiàn)？那如何讓子類的繼承屬性也能被監(jiān)聽到？了解到KVO依賴setter方法的重寫，那我子類重寫的setter方法之后，為什么子類繼承屬性的監(jiān)聽依然生效？

3.跨線程的監(jiān)聽

我們知道使用Notification時，跨線程發(fā)送通知是無法被接受到的，那么現(xiàn)在看看KVO在多線程中的表現(xiàn)。

// 在兩個線程定義目標和觀察者

dispatch_queue_t ?concurrentQueue = dispatch_queue_create("my.concurrent.queue", DISPATCH_QUEUE_CONCURRENT);

// dispatch_queue_t globalQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

__block Student *stu1 =nil;

dispatch_async(concurrentQueue, ^{// 對象屬性

stu1 = [[Student alloc] init];

NSLog(@"Student %@",[NSDate ?new]);?

stu1.lastName =@"yyyyyyy";?

});

__block StudentKvoObserver *stuObserver1;

dispatch_async(concurrentQueue, ^{?

sleep(2);?

stuObserver1 = [[StudentKvoObserver alloc] initWithStudent:stu1];

?[stuObserver1 addObserverForKeyPath:@"fullName"];

// 子類繼承屬性依舊被監(jiān)聽

NSLog(@" StudentKvoObserver %@",[NSDate new]); }); dispatch_barrier_async(concurrentQueue, ^{

NSLog(@"dispatch_barrier_async %@",[NSDate new]);

NSLog(@"zzzzzz start%@",[NSDate new]);

?stu1.lastName =@"zzzzzz";

NSLog(@"zzzzzz end%@",[NSDate new]); });

輸出結果

2016-10-11 10:46:53.319 KVCLearn[3364:331572] Student 2016-10-11 02:46:53 +0000

2016-10-11 10:46:55.324 KVCLearn[3364:331578] StudentKvoObserver 2016-10-11 02:46:55 +0000

2016-10-11 10:46:55.325 KVCLearn[3364:331578] dispatch_barrier_async 2016-10-11 02:46:55 +0000

2016-10-11 10:46:55.325 KVCLearn[3364:331578] zzzzzz start2016-10-11 02:46:55 +0000

2016-10-11 10:46:55.326 KVCLearn[3364:331578] fullName

{

kind = 1;

new = “(null)zzzzzz”;

old = “(null)yyyyyyy”;

}

2016-10-11 10:46:55.326 KVCLearn[3364:331578] zzzzzz end2016-10-11 02:46:55 +0000

可以看到在兩個不同的線程里創(chuàng)建的Observer和Target，觀察變化也是能夠生效的。

這里有一個關于GCD的問題，這里我使用了dispatch_barrier_async，分發(fā)到自定義的并發(fā)隊列上，這時barrier是正常工作的，保證了第三個task在前兩個執(zhí)行完之后執(zhí)行。但是當我直接使用系統(tǒng)全局的并發(fā)隊列時，barrier不起作用，不能保證他們的執(zhí)行順序。這里希望有高人看見了能解答下。

二、實現(xiàn)探究

1.API接口

Foundation里關于KVO的部分都定義在NSKeyValueObserving.h中，KVO通過以下三個NSObject分類實現(xiàn)。

NSObject(NSKeyValueObserving)

NSObject(NSKeyValueObserverRegistration)

NSObject(NSKeyValueObservingCustomization)

這里會從NSObject (NSKeyValueObserverRegistration) 的 - addObserver:forKeyPath:options:context: 為入口，去一步步分析如何整個KVO的實現(xiàn)方式。

2.先說結論

實現(xiàn)方式：

一個對象在被調用addObserver方法時，會動態(tài)創(chuàng)建一個KVO前綴的原類的子類，用來重寫所有的setter方法，并且該子類的 - (Class) class 和 - (Class) superclass 方法會被重寫，返回父類（原始類）的Class。最后會將當前對象的類改為這個KVO前綴的子類。

比較繞，讓我們來看個例子。比如說類Person的實例person調用了addObserver方法時，addObserver方法內部給你創(chuàng)建了一個KVOPerson類，KVOPerson的所有的setter方法會被重寫，它的class和superClass方法會被改寫成返回Person和NSObject，之后使用 object_setClass 將KVOPerson設置成person的class。

當我們調用person的setName方法時，實際是調用的一個KVOPerson實例的setName方法，但由于重寫了class，在外部看不出來其中的差別。在setter方法中，我們在實際值被改變的前后回調用 - (void)willChangeValueForKey:(NSString *)key; 和 - (void)didChangeValueForKey:(NSString *)key; 方法，通知觀察者值的變化。

3.代碼

源碼是來自GNUSetup里的Foundation，據(jù)說和apple的實現(xiàn)類似，只是相關API的版本會比較老一些。我們先從addObserver方法開始。

@implementationNSObject(NSKeyValueObserverRegistration)- (void) addObserver: (NSObject*)anObserver forKeyPath: (NSString*)aPath options: (NSKeyValueObservingOptions)options context: (void*)aContext{ ....// 1.使用當前類創(chuàng)建GSKVOReplacement對象r = replacementForClass([selfclass]); .... info = (GSKVOInfo*)[selfobservationInfo];if(info ==nil) { info = [[GSKVOInfo alloc] initWithInstance:self]; [selfsetObservationInfo: info];//2.重新設置classobject_setClass(self, [r replacement]); } ....//3.重寫replace的setter方法[r overrideSetterFor: aPath];//4.注冊當前類和觀察者到全局表中[info addObserver: anObserver forKeyPath: aPath options: options context: aContext];}

忽略了一些分支，可以看到主要為上面四個步驟。我們可以一個一個拆開來看。

replacementForClass

// 單例生成一個GSKVOReplacement對象，保證一個類只有一個KVO子類staticGSKVOReplacement *replacementForClass(Class c){ GSKVOReplacement *r; setup(); [kvoLock lock]; r = (GSKVOReplacement*)NSMapGet(classTable, (void*)c);if(r ==nil) { r = [[GSKVOReplacement alloc] initWithClass: c];NSMapInsert(classTable, (void*)c, (void*)r); } [kvoLock unlock];returnr;}- (id) initWithClass: (Class)aClass{NSValue*template;NSString*superName;NSString*name; original = aClass; superName =NSStringFromClass(original); name = [@"GSKVO"stringByAppendingString: superName];// 添加前綴template = GSObjCMakeClass(name, superName,nil);// 通過objc_allocateClassPair得到class指針GSObjCAddClasses([NSArrayarrayWithObject: template]);// objc_registerClassPair注冊classreplacement =NSClassFromString(name);// 前面動態(tài)生成且注冊了GSKVO子類，然后就可以通過該方法得到// 添加模板類的一些方法，包括重寫class和superClass讓對象類型不暴露，// setValue:forkey在數(shù)據(jù)改變前后加上willChange和didChange方法GSObjCAddClassBehavior(replacement, baseClass);/* Create the set of setter methods overridden.

*/keys = [NSMutableSetnew];returnself;}

object_setClass(self, [r replacement]);

// replace就是新生成的KVOXXX的class@interfaceGSKVOReplacement:NSObject{ Class original;/* The original class */Class replacement;/* The replacement class */NSMutableSet*keys;/* The observed setter keys */}replacement =NSClassFromString(name);// 在initWithClass方法中賦值

overrideSetterFor

重寫setter方法，在值改變前后添加上willChange&didChange- (void) overrideSetterFor: (NSString*)aKey{if([keys member: aKey] ==nil) {NSMethodSignature*sig;// 當前key值對應setter的方法簽名SEL sel;// 當前key值對應setter的方法名selectorIMP imp;// 當前key值對應setter的函數(shù)指針I(yè)MPconstchar*type;NSString*a[2];unsignedi;BOOLfound =NO;// 得到setXxxx:和_setXxxx:方法名a[0] = [NSStringstringWithFormat:@"set%@%@:", tmp, suffix]; a[1] = [NSStringstringWithFormat:@"_set%@%@:", tmp, suffix];for(i =0; i <2; i++) {/*

得到方法簽名

*/sel =NSSelectorFromString(a[i]); sig = [original instanceMethodSignatureForSelector: sel]; type = [sig getArgumentTypeAtIndex:2];// 第三個參數(shù)即入?yún)⒌念愋蛃witch(*type) {// 字符case_C_CHR:case_C_UCHR: imp = [[GSKVOSetter class] instanceMethodForSelector:@selector(setterChar:)];// 返回setterChar:函數(shù)的函數(shù)指針I(yè)MPbreak;// 對象、類、指針case_C_ID:case_C_CLASS:case_C_PTR: imp = [[GSKVOSetter class] instanceMethodForSelector:@selector(setter:)];// 返回setter:函數(shù)的函數(shù)指針I(yè)MP，后面有詳解break;break; ....default: imp =0;break; }if(imp !=0) {if(class_addMethod(replacement, sel, imp, [sig methodType]))// 將原sel和新imp加到replacement類中去{ found =YES; }else{NSLog(@"Failed to add setter method for %s to %s", sel_getName(sel), class_getName(original)); } } }if(found ==YES) { [keys addObject: aKey]; } }}

這個步驟是將keypath對應的setter方法重寫找出來，把原有的SEL函數(shù)名和重寫后的實現(xiàn)IMP加入到子類中去。這樣做，新生成的子類就有和原父類一樣表現(xiàn)了，再加上之前的class替換，在KVO的對外接口上已經(jīng)沒有差別。這里也解釋了我一開始的問題，keypath到底指的是什么，其實是setter方法，或者說方法名的后綴。因為我們用@property生成了默認的set方法是滿足規(guī)范的，所以會將keypath和property關聯(lián)起來。

// setter方法的實現(xiàn)細節(jié)@implementationGSKVOSetter- (void) setter: (void*)val{NSString*key; Class c = [selfclass];void(*imp)(id,SEL,void*); imp = (void(*)(id,SEL,void*))[c instanceMethodForSelector: _cmd]; key = newKey(_cmd);if([c automaticallyNotifiesObserversForKey: key] ==YES) {// pre setting code here[selfwillChangeValueForKey: key]; (*imp)(self, _cmd, val);// post setting code here[selfdidChangeValueForKey: key]; }else{ (*imp)(self, _cmd, val); } RELEASE(key);}

對于這個setter方法的實現(xiàn)，我其實是沒大看懂的。 [c instanceMethodForSelector: _cmd]; 這個取到的imp，應該是當前方法的函數(shù)指針（GSKVOSetter的setter），后面也是直接調用的該imp實現(xiàn)。沒有找到這個setter是如何和原類方法中實際的setter聯(lián)系起來的，之前通過sig方法簽名也只取出了sel，原有實現(xiàn)并沒有出現(xiàn)。希望有大牛看到這個能給我解答一下。

-(void) addObserver: forKeyPath: options: context:

這個部分就是觀察者的注冊了。通過以下類圖可以很方便得看到，所有的類的KVO觀察都是通過infoTable管理的。以被觀察對象實例作key，GSKVOInfo對象為value的形式保存在infoTable表里，每個被觀察者實例會對應多個keypath，每個keypath會對應多個observer對象。順帶提一下，關于Notification的實現(xiàn)也類似，也是全局表維護通知的注冊監(jiān)聽者和通知名。

GSKVOInfo的結構可以看出來，一個keyPath可以對應有多個觀察者。其中觀察對象的實例和option打包成GSKVOObservation對象保存在一起。

三、總結

看完了KVO的實現(xiàn)部分，我們再回過頭來看開頭提到的幾個問題。

keyPath是什么

首先keyPath，是對于setter方法的關聯(lián)，會使用keypath作為后綴去尋找原類的setter方法的方法簽名，和實際存取對象和property名稱沒有關系。所以這也是為什么我們重命名了setter方法之后，沒有辦法再去使用KVO或KVC了，需要手動調用一次willChangeValue方法。

子類繼承父類的一個屬性，當這個屬性被改變時，KVO能否觀察到？

因為繼承的關系Father <- Son <- KVOSon，當我監(jiān)聽一個父類屬性的keyPath的時候，Son實例同樣可以通過消息查找找到父類的setter方法，再將該方法加入到KVOSon類當中去。

子類繼承父類的一個未暴露的屬性，當這個屬性被改變時，KVO能否觀察到？

由于在overrideSetterFor中，我們是直接通過sel去得到方法簽名signature，所以和暴不暴露沒啥關系。

子類繼承父類屬性并重寫了它的setter方法，當這個屬性被改變時，KVO能否觀察到？

在上一條中知道，其實子類監(jiān)聽父類屬性，并不依賴繼承，而是通過ISA指針在消息轉發(fā)的時候能夠獲取到父類方法就足夠。所以當我們重寫父類setter方法，相當于在子類定義了該setter函數(shù)，在我們去用sel找方法簽名時，直接在子類中就拿到了，甚至都不需要去到父類里。所以理解了KVO監(jiān)聽父類屬性和繼承沒有直接聯(lián)系這一點，就不再糾結set方法是否重寫這個問題了。

最后線程安全的部分，沒有做深入的研究，在這篇就不多做表述了。在我貼的源碼中都去掉了很多枝葉，其中就包括加鎖的部分。有興趣的朋友可以去下面貼的源碼地址去看完整版，其中對線程安全的考慮，遞歸鎖、惰性遞歸鎖使用，也是很值得學習的。