KVO躏碳，全稱為Key-Value Observing谒主，是iOS中的一種設(shè)計模式，用于檢測對象的某些屬性的實時變化情況并作出響應(yīng)丐膝。網(wǎng)上廣為流傳普及的一個例子是利用KVO檢測股票價格的變動捐友，例如這里淫半。這個例子作為掃盲入門還是可以的，但是當(dāng)應(yīng)用場景比較復(fù)雜時匣砖，里面的一些細節(jié)還是需要改進的科吭，里面有多個地方存在crash的危險。本文旨在逐步遞進深入地探討出一種目前比較健壯穩(wěn)定的KVO實現(xiàn)方案猴鲫，彌補網(wǎng)上大部分教程的不足对人！
首先，假設(shè)我們的目標(biāo)是在一個UITableViewController內(nèi)對tableview的contentOffset進行實時監(jiān)測拂共，很容易地使用KVO來實現(xiàn)為牺弄。
在初始化方法中加入：
[_tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];
在dealloc中移除KVO監(jiān)聽：
[_tableView removeObserver:self forKeyPath:@"contentOffset" context:nil];
添加默認的響應(yīng)回調(diào)方法：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
[self doSomethingWhenContentOffsetChanges];
}
好了，KVO實現(xiàn)就到此完美結(jié)束了宜狐，拜拜势告。。抚恒。開個玩笑咱台，肯定沒這么簡單的，這樣的代碼太粗糙了俭驮，當(dāng)你在controller中添加多個KVO時回溺，所有的回調(diào)都是走同上述函數(shù)，那就必須對觸發(fā)回調(diào)函數(shù)的來源進行判斷。判斷如下：
- (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)前類(在例子中為UITableViewController)還有父類，并且父類也有自己綁定了一些其他KVO呢瓮恭？我們看到雄坪，上述回調(diào)函數(shù)體中只有一個判斷，如果這個if不成立屯蹦，這次KVO事件的觸發(fā)就會到此中斷了。但事實上绳姨，若當(dāng)前類無法捕捉到這個KVO登澜，那很有可能是在他的superClass，或者super-superClass...中飘庄，上述處理砍斷了這個鏈脑蠕。合理的處理方式應(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é)束了嗎？答案仍舊是否定的跪削。潛在的問題有可能出現(xiàn)在dealloc中對KVO的注銷上谴仙。KVO的一種缺陷(其實不能稱為缺陷，應(yīng)該稱為特性)是碾盐，當(dāng)對同一個keypath進行兩次removeObserver時會導(dǎo)致程序crash晃跺，這種情況常常出現(xiàn)在父類有一個kvo，父類在dealloc中remove了一次毫玖，子類又remove了一次的情況下掀虎。不要以為這種情況很少出現(xiàn)！當(dāng)你封裝framework開源給別人用或者多人協(xié)作開發(fā)時是有可能出現(xiàn)的付枫，而且這種crash很難發(fā)現(xiàn)烹玉。不知道你發(fā)現(xiàn)沒，目前的代碼中context字段都是nil阐滩，那能否利用該字段來標(biāo)識出到底kvo是superClass注冊的二打，還是self注冊的？
回答是可以的掂榔。我們可以分別在父類以及本類中定義各自的context字符串继效，比如在本類中定義context為@"ThisIsMyKVOContextNotSuper";然后在dealloc中remove observer時指定移除的自身添加的observer。這樣iOS就能知道移除的是自己的kvo衅疙，而不是父類中的kvo莲趣，避免二次remove造成crash。
