1 工具使用
1.1 Leaks查找泄漏點步驟
使用Xcode和Instruments調(diào)試解決iOS內(nèi)存泄露
http://blog.csdn.net/totogo2010/article/details/8233565
????????作為一名iOS開發(fā)攻城獅，在蘋果沒有出ARC(自動內(nèi)存管理機(jī)制)時，我們幾乎有一半的開發(fā)時間都耗費在這么管理內(nèi)存上。后來蘋果很人性的出了ARC，雖然在很大程度上，幫助我們開發(fā)者節(jié)省了精力和時間。但是我們在開發(fā)過程中，由于種種原因，還是會出現(xiàn)內(nèi)存泄露的問題。內(nèi)存泄露是一個很嚴(yán)重的問題。下面就簡單介紹下怎么使用Xcode7自帶的Instruments中的Leaks檢測我們的程序有沒有內(nèi)存泄露和定位內(nèi)存泄露的代碼。(分析內(nèi)存泄露不能把所有的內(nèi)存泄露查出來，有的內(nèi)存泄露是在運行時，用戶操作時才產(chǎn)生的)。
????????第一步:打開Xcode7自帶的Instruments
或者:
????????按上面操作，build成功后跳出Instruments工具，選擇Leaks選項
????????選擇之后界面如下圖:
????????到這里之后,我們前期的準(zhǔn)備工作做完啦，下面開始正式的測試!
????1.選中Xcode先把程序（command + R）運行起來
????2.再選中Xcode，按快捷鍵（command + control + i）運行起來,此時Leaks已經(jīng)跑起來了
????3.由于Leaks是動態(tài)監(jiān)測，所以我們需要手動操作APP，一邊操作，一邊觀察Leaks的變化，當(dāng)出現(xiàn)紅色叉時，就監(jiān)測到了內(nèi)存泄露，點擊右上角的第二個，進(jìn)行暫停檢測(也可繼續(xù)檢測，當(dāng)多個時暫停，一次處理了多個)。如圖所示：
????4.下面就是定位修改了,此時選中有紅色柱子的Leaks，下面有個"田"字方格，點開，選中Call Tree
????顯示如下圖界面
? ? 5.下面就是最關(guān)鍵的一步，在這個界面的右下角有若干選框，選中Invert Call Tree 和Hide System Libraries,（紅圈范圍內(nèi)）顯示如下：
????????到這里就算基本完成啦，這里顯示的就是內(nèi)存泄露代碼部分，那么現(xiàn)在還差一步：定位!
????6.選中顯示的若干條中的一條，雙擊，會自動跳到內(nèi)存泄露代碼處，如圖所示：
????7.找到了內(nèi)存泄露的地方，那么我們就可以修改即可
1.2 Zombies查找和解決僵尸對象
????Instruments的Zombies模板
1.3 Time Profiler
????????時間都去哪兒啦？ Time Profiler 可以回答。它會按照設(shè)定的時間間隔（默認(rèn) 1 毫秒）來跟蹤每一線程的堆棧信息（stack trace），并通過比較時間間隔之間的堆棧狀態(tài)，來推算出某個方法執(zhí)行了多久，給出一個近似值。
????????在演示應(yīng)用頭一項「Time Profiler: System Methods」中，我用插入排序（Insertion Sort）和冒泡排序（Bubble Sort）兩種算法來做性能比較，下面是 Swift 代碼：
/* 引用自：http://waynewbishop.com/swift/sorting-algorithms/ */
func insertionSort() {
??? var x, y, key: Int
??? for (x = 0; x < numberList.count; x++) {
??????? key = numberList[x]
??????? for (y = x; y > -1; y--) {
??????????? if key < numberList[y] {
???????????????numberList.removeAtIndex(y +1)
???????????????numberList.insert(key, atIndex: y)
?????????? ?}
??????? }
??? }
}
func bubbleSort() {
??? var x, y, z, passes, key : Int
??? for (x = 0; x < numberList.count; ++x) {
??????? passes = (numberList.count -1) - x;
??????? for (y = 0; y < passes; y++) {
??????????? key = numberList[y]
??????????? if (key > numberList[y + 1]) {
??????????????? z = numberList[y +1]
? ? ? ? ? ? ? ? numberList[y +1] = key
??????????????? numberList[y] = z
??????????? }
??????? }
??? }
}
????????這段代碼主要是對數(shù)組的添加和刪除，兩種方法執(zhí)行起來耗時不多，但后臺發(fā)生的系統(tǒng)動作卻多得讓人眼暈。
????????可以發(fā)現(xiàn)，代碼用到了很多間接依賴，這些都是支撐代碼運行的系統(tǒng)庫文件。因為處理大數(shù)據(jù)集比較消耗系統(tǒng)資源，所以要盡可能地把繁重的操作放到后臺去做，上面的代碼就走的后臺線程。在上圖的 Call Tree 中可以看到，被調(diào)用的堆棧名是 dispatch_worker_thread3。如果把它放到主線程去執(zhí)行，程序肯定會掛起。不信你注釋掉 dispatch_async 調(diào)用看一下。
????????再來個圖片加載的例子。
????????這兒有三種圖片加載方法：
????? loadSlowImage1：從指定 URL 下載一張圖片（加載速度慢）
????? loadImage2：從本地資源庫加載一張圖片（注意：沒用系統(tǒng)緩存）
????? loadFastImage3：從系統(tǒng)緩存中加載一張圖片（加載速度快）
????????我們來看看 Time Profiler 算出的結(jié)果是不是跟預(yù)想的一樣。
????????進(jìn)入演示應(yīng)用第二項「Time Profiler: Our Methods」，點擊「Reload」十次來重復(fù)加載圖片，這樣能產(chǎn)生足夠的數(shù)據(jù)來分析。然后在 Time Profiler 圖表中通過拖拉鼠標(biāo)選中要放大查看的區(qū)域，從 Call Tree 中雙擊調(diào)用了 .reload 方法那一行（上圖中加亮選中那一行），就會跳轉(zhuǎn)到對應(yīng)的代碼行，所用時間也標(biāo)注出來了。
????????看到誰最花時間了吧。雖然代碼沒什么可優(yōu)化的地方，但大家應(yīng)該認(rèn)識到緩存能發(fā)揮的作用。所以即使有時還得調(diào)用 loadSlowImage，多數(shù)情況下把圖片緩存下來，還是能省些資源占用。
????????此外，我想再說說 Call Tree 的選項設(shè)置。
????????這些選項默認(rèn)是不選的，但把它們勾選上可以幫你更快定位到關(guān)鍵的代碼上，往往這也是問題的源頭。
??????Separate by Thread：按線程分開做分析，這樣更容易揪出那些吃資源的問題線程。特別是對于主線程，它要處理和渲染所有的接口數(shù)據(jù)，一旦受到阻塞，程序必然卡頓或停止響應(yīng)。
????? Invert Call Tree：反向輸出調(diào)用樹。把調(diào)用層級最深的方法顯示在最上面，更容易找到最耗時的操作。
????? Hide Missing Symbols：隱藏缺失符號。如果 dSYM 文件或其他系統(tǒng)架構(gòu)缺失，列表中會出現(xiàn)很多奇怪的十六進(jìn)制的數(shù)值，用此選項把這些干擾元素屏蔽掉，讓列表回歸清爽。
????? Hide System Libraries：隱藏系統(tǒng)庫文件。過濾掉各種系統(tǒng)調(diào)用，只顯示自己的代碼調(diào)用。
????? Flattern Recursion：拼合遞歸。將同一遞歸函數(shù)產(chǎn)生的多條堆棧（因為遞歸函數(shù)會調(diào)用自己）合并為一條。
????? Top Functions：找到最耗時的函數(shù)或方法。
????需要添加其他工具的話：
1.4 Allocations
????????我們經(jīng)常需要從服務(wù)器下載大量圖片，特別是開發(fā)照片類的應(yīng)用。但往往稍不注意，內(nèi)存使用就會暴增，所以得保證把這些圖片緩存下來以便重復(fù)使用。下面來看看演示程序中內(nèi)存分配的例子。
????????從圖中可以看到，每次點擊「Reload」重新載入圖片時，內(nèi)存都會出現(xiàn)使用峰值。應(yīng)用先分配大量內(nèi)存來替換原有圖片，然后再釋放掉這部分內(nèi)存，可想而知這樣的操作效率高不了，而且如果要下載更大的文件，呃，局面大概會失控吧。
????????看一下堆棧列表第四行，ImageIO_PNG_Data 里有 9 張?zhí)幱诨顒訝顟B(tài)的圖片，占用了12.38 MB 內(nèi)存，這些都是沒被系統(tǒng)釋放或緩存的內(nèi)存，所以導(dǎo)致堆內(nèi)存分配升高。接下來再看看使用緩存后的效果。
????????使用了緩存庫（Swift Haneke）后，點「Reload」五次，這回在 Allocations 列表中卻看不到 ImageIO_PNG_Data 對象了，這說明它是空的，沒有任何圖像數(shù)據(jù)。同時，All Heap Allocations 的大小已從剛才的 14.61 MB 降到了 2.51 MB。Anonymous VM（匿名虛擬內(nèi)存）是系統(tǒng)為程序預(yù)留的、可能會立即被重復(fù)使用的一部分可用內(nèi)存。要防止程序崩潰，就別讓堆的尺寸增長太快。
????????還有就是，例子用的是異步方式來加載圖片，這樣用不著等到所有圖片下載完才能在界面中顯示。大多數(shù)圖像緩存庫都會把加載工作放到后臺，以避免延長主線程的響應(yīng)周期。
2 常見問題
2.1 配置使用
2.1.1 Thisapplication's application-identifier entitlement does not match that of theinstalled application. These values must match for an upgrade to be allowed.
可以修改profile的scheme
設(shè)為Debug模式
3 參考鏈接
(最新)使用Xcode7的Instruments檢測解決iOS內(nèi)存泄露
http://www.cnblogs.com/iOSv587country/p/4862989.html
iOS性能優(yōu)化
http://m.itdecent.cn/p/9e1f0b44935c
「原創(chuàng)譯文」iOS性能優(yōu)化：Instruments工具的救命三招
http://segmentfault.com/a/1190000002568993
IPhone測試工具-Instruments教程
Instruments概述
http://m.itdecent.cn/p/2f850a774fca
iOS性能優(yōu)化：Instruments使用實戰(zhàn)
