iOS效能調優之Analyze靜態分析

標籤：xcode   return   估計   編譯器   size   long   ade   環境   tag   

之前遇到一個同事寫的 陳年老工程，需要儘快的時間修改裡面的東西，急用，讓我幫忙。那就幫著看看。

而Analyze這個工具 真是好用。

工程存在嚴重的記憶體流失。  如果不解決  很容易就會出現崩潰等現象。  於是 乎  就用 Analyze 進行了 初步的檢查，檢查後，我去，一下子傻眼了，竟然有將近300個警告，和  200個 泄漏記憶體的藍色警告。  那就一個一個改吧，  這個可不能隨便改，看到藍色警告不能直接刪除，要先看代碼，分析清楚邏輯，確實這個代碼沒用，才能刪除。  

其實最不願意改這種了，屬於費力不討好的活，花了很大的精力  和 很多的時間，到頭來 boss 一看 ，頁面怎麼沒動，是不是 偷懶沒幹活？

會看的看門道，不會看的看熱鬧。這話一點沒錯！boss不知道你幹了什麼所以就一直催你，催完一個又一個。

本來老闆讓估算時間，那就估了一個時間 n天。

但是 老闆卻說  太多了 ，並做主 把時間壓縮了三分之二。（早知道我就不用估算了，估算半天還不是得按照老闆的時間來）

那可叫人怎麼搞？  於是乎 周末自己家裡加班，反正加班也沒加班費，乾脆在家搞吧，去公司還要多出車費呢。

反正挺坎坷，大家不知道 維護一個四、五年前經過一群人加工然後 還沒加工出成果的  工程 是 多麼的耗費精力 耗費時間，這個姑且不說，讓人不爽的是  做了這麼多， 老闆一看頁面沒有變，  就說你 沒有幹活， 然後還會訓斥你一頓，這下可省錢了，  不用吃飯了 ，直接 生氣就飽了。

還好，Analyze 比較只能，不用你去一個一個找哪裡有泄漏， 要是一個一個找估計給三個月也不一定能搞完啊。

下面就來說下 Analyze。

以下內容參考自網友，略作修改，感謝分享

相信IOS開發人員在App進行Build或Archive時，會產生很多編譯警告，這些警告是編譯時間產生的，靜態分析的過程也類似，在XCode Product菜單下，點擊Analyze對App進行靜態分析。 

Analyze主要分析以下四種問題： 

1、邏輯錯誤：訪問null 指標或未初始化的變數等； 

2、記憶體管理錯誤：如記憶體流失等； 

3、聲明錯誤：從未使用過的變數； 

4、Api調用錯誤：未包含使用的庫和架構。 

Analyze記憶體流失分析：

聲明錯誤、邏輯錯誤、Api調用錯誤基本在編譯時間都會有警告，Analyze的主要優勢在於靜態分析記憶體流失及代碼邏輯錯誤。 

比如在開啟arc的環境下，輸入以下一段代碼： 

//截取部分映像+(UIImage*)getSubImage:(unsigned long)ulUserHeader{    UIImage * sourceImage = [UIImage imageNamed:@"header.png"];    CGFloat height = sourceImage.size.height;    CGRect rect = CGRectMake(0 + ulUserHeader*height, 0, height, height);    CGImageRef imageRef = CGImageCreateWithImageInRect([sourceImage CGImage], rect);    UIImage* smallImage = [UIImage imageWithCGImage:imageRef];    //CGImageRelease(imageRef);    return smallImage;}

 

用注釋注釋掉CGImageRelease(imageRef)這行，雖然開起了arc，不過仍然會導致imageRef對象泄漏。 

使用Analyze進行分析，在導覽列Analyze選擇Analyzer查看分析結果： 

Analyze已經分析出imageRef對象有記憶體流失，這種情況在編譯時間是無法發現的。 

如果你沒有使用ARC，那麼Analyze更有用。 

Analyze的其他三種分析也可以使用，相比編譯器給出的資訊更明確。 

Analyze邏輯錯誤監測：

這種情況在codereview時也較難發現，可以藉助Analyze。 

如上代碼，當Tag不等於1、2和3的時候，就會出現很問題了。 

Analyze還給出了箭頭提示：len is a garbage value。建議在聲明變數時，同時進行初始化。

iOS效能調優之Analyze靜態分析