算法時(shí)間復(fù)雜度：

在集合里數(shù)據(jù)量小的情況下時(shí)間復(fù)雜度對(duì)于性能的影響看起來(lái)微乎其微立美。但如果某個(gè)開(kāi)發(fā)的功能是一個(gè)公共功能提茁，無(wú)法預(yù)料調(diào)用者傳入數(shù)據(jù)的量時(shí)骂蓖，這個(gè)復(fù)雜度的優(yōu)化顯得非常重要了帆精。

上圖列出了各種情況的時(shí)間復(fù)雜度，比如高效的排序算法一般都是 O(n log n)嘀掸。接下來(lái)看看下圖：

圖中可以看出 O(n) 是個(gè)分水嶺紫岩，大于它對(duì)于性能就具有很大的潛在影響，如果是個(gè)公共的接口一定要加上說(shuō)明睬塌，自己調(diào)用也要做到心中有數(shù)泉蝌。當(dāng)然最好是通過(guò)算法優(yōu)化或者使用合適的系統(tǒng)接口方法，權(quán)衡內(nèi)存消耗爭(zhēng)取通過(guò)空間來(lái)?yè)Q取時(shí)間揩晴。

下面通過(guò)集合里是否有某個(gè)值來(lái)舉個(gè)例子：

那么 OC 里幾種常用集合對(duì)象提供的接口方法時(shí)間復(fù)雜度是怎么樣的勋陪。

NSArray / NSMutableArray

首先我們發(fā)現(xiàn)他們是有排序，并允許重復(fù)元素存在的硫兰，那么這么設(shè)計(jì)就表明了集合存儲(chǔ)沒(méi)法使用里面的元素做 hash table 的 key 進(jìn)行相關(guān)的快速操作诅愚，。所以不同功能接口方法性能是會(huì)有很大的差異劫映。

→ containsObject:违孝，containsObject:，indexOfObject*泳赋，removeObject: 會(huì)遍歷里面元素查看是否與之匹對(duì)雌桑，所以復(fù)雜度等于或大于 O(n)

→ objectAtIndex:，firstObject:祖今，lastObject:校坑，addObject:拣技，removeLastObject: 這些只針對(duì)棧頂棧底操作的時(shí)間復(fù)雜度都是 O(1)

→ indexOfObject:inSortedRange:options:usingComparator: 使用的是二分查找，時(shí)間復(fù)雜度是 O(log n)

NSSet / NSMutableSet / NSCountedSet

這些集合類型是無(wú)序沒(méi)有重復(fù)元素耍目。這樣就可以通過(guò) hash table 進(jìn)行快速的操作膏斤。比如 addObject:, removeObject:, containsObject: 都是按照 O(1) 來(lái)的。需要注意的是將數(shù)組轉(zhuǎn)成 Set 時(shí)會(huì)將重復(fù)元素合成一個(gè)邪驮，同時(shí)失去排序莫辨。

NSDictionary / NSMutableDictionary

和 Set 差不多，多了鍵值對(duì)應(yīng)耕捞。添加刪除和查找都是 O(1) 的衔掸。需要注意的是 Keys 必須是符合 NSCopying。

containsObject 方法在數(shù)組和 Set 里不同的實(shí)現(xiàn)

在數(shù)組中的實(shí)現(xiàn)

可以看到會(huì)遍歷所有元素在查找到后才進(jìn)行返回.

接下來(lái)可以看看 containsObject 在 Set 里的實(shí)現(xiàn)：

找元素時(shí)是通過(guò)鍵值方式從 map 映射表里取出俺抽，因?yàn)?Set 里元素是唯一的，所以可以 hash 元素對(duì)象作為 key 達(dá)到快速獲取值的目的较曼。

用 GCD 來(lái)做優(yōu)化

我們可以通過(guò) GCD 提供的方法來(lái)將一些需要耗時(shí)操作放到非主線程上做磷斧，使得 App 能夠運(yùn)行的更加流暢響應(yīng)更快。但是使用 GCD 時(shí)需要注意避免可能引起線程爆炸和死鎖的情況捷犹，還有非主線程處理任務(wù)也不是萬(wàn)能的弛饭，如果一個(gè)處理需要消耗大量?jī)?nèi)存或者大量CPU操作 GCD 也沒(méi)法幫你，只能通過(guò)將處理進(jìn)行拆解分步驟分時(shí)間進(jìn)行處理才比較妥當(dāng)萍歉。

異步處理事件

上圖是最典型的異步處理事件的方法

需要耗時(shí)長(zhǎng)的任務(wù)

將 GCD 的 block 通過(guò) dispatch_block_create_with_qos_class 方法指定隊(duì)列的 QoS 為 QOS_CLASS_UTILITY侣颂。這種 QoS 系統(tǒng)會(huì)針對(duì)大的計(jì)算，I/O枪孩，網(wǎng)絡(luò)以及復(fù)雜數(shù)據(jù)處理做電量?jī)?yōu)化憔晒。

避免線程爆炸

→ 使用串行隊(duì)列

→ 使用 NSOperationQueues 的并發(fā)限制方法 NSOperationQueue.maxConcurrentOperationCount→

舉個(gè)例子，下面的寫法就比較危險(xiǎn)蔑舞，可能會(huì)造成線程爆炸和死鎖

那么怎么能夠避免呢拒担？首先可以使用 dispatch_apply

或者使用 dispatch_semaphore

GCD 相關(guān) Crash 日志

管理線程問(wèn)題

線程閑置時(shí)

線程活躍時(shí)

主線程閑置時(shí)

主隊(duì)列

I/O 性能優(yōu)化

I/O 是性能消耗大戶，任何的 I/O 操作都會(huì)使低功耗狀態(tài)被打破攻询，所以減少 I/O 次數(shù)是這個(gè)性能優(yōu)化的關(guān)鍵點(diǎn)从撼，為了達(dá)成這個(gè)目下面列出一些方法。

⒈將零碎的內(nèi)容作為一個(gè)整體進(jìn)行寫入

⒉使用合適的 I/O 操作 API

⒊使用合適的線程

⒋使用 NSCache 做緩存能夠減少 I/O

NSCache

達(dá)到如圖的目的為何不直接用字典來(lái)做呢钧栖？

NSCache 具有字典的所有功能低零，同時(shí)還有如下的特性：

⒈自動(dòng)清理系統(tǒng)占用內(nèi)存

⒉NSCache 是線程安全

⒊-(void)cache:(NSCache *)cache willEvictObject:(id)obj; 緩存對(duì)象將被清理時(shí)的回調(diào)

⒋evictsObjectsWithDiscardedContent 可以控制是否清理

那么 NSCache是如何做到這些特性的呢？

接下來(lái)學(xué)習(xí)下 NSCache 是如何做的拯杠。首先 NSCache 是會(huì)持有一個(gè) NSMutableDictionary掏婶。

需要設(shè)計(jì)一個(gè) Cached 對(duì)象結(jié)構(gòu)來(lái)保存一些額外的信息

在 Cache 讀取的時(shí)候會(huì)對(duì) _accesses 數(shù)組的添加刪除通過(guò) isEvictable 布爾值來(lái)保證線程安全操作。使用 Cached 對(duì)象里的 accessCount 屬性進(jìn)行 +1 操作為后面自動(dòng)清理的條件判斷做準(zhǔn)備阴挣。具體實(shí)現(xiàn)如下：

在每次 Cache 添加時(shí)會(huì)先去檢查是否自動(dòng)清理气堕，會(huì)創(chuàng)建一個(gè) Cached 對(duì)象將 key，object，cost 等信息記錄下添加到 _accesses 數(shù)組和 _objects 字典里茎芭。

那么上面提到的自動(dòng)清理內(nèi)存的方法是如何實(shí)現(xiàn)的呢揖膜？

既然是自動(dòng)清理必定需要有觸發(fā)時(shí)機(jī)和進(jìn)入清理的條件判斷，觸發(fā)時(shí)機(jī)一個(gè)是發(fā)生在添加 Cache 內(nèi)容時(shí)梅桩，一個(gè)是發(fā)生在內(nèi)存警告時(shí)壹粟。條件判斷代碼如下：

所以 NSCache 的 totalCostLimit 的值會(huì)和每次 Cache 添加的 cost 之和對(duì)比，超出限制必然觸發(fā)內(nèi)存清理宿百。

清理時(shí)會(huì)對(duì)經(jīng)常訪問(wèn)的 objects 不清理趁仙，主要是通過(guò) _totalAccesses 和總數(shù)獲得平均訪問(wèn)頻率，如果那個(gè)對(duì)象的訪問(wèn)次數(shù)是小于平均值的才需要清理垦页。

在清理之前還需要一些準(zhǔn)備工作雀费，包括標(biāo)記 Cached 對(duì)象的 isEvictable 防止后面有不安全的線程操作。將滿足條件的清理 objects 放到清理數(shù)組里痊焊，如果空間釋放足夠就不用再把更多的 objects 加到清理數(shù)組里了盏袄，最后遍歷清理數(shù)組進(jìn)行逐個(gè)清理即可。

在清理時(shí)會(huì)執(zhí)行回調(diào)內(nèi)容薄啥，這樣如果有些緩存數(shù)據(jù)需要持續(xù)化存儲(chǔ)可以在回調(diào)里進(jìn)行處理辕羽。

完整的實(shí)現(xiàn)可以查看 GNUstep Base 的 NSCache.m 文件。

下面可以看看 NSCache 在 SDWebImage 的運(yùn)用是怎么樣的：

可以看出利用 NSCache 自動(dòng)釋放內(nèi)存的特點(diǎn)將圖片都放到 NSCache 里這樣在內(nèi)存不夠用時(shí)可以自動(dòng)清理掉不常用的那些圖片垄惧，在讀取 Cache 里內(nèi)容時(shí)如果沒(méi)有被清理會(huì)直接返回圖片數(shù)據(jù)刁愿，清理了的話才會(huì)執(zhí)行 I/O 從磁盤讀取圖片，通過(guò)這種方式能夠利用空間減少磁盤操作到逊，空間也能夠更加有效的控制釋放铣口。

控制 App 的 Wake 次數(shù)

通知，VoIP蕾管，定位枷踏，藍(lán)牙等都會(huì)使設(shè)備從 Standby 狀態(tài)喚起。喚起這個(gè)過(guò)程會(huì)有比較大的消耗掰曾，應(yīng)該避免頻繁發(fā)生旭蠕。通知方面主要要在產(chǎn)品層面多做考慮。定位方面旷坦，下面可以看看定位的一些 API 看看它們對(duì)性能的不同影響掏熬，便于考慮采用合適的接口。

連續(xù)的位置更新

[locationManager startUpdatingLocation]

這個(gè)方法會(huì)使設(shè)備一直處于活躍狀態(tài)秒梅。

延時(shí)有效定位

[locationManager allowDeferredLocationUpdatesUntilTraveled: timeout:]

高效節(jié)能的定位方式旗芬，數(shù)據(jù)會(huì)緩存在位置硬件上。適合于跑步應(yīng)用應(yīng)該都采用這種方式捆蜀。

重大位置變化

[locationManager startMonitoringSignificantLocationChanges]

會(huì)更節(jié)能疮丛，對(duì)于那些只有在位置有很大變化的才需要回調(diào)的應(yīng)用可以采用這種幔嫂，比如天氣應(yīng)用。

區(qū)域監(jiān)測(cè)

[locationManager startMonitoringForRegion:(CLRegion *)]

也是一種節(jié)能的定位方式誊薄，比如在博物館里按照不同區(qū)域監(jiān)測(cè)展示不同信息之類的應(yīng)用比較適合這種定位履恩。

經(jīng)常訪問(wèn)的地方

// Start monitoring

locationManager.startMonitoringVisits()

// Stop monitoring when no longer needed

locationManager.stopMonitoringVisits()

總的來(lái)說(shuō)，不要輕易使用 startUpdatingLocation() 除非萬(wàn)不得已呢蔫，盡快的使用 stopUpdatingLocation() 來(lái)結(jié)束定位還用戶一個(gè)節(jié)能設(shè)備切心。

內(nèi)存對(duì)于性能的影響

首先 Reclaiming 內(nèi)存是需要時(shí)間的，突然的大量?jī)?nèi)存需求是會(huì)影響響應(yīng)的片吊。

如何預(yù)防這些性能問(wèn)題绽昏，需要刻意預(yù)防么

堅(jiān)持下面幾個(gè)原則爭(zhēng)取在編碼階段避免一些性能問(wèn)題。

⒈優(yōu)化計(jì)算的復(fù)雜度從而減少 CPU 的使用.

⒉在應(yīng)用響應(yīng)交互的時(shí)候停止沒(méi)必要的任務(wù)處理.

⒊設(shè)置合適的 QoS.

⒋將定時(shí)器任務(wù)合并俏脊，讓 CPU 更多時(shí)候處于 idle 狀態(tài).