單例是整個 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。這樣有以下問題：

computeSum 沒有顯式地通過使用參數的形式聲明它依賴於 _a 和 _b 的狀態。與僅僅通過查看函數聲明就可以知道這個函數的輸出依賴於哪些變量不同的是，另一個開發者必須查看這個函數的具體實現才能明白這個函數依賴那些變量。隱藏依賴是不好的。
當爲調用 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。這種把依賴性傳遞給依賴對象的技術正式的叫法是依賴注入，它有很多優點：

對於閱讀這個 SPFriendListViewController 頭文件的讀者來說，可以很清楚的知道它只有在有登錄用戶的情況下才會被展示。
這個 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 開發的世界中，單例的使用是如此的普遍以至於我們有時候忘記了我們多年來在其他面向對象編程中學到的教訓。

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

避免濫用單例

全局狀態

對象的生命週期

避免使用單例

結論

app定位、地圖、座標系的那些坑

The image set "" has an unassigned child.

自定義地圖樣式，各地圖信息梳理。

iOS 版本號

NSDictionary不區分大小寫key讀取value

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結