objc系列譯文(7.3):KVC 和 KVO

發表於2014-05-30

Key-value coding (KVC) 和 key-value observing (KVO) 是兩種能讓我們駕馭 Objective-C 動態特性並簡化程式碼的機制。在這篇文章裡,我們將接觸一些如何利用這些特性的例子。

觀察 model 物件的變化

在 Cocoa 的模型-檢視-控制器 (Model-view-controller)架構裡,控制器負責讓檢視和模型同步。這一共有兩步:當 model 物件改變的時候,檢視應該隨之改變以反映模型的變化;當使用者和控制器互動的時候,模型也應該做出相應的改變。

KVO 能幫助我們讓檢視和模型保持同步。控制器可以觀察檢視依賴的屬性變化。

讓我們看一個例子:我們的模型類 LabColor 代表一種 Lab色彩空間裡的顏色。和 RGB 不同,這種色彩空間有三個元素 Lab。我們要做一個用來改變這些值的滑塊和一個顯示顏色的方塊區域。

我們的模型類有以下三個用來代表顏色的屬性:

依賴的屬性

我們需要從這個類建立一個 UIColor 物件來顯示出顏色。我們新增三個額外的屬性,分別對應 R, G, B:

有了這些以後,我們就可以建立這個類的介面了:

維基百科提供了轉換 RGB 到 Lab 色彩空間的演算法。寫成方法之後如下所示:

這些程式碼沒什麼令人激動的地方。有趣的是 greenComponent 屬性依賴於 lComponent 和 aComponent。不論何時設定 lComponent的值,我們需要讓 RGB 三個 component 中與其相關的成員以及 color 屬性都要得到通知以保持一致。這一點這在 KVO 中很重要。

Foundation 框架提供的表示屬性依賴的機制如下:

更詳細的如下:

在我們的例子中如下:

現在我們完整的表達了屬性之間的依賴關係。請注意,我們可以把這些屬性連結起來。打個比方,如果我們寫一個子類去 overrideredComponent 方法,這些依賴關係仍然能正常工作。

觀察變化

現在讓我們目光轉向控制器。 NSViewController 的子類擁有 LabColor model 物件作為其屬性。

我們把檢視控制器註冊為觀察者來接收 KVO 的通知,這可以用以下 NSObject 的方法來實現:

這會讓以下方法:

在當 keyPath 的值改變的時候在觀察者 anObserver 上面被呼叫。這個 API 看起來有一點嚇人。更糟糕的是,我們還得記得呼叫以下的方法

來移除觀察者,否則我們我們的 app 會因為某些奇怪的原因崩潰。

對於大多數的應用來說,KVO 可以通過輔助類用一種更簡單優雅的方式實現。我們在檢視控制器新增以下的觀察記號(Observation token)屬性:

當 labColor 在檢視控制器中被設定時,我們只要 override labColor 的 setter 方法就行了:

KeyValueObserver 輔助類 封裝了 -addObserver:forKeyPath:options:context:-observeValueForKeyPath:ofObject:change:context:-removeObserverForKeyPath: 的呼叫,讓檢視控制器遠離雜亂的程式碼。

整合到一起

檢視控制器需要對 Lab 的滑塊控制做出反應:

所有的程式碼都在我們的 GitHub 示例程式碼 中找到。

手動通知 vs 自動通知

我們剛才所做的事情有點神奇,但是實際上發生的事情是,當 LabColor 例項的 -setLComponent: 等方法被呼叫的時候以下方法:

和:

會在執行 -setLComponent: 中的程式碼之前以及之後被自動呼叫。如果我們寫了 -setLComponent: 或者我們選擇使用自動 synthesize 的 lComponent 的 accessor 到時候就會發生這樣的事情。

有些情況下當我們需要 override -setLComponent: 並且我們要控制是否傳送鍵值改變的通知的時候,我們要做以下的事情:

我們關閉了 -willChangeValueForKey: 和 -didChangeValueForKey: 的自動呼叫,然後我們手動呼叫他們。我們只應該在關閉了自動呼叫的時候我們才需要在 setter 方法裡手動呼叫 -willChangeValueForKey: 和 -didChangeValueForKey:。大多數情況下,這樣優化不會給我們帶來太多好處。

如果我們在 accessor 方法之外改變例項物件(如 _lComponent ),我們要特別小心地和剛才一樣封裝 -willChangeValueForKey: 和 -didChangeValueForKey:。不過在多數情況下,我們只用 accessor 方法的話就可以了,這樣程式碼會簡潔很多。

KVO 和 context

有時我們會有理由不想用 KeyValueObserver 輔助類。建立另一個物件會有額外的效能開銷。如果我們觀察很多個鍵的話,這個開銷可能會變得明顯。

如果我們在實現一個類的時候把它自己註冊為觀察者的話:

一個非常重要的點是我們要傳入一個這個類唯一的 context。我們推薦把以下程式碼

寫在這個類 .m 檔案的頂端,然後我們像這樣呼叫 API 並傳入 PrivateKVOContext 的指標:

然後我們這樣寫 -observeValueForKeyPath:... 的方法:

這將確保我們寫的子類都是正確的。如此一來,子類和父類都能安全的觀察同樣的鍵值而不會衝突。否則我們將會碰到難以 debug 的奇怪行為。

進階 KVO

我們常常需要當一個值改變的時候更新 UI,但是我們也要在第一次執行程式碼的時候更新一次 UI。我們可以用 KVO 並新增NSKeyValueObservingOptionInitial 的選項 來一箭雙鵰地做好這樣的事情。這將會讓 KVO 通知在呼叫 -addObserver:forKeyPath:... 到時候也被觸發。

之前和之後

當我們註冊 KVO 通知的時候,我們可以新增 NSKeyValueObservingOptionPrior 選項,這能使我們在鍵值改變之前被通知。這和-willChangeValueForKey:被觸發的時間相對應。

如果我們註冊通知的時候附加了 NSKeyValueObservingOptionPrior 選項,我們將會收到兩個通知:一個在值變更前,另一個在變更之後。變更前的通知將會在 change 字典中有不同的鍵。我們可以像以下這樣區分通知是在改變之前還是之後被觸發的:

如果我們需要改變前後的值,我們可以在 KVO 選項中加入 NSKeyValueObservingOptionNew 和/或NSKeyValueObservingOptionOld

更簡單的辦法是用 NSKeyValueObservingOptionPrior 選項,隨後我們就可以用以下方式提取出改變前後的值:

通常來說 KVO 會在 -willChangeValueForKey: 和 -didChangeValueForKey: 被呼叫的時候儲存相應鍵的值。

索引

KVO 對一些集合類也有很強的支援,以下方法會返回集合物件:

我們將會詳細解釋這是怎麼工作的。如果你使用這些方法,change 字典裡會包含鍵值變化的型別(新增、刪除和替換)。對於有序的集合,change 字典會包含受影響的 index。

集合代理物件和變化的通知在用於更新UI的時候非常有效,尤其是處理大集合的時候。但是它們需要花費你一些心思。

KVO 和執行緒

一個需要注意的地方是,KVO 行為是同步的,並且發生與所觀察的值發生變化的同樣的執行緒上。沒有佇列或者 Run-loop 的處理。手動或者自動呼叫 -didChange... 會觸發 KVO 通知。

所以,當我們試圖從其他執行緒改變屬性值的時候我們應當十分小心,除非能確定所有的觀察者都用執行緒安全的方法處理 KVO 通知。通常來說,我們不推薦把 KVO 和多執行緒混起來。如果我們要用多個佇列和執行緒,我們不應該在它們互相之間用 KVO。

KVO 是同步執行的這個特性非常強大,只要我們在單一執行緒上面執行(比如主佇列 main queue),KVO 會保證下列兩種情況的發生:

首先,如果我們呼叫一個支援 KVO 的 setter 方法,如下所示:

KVO 能保證所有 exchangeRate 的觀察者在 setter 方法返回前被通知到。

其次,如果某個鍵被觀察的時候附上了 NSKeyValueObservingOptionPrior 選項,直到 -observe... 被呼叫之前,exchangeRate 的 accessor 方法都會返回同樣的值。

KVC

最簡單的 KVC 能讓我們通過以下的形式訪問屬性:

取值:

設定:

值得注意的是這個不僅可以訪問作為物件屬性,而且也能訪問一些標量(例如 int 和 CGFloat)和 struct(例如 CGRect)。Foundation 框架會為我們自動封裝它們。舉例來說,如果有以下屬性:

我們可以這樣設定它:

KVC 允許我們用屬性的字串名稱來訪問屬性,字串在這兒叫做。有些情況下,這會使我們非常靈活地簡化程式碼。我們下一節介紹例子簡化列表 UI

KVC 還有更多可以談的。集合(NSArrayNSSet 等)結合 KVC 可以擁有一些強大的集合操作。還有,物件可以支援用 KVC 通過代理物件訪問非常規的屬性。

簡化列表 UI

假設我們有這樣一個物件:

還有一個 detail 檢視控制器,含有四個對應的 UITextField 屬性:

我們可以簡化更新 UI 的邏輯。首先我們需要兩個方法:一個返回 model 裡我們用到的所有鍵的方法,一個把鍵對映到對應的文字框的方法:

有了這個,我們可以從 model 裡更新文字框,如下所示:

我們也可以用一個 action 方法讓四個文字框都能實時更新 model:

注意:我們之後會新增驗證輸入的部分,在鍵值驗證裡會提到。

最後,我們需要確認文字框在需要的時候被更新:

有了這個,我們的 detail 檢視控制器 就能正常工作了。

整個專案可以在 GitHub 上找到。它也用了我們後面提到的鍵值驗證

鍵路徑(Key Path)

KVC 同樣允許我們通過關係來訪問物件。假設 person 物件有屬性 addressaddress 有屬性 city,我們可以這樣通過 person 來訪問 city

值得注意的是這裡我們呼叫 -valueForKeyPath: 而不是 -valueForKey:

Key-Value Coding Without @property

不需要 @property 的 KVC

我們可以實現一個支援 KVC 而不用 @property 和 @synthesize 或是自動 synthesize 的屬性。最直接的方式是新增 -<key> 和 -set<Key>: 方法。例如我們想要 name ,我們這樣做:

這完全等於 @property 的實現方式。

但是當標量和 struct 的值被傳入 nil 的時候尤其需要注意。假設我們要 height 屬性支援 KVC 我們寫了以下的方法:

然後我們這樣呼叫:

這會丟擲一個 exception。要正確的處理 nil,我們要像這樣 override -setNilValueForKey:

我們可以通過 override 這些方法來讓一個類支援 KVC:

這也許看起來很怪,但這可以讓一個類動態的支援一些鍵的訪問。但是這兩個方法會在效能上拖後腿。

附註:Foundation 框架支援直接訪問例項變數。請小心的使用這個特性。你可以去檢視 +accessInstanceVariablesDirectly 的文件。這個值預設是 YES 的時候,Foundation 會按照 _<key>_is<Key><key> 和 is<Key> 的順序查詢例項變數。

集合的操作

一個常常被忽視的 KVC 特性是它對集合操作的支援。舉個例子,我們可以這樣來獲得一個陣列中最大的值:

或者說,我們有一個 Transaction 物件的陣列,物件有屬性 amount 的話,我們可以這樣獲得最大的 amount

當我們呼叫 [a valueForKeyPath:@"@max.amount"] 的時候,它會在陣列 a 的每個元素中呼叫 -valueForKey:@"amount" 然後返回最大的那個。

KVC 的蘋果官方文件有一個章節 Collection Operators 詳細的講述了類似的用法。

通過集合代理物件來實現 KVC

雖然我們可以像對待一般的物件一樣用 KVC 深入集合內部(NSArray 和 NSSet 等),但是通過集合代理物件, KVC 也讓我們實現一個相容 KVC 的集合。這是一個頗為高階的技巧。

當我們在物件上呼叫 -valueForKey: 的時候,它可以返回 NSArrayNSSet 或是 NSOrderedSet 的集合代理物件。這個類沒有實現通常的 -<Key> 方法,但是它實現了代理物件所需要使用的很多方法。

如果我們希望一個類支援通過代理物件的 contacts 鍵返回一個 NSArray,我們可以這樣寫:

這樣做的話,當我們呼叫 [object valueForKey:@"contacts”] 的時候,它會返回一個由這兩個方法來代理所有呼叫方法的NSArray 物件。這個陣列支援所有正常的對 NSArray 的呼叫。換句話說,呼叫者並不知道返回的是一個真正的 NSArray, 還是一個代理的陣列。

對於 NSSet 和 NSOrderedSet,如果要做同樣的事情,我們需要實現的方法是:

NSArray NSSet NSOrderedSet
-countOf<Key> -countOf<Key> -countOf<Key>
-enumeratorOf<Key> -indexIn<Key>OfObject:
以下兩者二選一 -memberOf<Key>:
-objectIn<Key>AtIndex: 以下兩者二選一
-<key>AtIndexes: -objectIn<Key>AtIndex:
-<key>AtIndexes:
可選(增強效能)
-get<Key>:range: 可選(增強效能)
-get<Key>:range:

可選 的一些方法可以增強代理物件的效能。

雖然只有特殊情況下我們用這些代理物件才會有意義,但是在這些情況下代理物件非常的有用。想象一下我們有一個很大的資料結構,呼叫者不需要(一次性)訪問所有的物件。

舉一個(也許比較做作的)例子說,我們想寫一個包含有很長一串質數的類。如下所示:

我們將會執行以下程式碼:

這將會呼叫一次 -countOfPrimes 和一次傳入引數 idx 作為最後一個索引的 -objectInPrimesAtIndex:。為了只取出最後一個值,它不需要先把所有的數封裝成 NSNumber 然後把它們都匯入 NSArray

在一個複雜一點的例子中,通訊錄編輯器示例 app 用同樣的方法把 C++ std::vector 封裝以來。它詳細說明了應該怎麼利用這個方法。

可變的集合

我們也可以在可變集合(例如 NSMutableArrayNSMutableSet,和 NSMutableOrderedSet)中用集合代理。

訪問這些可變的集合有一點點不同。呼叫者在這兒需要呼叫以下其中一個方法:

一個竅門:我們可以讓一個類用以下方法返回可變集合的代理:

然後在實現鍵 wrappedContacts 的一些方法。

我們需要實現上面的不變集合的兩個方法,還有以下的幾個:

NSMutableArray / NSMutableOrderedSet NSMutableSet
至少實現一個插入方法和一個刪除方法 至少實現一個插入方法和一個刪除方法
-insertObject:in<Key>AtIndex: -add<Key>Object:
-removeObjectFrom<Key>AtIndex: -remove<Key>Object:
-insert<Key>:atIndexes: -add<Key>:
-remove<Key>AtIndexes: -remove<Key>:
可選(增強效能)以下方法二選一 可選(增強效能)
-replaceObjectIn<Key>AtIndex:withObject: -intersect<Key>:
-replace<Key>AtIndexes:with<Key>: -set<Key>:

上面提到,這些可變集合代理物件和 KVO 結合起來也十分強大。KVO 機制能在這些集合改變的時候把詳細的變化放進 change 字典中。

有批量更新(需要傳入多個物件)的方法,也有隻改變一個物件的方法。我們推薦選擇相對於給定任務來說最容易實現的那個來寫,雖然我們有一點點傾向於選擇批量更新的那個。

在實現這些方法的時候,我們要對自動和手動的 KVO 之間的差別十分小心。Foundation 預設自動發出十分詳盡的變化通知。如果我們要手動實現傳送詳細通知的話,我們得實現這些:

或者這些:

我們要保證先把自動通知關閉,否則每次改變 KVO 都會發出兩次通知。

常見的 KVO 錯誤

首先,KVO 相容是 API 的一部分。如果類的所有者不保證某個屬性相容 KVO,我們就不能保證 KVO 正常工作。蘋果文件裡有 KVO 相容屬性的文件。例如,NSProgress 類的大多數屬性都是相容 KVO 的。

當做出改變以後,有些人試著放空的 -willChange 和 -didChange 方法來強制 KVO 的觸發。KVO 通知雖然會生效,但是這樣做破壞了有依賴於 NSKeyValueObservingOld 選項的觀察者。詳細來說,這影響了 KVO 對觀察鍵路徑 (key path) 的原生支援。KVO 在觀察鍵路徑 (key path) 時依賴於 NSKeyValueObservingOld 屬性。

我們也要指出有些集合是不能被觀察的。KVO 旨在觀察關係 (relationship) 而不是集合。我們不能觀察 NSArray,我們只能觀察一個物件的屬性——而這個屬性有可能是 NSArray。舉例說,如果我們有一個 ContactList 物件,我們可以觀察它的 contacts 屬性。但是我們不能向要觀察物件的 -addObserver:forKeyPath:... 傳入一個 NSArray

相似地,觀察 self 不是永遠都生效的。而且這不是一個好的設計。

除錯 KVO

你可以在 lldb 裡檢視一個被觀察物件的所有觀察資訊。

這會列印出有關誰觀察誰之類的很多資訊。

這個資訊的格式不是公開的,我們不能讓任何東西依賴它,因為蘋果隨時都可以改變它。不過這是一個很強大的排錯工具。

鍵值驗證 (KVV)

最後提示,KVV 也是 KVC API 的一部分。這是一個用來驗證屬性值的 API,只是它光靠自己很難提供邏輯和功能。

如果我們寫能夠驗證值的 model 類的話,我們就應該實現 KVV 的 API 來保證一致性。用 KVV 驗證 model 類的值是 Cocoa 的慣例。

讓我們在一次強調一下:KVC 不會做任何的驗證,也不會呼叫任何 KVV 的方法。那是你的控制器需要做的事情。通過 KVV 實現你自己的驗證方法會保證它們的一致性。

以下是一個簡單的例子:

它強大之處在於,當 model 類(Contact)驗證 name 的時候,會有機會去處理名字。

如果我們想讓名字不要有前後的空白字元,我們應該把這些邏輯放在 model 物件裡面。Contact 類可以像這樣實現 KVV:

通訊錄示例 裡的 DetailViewController 和 Contact 類詳解了這個用法。

相關文章