基礎集合類是每一個Mac/iOS應用的基本組成部分。在本文中，我們將對”老類”(NSArray, NSSet)和”新類”(NSMapTable, NSHashTable, NSPointerArray)進行一個深入的研究，探索每一個的效率細節，並討論其使用場景。

   提示:本文包含一些參照結果，但它們並不意味著絕對精確，也沒有進行多個、複雜的測試。這些結果的目的是給出一個快速和主要的執行時統計。所有的測試基於iPhone 5s，使用Xcode 5.1b1和iOS 7.1b1，64位的程式。編譯選項設定為-Ofast的釋出構建。Vectorize loops和unroll loops(預設設定)均設定為關閉。

大O符號

首先，我們需要一些理論知識。效率通常用大O符號描述。它定義了一個函式的 極限特徵 ，通常被用於描繪其演算法效率。O定義了函式增長率的上限。通過檢視通常使用的O符號和所需要的運算元來檢視差異的大小。

例如，如果用演算法複雜度為O(n2)的演算法對一個有50個元素的陣列排序，需要2500步的操作。而且，還有內部的系統開銷和方法呼叫 — 所以是2500個操作的時間常量。 O(1)是理想的複雜度，代表著恆定的時間。好的演算法通常需要O(n*log n)的時間。

可變性

大多數的集合類存在兩個版本:可變和不可變(預設)。這和其他大多數的框架有非常大的不同，一開始會讓人覺得有一點奇怪。然而其他的框架現在也應用了這一特性:就在幾個月前，.

NET公佈了作為官方擴充套件的不可變集合。

最大的好處是什麼?執行緒安全。不可變的集合完全是執行緒安全的，可以同時在多個執行緒中迭代，避免各種突變異常的風險。你的API 絕不 應該暴露可變集合。

當然從不可變到可變再變回來會有一定的代價 — 物件必須被拷貝兩次，所有集合內的物件將被retain/release。有時在內部使用一個可變的集合而在出口返回一個不可變的物件副本會更高效。

與其他框架不同，蘋果沒有提供一個執行緒安全的可變集合，NSCache是例外 — 但它真的算不上是集合類，因為它不是一個通用的容器。大多數時候，你的確想要高於集合級別的同步。想象一段程式碼，作用是檢查字典中一個key是否存在，並根據檢查結果決定設定一個新的key或者返回某些值 — 你通常需要把多個操作歸類，這時執行緒安全的可變變體並不能幫助你。

這裡有一些同步的，執行緒安全的可變集合有效的使用案例，只需要用幾行程式碼，通過子類和組合的方法建立諸如NSDictionary或NSArray。

需要注意的是，一些更新式的集合類，如NSHashTable，NSMapTable和NSPointerArray預設就是可變的，它們並沒有對應的不可變的類。它們用於類的內部使用，或者某個你想要不常見的可變類的場景。

NSArray

NSArray作為一個儲存物件的有序集合，可能是被使用最多的集合類。這也是為什麼它有自己的比原來的[NSArray arrayWithObjects:..., nil]簡短得多的快速語法糖符號@[...]。

NSArray實現了objectAtIndexedSubscript:，因為我們可以使用類C的語法array[0]來代替原來的[array objectAtIndex:0]。

效能特徵

關於NSArray的內容比你想象的要多的多。基於儲存物件的多少，它使用各種內部的變體。最有趣的部分是蘋果對於個別的物件訪問並不保證O(1)的訪問時間 — 正如你在CFArray.h CoreFoundation header中的關於演算法複雜度的註解中可以讀到的:

The access time for a value in the array is guaranteed to be at worst O(lg N) for any implementation, current and future, but will often be O(1) (constant time). Linear search operations similarly have a worst case complexity of O(Nlg N), though typically the bounds will be tighter, and so on. Insertion or deletion operations will typically be linear in the number of values in the array, but may be O(Nlg N) clearly in the worst case in some implementations. There are no favored positions within the array for performance; that is, it is not necessarily faster to access values with low indices, or to insert or delete values with high indices, or whatever.

在測量的時候，NSArray產生了一些有趣的額外的效能特徵。在陣列的開頭和結尾插入/刪除元素通常是一個O(1)操作，而隨機的插入/刪除通常是 O(N)的。

有用的方法

NSArray的大多數方法使用isEqual:來檢查物件間的關係(例如containsObject:)。有一個特別的方法indexOfObjectIdenticalTo:用來檢查指標相等，如果你確保在同一個集合中搜索，那麼這個方法可以很大的提升搜尋速度。

在iOS 7中，我們最終得到了與lastObject對應的公開的firstObject方法，對於空陣列，這兩個方法都會返回nil — 而常規的訪問方法會丟擲一個NSRangeException異常。

關於構造(可變)陣列有一個漂亮的細節可以節省程式碼量。如果你通過一個可能為nil的陣列建立一個可變陣列，通常會這麼寫:

1. NSMutableArray *mutableObjects = [array mutableCopy]; 
2. if (!mutableObjects) { 
3.     mutableObjects = [NSMutableArray array]; 
4. } 

或者通過更簡潔的三元運算子:

1. NSMutableArray *mutableObjects = [array mutableCopy] ?: [NSMutableArray array]; 

更好的解決方案是使用arrayWithArray:，即使原陣列為nil，該方法也會返回一個數組物件:

1. NSMutableArray *mutableObjects = [NSMutableArray arrayWithArray:array]; 

這兩個操作在效率上幾乎相等。使用copy會快一點點，不過話說回來，這不太可能是你應用的瓶頸所在。提醒:不要使用[@[] mutableCopy]。經典的[NSMutableArray array]可讀性更好。

翻轉一個數組非常簡單:array.reverseObjectEnumerator.allObjects。我們使用系統提供的reverseObjectEnumerator，每一個NSEnumerator都實現了allObjects，該方法返回一個新陣列。雖然沒有原生的randomObjectEnumerator方法，你可以寫一個自定義的打亂陣列順序的列舉器或者使用一些出色的開原始碼。

陣列排序

有很多各種各樣的方法來對一個數組排序。如果陣列儲存的是字串物件，sortedArrayUsingSelector:是第一選擇:

1. NSArray *array = @[@"John Appleseed", @"Tim Cook", @"Hair Force One", @"Michael Jurewitz"]; 
2. NSArray *sortedArray = [array sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)]; 

下面的程式碼對儲存數字的內容同樣很好，因為NSNumber實現了compare::

1. NSArray *numbers = @[@9, @5, @11, @3, @1]; 
2. NSArray *sortedNumbers = [numbers sortedArrayUsingSelector:@selector(compare:)]; 

如果想更可控，可以使用基於函式指標的排序方法:

1. - (NSData *)sortedArrayHint; 
2. - (NSArray *)sortedArrayUsingFunction:(NSInteger (*)(id, id, void *))comparator 
3.                               context:(void *)context; 
4. - (NSArray *)sortedArrayUsingFunction:(NSInteger (*)(id, id, void *))comparator 
5.                               context:(void *)context hint:(NSData *)hint; 

蘋果增加了一個方法來加速使用sortedArrayHint的排序。

The hinted sort is most efficient when you have a large array (N entries) that you sort once and then change only slightly (P additions and deletions, where P is much smaller than N). You can reuse the work you did in the original sort by conceptually doing a merge sort between the N “old” items and the P “new” items. To obtain an appropriate hint, you use sortedArrayHint when the original array has been sorted, and keep hold of it until you need it (when you want to re-sort the array after it has been modified).

因為block的引入，也出現了一些基於block的排序方法:

1. - (NSArray *)sortedArrayUsingComparator:(NSComparator)cmptr; 
2. - (NSArray *)sortedArrayWithOptions:(NSSortOptions)opts 
3.                     usingComparator:(NSComparator)cmptr; 

效能上來說，不同的方法間並沒有太多的不同。有趣的是，基於selector的方式是最快的。你可以在GitHub上找到測試用的原始碼:

1. Sorting 1000000 elements. selector: 4947.90[ms] function: 5618.93[ms] block: 5082.98[ms]. 

二分查詢

NSArray從iOS 4/Snow Leopard開始內建了二分查詢

1. typedef NS_OPTIONS(NSUInteger, NSBinarySearchingOptions) { 
2.         NSBinarySearchingFirstEqual     = (1UL << 8), 
3.         NSBinarySearchingLastEqual      = (1UL << 9), 
4.         NSBinarySearchingInsertionIndex = (1UL << 10), 
5. }; 
6. - (NSUInteger)indexOfObject:(id)obj 
7.               inSortedRange:(NSRange)r 
8.                     options:(NSBinarySearchingOptions)opts 
9.             usingComparator:(NSComparator)cmp; 

為什麼要使用這個方法?類似containsObject:和indexOfObject:這樣的方法從0索引開始搜尋每個物件直到找到目標 — 不需要陣列被排序而且是O(n)的效率特性。換句話說，二分查詢需要陣列事先被排序，但只需要O(log n)的時間。因此，對於1,000,000的記錄，二分查詢法最多隻需要21次比較，而傳統的線性查詢則平均需要5000,000次的比較。

這是個簡單的衡量二分查詢有多快的資料:

1. Time to search for 1000 entries within 1000000 objects. Linear: 54130.38[ms]. Binary: 7.62[ms] 

作為比較，查詢NSOrderedSet中的指定索引花費0.23毫秒 — 即使跟二分查詢相比也快了30多倍。

記住排序的開銷也是昂貴的。蘋果使用複雜度為O(n*log n)的歸併排序，所以如果執行過indexOfObject:一次，就沒有必要使用二分查找了。

通過指定NSBinarySearchingInsertionIndex，你可以獲得正確的插入索引，以確保在插入元素後仍然可以保證陣列的順序。

列舉和高階訊息

作為參照，我們來看一個普通的使用場景。從一個數組中過濾出另一個數組。測試了多個列舉方法和API特性:

1. // First variant, using `indexesOfObjectsWithOptions:passingTest:`. 
2. NSIndexSet *indexes = [randomArray indexesOfObjectsWithOptions:NSEnumerationConcurrent 
3.                                                    passingTest:^BOOL(id obj, NSUInteger idx, BOOL *stop) { 
4.     return testObj(obj); 
5. }]; 
6. NSArray *filteredArray = [randomArray objectsAtIndexes:indexes]; 
7. // Filtering using predicates (block-based or text)  
8. NSArray *filteredArray2 = [randomArray filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(id obj, NSDictionary *bindings) { 
9.     return testObj(obj); 
10. }]]; 
11. // Block-based enumeration  
12. NSMutableArray *mutableArray = [NSMutableArray array]; 
13. [randomArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) { 
14.     if (testObj(obj)) { 
15.         [mutableArray addObject:obj]; 
16.     } 
17. }]; 
18. // Classic enumeration 
19. NSMutableArray *mutableArray = [NSMutableArray array]; 
20. for (id obj in randomArray) { 
21.     if (testObj(obj)) { 
22.         [mutableArray addObject:obj]; 
23.     } 
24. } 
25. // Using NSEnumerator, old school. 
26. NSMutableArray *mutableArray = [NSMutableArray array]; 
27. NSEnumerator *enumerator = [randomArray objectEnumerator]; 
28. id obj = nil; 
29. while ((obj = [enumerator nextObject]) != nil) { 
30.     if (testObj(obj)) { 
31.         [mutableArray addObject:obj]; 
32.     } 
33. } 
34. // Using objectAtIndex: (via subscripting) 
35. NSMutableArray *mutableArray = [NSMutableArray array]; 
36. for (NSUInteger idx = 0; idx < randomArray.count; idx++) { 
37.     id obj = randomArray[idx]; 
38.     if (testObj(obj)) { 
39.         [mutableArray addObject:obj]; 
40.     } 
41. } 

為了更好的理解這裡的效率測量，我們首先看一下陣列是如何迭代的。

indexesOfObjectsWithOptions:passingTest:必須每次都執行一次block因此比傳統的使用NSFastEnumeration技術的基於for迴圈的列舉要稍微低效一些。然後如果開啟了併發列舉，那麼前者的速度則會大大的超過後者幾乎2倍。iPhone 5s是雙核的，所以這說得通。這裡並沒有體現出來的是NSEnumerationConcurrent只對大量的物件有意義，如果你的集合中的物件數量很少，用哪個方法就真的無關緊要。甚至NSEnumerationConcurrent上額外的執行緒管理實際上會使結果變得更慢。

最大的輸家是filteredArrayUsingPredicate:。NSPredicate需要在這裡提及是因為，人們可以寫出，尤其是用不基於block的變體。使用Core Data的使用者應該會很熟悉。

為了比較的完整，我們也加入了NSEnumerator作為比較 — 雖然沒有任何理由再使用它了。然而它竟出人意料的快(比基於NSPredicate的查詢要快)，它的執行時消耗無疑比快速列舉更多 — 現在它只用於向後相容。甚至沒有優化過的objectAtIndex:都要更快些。

NSFastEnumeration

在OSX 10.5和iOS的最初版本中，蘋果增加了NSFastEnumeration。在此之前，只有每次返回一個元素的NSEnumeration，每次迭代都有執行時開銷。而快速列舉，蘋果通過countByEnumeratingWithState:objects:count:返回一個數據塊。該資料塊被解析成ids型別的C陣列。這就是更快的速度的原因;迭代一個C陣列更快，而且可以被編譯器更深一步的優化。手動的實現快速列舉是十分難辦的，所以蘋果的FastEnumerationSample是一個不錯的開始，還有一篇Mike Ash的文章也很不錯。

應該用arrayWithCapacity:嗎?

初始化NSArray的時候，可以選擇指定陣列的預期大小。在檢測的時候，結果是在效率上沒有差別 — 測量的時間幾乎相等，且在統計不確定性的範圍內。有訊息透漏說實際上蘋果並沒有使用這個特性。然而使用arrayWithCapacity:仍然有用，在文件不清晰的程式碼中，它可以幫助理解程式碼:

1. Adding 10.000.000 elements to NSArray. no count 1067.35[ms] with count: 1083.13[ms]. 

子類化注意事項

很少有理由去子類化基礎集合類。大多數時候，使用CoreFoundation級別的類並且自定義回撥函式定製自定義行為是更好的解決方案。

建立一個大小寫不敏感的字典，一種方法是子類化NSDictionary並且自定義訪問方法，使其將字串始終變為小寫(或大寫)，並對排序也做類似的修改。更快更好的解決方案是提供一個不同的CFDictionaryKeyCallBacks集，你可以提供自定義的hash和isEqual:回撥。你可以在這裡找到一個例子。這種方法的優美之處(感謝toll-free bridging)在於它仍然是一個簡單的字典，可以被任何使用NSDictionary作為引數的API接受。

子類作用的一個例子是有序字典的用例。.NET提供了一個SortedDictionary，Java有TreeMap，C++有std::map。雖然你 可以 使用C++的STL容器，但卻無法使它自動的retain/release，這會使使用起來笨重的多。因為NSDictionary是一個類簇，所以子類化跟人們想象的相比非常不同。這已經超過了本文的討論範疇，這裡有一個真實的有序字典的例子。

NSDictionary

一個字典儲存任意的物件鍵值對。 由於歷史原因，初始化方法使用相反的物件到值的方法，[NSDictionary dictionaryWithObjectsAndKeys:object, key, nil]，而新的快捷語法則從key開始，@{key : value, ...}。

相關推薦