iOS 性能優化/記憶體優化常用方法

1. 用ARC管理記憶體

ARC(Automatic ReferenceCounting, 自動引用計數)和iOS5一起釋出，它避免了最常見的也就是經常是由于我們忘記釋放記憶體所造成的記憶體洩露。它自動為你管理retain和release的過程，是以你就不必去手動幹預了。忘掉代碼段結尾的release簡直像記得吃飯一樣簡單。而ARC會自動在底層為你做這些工作。除了幫你避免記憶體洩露，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對象的記憶體。

2. 在正确的地方使用 reuseIdentifier

一個開發中常見的錯誤就是沒有給UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設定正确的reuseIdentifier。

為了性能最優化，table view用`tableView:cellForRowAtIndexPath:`為rows配置設定cells的時候，它的資料應該重用自UITableViewCell。一個table view維持一個隊列的資料可重用的UITableViewCell對象。

不使用reuseIdentifier的話，每顯示一行table view就不得不設定全新的cell。這對性能的影響可是相當大的，尤其會使app的滾動體驗大打折扣。

自iOS6起，除了UICollectionView的cells和補充views，你也應該在header和footer views中使用reuseIdentifiers。

想要使用reuseIdentifiers的話，在一個table view中添加一個新的cell時在data source object中添加這個方法：

staticNSString *CellIdentifier = @"Cell";

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

這個方法把那些已經存在的cell從隊列中排除，或者在必要時使用先前注冊的nib或者class創造新的cell。如果沒有可重用的cell，你也沒有注冊一個class或者nib的話，這個方法傳回nil。

3.盡量把views設定為透明

如果你有透明的Views你應該設定它們的opaque屬性為YES。

原因是這會使系統用一個最優的方式渲染這些views。這個簡單的屬性在IB或者代碼裡都可以設定。

Apple的文檔對于為圖檔設定透明屬性的描述是：

(opaque)這個屬性給渲染系統提供了一個如何處理這個view的提示。如果設為YES，渲染系統就認為這個view是完全不透明的，這使得渲染系統優化一些渲染過程和提高性能。如果設定為NO，渲染系統正常地和其它内容組成這個View。預設值是YES。

在相對比較靜止的畫面中，設定這個屬性不會有太大影響。然而當這個view嵌在scroll view裡邊，或者是一個複雜動畫的一部分，不設定這個屬性的話會在很大程度上影響app的性能。

你可以在模拟器中用Debug\Color Blended Layers選項來發現哪些view沒有被設定為opaque。目标就是，能設為opaque的就全設為opaque!

4.避免過于龐大的XIB

iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場景中仍然很有用。比如你的app需要适應iOS5之前的裝置，或者你有一個自定義的可重用的view,你就不可避免地要用到他們。

如果你不得不XIB的話，使他們盡量簡單。嘗試為每個Controller配置一個單獨的XIB，盡可能把一個View Controller的view層次結構分散到單獨的XIB中去。

需要注意的是，當你加載一個XIB的時候所有内容都被放在了記憶體裡，包括任何圖檔。如果有一個不會即刻用到的view，你這就是在浪費寶貴的記憶體資源了。Storyboards就是另一碼事兒了，storyboard僅在需要時執行個體化一個view controller.

當家在XIB是，所有圖檔都被chache，如果你在做OS X開發的話，聲音檔案也是。Apple在相關文檔中的記述是：

當你加載一個引用了圖檔或者聲音資源的nib時，nib加載代碼會把圖檔和聲音檔案寫進記憶體。在OS X中，圖檔和聲音資源被緩存在named cache中以便将來用到時擷取。在iOS中，僅圖檔資源會被存進named caches。取決于你所在的平台，使用NSImage 或UIImage的`imageNamed:`方法來擷取圖檔資源。

5.不要阻塞主線程

永遠不要使主線程承擔過多。因為UIKit在主線程上做所有工作，渲染，管理觸摸反應，回應輸入等都需要在它上面完成。

一直使用主線程的風險就是如果你的代碼真的block了主線程，你的app會失去反應。

大部分阻礙主程序的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作，比如存儲或者網絡。

你可以使用`NSURLConnection`異步地做網絡操作:

(void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue*)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler

或者使用像AFNetworking這樣的架構來異步地做這些操作。

如果你需要做其它類型的需要耗費巨大資源的操作(比如時間敏感的計算或者存儲讀寫)那就用 Grand Central Dispatch，或者NSOperation和 NSOperationQueues.

下面代碼是使用GCD的模闆

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

// switch to a background thread and perform your expensive operation

dispatch_async(dispatch_get_main_queue(), ^{

// switch back to the main thread to update your UI

});

});

發現代碼中有一個嵌套的`dispatch_async`嗎？這是因為任何UIKit相關的代碼需要在主線程上進行。

6. 在Image Views中調整圖檔大小

如果要在`UIImageView`中顯示一個來自bundle的圖檔，你應保證圖檔的大小和UIImageView的大小相同。在運作中縮放圖檔是很耗費資源的，特别是`UIImageView`嵌套在`UIScrollView`中的情況下。

如果圖檔是從遠端服務加載的你不能控制圖檔大小，比如在下載下傳前調整到合适大小的話，你可以在下載下傳完成後，最好是用background thread，縮放一次，然後在UIImageView中使用縮放後的圖檔。

7. 選擇正确的Collection

學會選擇對業務場景最合适的類或者對象是寫出能效高的代碼的基礎。當處理collections時這句話尤其正确。

一些常見collection的總結：

· Arrays: 有序的一組值。使用index來lookup很快，使用value lookup很慢，插入/删除很慢。

· Dictionaries: 存儲鍵值對。用鍵來查找比較快。

· Sets: 無序的一組值。用值來查找很快，插入/删除很快。

8. 打開gzip壓縮

大量app依賴于遠端資源和第三方API，你可能會開發一個需要從遠端下載下傳XML, JSON, HTML或者其它格式的app。

問題是我們的目标是移動裝置，是以你就不能指望網絡狀況有多好。一個使用者現在還在edge網絡，下一分鐘可能就切換到了3G。不論什麼場景，你肯定不想讓你的使用者等太長時間。

減小文檔的一個方式就是在服務端和你的app中打開gzip。這對于文字這種能有更高壓縮率的資料來說會有更顯著的效用。

好消息是，iOS已經在NSURLConnection中預設支援了gzip壓縮，當然AFNetworking這些基于它的架構亦然。像Google App Engine這些雲服務提供者也已經支援了壓縮輸出。

9. 重用和延遲加載(lazy load) Views

更多的view意味着更多的渲染，也就是更多的CPU和記憶體消耗，對于那種嵌套了很多view在UIScrollView裡邊的app更是如此。

這裡我們用到的技巧就是模仿`UITableView`和`UICollectionView`的操作:不要一次建立所有的subview，而是當需要時才建立，當它們完成了使命，把他們放進一個可重用的隊列中。

這樣的話你就隻需要在滾動發生時建立你的views，避免了不劃算的記憶體配置設定。

建立views的能效問題也适用于你app的其它方面。想象一下一個使用者點選一個按鈕的時候需要呈現一個view的場景。有兩種實作方法：

1. 建立并隐藏這個view當這個screen加載的時候，當需要時顯示它；

2. 當需要時才建立并展示。

每個方案都有其優缺點。用第一種方案的話因為你需要一開始就建立一個view并保持它直到不再使用，這就會更加消耗記憶體。然而這也會使你的app操作更敏感因為當使用者點選按鈕的時候它隻需要改變一下這個view的可見性。

第二種方案則相反-消耗更少記憶體，但是會在點選按鈕的時候比第一種稍顯示卡頓。

10. Cache, Cache, 還是Cache!

一個極好的原則就是，緩存所需要的，也就是那些不大可能改變但是需要經常讀取的東西。

我們能緩存些什麼呢？一些選項是，遠端伺服器的響應，圖檔，甚至計算結果，比如UITableView的行高。

NSURLConnection預設會緩存資源在記憶體或者存儲中根據它所加載的HTTP Headers。你甚至可以手動建立一個NSURLRequest然後使它隻加載緩存的值。

下面是一個可用的代碼段，你可以可以用它去為一個基本不會改變的圖檔建立一個NSURLRequest并緩存它：

(NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];

request.cachePolicy = NSURLRequestReturnCacheDataElseLoad;// this will make sure the request always returns the cached image

request.HTTPShouldHandleCookies = NO;

request.HTTPShouldUsePipelining = YES;

[request addValue:@"image

}

}

這段代碼在每次周遊後釋放所有autorelease對象

24. 選擇是否緩存圖檔

常見的從bundle中加載圖檔的方式有兩種，一個是用`imageNamed`，二是用`imageWithContentsOfFile`，第一種比較常見一點。

既然有兩種類似的方法來實作相同的目的，那麼他們之間的差别是什麼呢？

`imageNamed`的優點是當加載時會緩存圖檔。`imageNamed`的文檔中這麼說:這個方法用一個指定的名字在系統緩存中查找并傳回一個圖檔對象如果它存在的話。如果緩存中沒有找到相應的圖檔，這個方法從指定的文檔中加載然後緩存并傳回這個對象。

相反的，`imageWithContentsOfFile`僅加載圖檔。

下面的代碼說明了這兩種方法的用法:

UIImage *img = [UIImage imageNamed:@"myImage"];// caching

// or

UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching

那麼我們應該如何選擇呢？

如果你要加載一個大圖檔而且是一次性使用，那麼就沒必要緩存這個圖檔，用`imageWithContentsOfFile`足矣，這樣不會浪費記憶體來緩存它。

然而，在圖檔反複重用的情況下`imageNamed`是一個好得多的選擇。

25. 避免日期格式轉換

如果你要用`NSDateFormatter`來處理很多日期格式，應該小心以待。就像先前提到的，任何時候重用`NSDateFormatters`都是一個好的實踐。

然而，如果你需要更多速度，那麼直接用C是一個好的方案。Sam Soffes有一個不錯的文章(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)裡面有一些可以用來解析ISO-8601日期字元串的代碼，簡單重寫一下就可以拿來用了。

嗯，直接用C來搞，看起來不錯了，但是你相信嗎，我們還有更好的方案！

如果你可以控制你所處理的日期格式，盡量選擇Unix時間戳。你可以友善地從時間戳轉換到NSDate:

- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {

return[NSDate dateWithTimeIntervalSince1970:timestamp];

}

這樣會比用C來解析日期字元串還快！需要注意的是，許多web API會以微秒的形式傳回時間戳，因為這種格式在javascript中更友善使用。記住用`dateFromUnixTimestamp`之前除以1000就好了。