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

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

2. 在正確的地方使用 reuseIdentifier

一個(gè)開發(fā)中常見(jiàn)的錯(cuò)誤就是沒(méi)有給UITableViewCells页藻， UICollectionViewCells桨嫁，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier。

為了性能最優(yōu)化份帐，table view用`tableView:cellForRowAtIndexPath:`為rows分配cells的時(shí)候璃吧，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell。一個(gè)table view維持一個(gè)隊(duì)列的數(shù)據(jù)可重用的UITableViewCell對(duì)象废境。

不使用reuseIdentifier的話畜挨，每顯示一行table view就不得不設(shè)置全新的cell。這對(duì)性能的影響可是相當(dāng)大的噩凹，尤其會(huì)使app的滾動(dòng)體驗(yàn)大打折扣巴元。

自iOS6起，除了UICollectionView的cells和補(bǔ)充views驮宴，你也應(yīng)該在header和footer views中使用reuseIdentifiers逮刨。

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

staticNSString *CellIdentifier = @"Cell";

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

這個(gè)方法把那些已經(jīng)存在的cell從隊(duì)列中排除堵泽，或者在必要時(shí)使用先前注冊(cè)的nib或者class創(chuàng)造新的cell修己。如果沒(méi)有可重用的cell，你也沒(méi)有注冊(cè)一個(gè)class或者nib的話迎罗，這個(gè)方法返回nil睬愤。

3.盡量把views設(shè)置為透明

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

原因是這會(huì)使系統(tǒng)用一個(gè)最優(yōu)的方式渲染這些views佳谦。這個(gè)簡(jiǎn)單的屬性在IB或者代碼里都可以設(shè)定戴涝。

Apple的文檔對(duì)于為圖片設(shè)置透明屬性的描述是：

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

在相對(duì)比較靜止的畫面中窗怒，設(shè)置這個(gè)屬性不會(huì)有太大影響。然而當(dāng)這個(gè)view嵌在scroll view里邊蓄拣，或者是一個(gè)復(fù)雜動(dòng)畫的一部分扬虚，不設(shè)置這個(gè)屬性的話會(huì)在很大程度上影響app的性能。

你可以在模擬器中用Debug\Color Blended Layers選項(xiàng)來(lái)發(fā)現(xiàn)哪些view沒(méi)有被設(shè)置為opaque球恤。目標(biāo)就是辜昵，能設(shè)為opaque的就全設(shè)為opaque!

4.避免過(guò)于龐大的XIB

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

如果你不得不XIB的話，使他們盡量簡(jiǎn)單舀锨。嘗試為每個(gè)Controller配置一個(gè)單獨(dú)的XIB岭洲，盡可能把一個(gè)View Controller的view層次結(jié)構(gòu)分散到單獨(dú)的XIB中去。

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

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

當(dāng)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)捏雌，nib加載代碼會(huì)把圖片和聲音文件寫進(jìn)內(nèi)存。在OS X中唠帝，圖片和聲音資源被緩存在named cache中以便將來(lái)用到時(shí)獲取屯掖。在iOS中，僅圖片資源會(huì)被存進(jìn)named caches襟衰。取決于你所在的平臺(tái)贴铜，使用NSImage 或UIImage的`imageNamed:`方法來(lái)獲取圖片資源。

5.不要阻塞主線程

永遠(yuǎn)不要使主線程承擔(dān)過(guò)多瀑晒。因?yàn)閁IKit在主線程上做所有工作绍坝，渲染，管理觸摸反應(yīng)苔悦，回應(yīng)輸入等都需要在它上面完成轩褐。

一直使用主線程的風(fēng)險(xiǎn)就是如果你的代碼真的block了主線程，你的app會(huì)失去反應(yīng)玖详。

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

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

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

或者使用像AFNetworking這樣的框架來(lái)異步地做這些操作蟋座。

如果你需要做其它類型的需要耗費(fèi)巨大資源的操作(比如時(shí)間敏感的計(jì)算或者存儲(chǔ)讀寫)那就用 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)代碼中有一個(gè)嵌套的`dispatch_async`嗎？這是因?yàn)槿魏蜺IKit相關(guān)的代碼需要在主線程上進(jìn)行向臀。

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

如果要在`UIImageView`中顯示一個(gè)來(lái)自bundle的圖片巢墅，你應(yīng)保證圖片的大小和UIImageView的大小相同。在運(yùn)行中縮放圖片是很耗費(fèi)資源的，特別是`UIImageView`嵌套在`UIScrollView`中的情況下砂缩。

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

7. 選擇正確的Collection

學(xué)會(huì)選擇對(duì)業(yè)務(wù)場(chǎng)景最合適的類或者對(duì)象是寫出能效高的代碼的基礎(chǔ)眨唬。當(dāng)處理collections時(shí)這句話尤其正確。

一些常見(jiàn)collection的總結(jié)：

· Arrays: 有序的一組值好乐。使用index來(lái)lookup很快匾竿，使用value lookup很慢，插入/刪除很慢蔚万。

· Dictionaries: 存儲(chǔ)鍵值對(duì)岭妖。用鍵來(lái)查找比較快。

· Sets: 無(wú)序的一組值反璃。用值來(lái)查找很快昵慌，插入/刪除很快。

8. 打開gzip壓縮

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

問(wèn)題是我們的目標(biāo)是移動(dòng)設(shè)備，因此你就不能指望網(wǎng)絡(luò)狀況有多好梧田。一個(gè)用戶現(xiàn)在還在edge網(wǎng)絡(luò)淳蔼，下一分鐘可能就切換到了3G。不論什么場(chǎng)景裁眯，你肯定不想讓你的用戶等太長(zhǎng)時(shí)間鹉梨。

減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開gzip。這對(duì)于文字這種能有更高壓縮率的數(shù)據(jù)來(lái)說(shuō)會(huì)有更顯著的效用穿稳。

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

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

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

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

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

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

1. 創(chuàng)建并隱藏這個(gè)view當(dāng)這個(gè)screen加載的時(shí)候踩官，當(dāng)需要時(shí)顯示它；

2. 當(dāng)需要時(shí)才創(chuàng)建并展示境输。

每個(gè)方案都有其優(yōu)缺點(diǎn)蔗牡。用第一種方案的話因?yàn)槟阈枰婚_始就創(chuàng)建一個(gè)view并保持它直到不再使用，這就會(huì)更加消耗內(nèi)存嗅剖。然而這也會(huì)使你的app操作更敏感因?yàn)楫?dāng)用戶點(diǎn)擊按鈕的時(shí)候它只需要改變一下這個(gè)view的可見(jiàn)性辩越。

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

10. Cache, Cache, 還是Cache!

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

我們能緩存些什么呢督惰？一些選項(xiàng)是，遠(yuǎn)端服務(wù)器的響應(yīng)欺旧，圖片姑丑，甚至計(jì)算結(jié)果，比如UITableView的行高辞友。

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

下面是一個(gè)可用的代碼段称龙，你可以可以用它去為一個(gè)基本不會(huì)改變的圖片創(chuàng)建一個(gè)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對(duì)象

24. 選擇是否緩存圖片

常見(jiàn)的從bundle中加載圖片的方式有兩種留拾，一個(gè)是用`imageNamed`，二是用`imageWithContentsOfFile`鲫尊，第一種比較常見(jiàn)一點(diǎn)痴柔。

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

`imageNamed`的優(yōu)點(diǎn)是當(dāng)加載時(shí)會(huì)緩存圖片咳蔚。`imageNamed`的文檔中這么說(shuō):這個(gè)方法用一個(gè)指定的名字在系統(tǒng)緩存中查找并返回一個(gè)圖片對(duì)象如果它存在的話。如果緩存中沒(méi)有找到相應(yīng)的圖片搔驼，這個(gè)方法從指定的文檔中加載然后緩存并返回這個(gè)對(duì)象谈火。

相反的，`imageWithContentsOfFile`僅加載圖片舌涨。

下面的代碼說(shuō)明了這兩種方法的用法:

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

// or

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

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

如果你要加載一個(gè)大圖片而且是一次性使用，那么就沒(méi)必要緩存這個(gè)圖片，用`imageWithContentsOfFile`足矣温技，這樣不會(huì)浪費(fèi)內(nèi)存來(lái)緩存它革为。

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

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

如果你要用`NSDateFormatter`來(lái)處理很多日期格式震檩，應(yīng)該小心以待。就像先前提到的系任，任何時(shí)候重用`NSDateFormatters`都是一個(gè)好的實(shí)踐恳蹲。

然而，如果你需要更多速度俩滥，那么直接用C是一個(gè)好的方案嘉蕾。Sam Soffes有一個(gè)不錯(cuò)的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)里面有一些可以用來(lái)解析ISO-8601日期字符串的代碼，簡(jiǎn)單重寫一下就可以拿來(lái)用了霜旧。

嗯错忱，直接用C來(lái)搞，看起來(lái)不錯(cuò)了挂据，但是你相信嗎以清，我們還有更好的方案！

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

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

return[NSDate dateWithTimeIntervalSince1970:timestamp];

}

這樣會(huì)比用C來(lái)解析日期字符串還快！需要注意的是个绍，許多web API會(huì)以微秒的形式返回時(shí)間戳勒葱，因?yàn)檫@種格式在javascript中更方便使用。記住用`dateFromUnixTimestamp`之前除以1000就好了巴柿。