KVO，全稱(chēng)為Key-Value Observing，是iOS中的一種設(shè)計(jì)模式靖避，用于檢測(cè)對(duì)象的某些屬性的實(shí)時(shí)變化情況并作出響應(yīng)。網(wǎng)上廣為流傳普及的一個(gè)例子是利用KVO檢測(cè)股票價(jià)格的變動(dòng)比默，例如這里幻捏。這個(gè)例子作為掃盲入門(mén)還是可以的，但是當(dāng)應(yīng)用場(chǎng)景比較復(fù)雜時(shí)命咐，里面的一些細(xì)節(jié)還是需要改進(jìn)的篡九，里面有多個(gè)地方存在crash的危險(xiǎn)。本文旨在逐步遞進(jìn)深入地探討出一種目前比較健壯穩(wěn)定的KVO實(shí)現(xiàn)方案醋奠，彌補(bǔ)網(wǎng)上大部分教程的不足榛臼！
首先，假設(shè)我們的目標(biāo)是在一個(gè)UITableViewController內(nèi)對(duì)tableview的contentOffset進(jìn)行實(shí)時(shí)監(jiān)測(cè)窜司，很容易地使用KVO來(lái)實(shí)現(xiàn)為讽坏。
在初始化方法中加入：
[_tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];
在dealloc中移除KVO監(jiān)聽(tīng)：
[_tableView removeObserver:self forKeyPath:@"contentOffset" context:nil]
添加默認(rèn)的響應(yīng)回調(diào)方法：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
? ? ? ? ? ? [self doSomethingWhenContentOffsetChanges];
}
好了，KVO實(shí)現(xiàn)就到此完美結(jié)束了例证，拜拜路呜。。织咧。開(kāi)個(gè)玩笑胀葱，肯定沒(méi)這么簡(jiǎn)單的，這樣的代碼太粗糙了笙蒙，當(dāng)你在controller中添加多個(gè)KVO時(shí)抵屿，所有的回調(diào)都是走同上述函數(shù)，那就必須對(duì)觸發(fā)回調(diào)函數(shù)的來(lái)源進(jìn)行判斷捅位。判斷如下：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context ?
{
? ? ? ? ? ?if (object == _tableView && [keyPath isEqualToString:@"contentOffset"]) {
? ? ? ? ? ? ? ? ? ?[self doSomethingWhenContentOffsetChanges];
? ? ? ? ? ? }?
}
你以為這樣就結(jié)束了嗎轧葛？答案是否定的！我們假設(shè)當(dāng)前類(lèi)(在例子中為UITableViewController)還有父類(lèi)艇搀，并且父類(lèi)也有自己綁定了一些其他KVO呢尿扯？我們看到，上述回調(diào)函數(shù)體中只有一個(gè)判斷焰雕，如果這個(gè)if不成立衷笋，這次KVO事件的觸發(fā)就會(huì)到此中斷了。但事實(shí)上矩屁，若當(dāng)前類(lèi)無(wú)法捕捉到這個(gè)KVO辟宗，那很有可能是在他的superClass爵赵，或者super-superClass...中，上述處理砍斷了這個(gè)鏈泊脐。合理的處理方式應(yīng)該是這樣的:
- (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];
? ? ? ? ? }
}
這樣就結(jié)束了嗎空幻？答案仍舊是否定的。潛在的問(wèn)題有可能出現(xiàn)在dealloc中對(duì)KVO的注銷(xiāo)上容客。KVO的一種缺陷(其實(shí)不能稱(chēng)為缺陷氛悬，應(yīng)該稱(chēng)為特性)是，當(dāng)對(duì)同一個(gè)keypath進(jìn)行兩次removeObserver時(shí)會(huì)導(dǎo)致程序crash耘柱，這種情況常常出現(xiàn)在父類(lèi)有一個(gè)kvo，父類(lèi)在dealloc中remove了一次棍现，子類(lèi)又remove了一次的情況下调煎。不要以為這種情況很少出現(xiàn)！當(dāng)你封裝framework開(kāi)源給別人用或者多人協(xié)作開(kāi)發(fā)時(shí)是有可能出現(xiàn)的己肮，而且這種crash很難發(fā)現(xiàn)士袄。不知道你發(fā)現(xiàn)沒(méi)，目前的代碼中context字段都是nil谎僻，那能否利用該字段來(lái)標(biāo)識(shí)出到底kvo是superClass注冊(cè)的娄柳，還是self注冊(cè)的？
回答是可以的艘绍。我們可以分別在父類(lèi)以及本類(lèi)中定義各自的context字符串赤拒，比如在本類(lèi)中定義context為@"ThisIsMyKVOContextNotSuper";然后在dealloc中remove observer時(shí)指定移除的自身添加的observer。這樣iOS就能知道移除的是自己的kvo诱鞠，而不是父類(lèi)中的kvo挎挖，避免二次remove造成crash。
