這裡是原文
入門 為了節省大家的時間,提供一個演示的Demo給大家。程式碼傳送門. 下載後解壓然後用Xcode開啟。編譯執行APP後 然後在搜尋框內輸入任意詞彙,點選結果你會看到下面的結果
正如你所見的,這個app很簡單.程式其實呼叫的是Flickr的API,通過app頂部的搜尋框執行搜尋後在下面的tableview顯示你搜索的搜尋詞,搜尋詞後面的括號內有搜尋結果的個數,點選此行進入一個縮圖的結果列表頁面 如上圖. 點選其中一行 進入影象的大圖模式,在這個頁面你可以根據需要旋轉影象。  到目前為止頁面看起來差不多了,你也許會想應該可以直接提交appstore了吧.接下來這篇文章將會教你instruments工具來提高你app效能和穩定性. “時間探測器” 天下武功，唯快不破。很多公司都信奉這個教條.恨不得把app壓法週期壓縮到最低,這就導致了開發中隱藏了很多問題,有點經驗的工程師草率的優化下,更糟的情況那些沒有經驗的工程師甚至不會對app進行任何優化. 某種程度上來說,你開發過程中是可以忽略效能優化的. 十年前,移動裝置的硬體資源是非常有限的.甚至連浮點數都是被禁止的.因為浮點數能導致程式碼變大計算的速度變慢. 科技發展如此迅速的今天,硬體很大程度上可以彌補軟體的短板.現在的移動裝置3D硬體處理的效率甚至媲美於PC機了,但是你不能總依賴於硬體和處理器速度來掩飾你APP做的多垃圾吧.(如果安卓系統跑在Iphone上還能夠像iOS一樣順滑嗎?其實是一個道理的) 效能這個概念很抽象,所以我們必須藉助資料化圖形化的輸出方式.你可能花一週的時間去優化一個有趣的演算法,但是這演算法只佔總執行時間的0.5%,不管你花多少精力去優化它,沒人會注意到.相反一個for迴圈花費了90%的時間,你稍微修改下就能提高10%的效率,就是這個簡單的修改可以得到大家很大的好感.因為.他們執行app時的第一感受就是比之前快了很多.沒人會care你修改的是一個多牛逼的演算法,還是一個簡單的for迴圈. 這個說明了什麼？ 與其花費時間在優化小細節上不如多點時間找到你改優化的地方. 下面引出第一個工具 Time Profiler，可以測量時間的間隔,中斷程式執行,跟蹤每個執行緒的堆疊.你可以想象下是Xcode除錯時按下暫停時的畫面
比如,100個樣本都在做1毫秒的間隔,然後在某個方法堆疊頂部有10個樣本，你可以推算出大概的時間有10%個10毫秒花費在此方法中，這是一個近似值. 從Xcode的選單選擇Product-Profile,或者選擇?
程式會啟動Instruments,這時候你會看到一個選擇視窗
這是instruments所有測試儀器的面板,選擇 “timer profilter” 點選“profile”回啟東模擬器和app,此時會要求你輸入一次密碼,以便instruments能有許可權去截獲監聽此程序。
在工具視窗中，可以看到時間計數，並留下了一個小箭頭移動到右側的圖形在螢幕的中央上方。這表明該應用程式正在執行。 現在開始執行app，搜尋一些圖片，這時候你發現查詢一個結果太慢了，而且搜尋結果列表頁面滾動起來也是讓人無法忍受的。 首先，確保工具欄中的檢視選擇有選擇的所有三個選項，如下所示： 
這將確保所有的面板都開啟。現在，研究下面的截圖和它下面的每個部分的解釋：
1. 錄控按鈕。中間的紅色按鈕將停止與啟動它被點選時，應用程式目前正在分析。注意這實際上是停止和啟動應用程式,而不是暫停它。   2. 執行定時器和執行導航,定時器顯示APP已經運行了多長時間,箭頭之間是可以移動的。如果停止，然後使用錄製按鈕重新啟動應用程式，這將開始一個新的執行。顯示屏便會顯示“run2 of 2”，你可以回到第一次執行的資料，首先你停止當前執行，然後按下左箭頭回去。   3. 執行軌道。 4. 擴充套件面板，在時間探查儀器的情況下，它是用來跟蹤顯示堆疊。   5. 詳細地面板。它顯示了你正在使用的儀器的主要資訊,這是使用頻率最高的部門,可以從它這裡看到cpu執行的時間    6. 選項面板，稍後介紹。 深究 執行影象搜尋，並深究結果。我個人比較喜歡尋找“狗”，當然你也可以選擇任意你想要的內容。比如貓啊美女啊什麼的。 現在上下滾動記下列表，讓時間探測器測量下資料，然後注意看下螢幕的變化和數值。這些數值反應了CPU週期。 但是你也許會發現下面的數值太多，看你的眼花繚亂。下面開啟左邊的呼叫樹 然後按著如下的配置
以下介紹下配置選項： Separate by Thread: 每個執行緒應該分開考慮。只有這樣你才能揪出那些大量佔用CPU的"重"執行緒   Invert Call Tree: 從上倒下跟蹤堆疊,這意味著你看到的表中的方法,將已從第0幀開始取樣,這通常你是想要的,只有這樣你才能看到CPU中話費時間最深的方法.也就是說FuncA{FunB{FunC}} 勾選此項後堆疊以C->B-A 把呼叫層級最深的C顯示在最外面  Hide Missing Symbols: 如果dSYM無法找到你的app或者系統框架的話,那麼表中看不到方法名只能看到十六進位制的數值,如果勾線此項可以隱藏這些符號,便於簡化資料 Hide System Libraries: 勾選此項你會顯示你app的程式碼,這是非常有用的. 因為通常你只關心cpu花在自己程式碼上的時間不是系統上的 Show Obj-C Only: 只顯示oc程式碼 ,如果你的程式是像OpenGl這樣的程式,不要勾選側向因為他有可能是C++的   Flatten Recursion: 遞迴函式, 每個堆疊跟蹤一個條目 Top Functions: 一個函式花費的時間直接在該函式中的總和，以及在函式呼叫該函式所花費的時間的總時間。因此，如果函式A呼叫B，那麼A的時間報告在A花費的時間加上B.花費的時間,這非常真有用，因為它可以讓你每次下到呼叫堆疊時挑最大的時間數字，歸零在你最耗時的方法。 如果您已啟用上述選項,雖然有些值可能會略有不同，下面的結果的順序應該是類似下表：
通過上面你能看到大部分時間都花在更新表格照片了. 雙擊此行,然後將會看到如下
那麼這很有趣，不是嗎！幾乎四分之三的時間花費在setPhoto：方法都花在創造照片的影象資料！ 現在可以看到的是什麼問題,NSData’s dataWithContentsOfURL 方法並不會立即返回,因為要從網上去資料,每次呼叫都需要長達幾秒的時間返回,而此方法執行在主執行緒,可想而知會有什麼結果了. 其實為了解決這個問題,類提供了一個ImageCache 的後臺非同步下載的方法. 現在，您可以切換到Xcode和手動找到該檔案，但儀器有一個方便的“開啟Xcode中”按鈕，就在你的眼前。找到它的面板只是上面的程式碼並單擊它：
想如下修改

1. - (void)setPhoto:(FlickrPhoto *)photo { 
2.     _photo = photo; 
3.     self.textLabel.text = photo.title;f 
4. //    NSData *imageData = [NSData dataWithContentsOfURL:_photo.thumbnailUrl]; 
5. //    self.imageView.image = [UIImage imageWithData:imageData];
6.     [[ImageCache sharedInstance] downloadImageAtURL:_photo.thumbnailUrl 
7.                                   completionHandler:^(UIImage *image) { 
8.                                       self.imageView.image = image; 
9.                                       [self setNeedsLayout]; 
10.                                   }]; 
11. } 

修改好後,在儀器重新執行該應用程式Product—Profile（或cmd-記住，這些快捷鍵真的會為您節省一些時間）。 請注意，這個時候會再問一次你是否使用一起。這是因為你還有一個視窗中開啟這個程式，及儀器假定您要使用相同的選項再次執行。 執行一些更多的搜尋，並注意此時使用者介面不是那麼卡頓了！這些影象現在非同步載入，並快取在後臺，所以一旦他們已經被下載一次，他們不必再次下載。 看上去很不錯！是時候釋出了嗎? 當然還不夠 分配，分配，分配 接下來的儀器是分配工具。它能給出你所有建立和儲存它們的記憶體的詳細資訊，它也顯示你保留了每個物件的計數。 關閉儀器，回到Xcode和選擇Product->Profile。然後，從選擇器分配並單擊配置檔案。如下圖:
程式再次開啟 然後你會看到
這個時候你會發現兩個曲目。一個叫(分配)Allocations，以及一個被稱為VM Tracker(虛擬機器跟蹤)。該分配軌道將詳細在本教程中討論;虛擬機器跟蹤也是非常有用的，但更復雜一點。 所以你的錯誤會追蹤下？ 有隱藏的專案，你可能不知道有東西在那兒。你可能已經聽說了記憶體洩漏。但你可能不知道的是，其實有兩種洩漏。 第一個是真正的記憶體洩漏，一個物件尚未被釋放，但是不再被引用的了。因此，儲存器不能被重新使用。 第二類洩漏是比較麻煩一些。這就是所謂的“無界記憶體增長”。這發生在記憶體繼續分配，並永遠不會有機會被釋放。 如果永遠這樣下去你的程式佔用的記憶體會無限大,當超過一定記憶體的話 會被系統的看門狗給kill掉. 建立一個場景，你可以檢測出無限的記憶體增長。首先，在應用程式使10個不同的搜尋（不要用已經存在的搜尋）。確保搜尋的一些結果！現在讓程式等待幾秒鐘。 你應該已經注意到，在分配的軌道圖不斷上升。這是告訴你的,記憶體被分配了。它的這一特徵，將引導你找到無限的記憶體增長。 你將要執行的是“heap shot analysis”。為此，按這個按鈕叫“Mark Heap”。你會發現的詳細面板左側的按鈕
按下它，你會看到一個紅色的標誌出現在軌道上，像這樣：   heap shot分析的目的是執行一個動作多次，看看如果記憶體是否無限增長。搜尋一個內容，稍等幾秒載入影象，然後返回主頁。然後再標記堆。反覆這樣做不同的搜尋。試過幾個搜尋後，儀器會看起來像這樣：
這時你應該會疑問。圖中的藍色是怎麼回事了，你繼續這樣操作10次這樣的搜尋 藍色還不斷變高： 那肯定是不好的。別急，有什麼關於記憶體的警告？你知道這些，對不對？記憶體警告是告訴一個應用程式，記憶體警告是ios處理app最好的方式尤其是在記憶體越來越吃緊的時候,你需要清除一些記憶體。 記憶體一直增長其實也不一定是你的程式碼除了問題,也有可能是UIKit 系統框架本身導致的. 通過選擇HardwareSimulate記憶體警告在iOS模擬器的選單欄模擬記憶體警告。你會發現，記憶體使用量出現小幅回落，但絕對不會回到它應該的。所以還是有無限的記憶體增長髮生的地方。 在iOS模擬器的選單欄中選擇hardwaresimulate記憶體警告模擬記憶體警告。你會發現記憶體使用會出現小幅回落，但肯定不會回到它應該在的地方。 每一次的搜尋後做你可以看到記憶體已拍攝之間的分配。在詳細資訊面板看一看，你會看到一好多堆鏡頭。 穩準狠 第一個堆鏡頭作為參照,然後隨便開啟一個堆鏡頭,你會看到如下:
靠，這是一個很大的物件！從哪裡開始看呢？ 最好的方式是通過列表，你在你的應用程式直接使用的類。在這種情況下，HTTPHeaderDict，CGRegion，CGPath，CFNumber，等等都是可以忽略了。 但是，一個突出的是UIImage,這肯定是在你程式使用的。點選上的UIImage左側的箭頭顯示的完整列表。選擇一個，在擴充套件詳細資訊面板：
圖中灰色的是系統庫,黑色部分是你應用的程式碼,要獲得此跟蹤更多的上下文,雙擊唯一的黑框ImageCache方法,這時候將掉轉到如下方法

1. - (void)downloadImageAtURL:(NSURL*)url completionHandler:(ImageCacheDownloadCompletionHandler)completion { 
2.     UIImage *cachedImage = [self imageForKey:[url absoluteString]]; 
3.     if (cachedImage) { 
4.         completion(cachedImage); 
5.     } else { 
6.         dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 
7.             NSData *data = [NSData dataWithContentsOfURL:url]; 
8.             UIImage *image = [UIImage imageWithData:data]; 
9.             [self setImage:image forKey:[url absoluteString]]; 
10.             dispatch_async(dispatch_get_main_queue(), ^{ 
11.                 completion(image); 
12.             }); 
13.         }); 
14.     } 
15. } 

工具是非常有用的,你現在要努力通過自己的程式碼思考發生了什麼.看看通過上面的方法，你會看到它呼叫一個名為setImage方法：forKey：。這種方法在快取以防它再次使用以後的應用程式的影象。 一起來看看該方法的實現：

1. - (void)setImage:(UIImage*)image forKey:(NSString*)key { 
2.     [_cache setObject:image forKey:key]; 
3. } 

從網路上下載一個圖片新增字典中,你會注意到這些圖片從來沒有從字典清楚過。 這就是記憶體為什麼會一直增長,因為應用程式並不會從快取裡刪除東西.它只會一直增加他們。 要解決此問題,你需要的是ImageCache收到UIApplication記憶體吃緊的警告時.清理快取。 為了使ImageCache能接收通知，修改init方法如下：

1. - (id)init { 
2.     if ((self = [super init])) { 
3.         _cache = [NSMutableDictionary new]; 
4.         [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(memoryWarning:) name:UIApplicationDidReceiveMemoryWarningNotification object:nil]; 
5.     } 
6.     return self; 
7. } 

註冊UIApplicationDidReceiveMemoryWarningNotification執行memoryWarning：方法。

1. - (void)memoryWarning:(NSNotification*)note { 
2.     [_cache removeAllObjects]; 
3. } 

memoryWarning刪除快取中的所有物件。這將確保沒有持影象。 為了測試此修復程式，再次啟動儀器（從Xcode中有cmd）和重複的步驟。不要忘了在模擬結束記憶體警告！ 注意：請確保您從Xcode中退出，重新構建，而不是僅僅點選儀器儀表上的紅色按鈕，以確保您使用的是最新的程式碼。 這一次分析應該是這樣的：
這個時候，記憶體受到記憶體警告後急劇下降。但還是有一些記憶體整體增長，但遠不及像以前那樣。 究其原因還是有一定的增長確實是由於系統庫，並沒有太多可以做的。看來，系統庫不釋放所有的記憶體，這可能是由設計或可能是一個錯誤。你可以在你的應用程式做的是釋放盡可能多的記憶體越好，你已經做到這一點！ 幹得好！還有一個問題，修補了, - 仍然有洩漏，你還沒有解決的第一種型別的問題。 記憶體洩露 記憶體洩漏的儀器。這是用來找到第一類洩漏前面提到的 - 當一個物件不再被引用時出現的那種。 檢測洩漏是可以理解的一個很複雜的事情，但洩漏的工具記得，已分配的所有物件，並定期通過掃描每個物件以確定是否有任何不能從任何其他物件訪問的。 關閉儀器，回到Xcode和選擇Product->Profile
回到你的應用程式！執行搜尋，得到結果。然後點選結果的預覽行開啟全屏瀏覽器。按下旋轉按鈕在左上角，然後再按一次。 回到儀器，等待片刻。如果你已經正確地完成上述步驟後，你會發現洩漏已經出現了！你的工具視窗將看起來像這樣：
返回到模擬器，並按下旋轉幾次。然後返回到儀器和等會,得到如下結果：
哪來的洩漏從哪裡來？擴充套件詳細資訊面板
在擴充套件的詳細資訊面板開啟CGContext上名單。在列表中選擇CGContext上的元素之一，這表明導致要建立的物件，如下面的堆疊跟蹤：
再次，涉及到你的程式碼中的幀顯示為黑色。由於只有一個，雙擊它，看看程式碼的方法。 有問題的方法是rotateTapped： ，這是被呼叫時被竊聽旋轉按鈕的處理程式。這種方法旋轉原始影象，並建立一個新的影象，如下：

1. - (void)rotateTapped:(id)sender { 
2.     UIImage *currentImage = _imageView.image; 
3.     CGImageRef currentCGImage = currentImage.CGImage; 
4.     CGSize originalSize = currentImage.size; 
5.     CGSize rotatedSize = CGSizeMake(originalSize.height, originalSize.width); 
6.     CGContextRef context = CGBitmapContextCreate(NULL, 
7.                                                  rotatedSize.width, 
8.                                                  rotatedSize.height, 
9.                                                  CGImageGetBitsPerComponent(currentCGImage), 
10.                                                  CGImageGetBitsPerPixel(currentCGImage) * rotatedSize.width, 
11.                                                  CGImageGetColorSpace(currentCGImage), 
12.                                                  CGImageGetBitmapInfo(currentCGImage)); 
13.     CGContextTranslateCTM(context, rotatedSize.width, 0.0f); 
14.     CGContextRotateCTM(context, M_PI_2); 
15.     CGContextDrawImage(context, (CGRect){.origin=CGPointZero, .size=originalSize}, currentCGImage); 
16.     CGImageRef newCGImage = CGBitmapContextCreateImage(context); 
17.     UIImage *newImage = [UIImage imageWithCGImage:newCGImage]; 
18.     self.imageView.image = newImage; 
19. } 

再次，儀器只能在這裡給你一個提示，問題出在哪裡，它不能告訴你確切位置的洩漏。這是唯一能夠證明你在建立物件洩露的地方.你可能認為ARC並有不可能是造成程式碼中記憶體洩漏…對不對？ 回想一下，ARC只涉及Objective-C的物件。它不管理保留和的CoreFoundation物件而不是Objective-C的物件的釋放。 啊，現在它開始變得明顯的問題是什麼？ -CGContextRef和CGImageRef物件永遠不會被釋放！為了解決這個問題，在rotateTapped方法的末尾新增以下兩行程式碼：

1. CGImageRelease(newCGImage); 
2. CGContextRelease(context); 

這兩種呼叫都需要來維護這兩個物件的保留計數。這個說明，你還需要了解引用計數 - 即使你在你的專案中使用的ARC！ 從在Xcode中，使用cmd工具構建和執行應用程式。 在使用洩漏儀器儀器再看看應用程式，看看是否洩漏的被固定。如果你正確地遵循上述步驟，洩漏應消失！