OC觀察者模式之KVO的使用與思考

EAWorld發表於2020-04-06

OC觀察者模式之KVO的使用與思考

轉載本文需註明出處:微信公眾號EAWorld,違者必究。

引言:

無論用哪種語言進行軟體開發,我們都會接觸到設計模式,個人認為設計模式存在的意義在於:在某些需求下,採用適合的設計模式,使程式碼結構合理,從而提高程式碼的可讀性、可擴充套件性、可移植性,此文將要討論的是OC開發中的一種常用模式之一:觀察者模式之KVO。
KVO俗稱鍵值觀察(key-value observe),鍵值觀察是當被觀察的物件屬性發生改變時,會通知到觀察物件的一種機制。

目錄:

1、KVO的作用

2、KVO的使用方法

3、KVO的實現原理

4、KVO與KVC、代理、通知的區別

5、KVO實現過程中的注意事項

無論用哪種語言進行軟體開發,我們都會接觸到設計模式,個人認為設計模式存在的意義在於:在某些需求下,採用適合的設計模式,使程式碼結構合理,從而提高程式碼的可讀性、可擴充套件性、可移植性,此文將要討論的是iOS開發中的一種常用模式之一:觀察者模式之KVO。我們先看下官方文件給的KVO介紹:
OC觀察者模式之KVO的使用與思考

翻譯過來就是:KVO是運用isa混寫技術實現自動觀察鍵值的。isa指標是指向物件的類,本質上是指向類中的方法實現。當一個物件註冊觀察者時,這個物件的isa指標被修改指向一箇中間類。永遠不要用isa來判斷一個類的繼承關係,而是應該用class方法來判斷類的例項。

KVO俗稱鍵值觀察(key-value observe),鍵值觀察是當被觀察的物件屬性發生改變時,會通知到觀察物件的一種機制。
1.KVO的作用

1、監聽帶有狀態的基礎控制元件,如開關、按鈕等;

2、監聽字串的改變,當監聽的字串改變時,來做一些自定義的操作;

3、當資料模型的資料發生改變時,檢視元件能動態的更新,及時顯示資料模型更新後的資料,比如tableview中資料發生變化進行重新整理列表操作,監聽 scrollView的contentOffset屬性監聽頁面的滑動.

2.KVO的使用方法
KVO的使用可分為自動監聽和手動監聽。
1.自動監聽
1.1自動監聽操作步驟:
(1)新增觀察者
(2)在觀察者中新增觀察鍵值方法
(3)在dealloc中移除監聽

1.2示例程式碼:

建立兩個類ModelA和ModelB,兩個類中都新增屬性“des”,在控制器中,將B新增為A的觀察者。程式碼如下:

ModelA中程式碼:

OC觀察者模式之KVO的使用與思考

OC觀察者模式之KVO的使用與思考

ModelB中程式碼:

OC觀察者模式之KVO的使用與思考

OC觀察者模式之KVO的使用與思考

控制器中程式碼:


OC觀察者模式之KVO的使用與思考

控制器中新增觀察者的方法呼叫的是如下的類方法:
- (void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options context:(nullable void *)context
各個引數說明:
@param observer 被監聽的物件
@param keyPath 被監聽物件的屬性名,不可為空,為空崩潰
@param options 有4種
(1)NSKeyValueObservingOptionNew 把更改之前的值提供給處理方法
(2)NSKeyValueObservingOptionOld 把更改之後的值提供給處理方法
(3)NSKeyValueObservingOptionInitial 把初始化的值提供給處理方法,一旦註冊,立馬就會呼叫一次。通常它會帶有新值,而不會帶有舊值。
(4)NSKeyValueObservingOptionPrior 分2次呼叫。在值改變之前和值改變之後
@param context 上下文
上述示例程式碼的執行結果如下所示:
OC觀察者模式之KVO的使用與思考

2.手動監聽

OC觀察者模式之KVO的使用與思考

意思就是說:當某些需要控制監聽過程的場景下,就需要手動監聽,比如:為了儘量減少不必要的觸發通知操作,或者當多個更改同時具備的時候才呼叫屬性改變的監聽方法。

實現手動監聽的要點主要包括這幾部分:

a.重寫

(BOOL)automaticallyNotifiesObserversForKey:(NSString *)key

b.在set方法中在賦值的前後分別呼叫

willChangeValueForKey和didChangeValueForKey

2.1實現部分屬性的手動監聽

在animal.h中新增兩個屬性age和name,在animal.m中關閉age的自動監聽功能,其它屬性依然可以自動監聽,在控制其中實現新增按鈕點選按鈕的時候改變age的值,並觸發監聽方法,程式碼如下:
animal類:
OC觀察者模式之KVO的使用與思考
要實現類方法 automaticallyNotifiesObserversForKey,並在其中設定對特定的 key 不自動傳送通知(返回 NO 即可)。這裡要注意,對其它非手動實現的 key,要轉交給 super 來處理[1,2,3]
OC觀察者模式之KVO的使用與思考

控制器:

OC觀察者模式之KVO的使用與思考

OC觀察者模式之KVO的使用與思考

OC觀察者模式之KVO的使用與思考

當不點選按鈕的時候,列印結果只列印了name屬性的值:

OC觀察者模式之KVO的使用與思考

當點選按鈕之後,會手動觸發監聽,列印結果如下:

OC觀察者模式之KVO的使用與思考

2.2所有屬性都手動監聽(禁止自動監聽)

如果需要禁用該類KVO的話直接automaticallyNotifiesObserversForKey返回NO。
將animal.m中的類方法修改之後:
OC觀察者模式之KVO的使用與思考
執行之後不點選按鈕的話,age和name屬性都不會自動呼叫監聽方法:
OC觀察者模式之KVO的使用與思考
點選了按鈕之後,只有實現了手動監聽的age屬性呼叫了監聽方法:
OC觀察者模式之KVO的使用與思考

3.KVO的實現原理

當某一個類的例項第一次使用KVO的時候,系統就會在執行期間動態的建立該類的一個派生類,該類的命名規則一般是以NSKVONotifying為字首,以原本的類名為字尾。並且將原型的物件的isa指標指向該派生類。同時在派生類中過載了使用KVO的屬性的setter方法,在過載的setter方法中實現真正的通知機制,正如前面我們手動實現KVO一樣。這麼做是基於設定屬性會呼叫setter方法,而透過重寫就獲得了 KVO 需要的通知機制。當然前提是要透過遵循 KVO 的屬性設定方式來變更屬性值,如果僅是直接修改屬性對應的成員變數,是無法實現 KVO 的[4,5]

4.KVO與KVC、代理、通知的區別

 1.與KVC的不同?
KVC,即是指 NSKeyValueCoding,一個非正式的 Protocol,提供一種機制來間接訪問物件的屬性,而不是透過呼叫Setter、Getter方法等 顯式的存取方式去訪問。KVO 就是基於 KVC 實現的關鍵技術之一。
KVO,即Key-Value Observing,它提供一種機制,當指定的物件的屬性被修改後,物件就會接受到通知。
2.與delegate的不同?
和delegate一樣,KVO和NSNotification的作用都是類與類之間的通訊。但是與delegate不同的是:這兩個都是負責傳送接收通知,剩下的事情由系統處理,所以不用返回值;而delegate 則需要通訊的物件透過變數(代理)聯絡;delegate只是一對一,而這兩個可以一對多。delegate是非常嚴格的語法,需要定義很多程式碼。

3.和notification的區別?
notification比KVO多了傳送通知的一步。兩者都是一對多,但是物件之間直接的互動,notification明顯得多,需要notificationCenter來做為中間互動。而KVO如我們介紹的,設定觀察者->處理屬性變化,至於中間通知這一環,則隱秘多了,只留一句“交由系統通知”,具體的可參照以上實現過程的剖析。notification的優點是監聽不侷限於屬性的變化,還可以對多種多樣的狀態變化進行監聽,監聽範圍廣,例如鍵盤、前後臺等系統通知的使用也更顯靈活方便[6,7]
5.KVO實現過程中的注意事項

iOS 10以下會有這些情況,iOS11不會出現這些情況,但是為了程式碼的嚴謹性,以及以防出現無法預知的錯誤,還是避開這些比較好
1、新增觀察者次數與remove次數不匹配導致程式崩潰
連續對同一屬性新增觀察者是可以的,但是也要保證在移除觀察者的時候也要移除對應次,不然可能會引發崩潰(iOS11以上不會崩潰)。
當對同一個keypath進行兩次removeObserver時會導致程式crash,這種情況常常出現在父類有一個kvo,父類在dealloc中remove了一次,子類又remove了一次的情況下。不要以為這種情況很少出現!當你封裝framework開源給別人用或者多人協作開發時是有可能出現的,而且這種crash很難發現。不知道你發現沒,目前的程式碼中context欄位都是nil,那能否利用該欄位來標識出到底kvo是superClass註冊的,還是self註冊的?我們可以分別在父類以及本類中定義各自的context字串,比如在本類中定義context為@"ThisIsMyKVOContextNotSuper";然後在dealloc中remove observer時指定移除的自身新增的observer。這樣iOS就能知道移除的是自己的kvo,而不是父類中的kvo,避免二次remove造成crash[8]
2、移除不存在的觀察者(iOS11以上不會崩潰)
當某個物件並沒有新增觀察者時,卻執行了移除觀察者的操作,也會導致程式崩潰,此處不附相關程式碼。
3、被觀察者銷燬時還存在觀察者(iOS11以上不會崩潰)
這種情況常出現在複雜邏輯下,觀察者先於被觀察者銷燬[9]
4、KVO 行為是同步的,並且發生與所觀察的值發生變化的同樣的執行緒上。沒有佇列或者 Run-loop 的處理。手動或者自動呼叫 -didChange… 會觸發 KVO 通知。
所以,當我們試圖從其他執行緒改變屬性值的時候我們應當十分小心,除非能確定所有的觀察者都用執行緒安全的方法處理 KVO 通知。通常來說,我們不推薦把 KVO 和多執行緒混起來。如果我們要用多個佇列和執行緒,我們不應該在它們互相之間用 KVO[10]

參考資料:
[1]
[2]
[3]
[4]https://www.cnblogs.com/yang-shuai/p/8556326.html
[5]https://www.cnblogs.com/PSSSCode/p/5506577.html 
[6]
[7]
[8]https://www.cnblogs.com/wengzilin/p/4346775.html
[9]https://segmentfault.com/a/1190000016896055
[10]

關於作者小幸運,iOS軟體開發工程師,參與普元Dev客戶端OC程式碼的維護及新功能開發;使用普元移動開發平臺開發郵政移動平臺專案郵我行app。熱愛網際網路技術,努力拓寬技術面的程式媛一枚。

關於EWorld:微服務,DevOps,資料治理,移動架構原創技術分享。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562043/viewspace-2658407/,如需轉載,請註明出處,否則將追究法律責任。

相關文章