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