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

ARC除了幫你避免內(nèi)存泄露寨闹，ARC還可以幫你提高性能留潦，它能保證釋放掉不再需要的對象的內(nèi)存鸭叙。

2. 在正確的地方使用 reuseIdentifier

3.如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES闯第。

在相對比較靜止的畫面中，設(shè)置這個屬性不會有太大影響旺聚。然而當(dāng)這個view嵌在scroll view里邊织阳，或者是一個復(fù)雜動畫的一部分，不設(shè)置這個屬性的話會在很大程度上影響app的性能砰粹。

4.避免過于龐大的XIB

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

5.不要阻塞主線程

永遠(yuǎn)不要使主線程承擔(dān)過多嵌器。因為UIKit在主線程上做所有工作肛真，渲染，管理觸摸反應(yīng)爽航，回應(yīng)輸入等都需要在它上面完成蚓让。

一直使用主線程的風(fēng)險就是如果你的代碼真的block了主線程，你的app會失去反應(yīng)讥珍。

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

如果要在`UIImageView`中顯示一個來自bundle的圖片历极，你應(yīng)保證圖片的大小和UIImageView的大小相同。在運(yùn)行中縮放圖片是很耗費(fèi)資源的衷佃，特別是`UIImageView`嵌套在`UIScrollView`中的情況下趟卸。如果圖片是從遠(yuǎn)端服務(wù)加載的最好是用background thread，縮放一次纲酗，然后在UIImageView中使用縮放后的圖片衰腌。

使用后臺線程加載圖片來提升性能

有兩種方式可以為強(qiáng)制解壓提前渲染圖片：

● 將圖片的一個像素繪制成一個像素大小的CGContext。這樣仍然會解壓整張圖片觅赊，但是繪制本身并沒有消耗任何時間右蕊。這樣的好處在于加載的圖片并不會在特定的設(shè)備上為繪制做優(yōu)化，所以可以在任何時間點(diǎn)繪制出來吮螺。同樣iOS也就可以丟棄解壓后的圖片來節(jié)省內(nèi)存了饶囚。

● 將整張圖片繪制到CGContext中，丟棄原始的圖片鸠补，并且用一個從上下文內(nèi)容中新的圖片來代替萝风。這樣比繪制單一像素那樣需要更加復(fù)雜的計算，但是因此產(chǎn)生的圖片將會為繪制做優(yōu)化紫岩，而且由于原始壓縮圖片被拋棄了规惰，iOS就不能夠隨時丟棄任何解壓后的圖片來節(jié)省內(nèi)存了。

7. 選擇正確的集合

· Arrays: 有序的一組值泉蝌。使用index來lookup很快歇万，使用value lookup很慢揩晴，插入/刪除很慢。

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

· Sets: 無序的一組值。用值來查找很快寒锚，插入/刪除很快劫映。

8. 打開gzip壓縮

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

好消息是泳赋，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然腮郊。

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

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

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

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

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

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

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

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

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

10. Cache, Cache, 還是Cache!

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

我們能緩存些什么呢档桃？一些選項是，遠(yuǎn)端服務(wù)器的響應(yīng)憔晒，圖片藻肄，甚至計算結(jié)果蔑舞，比如UITableView的行高。

NSURLConnection默認(rèn)會緩存資源在內(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.權(quán)衡渲染方法

在iOS中可以有很多方法做出漂亮的按鈕阴挣。你可以用整幅的圖片，可調(diào)大小的圖片纺腊，uozhe可以用CALayer畔咧， CoreGraphics甚至OpenGL來畫它們。

當(dāng)然每個不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能揖膜。

簡單來說誓沸，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序壹粟。問題是你需要把所有你需要用到的圖片放到app的bundle里面拜隧，這樣就增加了體積–這就是使用可變大小的圖片更好的地方了:你可以省去一些不必要的空間，也不需要再為不同的元素(比如按鈕)來做不同的圖趁仙。

然而洪添，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動性，你需要一遍又一遍不斷地重做他們雀费，這樣就很浪費(fèi)時間了干奢，而且你如果要做一個動畫效果，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大坐儿。

總得來說律胀，你需要權(quán)衡一下利弊，到底是要性能能還是要bundle保持合適的大小貌矿。

12.處理內(nèi)存警告

一旦系統(tǒng)內(nèi)存過低炭菌，iOS會通知所有運(yùn)行中app。在官方文檔中是這樣記述:

如果你的app收到了內(nèi)存警告逛漫，它就需要盡可能釋放更多的內(nèi)存黑低。最佳方式是移除對緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.

幸運(yùn)的是，UIKit提供了幾種收集低內(nèi)存警告的方法:

· 在app delegate中使用`applicationDidReceiveMemoryWarning:`的方法

· 在你的自定義UIViewController的子類(subclass)中覆蓋`didReceiveMemoryWarning`

· 注冊并接收 UIApplicationDidReceiveMemoryWarningNotification的通知

一旦收到這類通知克握，你就需要釋放任何不必要的內(nèi)存使用蕾管。

例如，UIViewController的默認(rèn)行為是移除一些不可見的view菩暗，它的一些子類則可以補(bǔ)充這個方法掰曾，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片停团。

這樣對內(nèi)存警報的處理是很必要的旷坦，若不重視，你的app就可能被系統(tǒng)殺掉佑稠。

然而秒梅，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來釋放內(nèi)存。一定要在開發(fā)中用模擬器中的內(nèi)存提醒模擬去測試一下舌胶。

13.重用大開銷對象

一些objects的初始化很慢捆蜀，比如NSDateFormatter和NSCalendar。然而幔嫂，你又不可避免地需要使用它們辆它，比如從JSON或者XML中解析數(shù)據(jù)。

想要避免使用這個對象的瓶頸你就需要重用他們履恩，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來實(shí)現(xiàn)娩井。

注意如果你要選擇第二種方法，對象會在你的app運(yùn)行時一直存在于內(nèi)存中似袁，和單例(singleton)很相似。

下面的代碼說明了使用一個屬性來延遲加載一個date formatter. 第一次調(diào)用時它會創(chuàng)建一個新的實(shí)例咐刨，以后的調(diào)用則將返回已經(jīng)創(chuàng)建的實(shí)例：

// 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;

}

還需要注意的是昙衅，其實(shí)設(shè)置一個NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的！所以如果你的app需要經(jīng)常進(jìn)行日期格式處理的話定鸟，你會從這個方法中得到不小的性能提升而涉。

14. 使用Sprite Sheets

Sprite sheet可以讓渲染速度加快，甚至比標(biāo)準(zhǔn)的屏幕渲染方法節(jié)省內(nèi)存联予。

15.避免反復(fù)處理數(shù)據(jù)

許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)啼县。在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要。在內(nèi)存中操作數(shù)據(jù)使它們滿足你的數(shù)據(jù)結(jié)構(gòu)是開銷很大的沸久。

比如你需要數(shù)據(jù)來展示一個table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變季眷。

類似的，如果需要從特定key中取數(shù)據(jù)卷胯，那么就使用鍵值對的dictionary子刮。

16.選擇正確的數(shù)據(jù)格式

從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案，最常見的就是JSON和XML。你需要選擇對你的app來說最合適的一個挺峡。

解析JSON會比XML更快一些葵孤，JSON也通常更小更便于傳輸。從iOS5起有了官方內(nèi)建的JSON deserialization就更加方便使用了橱赠。

但是XML也有XML的好處尤仍，比如使用SAX來解析XML就像解析本地文件一樣，你不需像解析json一樣等到整個文檔下載完成才開始解析狭姨。當(dāng)你處理很大的數(shù)據(jù)的時候就會極大地減低內(nèi)存消耗和增加性能宰啦。

17.正確設(shè)定背景圖片

在View里放背景圖片就像很多其它iOS編程一樣有很多方法:

使用UIColor的 colorWithPatternImage來設(shè)置背景色；

在view中添加一個UIImageView作為一個子View送挑。

如果你使用全畫幅的背景圖绑莺，你就必須使用UIImageView因為UIColor的colorWithPatternImage是用來創(chuàng)建小的重復(fù)的圖片作為背景的。這種情形下使用UIImageView可以節(jié)約不少的內(nèi)存：

// You could also achieve the same result in Interface Builder

UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];

[self.view addSubview:backgroundView];

如果你用小圖平鋪來創(chuàng)建背景惕耕，你就需要用UIColor的colorWithPatternImage來做了纺裁，它會更快地渲染也不會花費(fèi)很多內(nèi)存：

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

18. 減少使用Web特性

UIWebView很有用，用它來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIKit很難做到的動畫效果是很簡單的一件事司澎。

但是你可能有注意到UIWebView并不像驅(qū)動Safari的那么快欺缘。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。

所以想要更高的性能你就要調(diào)整下你的HTML了挤安。第一件要做的事就是盡可能移除不必要的javascript谚殊，避免使用過大的框架。能只用原生js就更好了蛤铜。

另外嫩絮，盡可能異步加載例如用戶行為統(tǒng)計script這種不影響頁面表達(dá)的javascript。

最后围肥，永遠(yuǎn)要注意你使用的圖片剿干，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存穆刻。

19. 設(shè)定Shadow Path

如何在一個View或者一個layer上加一個shadow呢置尔，QuartzCore框架是很多開發(fā)者的選擇：

#import

// 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不得不先在后臺得出你的圖形并加好陰影然后才渲染朵锣，這開銷是很大的谬盐。

使用shadowPath的話就避免了這個問題：

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

使用shadow path的話iOS就不必每次都計算如何渲染，它使用一個預(yù)先計算好的路徑猪勇。但問題是自己計算path的話可能在某些View中比較困難设褐，且每當(dāng)view的frame變化的時候你都需要去update shadow path.

20. 優(yōu)化Table View

Table view需要有很好的滾動性能，不然用戶會在滾動過程中發(fā)現(xiàn)動畫的瑕疵。

為了保證table view平滑滾動助析，確保你采取了以下的措施:

· 正確使用`reuseIdentifier`來重用cells

· 盡量使所有的view opaque犀被，包括cell自身

· 避免漸變，圖片縮放外冀，后臺選人

· 緩存行高

· 如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自web寡键，使用異步加載，緩存請求結(jié)果

· 使用`shadowPath`來畫陰影

· 減少subviews的數(shù)量

· 盡量不適用`cellForRowAtIndexPath:`雪隧，如果你需要用到它西轩，只用一次然后緩存結(jié)果

· 使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)

· 使用`rowHeight`, `sectionFooterHeight`和 `sectionHeaderHeight`來設(shè)定固定的高吏祸，不要請求delegate

21.選擇正確的數(shù)據(jù)存儲選項

當(dāng)存儲大塊數(shù)據(jù)時你會怎么做岛啸？

你有很多選擇，比如：

· 使用`NSUerDefaults`

· 使用XML, JSON, 或者 plist

· 使用NSCoding存檔

· 使用類似SQLite的本地SQL數(shù)據(jù)庫

· 使用 Core Data

NSUserDefaults的問題是什么录语？雖然它很nice也很便捷庄拇，但是它只適用于小數(shù)據(jù)注服，比如一些簡單的布爾型的設(shè)置選項，再大點(diǎn)你就要考慮其它方式了

XML這種結(jié)構(gòu)化檔案呢措近？總體來說溶弟，你需要讀取整個文件到內(nèi)存里去解析，這樣是很不經(jīng)濟(jì)的瞭郑。使用SAX又是一個很麻煩的事情辜御。

NSCoding？不幸的是屈张，它也需要讀寫文件擒权，所以也有以上問題。

在這種應(yīng)用場景下阁谆，使用SQLite 或者 Core Data比較好菜拓。使用這些技術(shù)你用特定的查詢語句就能只加載你需要的對象。

在性能層面來講笛厦，SQLite和Core Data是很相似的。他們的不同在于具體使用方法俺夕。Core Data代表一個對象的graph model裳凸，但SQLite就是一個DBMS。Apple在一般情況下建議使用Core Data劝贸，但是如果你有理由不使用它姨谷，那么就去使用更加底層的SQLite吧。

如果你使用SQLite映九，你可以用FMDB(https://GitHub.com/ccgus/fmdb)這個庫來簡化SQLite的操作梦湘，這樣你就不用花很多經(jīng)歷了解SQLite的C API了。

23. 使用Autorelease Pool

`NSAutoreleasePool`負(fù)責(zé)釋放block中的autoreleased objects。一般情況下它會自動被UIKit調(diào)用捌议。但是有些狀況下你也需要手動去創(chuàng)建它哼拔。

假如你創(chuàng)建很多臨時對象，你會發(fā)現(xiàn)內(nèi)存一直在減少直到這些對象被release的時候瓣颅。這是因為只有當(dāng)UIKit用光了autorelease pool的時候memory才會被釋放倦逐。好消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時的對象來避免這個行為：

NSArray *urls = <# An array of file URLs #>;

for(NSURL *url in urls) {

@autoreleasepool {

NSError *error;

NSString *fileContents = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];

/* Process the string, creating and autoreleasing more objects. */

}

}

這段代碼在每次遍歷后釋放所有autorelease對象

24. 選擇是否緩存圖片

常見的從bundle中加載圖片的方式有兩種，一個是用`imageNamed`宫补，二是用`imageWithContentsOfFile`檬姥，第一種比較常見一點(diǎn)。

既然有兩種類似的方法來實(shí)現(xiàn)相同的目的粉怕，那么他們之間的差別是什么呢健民？

`imageNamed`的優(yōu)點(diǎn)是當(dāng)加載時會緩存圖片。`imageNamed`的文檔中這么說:這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話贫贝。如果緩存中沒有找到相應(yīng)的圖片秉犹，這個方法從指定的文檔中加載然后緩存并返回這個對象。

相反的平酿，`imageWithContentsOfFile`僅加載圖片凤优。

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

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

// or

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

那么我們應(yīng)該如何選擇呢？

如果你要加載一個大圖片而且是一次性使用蜈彼，那么就沒必要緩存這個圖片筑辨，用`imageWithContentsOfFile`足矣，這樣不會浪費(fèi)內(nèi)存來緩存它幸逆。

然而棍辕，在圖片反復(fù)重用的情況下`imageNamed`是一個好得多的選擇。

25. 避免日期格式轉(zhuǎn)換

如果你要用`NSDateFormatter`來處理很多日期格式还绘，應(yīng)該小心以待楚昭。就像先前提到的，任何時候重用`NSDateFormatters`都是一個好的實(shí)踐拍顷。

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

嗯踏揣，直接用C來搞庆亡，看起來不錯了，但是你相信嗎捞稿，我們還有更好的方案又谋！

如果你可以控制你所處理的日期格式拼缝，盡量選擇Unix時間戳。你可以方便地從時間戳轉(zhuǎn)換到NSDate:

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

return[NSDate dateWithTimeIntervalSince1970:timestamp];

}

這樣會比用C來解析日期字符串還快彰亥！需要注意的是咧七，許多web API會以微秒的形式返回時間戳，因為這種格式在javascript中更方便使用剩愧。記住用`dateFromUnixTimestamp`之前除以1000就好了猪叙。