卷首語(yǔ)
歡迎來(lái)到 objc.io 第七期！
這個(gè)月，我們選擇了 Foundation 框架作為我們的主題。
Foundation 框架的起源，可追溯到NeXTSTEP的時(shí)代, 到現(xiàn)在大概有 25 年的歷史了，涵蓋了很多的內(nèi)容。
本期不會(huì)描述太多關(guān)于 Foundation 框架的細(xì)節(jié)，而是重點(diǎn)會(huì)選取幾個(gè)話題來(lái)進(jìn)行討論。我們選擇了對(duì)所有 Objective-C 開發(fā)者都有用的一些話題：基礎(chǔ)集合類（collection classes）、KVC(key-value coding) 和 KVO(key-value observing)、值對(duì)象（value objects）和 值格式處理器（value formatters）。我們也挑選了一篇通用的關(guān)于通訊模式的文章，文章討論了在 Foundation 框架中發(fā)現(xiàn)的一些模式，也涉及到了一個(gè)比較特別的話題：NSLinguisticTagger.
非常感謝Peter Steinberger，Klaas Pieter Annema和Oliver Mason，他們?yōu)檫@一期貢獻(xiàn)了很多。也很感謝為這個(gè)社區(qū)出力的所有人，沒有他們就沒有 objc.io?？纯次覀兊?a target="_blank" rel="nofollow">貢獻(xiàn)者的名單，我就明白我所說(shuō)的了。
說(shuō)到支持，我們上個(gè)月上線了objc.io Newsstand應(yīng)用，那時(shí)候我們說(shuō)，或者你可以捐贈(zèng)支持我們。后續(xù)的反響很令人欣慰。我們并不是說(shuō)需要拿錢去買什么很酷的車子，捐贈(zèng)所得的錢會(huì)用于維持這個(gè)網(wǎng)站的日常運(yùn)作，如果有余錢，我們會(huì)把余錢捐給那些和 objc.io 的理念相似的社區(qū)協(xié)作項(xiàng)目上。
為了信息的透明，我們需要說(shuō)明，現(xiàn)在大部分的錢被用于主機(jī)、設(shè)計(jì)工作和內(nèi)容編輯上。另外，我們每個(gè)月會(huì)抽出一小部分錢，存著留待日后用于 objc.io 的改善上。盡管也花費(fèi)了不少，現(xiàn)在還是有不少的余錢。
除了上面的提到的，我們還決定要把錢用在有意義的地方（where it makes a difference）。從這個(gè)月開始，我們會(huì)把額外的錢捐贈(zèng)給一個(gè)慈善計(jì)劃。我們會(huì)在下個(gè)月公布更多的消息。
從柏林發(fā)來(lái)最誠(chéng)摯的祝福!
Chris, Daniel 和 Florian。
基礎(chǔ)集合類
NSArray, NSSet, NSOrderedSet 和 NSDictionary
基礎(chǔ)集合類是每一個(gè) Mac/iOS 應(yīng)用的基本組成部分。在本文中，我們將對(duì)”老類” (NSArray,NSSet)和”新類” (NSMapTable,NSHashTable,NSPointerArray) 進(jìn)行一個(gè)深入的研究，探索每一個(gè)的效率細(xì)節(jié)，并討論其使用場(chǎng)景。
作者提示：本文包含一些參照結(jié)果，但它們并不意味著絕對(duì)精確，也沒有進(jìn)行均差分析及多次的測(cè)試。這些結(jié)果的目的是給出運(yùn)行時(shí)統(tǒng)計(jì)，來(lái)幫助我們認(rèn)識(shí)到通常來(lái)說(shuō)用什么會(huì)更快。所有的測(cè)試基于 iPhone 5s，使用 Xcode 5.1b1 和 iOS 7.1b1 的 64 位程序。編譯選項(xiàng)設(shè)置為 -Ofast 的發(fā)布構(gòu)建。Vectorize loops 和 unroll loops (默認(rèn)設(shè)置) 均設(shè)置為關(guān)閉。
大 O 符號(hào)，算法復(fù)雜度計(jì)量
首先，我們需要一些理論知識(shí)。效率通常用大 O 符號(hào)描述。它定義了一個(gè)函數(shù)的極限特征，通常被用于描繪其算法效率。O 定義了函數(shù)增長(zhǎng)率的上限。不同量級(jí)的差異非常巨大，可以看看通常使用的 O 符號(hào)的量級(jí)以及它們所對(duì)應(yīng)需要的操作數(shù)的關(guān)系。
例如，如果用算法復(fù)雜度為 O(n^2)的算法對(duì)一個(gè)有 50 個(gè)元素的數(shù)組排序，需要 2,500 步的操作。而且，還有內(nèi)部的系統(tǒng)開銷和方法調(diào)用 — 所以是 250 0個(gè)操作的時(shí)間常量。 O(1)是理想的復(fù)雜度，代表著恒定的時(shí)間。好的排序算法通常需要 O(n*log n) 的時(shí)間。
可變性
大多數(shù)的集合類存在兩個(gè)版本:可變和不可變(默認(rèn))。這和其他大多數(shù)的框架有非常大的不同，一開始會(huì)讓人覺得有一點(diǎn)奇怪。然而其他的框架現(xiàn)在也應(yīng)用了這一特性：就在幾個(gè)月前，.NET公布了作為官方擴(kuò)展的不可變集合。
最大的好處是什么？線程安全。不可變的集合完全是線程安全的，可以同時(shí)在多個(gè)線程中迭代，避免各種轉(zhuǎn)變時(shí)出現(xiàn)異常的風(fēng)險(xiǎn)。你的 API絕不應(yīng)該暴露一個(gè)可變的集合。
當(dāng)然從不可變到可變?nèi)缓笤倩貋?lái)是會(huì)有一定代價(jià)的 — 對(duì)象必須被拷貝兩次，所有集合內(nèi)的對(duì)象將被 retain/release。有時(shí)在內(nèi)部使用一個(gè)可變的集合，而在訪問時(shí)返回一個(gè)不可變的對(duì)象副本會(huì)更高效。
與其他框架不同的是，蘋果沒有提供一個(gè)線程安全的可變集合，NSCache是例外，但它真的算不上是集合類，因?yàn)樗皇且粋€(gè)通用的容器。大多數(shù)時(shí)候，你不會(huì)需要在集合層級(jí)的同步特性。想象一段代碼，作用是檢查字典中一個(gè) key 是否存在，并根據(jù)檢查結(jié)果決定設(shè)置一個(gè)新的 key 或者返回某些值 — 你通常需要把多個(gè)操作歸類，這時(shí)線程安全的可變集合并不能對(duì)你有所幫助。
其實(shí)也有一些同步的，線程安全的可以使用的可變集合案例，它們往往只需要用幾行代碼，通過子類和組合的方法建立，比如這個(gè)NSDictionary或這個(gè)NSArray。
需要注意的是，一些較新的集合類，如NSHashTable，NSMapTable和NSPointerArray默認(rèn)就是可變的，它們并沒有對(duì)應(yīng)的不可變的類。它們用于類的內(nèi)部使用，你基本應(yīng)該不會(huì)能找到需要它們的不可變版本的應(yīng)用場(chǎng)景。
NSArray
NSArray作為一個(gè)存儲(chǔ)對(duì)象的有序集合，可能是被使用最多的集合類。這也是為什么它有自己的比原來(lái)的[NSArray arrayWithObjects:..., nil]簡(jiǎn)短得多的快速語(yǔ)法糖符號(hào)@[...]。NSArray實(shí)現(xiàn)了objectAtIndexedSubscript:，因?yàn)槲覀兛梢允褂妙?C 的語(yǔ)法array[0]來(lái)代替原來(lái)的[array objectAtIndex:0]。
性能特征
關(guān)于NSArray的內(nèi)容比你想象的要多的多。基于存儲(chǔ)對(duì)象的多少，它使用各種內(nèi)部的變體。最有趣的部分是蘋果對(duì)于個(gè)別的對(duì)象訪問并不保證 O(1) 的訪問時(shí)間 — 正如你在CFArray.h CoreFoundation 頭文件中的關(guān)于算法復(fù)雜度的注解中可以讀到的:
對(duì)于 array 中值的訪問時(shí)間，不管是在現(xiàn)在還是將來(lái)，我們保證在任何一種實(shí)現(xiàn)下最壞情況是 O(lg N)。但是通常來(lái)說(shuō)它會(huì)是 O(1) (常數(shù)時(shí)間)。線性搜索操作很可能在最壞情況下的復(fù)雜度為 O(N*lg N)，但通常來(lái)說(shuō)上限會(huì)更小一些。插入和刪除操作耗時(shí)通常和數(shù)組中的值的數(shù)量成線性關(guān)系。但在某些實(shí)現(xiàn)的最壞情況下會(huì)是 O(N*lg N) 。在數(shù)組中，沒有對(duì)于性能上特別有優(yōu)勢(shì)的數(shù)據(jù)位置，也就是說(shuō)，為了更快地訪問到元素而將其設(shè)為在較低的 index 上，或者在較高的 index 上進(jìn)行插入和刪除，或者類似的一些做法，是沒有必要的。
在測(cè)量的時(shí)候，NSArray產(chǎn)生了一些有趣的額外的性能特征。在數(shù)組的開頭和結(jié)尾插入/刪除元素通常是一個(gè) O(1)操作，而隨機(jī)的插入/刪除通常是 O(N) 的。
有用的方法
NSArray的大多數(shù)方法使用isEqual:來(lái)檢查對(duì)象間的關(guān)系(例如containsObject:中)。有一個(gè)特別的方法indexOfObjectIdenticalTo:用來(lái)檢查指針相等，如果你確保在同一個(gè)集合中搜索，那么這個(gè)方法可以很大的提升搜索速度。 在 iOS 7 中，我們最終得到了與lastObject對(duì)應(yīng)的公開的firstObject方法，對(duì)于空數(shù)組，這兩個(gè)方法都會(huì)返回nil— 而常規(guī)的訪問方法會(huì)拋出一個(gè)NSRangeException異常。
關(guān)于構(gòu)造（可變）數(shù)組有一個(gè)漂亮的細(xì)節(jié)可以節(jié)省代碼量。如果你通過一個(gè)可能為 nil 的數(shù)組創(chuàng)建一個(gè)可變數(shù)組，通常會(huì)這么寫:
或者通過更簡(jiǎn)潔的三元運(yùn)算符:
NSMutableArray*mutableObjects = [array mutableCopy] ?: [NSMutableArrayarray];
更好的解決方案是使用arrayWithArray:，即使原數(shù)組為nil，該方法也會(huì)返回一個(gè)數(shù)組對(duì)象:
NSMutableArray*mutableObjects = [NSMutableArrayarrayWithArray:array];
這兩個(gè)操作在效率上幾乎相等。使用copy會(huì)快一點(diǎn)點(diǎn)，不過話說(shuō)回來(lái)，這不太可能是你應(yīng)用的瓶頸所在。提醒：不要使用[@[] mutableCopy]。經(jīng)典的[NSMutableArray array]可讀性更好。
逆序一個(gè)數(shù)組非常簡(jiǎn)單：array.reverseObjectEnumerator.allObjects。我們使用系統(tǒng)提供的reverseObjectEnumerator，每一個(gè)NSEnumerator都實(shí)現(xiàn)了allObjects，該方法返回一個(gè)新數(shù)組。雖然沒有原生的randomObjectEnumerator方法，你可以寫一個(gè)自定義的打亂數(shù)組順序的枚舉器或者使用一些出色的開源代碼。
數(shù)組排序
有很多各種各樣的方法來(lái)對(duì)一個(gè)數(shù)組排序。如果數(shù)組存儲(chǔ)的是字符串對(duì)象，sortedArrayUsingSelector:是第一選擇:
如果想更可控，可以使用基于函數(shù)指針的排序方法:
蘋果增加了一個(gè)方法來(lái)加速使用sortedArrayHint的排序。
hinted sort 方式在你有一個(gè)已排序的大數(shù)組 (N 個(gè)元素) 并且只改變其中一小部分（P 個(gè)添加和刪除，這里 P遠(yuǎn)小于 N）時(shí)，會(huì)非常有效。你可以重用原來(lái)的排序結(jié)果，然后在 N 個(gè)老項(xiàng)目和 P 個(gè)新項(xiàng)目進(jìn)行一個(gè)概念上的歸并排序。為了得到合適的 hint，你應(yīng)該在原來(lái)的數(shù)組排序后使用 sortedArrayHint 來(lái)在你需要的時(shí)候(比如在數(shù)組改變后想重新排序時(shí))保證持有它。
因?yàn)閎lock的引入，也出現(xiàn)了一些基于block的排序方法:
性能上來(lái)說(shuō)，不同的方法間并沒有太多的不同。有趣的是，基于 selector 的方式是最快的。
:
Sorting 1000000 elements. selector: 4947.90[ms] function: 5618.93[ms] block: 5082.98[ms].
二分查找
NSArray從 iOS 4 / Snow Leopard 開始內(nèi)置了二分查找
這是個(gè)簡(jiǎn)單的衡量二分查找有多快的數(shù)據(jù):
Timeto searchfor1000entries within1000000objects.Linear:54130.38[ms].Binary:7.62[ms]
作為比較，查找NSOrderedSet中的指定索引花費(fèi) 0.23 毫秒 — 就算和二分查找相比也又快了 30 多倍。
記住排序的開銷也是昂貴的。蘋果使用復(fù)雜度為 O(n*log n) 的歸并排序，所以如果你執(zhí)行一次indexOfObject:的話，就沒有必要使用二分查找了。
通過指定NSBinarySearchingInsertionIndex，你可以獲得正確的插入索引，以確保在插入元素后仍然可以保證數(shù)組的順序。
枚舉和總覽
作為測(cè)試，我們來(lái)看一個(gè)普通的使用場(chǎng)景。從一個(gè)數(shù)組中過濾出一些元素組成另一個(gè)數(shù)組。這些測(cè)試都包括了枚舉的方法以及使用 API 進(jìn)行過濾的方式：
indexesOfObjectsWithOptions:passingTest:必須每次都執(zhí)行一次 block 因此比傳統(tǒng)的使用NSFastEnumeration技術(shù)的基于 for 循環(huán)的枚舉要稍微低效一些。但是如果開啟了并發(fā)枚舉，那么前者的速度則會(huì)大大的超過后者幾乎 2 倍。iPhone 5s 是雙核的，所以這說(shuō)得通。這里并沒有體現(xiàn)出來(lái)的是NSEnumerationConcurrent只對(duì)大量的對(duì)象有意義，如果你的集合中的對(duì)象數(shù)量很少，用哪個(gè)方法就真的無(wú)關(guān)緊要。甚至NSEnumerationConcurrent上額外的線程管理實(shí)際上會(huì)使結(jié)果變得更慢。
最大的輸家是filteredArrayUsingPredicate:。NSPredicate需要在這里提及是因?yàn)?，人們可以寫?a target="_blank" rel="nofollow">非常復(fù)雜的表達(dá)式，尤其是用不基于 block 的變體。使用 Core Data 的用戶應(yīng)該會(huì)很熟悉。
為了比較的完整，我們也加入了NSEnumerator作為比較 — 雖然沒有任何理由再使用它了。然而它竟出人意料的快(至少還是比基于NSPredicate的過濾要快)，它的運(yùn)行時(shí)消耗無(wú)疑比快速枚舉更多 — 現(xiàn)在它只用于向后兼容。甚至沒有優(yōu)化過的objectAtIndex:都要更快些。
NSFastEnumeration
在OSX 10.5和iOS的最初版本中，蘋果增加了NSFastEnumeration。在此之前，只有每次返回一個(gè)元素的NSEnumeration，每次迭代都有運(yùn)行時(shí)開銷。而快速枚舉，蘋果通過countByEnumeratingWithState:objects:count:返回一個(gè)數(shù)據(jù)塊。該數(shù)據(jù)塊被解析成id類型的 C 數(shù)組。這就是更快的速度的原因；迭代一個(gè) C 數(shù)組要快得多，而且可以被編譯器更深一步的優(yōu)化。手動(dòng)的實(shí)現(xiàn)快速枚舉是十分難辦的，所以蘋果的FastEnumerationSample是一個(gè)不錯(cuò)的開始，還有一篇Mike Ash 的文章也很不錯(cuò)。
應(yīng)該用arrayWithCapacity:嗎?
初始化NSArray的時(shí)候，可以選擇指定數(shù)組的預(yù)期大小。在檢測(cè)的時(shí)候，結(jié)果是在效率上沒有差別 — 至少在統(tǒng)計(jì)誤差范圍內(nèi)的測(cè)量的時(shí)間幾乎相等。有消息透漏說(shuō)實(shí)際上蘋果根本沒有使用這個(gè)參數(shù)。然而使用arrayWithCapacity:仍然好處，它可以作為一種隱性的文檔來(lái)幫助你理解代碼:
Adding 10.000.000 elements to NSArray. no count 1067.35[ms] with count: 1083.13[ms].
子類化注意事項(xiàng)
很少有理由去子類化基礎(chǔ)集合類。大多數(shù)時(shí)候，使用 CoreFoundation 級(jí)別的類并且自定義回調(diào)函數(shù)定制自定義行為是更好的解決方案。 創(chuàng)建一個(gè)大小寫不敏感的字典，一種方法是子類化NSDictionary并且自定義訪問方法，使其將字符串始終變?yōu)樾?或大寫)，并對(duì)排序也做類似的修改。更快更好的解決方案是提供一組不同的CFDictionaryKeyCallBacks集，你可以提供自定義的hash和isEqual:回調(diào)。你可以在這里找到一個(gè)例子。這種方法的優(yōu)美之處應(yīng)該歸功于toll-free 橋接)，它仍然是一個(gè)簡(jiǎn)單的字典，因此可以被任何使用NSDictionary作為參數(shù)的API接受。
子類作用的一個(gè)例子是有序字典的用例。.NET 提供了一個(gè)SortedDictionary，Java 有TreeMap，C++ 有std::map。雖然你可以使用 C++ 的 STL 容器，但卻無(wú)法使它自動(dòng)的retain/release，這會(huì)讓使用起來(lái)笨拙得多。因?yàn)镹SDictionary是一個(gè)類簇，所以子類化跟人們想象的相比非常不同。這已經(jīng)超過了本文的討論范疇，這里有一個(gè)真實(shí)的有序字典的例子。
NSDictionary
一個(gè)字典存儲(chǔ)任意的對(duì)象鍵值對(duì)。 由于歷史原因，初始化方法[NSDictionary dictionaryWithObjectsAndKeys:object, key, nil]使用了相反的值到鍵的順序，而新的快捷語(yǔ)法則從 key 開始，@{key : value, ...}。
NSDictionary中的鍵是被拷貝的并且需要是不變的。如果在一個(gè)鍵在被用于在字典中放入一個(gè)值后被改變的話，那么這個(gè)值就會(huì)變得無(wú)法獲取了。一個(gè)有趣的細(xì)節(jié)是，在NSDictionary中鍵是被 copy 的，但是在使用一個(gè) toll-free 橋接的CFDictionary時(shí)卻只會(huì)被 retain。CoreFoundation 類沒有通用的拷貝對(duì)象的方法，因此這時(shí)拷貝是不可能的(*)。這只適用于你使用CFDictionarySetValue()的時(shí)候。如果你是通過setObject:forKey來(lái)使用一個(gè) toll-free 橋接的CFDictionary的話，蘋果會(huì)為其增加額外處理邏輯，使得鍵被拷貝。但是反過來(lái)這個(gè)結(jié)論則不成立 — 使用已經(jīng)轉(zhuǎn)換為CFDictionary的NSDictionary對(duì)象，并用對(duì)其使用CFDictionarySetValue()方法，還是會(huì)導(dǎo)致調(diào)用回setObject:forKey并對(duì)鍵進(jìn)行拷貝。
(*)其實(shí)有一個(gè)現(xiàn)成的鍵的回調(diào)函數(shù)kCFCopyStringDictionaryKeyCallBacks可以拷貝字符串，因?yàn)閷?duì)于 ObjC對(duì)象來(lái)說(shuō)，CFStringCreateCopy()會(huì)調(diào)用[NSObject copy]，我們可以巧妙使用這個(gè)回調(diào)來(lái)創(chuàng)建一個(gè)能進(jìn)行鍵拷貝的CFDictionary。
性能特征
蘋果在定義字典的計(jì)算復(fù)雜度時(shí)顯得相當(dāng)?shù)驼{(diào)。唯一的信息可以在CFDictionary的頭文件中找到:
對(duì)于字典中值的訪問時(shí)間，不管是在現(xiàn)在還是將來(lái)，我們保證在任何一種實(shí)現(xiàn)下最壞情況是 O(N)。但通常來(lái)說(shuō)它會(huì)是 O(1) (常數(shù)時(shí)間)。插入和刪除操作一般來(lái)說(shuō)也會(huì)是常數(shù)時(shí)間，但是在某些實(shí)現(xiàn)中最壞情況將為 O(N*N)。通過鍵來(lái)訪問值將比直接訪問值要快（如果你有這樣的操作要做的話）。對(duì)于同樣數(shù)目的值，字典需要花費(fèi)比數(shù)組多得多的內(nèi)存空間。
跟數(shù)組相似的，字典根據(jù)尺寸的不同使用不同的實(shí)現(xiàn)，并在其中無(wú)縫切換。
枚舉和總覽
過濾字典有幾個(gè)不同的方法:
(*)使用getObjects:andKeys:時(shí)需要注意。在上面的代碼例子中，我們使用了可變長(zhǎng)度數(shù)組這一 C99 特性(通常，數(shù)組的數(shù)量需要是一個(gè)固定值)。這將在棧上分配內(nèi)存，雖然更方便一點(diǎn)，但卻有其限制。上面的代碼在元素?cái)?shù)量很多的時(shí)候會(huì)崩潰掉，所以我們使用基于malloc/calloc的分配 (和free) 以確保安全。
為什么這次NSFastEnumeration這么慢？迭代字典通常需要鍵和值兩者，快速枚舉只能枚舉鍵，我們必須每次都自己獲取值。使用基于 block 的enumerateKeysAndObjectsUsingBlock:更高效，因?yàn)閮烧叨伎梢愿咝У谋惶崆矮@取。
這次測(cè)試的勝利者又是通過keysOfEntriesWithOptions:passingTest:和objectsForKeys:notFoundMarker:的并發(fā)迭代。代碼稍微多了一點(diǎn)，但是可以用 category 進(jìn)行漂亮的封裝。
應(yīng)該用 dictionaryWithCapacity: 嗎?
到現(xiàn)在你應(yīng)該已經(jīng)知道該如何測(cè)試了，簡(jiǎn)單的回答是不，count參數(shù)沒有改變?nèi)魏问虑?
Adding 10000000 elements to NSDictionary. no count 10786.60[ms] with count: 10798.40[ms].
排序
關(guān)于字典排序沒有太多可說(shuō)的。你只能將鍵數(shù)組排序?yàn)橐粋€(gè)新對(duì)象，因此你可以使用任何正規(guī)的NSArray的排序方法:
共享鍵
從 iOS 6 和 OS X 10.8 開始，新建的字典可以使用一個(gè)預(yù)先生成好的鍵集，使用sharedKeySetForKeys:從一個(gè)數(shù)組中創(chuàng)建鍵集，然后用dictionaryWithSharedKeySet:創(chuàng)建字典。共享鍵集會(huì)復(fù)用對(duì)象，以節(jié)省內(nèi)存。根據(jù)Foundation Release Notes，sharedKeySetForKeys:中會(huì)計(jì)算一個(gè)最小完美哈希，這個(gè)哈希值可以取代字典查找過程中探索循環(huán)的需要，因此使鍵的訪問更快。
雖然在我們有限的測(cè)試中沒有法線蘋果在NSJSONSerialization中使用這個(gè)特性，但毫無(wú)疑問，在處理 JSON 的解析工作時(shí)這個(gè)特性可以發(fā)揮得淋漓盡致。(使用共享鍵集創(chuàng)建的字典是NSSharedKeyDictionary的子類；通常的字典是__NSDictionaryI/__NSDictionaryM，I / M 表明可變性；可變和不可變的的字典在 toll-free 橋接后對(duì)應(yīng)的都是_NSCFDictionary類。)
有趣的細(xì)節(jié)：共享鍵字典始終是可變的，即使對(duì)它們執(zhí)行了”copy”命令后也是。這個(gè)行為文檔中并沒有說(shuō)明，但很容易被測(cè)試:
NSSet
NSSet和它的可變變體NSMutableSet是無(wú)序?qū)ο蠹稀z查一個(gè)對(duì)象是否存在通常是一個(gè) O(1) 的操作，使得比NSArray快很多。NSSet只在被使用的哈希方法平衡的情況下能高效的工作；如果所有的對(duì)象都在同一個(gè)哈?？饍?nèi)，NSSet在查找對(duì)象是否存在時(shí)并不比NSArray快多少。
NSSet還有變體NSCountedSet，以及非 toll-free 計(jì)數(shù)變體CFBag/CFMutableBag。
NSSet會(huì) retain 它其中的對(duì)象，但是根據(jù) set 的規(guī)定，對(duì)象應(yīng)該是不可變的。添加一個(gè)對(duì)象到 set 中隨后改變它會(huì)導(dǎo)致一些奇怪的問題并破壞 set 的狀態(tài)。
NSSet的方法比NSArray少的多。沒有排序方法，但有一些方便的枚舉方法。重要的方法有allObjects，將對(duì)象轉(zhuǎn)化為NSArray，anyObject則返回任意的對(duì)象，如果 set 為空，則返回 nil。
Set 操作
NSMutableSet有幾個(gè)很強(qiáng)大的方法，例如intersectSet:，minusSet:和unionSet:。
應(yīng)該用setWithCapacity:嗎?
我們?cè)僖淮螠y(cè)試當(dāng)創(chuàng)建 set 時(shí)給定容量大小是否會(huì)有顯著的速度差異:
Adding 1.000.000 elements to NSSet. no count 2928.49[ms] with count: 2947.52[ms].
在統(tǒng)計(jì)誤差范圍內(nèi)，結(jié)果沒有顯著差異。有一份證據(jù)表明至少在上一個(gè) runtime 版本中，有很多的性能上的影響。
NSSet 性能特征
這個(gè)檢測(cè)非常符合我們的預(yù)期：NSSet在每一個(gè)被添加的對(duì)象上執(zhí)行hash和isEqual:方法并管理一系列哈希值，所以在添加元素時(shí)耗費(fèi)了更多的時(shí)間。set的隨機(jī)訪問比較難以測(cè)試，因?yàn)檫@里執(zhí)行的都是anyObject。
這里沒有必要包含containsObject:的測(cè)試，set 要快幾個(gè)數(shù)量級(jí)，畢竟這是它的特點(diǎn)。
NSOrderedSet
NSOrderedSet在 iOS 5 和 Mac OS X 10.7 中第一次被引入，除了 Core Data，幾乎沒有直接使用它的 API?？瓷先ニC合了NSArray和NSSet兩者的好處，對(duì)象查找，對(duì)象唯一性，和快速隨機(jī)訪問。
NSOrderedSet有著優(yōu)秀的 API 方法，使得它可以很便利的與其他 set 或者有序 set 對(duì)象合作。合并，交集，差集，就像NSSet支持的那樣。它有NSArray中除了比較陳舊的基于函數(shù)的排序方法和二分查找以外的大多數(shù)排序方法。畢竟containsObject:非?？?，所以沒有必要再用二分查找了。
NSOrderedSet的array和set方法分別返回一個(gè)NSArray和NSSet，這些對(duì)象表面上是不可變的對(duì)象，但實(shí)際上在 NSOrderedSet 更新的時(shí)候，它們也會(huì)更新自己。如果你在不同線程上使用這些對(duì)象并發(fā)生了詭異異常的時(shí)候，知道這一點(diǎn)是非常有好處的。本質(zhì)上，這些類使用的是__NSOrderedSetSetProxy和__NSOrderedSetArrayProxy。
附注：如果你想知道為什么NSOrderedSet不是NSSet的子類，NSHipster 上有一篇非常好的文章解釋了可變/不可變類簇的缺點(diǎn)。
NSOrderedSet 性能特征
這個(gè)測(cè)試在每一個(gè)集合類中添加自定義字符串，隨后隨機(jī)訪問它們。
NSOrderedSet比NSSet和NSArray占用更多的內(nèi)存，因?yàn)樗枰瑫r(shí)維護(hù)哈希值和索引。
NSHashTable
NSHashTable效仿了NSSet，但在對(duì)象/內(nèi)存處理時(shí)更加的靈活?？梢酝ㄟ^自定義CFSet的回調(diào)獲得NSHashTable的一些特性，哈希表可以保持對(duì)對(duì)象的弱引用并在對(duì)象被銷毀之后正確的將其移除，有時(shí)候如果手動(dòng)在 NSSet 中添加的話，想做到這個(gè)是挺惡心的一件事。它是默認(rèn)可變的 — 并且這個(gè)類沒有相應(yīng)的不可變版本。
NSHashTable有 ObjC 和原始的 C API，C API 可以用來(lái)存儲(chǔ)任意對(duì)象。蘋果在 10.5 Leopard 系統(tǒng)中引入了這個(gè)類，但是 iOS 的話直到最近的 iOS 6 中才被加入。足夠有趣的是它們只移植了 ObjC API；更多強(qiáng)大的 C API 沒有包括在 iOS 中。
NSHashTable可以通過initWithPointerFunctions:capacity:進(jìn)行大量的設(shè)置 — 我們只選取使用預(yù)先定義的hashTableWithOptions:這一最普遍的使用場(chǎng)景。其中最有用的選項(xiàng)有利用weakObjectsHashTable來(lái)使用其自身的構(gòu)造函數(shù)。
NSPointerFunctions
這些指針函數(shù)可以被用在NSHashTable，NSMapTable和NSPointerArray中，定義了對(duì)存儲(chǔ)在這個(gè)集合中的對(duì)象的獲取和保留行為。這里只介紹最有用的選項(xiàng)。完整列表參見NSPointerFunctions.h。
有兩組選項(xiàng)。內(nèi)存選項(xiàng)決定了內(nèi)存管理，個(gè)性化定義了哈希和相等。
NSPointerFunctionsStrongMemory創(chuàng)建了一個(gè)r etain/release 對(duì)象的集合，非常像常規(guī)的NSSet或NSArray。
NSPointerFunctionsWeakMemory使用和__weak等價(jià)的方式來(lái)存儲(chǔ)對(duì)象并自動(dòng)移除被銷毀的對(duì)象。
NSPointerFunctionsCopyIn在對(duì)象被加入到集合前拷貝它們。
NSPointerFunctionsObjectPersonality使用對(duì)象的hash和isEqual:(默認(rèn))。
NSPointerFunctionsObjectPointerPersonality對(duì)于isEqual:和hash使用直接的指針比較。
NSHashTable 性能特征
如果你只是需要NSSet的特性，請(qǐng)堅(jiān)持使用NSSet。NSHashTable在添加對(duì)象時(shí)花費(fèi)了將近2倍的時(shí)間，但是其他方面的效率卻非常相近。
NSMapTable
NSMapTable和NSHashTable相似，但是效仿的是NSDictionary。因此，我們可以通過mapTableWithKeyOptions:valueOptions:分別控制鍵和值的對(duì)象獲取/保留行為。存儲(chǔ)弱引用是NSMapTable最有用的特性，這里有4個(gè)方便的構(gòu)造函數(shù):
strongToStrongObjectsMapTable
weakToStrongObjectsMapTable
strongToWeakObjectsMapTable
weakToWeakObjectsMapTable
注意，除了使用NSPointerFunctionsCopyIn，任何的默認(rèn)行為都會(huì) retain (或弱引用)鍵對(duì)象而不會(huì)拷貝它，這與CFDictionary的行為相同而與NSDictionary不同。當(dāng)你需要一個(gè)字典，它的鍵沒有實(shí)現(xiàn)NSCopying協(xié)議的時(shí)候（比如像UIView），這會(huì)非常有用。
如果你好奇為什么蘋果”忘記”為NSMapTable增加下標(biāo)，你現(xiàn)在知道了。下標(biāo)訪問需要一個(gè)id作為 key，對(duì)NSMapTable來(lái)說(shuō)這不是強(qiáng)制的。如果不通過一個(gè)非法的 API 協(xié)議或者移除NSCopying協(xié)議來(lái)削弱全局下標(biāo)，是沒有辦法給它增加下標(biāo)的。
你可以通過dictionaryRepresentation把內(nèi)容轉(zhuǎn)換為普通的NSDictionary。不像NSOrderedSet，這個(gè)方法返回的是一個(gè)常規(guī)的字典而不是一個(gè)代理。
NSMapTable 性能特征
NSMapTable只比NSDictionary略微慢一點(diǎn)。如果你需要一個(gè)不 retain 鍵的字典，放棄CFDictionary而使用它吧。
NSPointerArray
NSPointerArray類是一個(gè)稀疏數(shù)組，工作起來(lái)與NSMutableArray相似，但可以存儲(chǔ)NULL值，并且count方法會(huì)反應(yīng)這些空點(diǎn)。可以用NSPointerFunctions對(duì)其進(jìn)行各種設(shè)置，也有應(yīng)對(duì)常見的使用場(chǎng)景的快捷構(gòu)造函數(shù)strongObjectsPointerArray和weakObjectsPointerArray。
在能使用insertPointer:atIndex:之前，我們需要通過直接設(shè)置count屬性來(lái)申請(qǐng)空間，否則會(huì)產(chǎn)生一個(gè)異常。另一種選擇是使用addPointer:，這個(gè)方法可以自動(dòng)根據(jù)需要增加數(shù)組的大小。
你可以通過allObjects將一個(gè)NSPointerArray轉(zhuǎn)換成常規(guī)的NSArray。這時(shí)所有的NULL值會(huì)被去掉，只有真正存在的對(duì)象被加入到數(shù)組 — 因此數(shù)組的對(duì)象索引很有可能會(huì)跟指針數(shù)組的不同。注意：如果向指針數(shù)組中存入任何非對(duì)象的東西，試圖執(zhí)行allObjects都會(huì)造成EXC_BAD_ACCESS崩潰，因?yàn)樗鼤?huì)一個(gè)一個(gè)地去 retain ”對(duì)象”。
從調(diào)試的角度講，NSPointerArray沒有受到太多歡迎。description方法只是簡(jiǎn)單的返回了。為了得到所有的對(duì)象需要執(zhí)行[pointerArray allObjects]，當(dāng)然，如果存在NULL的話會(huì)改變索引。
NSPointerArray 性能特征
在性能方面，NSPointerArray真的非常非常慢，所以當(dāng)你打算在一個(gè)很大的數(shù)據(jù)集合上使用它的時(shí)候一定要三思。在本測(cè)試中我們比較了使用NSNull作為空標(biāo)記的NSMutableArray，而對(duì)NSPointerArray我們用NSPointerFunctionsStrongMemory來(lái)進(jìn)行設(shè)置 (這樣對(duì)象會(huì)被適當(dāng)?shù)?retain)。在一個(gè)有 10,000 個(gè)元素的數(shù)組中，我們每隔十個(gè)插入一個(gè)字符串 ”Entry %d”。此測(cè)試包括了用NSNull.null填充NSMutableArray的總時(shí)間。對(duì)于NSPointerArray，我們使用setCount:來(lái)代替:
注意NSPointerArray需要的時(shí)間比NSMutableArray多了超過* 250 倍(!)* 。這非常奇怪和意外。跟蹤內(nèi)存是比較困難的，所以按理說(shuō)NSPointerArray會(huì)更高效才對(duì)。不過由于我們使用的是同一個(gè)NSNull來(lái)標(biāo)記空對(duì)象，所以除了指針也沒有什么更多的消耗。
NSCache
NSCache是一個(gè)非常奇怪的集合。在 iOS 4 / Snow Leopard 中加入，默認(rèn)為可變并且線程安全的。這使它很適合緩存那些創(chuàng)建起來(lái)代價(jià)高昂的對(duì)象。它自動(dòng)對(duì)內(nèi)存警告做出反應(yīng)并基于可設(shè)置的”成本”清理自己。與NSDictionary相比，鍵是被 retain 而不是被 copy 的。
NSCache的回收方法是不確定的，在文檔中也沒有說(shuō)明。向里面放一些類似圖片那樣超大的對(duì)象并不是一個(gè)好主意，有可能它在能回收之前就更快地把你的 cache 給填滿了。(這是在PSPDFKit中很多跟內(nèi)存有關(guān)的 crash 的原因，在使用自定義的基于 LRU 的鏈表緩存的代碼之前，我們起初使用了NSCache存儲(chǔ)事先渲染的圖片。)
可以對(duì)NSCache進(jìn)行設(shè)置，這樣它就能自動(dòng)回收那些實(shí)現(xiàn)了NSDiscardableContent協(xié)議的對(duì)象。實(shí)現(xiàn)了該屬性的一個(gè)比較常用的類是同時(shí)間加入的NSPurgeableData，但是在 OS X 10.9 之前，它是非完全線程安全的 (也沒有信息表明這個(gè)變化也影響到了 iOS，或者說(shuō)在 iOS 7 中被修復(fù)了)。
NSCache 性能
那么相比起NSMutableDictionary來(lái)說(shuō)，NSCache表現(xiàn)如何呢？加入的線程安全必然會(huì)帶來(lái)一些消耗。處于好奇，我也加入了一個(gè)自定義的線程安全的字典的子類 (PSPDFThreadSafeMutableDictionary)，它通過OSSpinLock實(shí)現(xiàn)同步的訪問。
NSCache表現(xiàn)的相當(dāng)好，隨機(jī)訪問跟我們自定義的線程安全字典一樣快。如我們預(yù)料的，添加更慢一些，因?yàn)镹SCache要多維護(hù)一個(gè)決定何時(shí)回收對(duì)象的成本系數(shù)。就這一點(diǎn)來(lái)看這不是一個(gè)非常公平的比較。有趣的是，在模擬器上運(yùn)行效率要慢了幾乎 10 倍。無(wú)論對(duì) 32 或 64 位的系統(tǒng)都是這樣。而且看起來(lái)這個(gè)類已經(jīng)在 iOS 7 中優(yōu)化過，或者是受益于 64 位 runtime 環(huán)境。當(dāng)在老的設(shè)備上測(cè)試時(shí)，使用NSCache的性能消耗就明顯得多。
iOS 6(32 bit) 和 iOS 7(64 bit) 的區(qū)別也很明顯，因?yàn)?64 位運(yùn)行時(shí)使用標(biāo)簽指針 (tagged pointer)，因此我們的@(idx)boxing 要更為高效。
NSIndexSet
有些使用場(chǎng)景下NSIndexSet(和它的可變變體，NSMutableIndexSet) 真的非常出色，對(duì)它的使用貫穿在 Foundation 中。它可以用一種非常高效的方法存儲(chǔ)一組無(wú)符號(hào)整數(shù)的集合，尤其是如果只是一個(gè)或少量范圍的時(shí)候。正如 set 這個(gè)名字已經(jīng)暗示的那樣，每一個(gè)NSUInteger要么在索引 set 中，要么不在。如果你需要存儲(chǔ)任意非唯一的數(shù)的時(shí)候，最好使用NSArray。
下面是如何把一個(gè)整數(shù)數(shù)組轉(zhuǎn)換為NSIndexSet:
如果不使用block，從索引set中拿到所有的索引有點(diǎn)麻煩，getIndexes:maxCount:inIndexRange:是最快的方法，其次是使用firstIndex并迭代直到indexGreaterThanIndex:返回NSNotFound。隨著 block 的到來(lái)，使用NSIndexSet工作變得方便的多:
NSIndexSet性能
Core Foundation 中沒有和NSIndexSet相當(dāng)?shù)念?，蘋果也沒有對(duì)性能做出任何承諾。NSIndexSet和NSSet之間的比較也相對(duì)的不公平，因?yàn)槌Ｒ?guī)的 set 需要對(duì)數(shù)字進(jìn)行包裝。為了緩解這個(gè)影響，這里的測(cè)試準(zhǔn)備了實(shí)現(xiàn)包裝好的NSUintegers，并且在兩個(gè)循環(huán)中都會(huì)執(zhí)行unsignedIntegerValue:
我們看到在一百萬(wàn)左右對(duì)象的時(shí)候，NSIndexSet開始變得比NSSet慢，但只是因?yàn)樾碌倪\(yùn)行時(shí)和標(biāo)簽指針。在 iOS 6 上運(yùn)行相同的測(cè)試表明，甚至在更高數(shù)量級(jí)實(shí)體的條件下，NSIndexSet更快。實(shí)際上，在大多數(shù)應(yīng)用中，你不會(huì)添加太多的整數(shù)到索引 set 中。還有一點(diǎn)這里沒有測(cè)試，就是NSIndexSet跟NSSet比無(wú)疑有更好的內(nèi)存優(yōu)化。
結(jié)論
本文提供了一些真實(shí)的測(cè)試，使你在使用基礎(chǔ)集合類的時(shí)候做出有根據(jù)的選擇。除了上面討論的類，還有一些不常用但確實(shí)有用的類，尤其是NSCountedSet，CFBag，CFTree，CFBitVector和CFBinaryHeap。
