本文收集了25個關于可以提升程序性能的提示和技巧，分為3個不同的等級：初級、中級和高級。您也可以點擊查看初級篇。

在性能優(yōu)化時，當你碰到一些復雜的問題，應該注意和使用如下技巧：

9.重用和延遲加載View
10.緩存、緩存、緩存
11.考慮繪制
12.處理內存警告
13.重用花銷很大的對象
14.使用Sprite Sheets
15.避免重新處理數(shù)據(jù)
16.選擇正確的數(shù)據(jù)格式
17.設置適當?shù)谋尘皥D片
18.降低Web內容的影響
19.設置陰影路徑
20.優(yōu)化TableView
21.選擇正確的數(shù)據(jù)存儲方式

中級性能提升
現(xiàn)在，在進行代碼優(yōu)化時，你已經能夠完成一些初級性能優(yōu)化了。但是下面還有另外一些優(yōu)化方案，雖然可能不太明顯（取決于程序的架構和相關代碼），但是，如果能夠正確的利用好這些方案，那么它們對性能的優(yōu)化將非常明顯！
9) 重用和延遲加載View

程序界面中包含更多的view，意味著界面在顯示的時候，需要進行更多的繪制任務；也就意味著需要消耗更多的CPU和內存資源。特別是在一個UIScrollView里面加入了許多view。

這種情況的管理技巧可以參考UITableView和UICollectionView的行為：不要一次性創(chuàng)建所有的subview，而是在需要的時候在創(chuàng)建view，并且當view使用完畢時候將它們添加到重用隊列中。

這樣就可以僅在UIScrollView滾動的時候才配置view，以此可以避免分配創(chuàng)建view的帶來的成本——這可能是非常耗資源的。

現(xiàn)在有這樣的一個問題：在程序中需要顯示的view在什么時機創(chuàng)建（比如說，當用戶點擊某個按鈕，需要顯示某個view）。這里有兩種可選方法：

在屏幕***次加載以及隱藏的時候，創(chuàng)建view；然后在需要的時候，再把view顯示出來。
直到需要顯示view的時候，才創(chuàng)建并顯示view。
每種方法都有各自的優(yōu)點和缺點。***種方法需要消耗更多的內容，因為創(chuàng)建出來的view一直占據(jù)著內存，直到view被release掉。不過，使用這種 方法，當用戶點擊按鈕時，程序會很快的顯示出view，因為只需要修改一下view的可見性即可。而第二種方法則產生相反的效果；當需要的時候猜創(chuàng)建 view，這會消耗更少的內存；不過，當用戶點擊按鈕的時候，不會立即顯示出view。
10) 緩存、緩存、緩存

在開發(fā)程序時，一個重要的規(guī)則就是“緩存重要的內容”——這些內容一般不會改變，并且訪問的頻率比較高。

可以緩存寫什么內容呢？比如遠程服務器的響應內容，圖片，甚至是計算結果，比如UITableView的行高。

NSURLConnection根據(jù)HTTP頭的處理過程，已經把一些資源緩存到磁盤和內存中了。你甚至可以手動創(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請求，但是同樣可以使用AFNetworking來抓取，這種方法不用修改所有網絡相關的代碼——這是一個技巧！

更多關于HTTP 緩存, NSURLCache, NSURLConnection 以及相關的內容, 那么看一下NSHipster中的the NSURLCache entry。

如果你需要緩存的內容沒涉及到HTTP請求，那使用NSCache。NSCache的外觀和行為與NSDictionary類似, 但是，當系統(tǒng)需要回收內存時，NSCache會自動的里面存儲的內容。Mattt Thompson 在NSHipster上寫了一篇關于NSCache非常不錯的文章。

更多關于HTTP緩存的內容，建議讀一下Google的這篇文章：best-practices document on HTTP caching。
11) 考慮繪制

這些方法的復雜程度不同，性能也有區(qū)別。這篇關于iOS中圖形性能的文章值得一讀。其中Andy Matuschak（曾經是蘋果的UIKit小組的組員）對這篇文章的評論中，對于不同的方法及其性能權衡有非常好的一個見解。

簡單來說，使用預渲染圖片技術是最快的，因為iOS中不用等到在屏幕上顯示的時候才創(chuàng)建圖形和對形狀進行繪制（圖片已經創(chuàng)建好了!）。這樣帶來的問 題是需要把所有的圖片都放到程序bundle中，從而增加了程序的大小。因此使用可伸縮圖片在這里將排上用場了：可以移除“浪費”空間的圖片——iOS可 以重復利用。并且針對不同的元素（例如按鈕）不需要創(chuàng)建不同的圖片。

不過，使用圖片的話會失去代碼對圖片的控制能力，進而針對不同的程序，就需要重復的生成每一個需要的圖片，并反復的放到每個程序中。這個處理過程一 般會比較慢。另外一點就是如果你需要一個動畫，或者許多圖片都要進行輕微的調整（比如多個顏色的覆蓋），那么需要在程序中加入許多圖片，進而增加了程序 bundle的大小。

總的來說，要考慮一下什么才是最重要的：繪制性能還是程序大小。一般來說都重要，所以在同一個工程中，應該兩種都應考慮。
12) 處理內存警告

當系統(tǒng)內存偏低時，iOS會通知所有在運行的程序。蘋果的官方文檔中介紹了如何處理低內存警告：

If your app receives this warning, it must free up as much memory as possible. The best way to do this is to remove strong references to caches, image objects, and other data objects that can be recreated later.

如果程序收到了低內存警告，在程序中必須盡量釋放內存。***方法就是移除強引用的涉及到的緩存，圖片對象，以及其它可以在之后使用時還可以重新創(chuàng)建的數(shù)據(jù)對象。

UIKit中提供了如下幾種方法來接收低內存（low-memory）警告：

實現(xiàn)app delegate中的applicationDidReceiveMemoryWarning: 方法。
在UIViewController子類中重寫(Override)didReceiveMemoryWarning方法。
在通知中心里面注冊UIApplicationDidReceiveMemoryWarningNotificatio通知。
在收到以上任意的警告時，需要立即釋放任何不需要的內存。

例如，UIViewController的默認情況是清除掉當前不可見的view；在UIViewController的子類中，可以清除一些額外的數(shù)據(jù)。程序中不沒有顯示在當前屏幕中的圖片也可以release掉。

當收到低內存警告時，盡量釋放內存是非常重要的。否則，運行中的程序有可能會被系統(tǒng)殺掉。

不過，在清除內存時要注意一下：確保被清除的對象之后還可以被創(chuàng)建出來。另外，在開發(fā)程序的時候，請使用iOS模擬器中的模擬內存警告功能對程序進行測試！

別走開，下頁繼續(xù)為您激情介紹

#p#

13) 重用花銷很大的對象

當使用這些對象時，為了避免性能上的瓶頸，可以嘗試盡量重用這些對象——在類中添加一個屬性或者創(chuàng)建一個靜態(tài)變量。

注意，如果使用靜態(tài)變量的話，對象會在程序運行的時候一直存在，就像單例一樣。

下面的代碼演示創(chuàng)建一個延遲加載的日期格式屬性。***次調用屬性的時候，會創(chuàng)建一個新的日期格式。之后再調用的話，會返回已經創(chuàng)建好的實例對象：

// in your .h or inside a class extension 
@property (nonatomic, strong) NSDateFormatter *formatter; 
// inside the implementation (.m) 
// When you need, just use self.formatter 
- (NSDateFormatter *)formatter { 
    if (! _formatter) { 
        _formatter = [[NSDateFormatter alloc] init]; 
        _formatter.dateFormat = @"EEE MMM dd HH:mm:ss Z yyyy"; // twitter date format 
    } 
    return _formatter; 
} 

另外，還需要記住的是在設置NSDateFormatter的日期格式時，同樣跟創(chuàng)建新的一個NSDateFormatter實例對象時一樣慢！因此，在程序中如果需要頻繁的處理日期格式，那么對NSDateFormatter進行重用是非常好的。

14) 使用Sprite Sheets

下面是兩個非常不錯的sprite sheets教程：

如何在Cocos2D中使用動畫和Sprite Sheets 

如何在Cocos2D中使用紋理包（Texture Packer）和像素格式來創(chuàng)建并優(yōu)化Sprite Sheets  。（第二個教程詳細的介紹了像素格式——在游戲中可以衡量性能的影響）

如果還不熟悉sprite sheets，可以看看這里的介紹：SpriteSheets – 視頻, Part 1和 Part 2 。這兩個視頻的作者是Andreas Löw, 他是紋理包(Texture Packer)的創(chuàng)建者, 紋理包是創(chuàng)建sprite sheets的重要工具。

除了使用sprite sheets外，這里還介紹了一些用于游戲開發(fā)中的技巧，例如，如果你有很多sprite（比如射擊類游戲中），那么可以重用sprite，而不用每次都創(chuàng)建sprite。
15) 避免重新處理數(shù)據(jù)

許多程序都需要從遠程服務器中獲取數(shù)據(jù)，以滿足程序的需求。這些數(shù)據(jù)一般是JSON或XML格式。在請求和接收數(shù)據(jù)時，使用相同的數(shù)據(jù)結構非常重要。

為什么呢？在內存中把數(shù)據(jù)轉換為適合程序的數(shù)據(jù)格式是需要付出額外代價的。

例如，如果你需要在table view中顯示一些數(shù)據(jù)，那么請求和接收的數(shù)據(jù)格式***是數(shù)組格式的，這樣可以避免一些中間操作——將數(shù)據(jù)轉換為適合程序使用的數(shù)據(jù)結構。

類似的，如果程序是根據(jù)鍵來訪問具體的值，那么***請求和接收一個鍵/值對字典。

在***時間獲得的數(shù)據(jù)就是所需要格式的，可以避免將數(shù)據(jù)轉換為適合程序的數(shù)據(jù)格式帶來的額外代價。
16) 選擇正確的數(shù)據(jù)格式

將數(shù)據(jù)從程序傳到網絡服務器中有多種方法，其中使用的數(shù)據(jù)格式基本都是JSON和XML。你需要做的就是在程序中選擇正確的數(shù)據(jù)格式。

JSON的解析速度非?？欤⑶乙萖ML小得多，也就意味著只需要傳輸更少數(shù)據(jù)。并且在iOS5之后，已經有內置的JSON反序列化API了，所以使用JSON是很容易的。

不過XML也有它自己的優(yōu)勢：如果使用SAX方法來解析XML，那么可以邊讀XML邊解析，并不用等到全部的XML獲取到了才開始解析，這與JSON是不同的。當處理大量數(shù)據(jù)時，這種方法可以提升性能并減少內存的消耗。
17) 設置適當?shù)谋尘皥D片

在iOS編碼中，跟別的許多東西類似，這里也有兩種方法來給view設置一個背景圖片：

1.可以使用UIColor的colorWithPatternImge方法來創(chuàng)建一個顏色，并將這個顏色設置為view的背景顏色。
2.可以給view添加一個UIImageView子視圖。

如果你有一個全尺寸的背景圖片，那么應該使用UIImageView，因為UIColor的colorWithPatternImge方法是用來創(chuàng)建小圖片的——該圖片會被重復使用。此時使用UIImageView會節(jié)省很多內存。

// You could also achieve the same result in Interface Builder 
UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]]; 
[self.view addSubview:backgroundView]; 

不過，如果你計劃用小圖片當做背景，那么應該使用UIColor的colorWithPatternImge方法。這種情況下繪制速度會很快，并且不會消耗大量的內存。

self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];  

 

別走開，下頁繼續(xù)為您激情介紹

#p#

18）降低Web、內容的影響

UIWebView非常有用。用它可以很容易的顯示web內容，甚至可以構建UIKit空間難以顯示的內容。

不過，你可以能已經注意到程序中使用的UIWebView組建沒有蘋果的Safari程序快。這是因為JIT編譯限制了WebKit的Nitro引擎的使用。

因此為了獲得更加的性能，需要調整一下HTML的大小。首先就是盡量的擺脫JavaScript，并避免使用大的礦建，例如jQuery。有時候使用原始的JavaScript要比別的框架快。

另外，盡量的異步加載JavaScript文件——特別是不直接影響到頁面行為時，例如分析腳本。

***——讓使用到的圖片，跟實際需要的一樣大小。如之前提到的，盡量使用sprite sheets，以此節(jié)省內存和提升速度。

更多相關信息，可以看一下： WWDC 2012 session #601 – 在iOS中優(yōu)化UIWebView和網站中的Web內容。

19) 設置陰影路徑

如果需要在view活layer中添加一個陰影，該如何處理呢？大多數(shù)開發(fā)者首先將QuartzCore框架添加到工程中，然后添加如下代碼：

 

#import <QuartzCore/QuartzCore.h> 
// Somewhere later ... 
UIView *view = [[UIView alloc] init]; 
// Setup the shadow ... 
view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f); 
view.layer.shadowRadius = 5.0f; 
view.layer.shadowOpacity = 0.6; 

上面這種方法有一個問題，Core Animation在渲染陰影效果之前，必須通過做一個離屏(offscreen)才能確定view的形狀，而這個離屏操作非常耗費資源。下面方法可以更容易地讓系統(tǒng)進行陰影渲染：設置陰影路徑！

 

view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath]; 

通過設置陰影路徑，iOS就不用總是再計算該如何繪制陰影了。只需要使用你預先計算好的路徑即可。有一點不好的是，根據(jù)view的格式，自己可能很難計算出路徑。另外一個問題就是當view的frame改變時，必須每次都更新一下陰影路徑。

如果你想了解更多相關信息，可參看Mark Pospesel的一篇文章：shadowPath。
20) 優(yōu)化TableView

Table views需要快速的滾動——如果不能的話，用戶會感覺到停頓。為了讓table view平滑的滾動，確保遵循了如下建議：

1.設置正確的reuseIdentifer以重用cell。
2.盡量將view設置為不透明，包括cell本身。
3.避免漸變，圖像縮放以及離屏繪制。
4.如果row的高度不相同，那么將其緩存下來。
5.如果cell顯示的內容來此網絡，那么確保這些內容是通過異步來獲取的。
6.使用shadowPath來設置陰影。
7.減少subview的數(shù)量。
8.在cellForRowAtIndexPath:中盡量做更少的操作。如果需要做一些處理，那么***做過一次之后，就將結果緩存起來。
9.使用適當?shù)臄?shù)據(jù)結構來保存需要的信息。不同的結構會帶來不同的操作代價。
10.使用rowHeight, sectionFooterHeight 和 sectionHeaderHeight 來設置一個恒定 高度，而不要從delegate中獲取。
21) 選擇正確的數(shù)據(jù)存儲方式

1.使用NSUserDefaults進行存儲
2.保存為XML，JSON或Plist格式的文件
3.利用NSCoding進行歸檔
4.存儲到一個本地數(shù)據(jù)庫，例如SQLite。
5.使用Core Data.
使用NSUserDefaults有什么問題呢? 雖然NSUserDefaults很好并且容易，不過只只針對于存儲小量數(shù)據(jù)（比如你的級別，或者聲音是開或關）。如果要存儲大量的數(shù)據(jù)，***選擇別的存儲方式。

大量數(shù)據(jù)保存為結構化的文件也可能會帶來問題。一般，在解析這些結構數(shù)據(jù)之前，需要將內容全部加載到內存中，這是很消耗資源的。雖然可以使用SAX來處理XML文件，但是這有點復雜。另外，加載到內存中的所有對象，不一定全部都需要用到。

那么使用NSCoding來保存大量數(shù)據(jù)怎么樣呢？因為它同樣是對文件進行讀寫，因此依然存在上面說的問題。

要保存大量的數(shù)據(jù)，***使用SQLite或Core Data。通過SQLite或Core Data可以進行具體的查詢——只需要獲取并加載需要的數(shù)據(jù)對象——避免對數(shù)據(jù)進行不合理的搜索。在性能方面，SQLite和Core Data差不大。

SQLite和Core Data***的區(qū)別實際上就是用法上。Core Data代表一個對象模型，而SQLite只是一個DBMS。一般，蘋果建議使用Core Data，不過如果你有特殊的原因不能使用Core Data的話，可以使用低級別的SQLite。

在程序中，如果選擇使用SQLite，這里有個方便的庫FMDB ：可以利用該庫操作SQLite數(shù)據(jù)庫，而不用深入使用SQLite C API。

查看初級篇：25個增強iOS應用程序性能的提示和技巧(初級篇)

查看高級篇：25個增強iOS應用程序性能的提示和技巧(高級篇)