單例是整個 Cocoa 中被廣泛使用的核心設計模式之一。事實上，蘋果開發者庫把單例作為 "Cocoa 核心競爭力" 之一。作為一個iOS開發者，我們經常和單例打交道，比如UIApplication和NSFileManager等等。我們在開源專案、蘋果示例程式碼和 StackOverflow 中見過了無數使用單例的例子。Xcode 甚至有一個預設的 "Dispatch Once" 程式碼片段，可以使我們非常簡單地在程式碼中新增一個單例：

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

由於這些原因，單例在 iOS 開發中隨處可見。問題是，它們很容易被濫用。

儘管有些人認為單例是 '反模式'， '魔鬼' 以及'病態的說謊者'，我不會去完全否認單例所帶來的的好處，而是會展示一些使用單例所帶來的問題，這樣下一次在使用dispatch_once程式碼片段的自動補全功能時，你可以對它的影響進行評估，三思而行。

全域性狀態

大多數的開發者都認同使用全域性可變的狀態是不好的行為。太多狀態使得程式難以理解，難以除錯。我們這些面向物件的程式設計師在最小化程式碼的狀態複雜程度的方面，有很多需要向函數語言程式設計學習的地方。

@implementation SPMath {
    NSUInteger _a;
    NSUInteger _b;
}

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

在上面這個簡單的數學庫的實現中，程式設計師需要在呼叫computeSum前正確的設定例項變數_a和_b。這樣有以下問題：

1. computeSum沒有顯式地通過使用引數的形式宣告它依賴於_a和_b的狀態。與僅僅通過檢視函式宣告就可以知道這個函式的輸出依賴於哪些變數不同的是，另一個開發者必須檢視這個函式的具體實現才能明白這個函式依賴那些變數。隱藏依賴是不好的。

2. 當為呼叫computeSum

   做準備而修改_a和_b的數值時，程式設計師需要保證這些修改不會影響任何其他依賴於這兩個變數的程式碼的正確性。而這在多執行緒的環境中是尤其困難的。

把下面的程式碼和上面的例子做對比：

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

這裡，對變數a和b的依賴被顯式地聲明瞭。我們不需要為了呼叫這個方法而去改變例項變數的狀態。並且我們也不需要擔心呼叫這個函式會留下持久的副作用。我們甚至可以把這個方法宣告為類方法，這樣就告訴了程式碼的閱讀者這個方法不會修改任何例項的狀態。

那麼，這個例子和單例又有什麼關係呢？用 Miško Hevery 的話來說，"單例就是披著羊皮的全域性狀態"。一個單例可以被使用在任何地方，而不需要顯式地宣告依賴。就像變數_a和_b在computeSum內部被使用了，卻沒有被顯式宣告一樣，程式的任意模組都可以呼叫[SPMySingleton sharedInstance]並且訪問這個單例。這意味著任何和這個單例互動產生的副作用都會影響程式其他地方的任意程式碼。

@interface SPSingleton : NSObject

+ (instancetype)sharedInstance;

- (NSUInteger)badMutableState;
- (void)setBadMutableState:(NSUInteger)badMutableState;

@end

@implementation SPConsumerA

- (void)someMethod
{
    if ([[SPSingleton sharedInstance] badMutableState]) {
        // ...
    }
}

@end

@implementation SPConsumerB

- (void)someOtherMethod
{
    [[SPSingleton sharedInstance] setBadMutableState:0];
}

@end

在上面的例子中，SPConsumerA和SPConsumerB是兩個完全獨立的模組。但是SPConsumerB可以通過使用單例提供的共享狀態來影響SPConsumerA的行為。這種情況應該只能發生在 consumer B 顯式引用了 A，並表明了兩者之間的關係時。這裡使用了單例，由於其具有全域性和多狀態的特性，導致隱式地在兩個看起來完全不相關的模組之間建立了耦合。

讓我們來看一個更具體的例子，並且暴露一個使用全域性可變狀態的額外問題。比如我們想要在我們的應用中構建一個網頁檢視器。為了支援這個檢視器，我們構建了一個簡單的 URL cache：

@interface SPURLCache

+ (SPCache *)sharedURLCache;

- (void)storeCachedResponse:(NSCachedURLResponse *)cachedResponse forRequest:(NSURLRequest *)request;

@end    

這個開發者開始寫一些單元測試來保證程式碼在一些不同的情況下都能達到預期。首先，他寫了一個測試用例來保證網頁檢視器在裝置沒有連線時能夠展示出錯誤資訊。然後他寫了一個測試用例來保證網頁檢視器能夠正確的處理伺服器錯誤。最後，他為成功情況時寫了一個測試用例，來保證返回的網路內容能夠被正確的顯示出來。這個開發者運行了所有的測試用例，並且它們都如預期一樣正確。贊！

幾個月以後，這些測試用例開始出現失敗，儘管網頁檢視器的程式碼從它寫完後就從來沒有再改動過！到底發生了什麼？

原來，有人改變了測試的順序。處理成功的那個測試用例首先被執行，然後再執行其他兩個。處理錯誤的那兩個測試用例現在竟然成功了，和預期不一樣，因為 URL cache 這個單例把不同測試用例之間的 response 快取起來了。

持久化狀態是單元測試的敵人，因為單元測試在各個測試用例相互獨立的情況下才有效。如果狀態從一個測試用例傳遞到了另外一個，這樣就和測試用例的執行順序就有關係了。有 bug 的測試用例，尤其是那些本來不應該通過的測試用例，是非常糟糕的事情。

物件的生命週期

另外一個關鍵問題就是單例的生命週期。當你在程式中新增一個單例時，很容易會認為 “永遠只會有一個例項”。但是在很多我看到過的 iOS 程式碼中，這種假定都可能被打破。

比如，假設我們正在構建一個應用，在這個應用裡使用者可以看到他們的好友列表。他們的每個朋友都有一張個人資訊的圖片，並且我們想使我們的應用能夠下載並且在裝置上快取這些圖片。 使用dispatch_once程式碼片段，我們可以寫一個SPThumbnailCache單例：

@interface SPThumbnailCache : NSObject

+ (instancetype)sharedThumbnailCache;

- (void)cacheProfileImage:(NSData *)imageData forUserId:(NSString *)userId;
- (NSData *)cachedProfileImageForUserId:(NSString *)userId;

@end

我們繼續構建我們的應用，一切看起來都很正常，直到有一天，我們決定去實現‘登出’功能，這樣使用者可以在應用中進行賬號切換。突然我們發現我們將要面臨一個討厭的問題：使用者相關的狀態儲存在全域性單例中。當用戶登出後，我們希望能夠清理掉所有的硬碟上的持久化狀態。否則，我們將會把這些被遺棄的資料殘留在使用者的裝置上，浪費寶貴的硬碟空間。對於使用者登出又登入了一個新的賬號這種情況，我們也想能夠對這個新使用者使用一個全新的SPThumbnailCache例項。

問題在於按照定義單例被認為是“建立一次，永久有效”的例項。你可以想到一些對於上述問題的解決方案。或許我們可以在使用者登出時移除這個單例：

static SPThumbnailCache *sharedThumbnailCache;

+ (instancetype)sharedThumbnailCache
{
    if (!sharedThumbnailCache) {
        sharedThumbnailCache = [[self alloc] init];
    }
    return sharedThumbnailCache;
}

+ (void)tearDown
{
    // The SPThumbnailCache will clean up persistent states when deallocated
    sharedThumbnailCache = nil;
}

這是一個明顯的對單例模式的濫用，但是它可以工作，對吧？

我們當然可以使用這種方式去解決，但是代價實在是太大了。我們不能使用簡單的的dispatch_once方案了，而這個方案能夠保證執行緒安全以及所有呼叫[SPThumbnailCache sharedThumbnailCache]的地方都能訪問到同一個例項。現在我們需要對使用縮圖 cache 的程式碼的執行順序非常小心。假設當用戶正在執行登出操作時，有一些後臺任務正在執行把圖片儲存到快取中的操作:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [[SPThumbnailCache sharedThumbnailCache] cacheProfileImage:newImage forUserId:userId];
});

我們需要保證在所有的後臺任務完成前，tearDown一定不能被執行。這確保了newImage資料可以被正確的清理掉。或者，我們需要保證在縮圖 cache 被移除時，後臺快取任務一定要被取消掉。否則，一個新的縮圖 cache 的例項將會被延遲建立，並且之前使用者的資料 (newImage物件) 會被儲存在它裡面。

由於對於單例例項來說它沒有明確的所有者，(因為單例自己管理自己的生命週期)，“關閉”一個單例變得非常的困難。

分析到這裡，我希望你能夠意識到，“這個縮圖 cache 從來就不應該作為一個單例！”。問題在於一個物件得生命週期可能在專案的最初階段沒有被很好得考慮清楚。舉一個具體的例子，Dropbox 的 iOS 客戶端曾經只支援一個賬號登入。它以這樣的狀態存在了數年，直到有一天我們希望能夠同時支援多個使用者賬號登入 (同時登陸私人賬號和工作賬號)。突然之間，我們以前的的假設“只能夠同時有一個使用者處於登入狀態”就不成立了。如果假定了一個物件的生命週期和應用的生命週期一致，那你的程式碼的靈活擴充套件就受到了限制，早晚有一天當產品的需求產生變化時，你會為當初的這個假定付出代價的。

這裡我們得到的教訓是，單例應該只用來儲存全域性的狀態，並且不能和任何作用域繫結。如果這些狀態的作用域比一個完整的應用程式的生命週期要短，那麼這個狀態就不應該使用單例來管理。用一個單例來管理使用者繫結的狀態，是程式碼的壞味道，你應該認真的重新評估你的物件圖的設計。

避免使用單例

既然單例對區域性作用域的狀態有這麼多的壞處，那麼我們應該怎樣避免使用它們呢？

讓我們來重溫一下上面的例子。既然我們的縮圖 cache 的快取狀態是和具體的使用者繫結的，那麼讓我們來定義一個user物件吧：

@interface SPUser : NSObject

@property (nonatomic, readonly) SPThumbnailCache *thumbnailCache;

@end

@implementation SPUser

- (instancetype)init
{
    if ((self = [super init])) {
        _thumbnailCache = [[SPThumbnailCache alloc] init];

        // Initialize other user-specific state...
    }
    return self;
}

@end

我們現在用一個物件來作為一個經過認證的使用者會話的模型類，並且我們可以把所有和使用者相關的狀態儲存在這個物件中。現在假設我們有一個view controller來展現好友列表：

@interface SPFriendListViewController : UIViewController

- (instancetype)initWithUser:(SPUser *)user;

@end

我們可以顯式地把經過認證的 user 物件作為引數傳遞給這個 view controller。這種把依賴性傳遞給依賴物件的技術正式的叫法是依賴注入，它有很多優點：

1. 對於閱讀這個SPFriendListViewController標頭檔案的讀者來說，可以很清楚的知道它只有在有登入使用者的情況下才會被展示。

2. 這個SPFriendListViewController只要還在使用中，就可以強引用 user 物件。舉例來說，對於前面的例子，我們可以像下面這樣在後臺任務中儲存一個圖片到縮圖 cache 中：

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [_user.thumbnailCache cacheProfileImage:newImage forUserId:userId];
    });
   

   就算後臺任務還沒有完成，應用其他地方的程式碼也可以建立和使用一個全新的SPUser物件，而不會在清理第一個例項時阻塞使用者互動。

為了更詳細的說明一下第二點，讓我們畫一下在使用依賴注入之前和之後的物件圖。

假設我們的SPFriendListViewController是當前 window 的 root view controller。使用單例時，我們的物件圖看起來如下所示：

view controller 自己，以及自定義的 image view 的列表，都會和sharedThumbnailCache產生互動。當用戶登出後，我們想要清理 root view controller 並且退出到登入頁面：

這裡的問題在於這個好友列表的 view controller 可能仍然在執行程式碼 (由於後臺操作的原因)，並且可能因此仍然有一些沒有執行的涉及到sharedThumbnailCache的呼叫。

和使用依賴注入的解決方案對比一下：

簡單起見，假設SPApplicationDelegate管理SPUser的例項 (在實踐中，你可能會把這些使用者狀態的管理工作交給另外一個物件來做，這樣可以使你的 application delegate簡化)。當展現好友列表 view controller 時，會傳遞進去一個 user 的引用。這個引用也會向下傳遞給 profile image views。現在，當用戶登出時，我們的物件圖如下所示：

這個物件圖看起來和使用單例時很像。那麼，區別是什麼呢？

關鍵問題是作用域。在單例那種情況中，sharedThumbnailCache仍然可以被程式的任意模組訪問。假如使用者快速的登入了一個新的賬號。該使用者也想看看他的好友列表，這也就意味著需要再一次的和縮圖 cache 產生互動：

當用戶登入一個新賬號，我們應該能夠構建並且與全新的SPThumbnailCache互動，而不需要再在銷燬老的縮圖 cache 上花費精力。基於物件管理的典型規則，老的 view controllers 和老的縮圖 cache 應該能夠自己在後臺延遲被清理掉。簡而言之，我們應該隔離使用者 A 相關聯的狀態和使用者 B 相關聯的狀態：

結論

希望這篇文章中的內容讀起來不像奇幻小說那樣難以理解。人們已經對單例的濫用抱怨了很多年了，並且我們也都知道全域性狀態是很不好的事情。但是在 iOS 開發的世界中，單例的使用是如此的普遍以至於我們有時候忘記了我們多年來在其他面向物件程式設計中學到的教訓。

這一切的關鍵點是，在面向物件程式設計中我們想要最小化可變狀態的作用域。但是單例卻因為使可變的狀態可以被程式中的任何地方訪問，而站在了對立面。下一次你想使用單例時，我希望你能夠好好考慮一下使用依賴注入作為替代方案。