1. 用ARC管理內(nèi)存

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

現(xiàn)在所有的iOS程序都用ARC了，這條可以忽略。

2. 在正確的地方使用 reuseIdentifier

一個開發(fā)中常見的錯誤就是沒有給UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設置正確的reuseIdentifier。

為了性能最優(yōu)化，table view用tableView:cellForRowAtIndexPath:為rows分配cells的時候，它的數(shù)據(jù)應該重用自UITableViewCell。一個table view維持一個隊列的數(shù)據(jù)可重用的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]; 

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

 3.盡量把views設置為透明

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

原因是這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views。這個簡單的屬性在IB或者代碼里都可以設定。

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

(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示。如果設為YES，渲染系統(tǒng)就認為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設置為NO，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View。默認值是YES。

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

你可以在模擬器中用Debug/Color Blended Layers選項來發(fā)現(xiàn)哪些view沒有被設置為opaque。目標就是，能設為opaque的就全設為opaque!

這里有一點需要注意，只要是有中文字符的Label，哪怕你設置成不透明，模擬器中這個Label依然會變紅，這個猜測是字符繪制的時候出的問題，這個目前沒找到好的解決方法。

 4.避免過于龐大的XIB

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

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

需要注意的是，當你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里，包括任何圖片。如果有一個不會即刻用到的view，你這就是在浪費寶貴的內(nèi)存資源了。Storyboards就是另一碼事兒了，storyboard僅在需要時實例化一個view controller.

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

當你加載一個引用了圖片或者聲音資源的nib時，nib加載代碼會把圖片和聲音文件寫進內(nèi)存。在OS X中，圖片和聲音資源被緩存在named cache中以便將來用到時獲取。在iOS中，僅圖片資源會被存進named caches。取決于你所在的平臺，使用NSImage 或UIImage的imageNamed:方法來獲取圖片資源。

這個問題我深有體會，用xib寫的界面加載速度比直接用代碼寫的要慢好多。

5.不要阻塞主線程

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

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

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

你可以使用NSURLConnection異步地做網(wǎng)絡操作:

+ (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  }); }); 

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

6. 在Image Views中調(diào)整圖片大小

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

如果圖片是從遠端服務加載的你不能控制圖片大小，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后，最好是用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。

7. 選擇正確的Collection

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

一些常見collection的總結：

1.  Arrays: 有序的一組值。使用index來lookup很快，使用value lookup很慢，插入/刪除很慢。
2.  Dictionaries: 存儲鍵值對。用鍵來查找比較快。
3.  Sets: 無序的一組值。用值來查找很快，插入/刪除很快。因為Set用到了哈希，所以插入刪除查找速度比Array快很多

 8. 打開gzip壓縮

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

問題是我們的目標是移動設備，因此你就不能指望網(wǎng)絡狀況有多好。一個用戶現(xiàn)在還在edge網(wǎng)絡，下一分鐘可能就切換到了3G。不論什么場景，你肯定不想讓你的用戶等太長時間。

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

好消息是，iOS已經(jīng)在NSURLConnection中默認支持了gzip壓縮，當然AFNetworking這些基于它的框架亦然。像Google App Engine這些云服務提供者也已經(jīng)支持了壓縮輸出。

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

更多的view意味著更多的渲染，也就是更多的CPU和內(nèi)存消耗，對于那種嵌套了很多view在UIScrollView里邊的app更是如此。

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

這樣的話你就只需要在滾動發(fā)生時創(chuàng)建你的views，避免了不劃算的內(nèi)存分配。

創(chuàng)建views的能效問題也適用于你app的其它方面。想象一下一個用戶點擊一個按鈕的時候需要呈現(xiàn)一個view的場景。有兩種實現(xiàn)方法：

1. 創(chuàng)建并隱藏這個view當這個screen加載的時候，當需要時顯示它；

2. 當需要時才創(chuàng)建并展示。

每個方案都有其優(yōu)缺點。用第一種方案的話因為你需要一開始就創(chuàng)建一個view并保持它直到不再使用，這就會更加消耗內(nèi)存。然而這也會使你的app操作更敏感因為當用戶點擊按鈕的時候它只需要改變一下這個view的可見性。

第二種方案則相反-消耗更少內(nèi)存，但是會在點擊按鈕的時候比第一種稍顯卡頓。

 10. Cache, Cache, 還是Cache!注意你的緩存

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

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

NSURLConnection默認會緩存資源在內(nèi)存或者存儲中根據(jù)它所加載的HTTP Headers。你甚至可以手動創(chuàng)建一個NSURLRequest然后使它只加載緩存的值。

下面是一個可用的代碼段，你可以可以用它去為一個基本不會改變的圖片創(chuàng)建一個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/*"forHTTPHeaderField:@"Accept"]; return request; } 

注意你可以通過 NSURLConnection 獲取一個URL request， AFNetworking也一樣的。這樣你就不必為采用這條tip而改變所有的networking代碼了。

如果你需要緩存其它不是HTTP Request的東西，你可以用NSCache。

NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時候它會自動刪掉它的內(nèi)容。

11.權衡渲染方法

在iOS中可以有很多方法做出漂亮的按鈕。你可以用整幅的圖片，可調(diào)大小的圖片，或者可以用CALayer， CoreGraphics甚至OpenGL來畫它們。當然每個不同的解決方法都有不同的復雜程度和相應的性能。

簡單來說，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序。問題是你需要把所有你需要用到的圖片放到app的bundle里面，這樣就增加了體積