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è)開(kāi)發(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的話(huà)诅迷，每顯示一行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的話(huà)赋秀，在一個(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的話(huà)，這個(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ì)比較靜止的畫(huà)面中，設(shè)置這個(gè)屬性不會(huì)有太大影響涡尘。然而當(dāng)這個(gè)view嵌在scroll view里邊忍弛，或者是一個(gè)復(fù)雜動(dòng)畫(huà)的一部分，不設(shè)置這個(gè)屬性的話(huà)會(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的話(huà)吧彪，使他們盡量簡(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開(kāi)發(fā)的話(huà)瞄摊，聲音文件也是。Apple在相關(guān)文檔中的記述是：

當(dāng)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)苦掘，nib加載代碼會(huì)把圖片和聲音文件寫(xiě)進(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.不要阻塞主線(xiàn)程

永遠(yuǎn)不要使主線(xiàn)程承擔(dān)過(guò)多。因?yàn)閁IKit在主線(xiàn)程上做所有工作抖部，渲染说贝，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成慎颗。

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

大部分阻礙主進(jìn)程的情形是你的app在做一些牽涉到讀寫(xiě)外部資源的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)異步地做這些操作。

如果你需要做其它類(lèi)型的需要耗費(fèi)巨大資源的操作(比如時(shí)間敏感的計(jì)算或者存儲(chǔ)讀寫(xiě))那就用 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)的代碼需要在主線(xià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)整到合適大小的話(huà)沪蓬，你可以在下載完成后彤钟，最好是用background thread，縮放一次跷叉，然后在UIImageView中使用縮放后的圖片逸雹。

7. 選擇正確的Collection

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

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

· Arrays: 有序的一組值梆砸。使用index來(lái)lookup很快，使用value lookup很慢园欣，插入/刪除很慢帖世。

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

· Sets: 無(wú)序的一組值日矫。用值來(lái)查找很快，插入/刪除很快绑榴。

8. 打開(kāi)gzip壓縮

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

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

減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開(kāi)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ì)列中。

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

創(chuàng)建views的能效問(wèn)題也適用于你app的其它方面。想象一下一個(gè)用戶(hù)點(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)芬萍。用第一種方案的話(huà)因?yàn)槟阈枰婚_(kāi)始就創(chuàng)建一個(gè)view并保持它直到不再使用，這就會(huì)更加消耗內(nèi)存搔啊。然而這也會(huì)使你的app操作更敏感因?yàn)楫?dāng)用戶(hù)點(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/*"forHTTPHeaderField:@"Accept"];

return request;

}

注意你可以通過(guò) NSURLConnection 獲取一個(gè)URL request， AFNetworking也一樣的纤壁。這樣你就不必為采用這條tip而改變所有的networking代碼了左刽。

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

NSCache和NSDictionary類(lèi)似欠痴，不同的是系統(tǒng)回收內(nèi)存的時(shí)候它會(huì)自動(dòng)刪掉它的內(nèi)容。

11.權(quán)衡渲染方法

在iOS中可以有很多方法做出漂亮的按鈕秒咨。你可以用整幅的圖片喇辽，可調(diào)大小的圖片，uozhe可以用CALayer雨席， CoreGraphics甚至OpenGL來(lái)畫(huà)它們菩咨。

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

簡(jiǎn)單來(lái)說(shuō)，就是用事先渲染好的圖片更快一些抽米，因?yàn)槿绱艘粊?lái)iOS就免去了創(chuàng)建一個(gè)圖片再畫(huà)東西上去然后顯示在屏幕上的程序特占。問(wèn)題是你需要把所有你需

要用到的圖片放到app的bundle里面，這樣就增加了體積–這就是使用可變大小的圖片更好的地方了:你可以省去一些不必要的空間云茸，也不需要再為不同的

元素(比如按鈕)來(lái)做不同的圖是目。

然而，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動(dòng)性标捺，你需要一遍又一遍不斷地重做他們懊纳，這樣就很浪費(fèi)時(shí)間了，而且你如果要做一個(gè)動(dòng)畫(huà)效果宜岛，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大长踊。

總得來(lái)說(shuō)，你需要權(quán)衡一下利弊萍倡，到底是要性能能還是要bundle保持合適的大小身弊。

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

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

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

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

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

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

· 注冊(cè)并接收 UIApplicationDidReceiveMemoryWarningNotification的通知

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

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

這樣對(duì)內(nèi)存警報(bào)的處理是很必要的秧耗，若不重視备籽，你的app就可能被系統(tǒng)殺掉。

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

13.重用大開(kāi)銷(xiāo)對(duì)象

一些objects的初始化很慢尺锚，比如NSDateFormatter和NSCalendar珠闰。然而，你又不可避免地需要使用它們瘫辩，比如從JSON或者XML中解析數(shù)據(jù)铸磅。

想要避免使用這個(gè)對(duì)象的瓶頸你就需要重用他們赡矢，可以通過(guò)添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來(lái)實(shí)現(xiàn)。

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

下面的代碼說(shuō)明了使用一個(gè)屬性來(lái)延遲加載一個(gè)date formatter. 第一次調(diào)用時(shí)它會(huì)創(chuàng)建一個(gè)新的實(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è)置一個(gè)NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的！所以如果你的app需要經(jīng)常進(jìn)行日期格式處理的話(huà)羞迷，你會(huì)從這個(gè)方法中得到不小的性能提升界轩。

14. 使用Sprite Sheets

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

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

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

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

類(lèi)似的，如果需要從特定key中取數(shù)據(jù)薇宠，那么就使用鍵值對(duì)的dictionary偷办。

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

從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案，最常見(jiàn)的就是JSON和XML澄港。你需要選擇對(duì)你的app來(lái)說(shuō)最合適的一個(gè)椒涯。

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

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

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

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

使用UIColor的 colorWithPatternImage來(lái)設(shè)置背景色髓涯；

在view中添加一個(gè)UIImageView作為一個(gè)子View。

如果你使用全畫(huà)幅的背景圖哈扮，你就必須使用UIImageView因?yàn)閁IColor的colorWithPatternImage是用來(lái)創(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];

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

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

18. 減少使用Web特性

UIWebView很有用包各，用它來(lái)展示網(wǎng)頁(yè)內(nèi)容或者創(chuàng)建UIKit很難做到的動(dòng)畫(huà)效果是很簡(jiǎn)單的一件事。

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

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

另外，盡可能異步加載例如用戶(hù)行為統(tǒng)計(jì)script這種不影響頁(yè)面表達(dá)的javascript卵皂。

最后秩铆，永遠(yuǎn)要注意你使用的圖片，保證圖片的符合你使用的大小灯变。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存殴玛。

19. 設(shè)定Shadow Path

如何在一個(gè)View或者一個(gè)layer上加一個(gè)shadow呢，QuartzCore框架是很多開(kāi)發(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;

看起來(lái)很簡(jiǎn)單添祸，對(duì)吧滚粟。可是刃泌，壞消息是使用這個(gè)方法也有它的問(wèn)題… Core Animation不得不先在后臺(tái)得出你的圖形并加好陰影然后才渲染凡壤，這開(kāi)銷(xiāo)是很大的。

使用shadowPath的話(huà)就避免了這個(gè)問(wèn)題：

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

使用shadow path的話(huà)iOS就不必每次都計(jì)算如何渲染蔬咬，它使用一個(gè)預(yù)先計(jì)算好的路徑鲤遥。但問(wèn)題是自己計(jì)算path的話(huà)可能在某些View中比較困難，且每當(dāng)view的frame變化的時(shí)候你都需要去update shadow path.

20. 優(yōu)化Table View

Table view需要有很好的滾動(dòng)性能林艘，不然用戶(hù)會(huì)在滾動(dòng)過(guò)程中發(fā)現(xiàn)動(dòng)畫(huà)的瑕疵盖奈。

為了保證table view平滑滾動(dòng)，確保你采取了以下的措施:

· 正確使用`reuseIdentifier`來(lái)重用cells

· 盡量使所有的view opaque狐援，包括cell自身

· 避免漸變钢坦，圖片縮放，后臺(tái)選人

· 緩存行高

· 如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web啥酱，使用異步加載爹凹，緩存請(qǐng)求結(jié)果

· 使用`shadowPath`來(lái)畫(huà)陰影

· 減少subviews的數(shù)量

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

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

· 使用`rowHeight`, `sectionFooterHeight`和 `sectionHeaderHeight`來(lái)設(shè)定固定的高禾酱，不要請(qǐng)求delegate

21.選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)

當(dāng)存儲(chǔ)大塊數(shù)據(jù)時(shí)你會(huì)怎么做？

你有很多選擇绘趋，比如：

· 使用`NSUerDefaults`

· 使用XML, JSON, 或者 plist

· 使用NSCoding存檔

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

· 使用 Core Data

NSUserDefaults的問(wèn)題是什么颤陶？雖然它很nice也很便捷，但是它只適用于小數(shù)據(jù)陷遮，比如一些簡(jiǎn)單的布爾型的設(shè)置選項(xiàng)滓走，再大點(diǎn)你就要考慮其它方式了

XML這種結(jié)構(gòu)化檔案呢？總體來(lái)說(shuō)帽馋，你需要讀取整個(gè)文件到內(nèi)存里去解析搅方，這樣是很不經(jīng)濟(jì)的比吭。使用SAX又是一個(gè)很麻煩的事情。

NSCoding姨涡？不幸的是衩藤，它也需要讀寫(xiě)文件，所以也有以上問(wèn)題绣溜。

在這種應(yīng)用場(chǎng)景下慷彤，使用SQLite 或者 Core Data比較好。使用這些技術(shù)你用特定的查詢(xún)語(yǔ)句就能只加載你需要的對(duì)象怖喻。

在性能層面來(lái)講底哗，SQLite和Core Data是很相似的。他們的不同在于具體使用方法锚沸。Core Data代表一個(gè)對(duì)象的graph

model跋选，但SQLite就是一個(gè)DBMS。Apple在一般情況下建議使用Core

Data哗蜈，但是如果你有理由不使用它前标，那么就去使用更加底層的SQLite吧。

如果你使用SQLite距潘，你可以用FMDB(https://GitHub.com/ccgus/fmdb)這個(gè)庫(kù)來(lái)簡(jiǎn)化SQLite的操作炼列，這樣你就不用花很多經(jīng)歷了解SQLite的C API了。

23. 使用Autorelease Pool

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

假如你創(chuàng)建很多臨時(shí)對(duì)象洞翩，你會(huì)發(fā)現(xiàn)內(nèi)存一直在減少直到這些對(duì)象被release的時(shí)候稽犁。這是因?yàn)橹挥挟?dāng)UIKit用光了autorelease

pool的時(shí)候memory才會(huì)被釋放。好消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時(shí)的對(duì)象來(lái)避免這個(gè)行為：

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對(duì)象

24. 選擇是否緩存圖片

常見(jiàn)的從bundle中加載圖片的方式有兩種骚亿，一個(gè)是用`imageNamed`已亥，二是用`imageWithContentsOfFile`，第一種比較常見(jiàn)一點(diǎn)来屠。

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

`imageNamed`的優(yōu)點(diǎn)是當(dāng)加載時(shí)會(huì)緩存圖片俱笛。`imageNamed`的文檔中這么說(shuō):這個(gè)方法用一個(gè)指定的名字在系統(tǒng)緩存中查找并返回一個(gè)圖片對(duì)象如果它存在的話(huà)捆姜。如果緩存中沒(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)單重寫(xiě)一下就可以拿來(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就好了旭等。