iOS開發(fā)教程之單例使用問題分析

這篇文章主要講解了“iOS開發(fā)教程之單例使用問題分析”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“iOS開發(fā)教程之單例使用問題分析”吧！

導(dǎo)語

單例（Singletons），是Cocoa的核心模式之一。在iOS上，單例十分常見，比如：UIApplication，NSFileManager等等。雖然它們用起來十分方便，但實際上它們有許多問題需要注意。所以在你下次自動補(bǔ)全dispatch_once代碼片段的時候，想一下這樣會導(dǎo)致什么后果。

什么是單例

在《設(shè)計模式》一書中給出了單例的定義：

單例模式：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

單例模式提供了一個訪問點，供客戶類為共享資源生成唯一實例，并通過它來對共享資源進(jìn)行訪問，這一模式提供了靈活性。

在objective-c中，可以使用以下代碼創(chuàng)建一個單例：

+(instancetype)sharedInstance{ static dispatch_once_t once; static id sharedInstance; dispatch_once(&once, ^{ sharedInstance = [[self alloc]init]; }); return sharedInstance;}

當(dāng)類只能有一個實例，而且必須從一個訪問點對其進(jìn)行訪問時使用單例就顯得十分方便，因為使用單例保證了訪問點的唯一、一致且為人熟知。

單例中的問題

全局狀態(tài)

首先我們都應(yīng)該達(dá)成一個共識“全局可變狀態(tài)”是危險的，因為這樣會讓程序變得難以理解和調(diào)試，就削減狀態(tài)性代碼上，面向?qū)ο缶幊虘?yīng)該向函數(shù)式編程學(xué)習(xí)。

比如下面的代碼：

@implementation Math{ NSUInteger _a; NSUInteger _b;}-(NSUInteger)computeSum{ return _a + _b;}

這段代碼想要計算_a和_B相加的和，并返回。但事實上這段代碼存在著不少問題：

computeSum方法中并沒有把_a和_b作為參數(shù)。相比查找interface并了解哪個變量控制方法的輸出，查找implementation來了解顯得更隱蔽，而隱蔽代表著容易發(fā)生錯誤。當(dāng)準(zhǔn)備修改_a和_b的值來讓它們調(diào)用computeSum方法的時候，程序員必須清楚修改它們的值不會影響其他包含著兩個值的代碼的正確性，而在多線程的情況下作出這樣的判斷顯得尤其困難。

對比下面這段代碼：

+(NSUInteger)computeSumOf:(NSUInteger)a plus:(NSUInteger)b{ return a + b;}

這段代碼中，a和b的從屬顯得十分清晰，不再需要去改變實例的狀態(tài)來調(diào)用這個方法，而且不用擔(dān)心調(diào)用這個方法的副作用。

那這個例子和單例又有什么關(guān)系呢？事實上，單例就是披著羊皮的全局狀態(tài)。一個單例可以在任何地方被使用，而且不用清晰地聲明從屬。程序中的任何模塊都可以簡單的調(diào)用[MySingleton sharedInstance]，然后拿到這個單例的訪問點，這意味著任何和單例交互時產(chǎn)生的副作用都會有可能影響程序中隨機(jī)的一段代碼，如：

@interface MySingleton : NSObject+(instancetype)sharedInstance;-(NSUInteger)badMutableState;-(void)setBadMutableState:(NSUInteger)badMutableState;@end@implementation ConsumerA-(void)someMethod{ if([[MySingleton sharedInstance] badMutableState]){ //do something... }}@end@implementation ConsumerB-(void)someOtherMethod{ [[MySingleton sharedInstance] setBadMutableState:0];}

在上面的代碼中，ConsumerA和ComsumerB是程序中兩個完全獨立的模塊，但是ComsumerB中的方法會影響到ComsumerA中的行為，因為這個狀態(tài)的改變通過單例傳遞了過去。

在這段代碼，正是因為單例的全局性和狀態(tài)性，導(dǎo)致了ComsumerA和ComsumerB這兩個看起來似乎毫無關(guān)系的模塊之間隱含的耦合。

對象生命周期

另一個單例的主要問題是它們的生命周期。

舉個例子，假設(shè)一個app中需要實現(xiàn)能夠讓用戶看到他們的好友列表的功能，每一個好友有自己的頭像，同時我們還希望這個app能夠下載并緩存這些好友的頭像。這時候通過之前學(xué)習(xí)單例的知識，我們很可能會寫出以下的代碼：

@interface MyAppCache : NSObject+(instancetype)sharedCMyAppCache;-(void)cacheProfileImage:(NSData *)imageData forUserId:(NSString *)userID;-(NSData *)cachedProfileImageForUserId:(NSString *)userId;@end

這段代碼看起來完全沒有問題，運行起來也很好，所以app繼續(xù)開發(fā)，直到有一天，我們決定幫app加入“登出”的功能。突然我們發(fā)現(xiàn)，用戶數(shù)據(jù)儲存在全局單例中。當(dāng)用戶登出的時候，我們想要把這些數(shù)據(jù)清除掉，當(dāng)新用戶登入的時候，再為他創(chuàng)建一個新的MyAppCache。

但是問題出在了單例這里，因為單例的定義就是：“創(chuàng)建一次，永久存活”的實例。事實上有很多方法解決上面的問題，我們也許可以在用戶登出的時候銷毀這個單例：

static MyAppCache *myAppCache;+(instancetype)sharedMyAppCache{ if(!myAppCache) { myAppCache = [[self alloc] init]; } return myAppCache;}+(void)tearDown{ myAppCache = nil;}

上面的代碼扭曲了單例這個模式，但是能起到作用。

事實上的確可以使用這個方法來解決這個問題，但是代價太大了。最重要的一點是我們放棄了dispatch_once，而它正是保證了方法調(diào)用時候的線程安全，現(xiàn)在所有調(diào)用[MyAppCache shareMyAppCache]的代碼都會得到同一個變量，著需要清楚使用MyAppCache代碼執(zhí)行的順序。試想一下當(dāng)用戶在登出的時候碰巧后臺調(diào)用了這個方法來保存圖片。

另一方面，實行這個方法需要確保tearDown這個方法不會在后臺任務(wù)還沒執(zhí)行完成的時候調(diào)用，或者說確保執(zhí)行tearDown方法的時候后臺任務(wù)都會被取消。否則另一個新的MyAppCache將會創(chuàng)建，并把陳舊的數(shù)據(jù)保存進(jìn)去。

但是由于單例沒有明確的owner（因為單例自己管理自己的生命周期），銷毀一個單例是非常艱難的。

所以這時你可能會想，“那就不要把MyAppCache做成單例吧！”其實問題在于一個對象的生命周期在項目初期可能沒有辦法很好的確定，如果假設(shè)一個對象的生命周期將會匹配整個程序的生命周期，這將會大大限制了代碼的可拓展性，當(dāng)產(chǎn)品需求改動的時候這將會很痛苦。

所以上面的一切都是為了闡明一個觀點：“單例只應(yīng)該保持全局狀態(tài)，且該狀態(tài)的生命周期與程序的生命周期一致”。對于程序中已經(jīng)存在的單例，需要批判性的審閱。

不利于測試

關(guān)于這一部分原文中放到了上一章節(jié)中提及，但我認(rèn)為在軟件開發(fā)中測試是十分重要的一環(huán)，所以單獨把這一塊的內(nèi)容另開一個章節(jié)，并加入一些個人的見解。

由于單例一直在整個app的生命周期中存活著，甚至在執(zhí)行測試的時候也一直存活著，這導(dǎo)致了在一個測試或許會影響另一個測試，這是在單元測試中的大忌。所以有必要在進(jìn)行單元測試的時候能夠有效銷毀一個單例，并保持住單例線程安全的特性。但在上文中我提到：

"但是由于單例沒有明確的owner（因為單例自己管理自己的生命周期），銷毀一個單例是非常艱難的。"

似乎兩者在自相矛盾，其實不然，可以選擇簡化單例，與其擁有各種的單例，不如只擁有一個“真正的” 單例ServiceRegistry，而把其他“潛在的”單例來被ServiceRegistry引用，這樣其他單例擁有了一個owner，能夠在進(jìn)行單元測試的時候能夠及時對單例進(jìn)行銷毀，保證了單元測試的獨立性。

另一方面，ServiceRegistry的存在使得其他“單例”不再是單例，這樣在TDD的時候會讓之前難以 mock 的單例變得更加簡單的 mock 。

感謝各位的閱讀，以上就是“iOS開發(fā)教程之單例使用問題分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對iOS開發(fā)教程之單例使用問題分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！