導(dǎo)讀
性能對(duì) iOS 應(yīng)用的開發(fā)尤其重要，如果你的應(yīng)用失去反應(yīng)或者很慢恩急，失望的用戶會(huì)把他們的失望寫滿App Store的評(píng)論盛垦。然而由于iOS設(shè)備的限制，有時(shí)搞好性能是一件難事裁良。開發(fā)過程中你會(huì)有很多需要注意的事項(xiàng)凿将，你也很容易在做出選擇時(shí)忘記考慮性能影響。
iOS最全性能優(yōu)化(上)http://www.reibang.com/p/9c450e512020
iOS最全性能優(yōu)化(中)http://www.reibang.com/p/ad90e90dce4f
iOS最全性能優(yōu)化(下)http://www.reibang.com/p/25e2f1ae51d2
請(qǐng)耐心讀完這篇文章价脾，為你未來的app提個(gè)速牧抵！
目錄
我要給出的建議將分為三個(gè)不同的等級(jí)： 入門級(jí)、 中級(jí)和進(jìn)階級(jí)：
-
入門級(jí)（這是些你一定會(huì)經(jīng)常用在你app開發(fā)中的建議）
1. 用ARC管理內(nèi)存
2. 在正確的地方使用reuseIdentifier
3. 盡可能使Views透明
4. 避免龐大的XIB
5. 不要block主線程
6. 在Image Views中調(diào)整圖片大小
7. 選擇正確的Collection
8. 打開gzip壓縮
-
中級(jí)（這些是你可能在一些相對(duì)復(fù)雜情況下可能用到的）
9. 重用和延遲加載Views
10. Cache, Cache, 還是Cache！
11. 權(quán)衡渲染方法
12. 處理內(nèi)存警告
13. 重用大開銷的對(duì)象
14. 使用Sprite Sheets
15. 避免反復(fù)處理數(shù)據(jù)
16. 選擇正確的數(shù)據(jù)格式
17. 正確地設(shè)定Background Images
18. 減少使用Web特性
19. 設(shè)定Shadow Path
20. 優(yōu)化你的Table View
21. 選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)
-
進(jìn)階級(jí)（這些建議只應(yīng)該在你確信他們可以解決問題和得心應(yīng)手的情況下采用）
22. 加速啟動(dòng)時(shí)間 23. 使用Autorelease Pool 24. 選擇是否緩存圖片 25. 盡量避免日期格式轉(zhuǎn)換
無需贅述犀变，讓我們進(jìn)入正題吧~
初學(xué)者性能提升
這個(gè)部分致力于一些能提高性能的基本改變妹孙。但所有層次的開發(fā)者都有可能會(huì)從這個(gè)記錄了一些被忽視的項(xiàng)目的小小的性能備忘錄里獲得一些提升。
1.用ARC管理內(nèi)存
-
ARC(Automatic Reference Counting, 自動(dòng)引用計(jì)數(shù))和iOS5一起發(fā)布获枝，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露蠢正。它自動(dòng)為你管理retain和release的過程，所以你就不必去手動(dòng)干預(yù)了省店。
下面是你會(huì)經(jīng)常用來去創(chuàng)建一個(gè)View的代碼段:UIView *view = [[UIView alloc] init]; // ... [self.view addSubview:view]; [view release]; 忘掉代碼段結(jié)尾的release簡(jiǎn)直像記得吃飯一樣簡(jiǎn)單嚣崭。而ARC會(huì)自動(dòng)在底層為你做這些工作。除了幫你避免內(nèi)存泄露懦傍，ARC還可以幫你提高性能雹舀，它能保證釋放掉不再需要的對(duì)象的內(nèi)存。這都啥年代了粗俱，你應(yīng)該在你的所有項(xiàng)目里使用ARC!
2.在正確的地方使用 reuseIdentifier
- 一個(gè)開發(fā)中常見的錯(cuò)誤就是沒有給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
3.盡量把views設(shè)置為完全不透明
如果你有透明的Views你應(yīng)該設(shè)置它們的opaque(不透明)屬性為YES。例如一個(gè)黑色半透明的可以設(shè)置為一個(gè)灰色不透明的View替代.原因是這會(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)化一些渲染過程和提高性能。如果設(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的性能几于。
-
換種說法蕊苗，大家可能更好理解：
只要一個(gè)視圖的不透明度小于1,就會(huì)導(dǎo)致blending.blending操作在iOS的圖形處理器（GPU）中完成的,blending主要指的是混合像素顏色的計(jì)算。舉個(gè)例子,我們把兩個(gè)圖層疊加在一起,如果第一個(gè)圖層的有透明效果,則最終像素的顏色計(jì)算需要將第二個(gè)圖層也考慮進(jìn)來孩革。這一過程即為Blending。
為什么Blending會(huì)導(dǎo)致性能的損失得运？
原因是很直觀的,如果一個(gè)圖層是完全不透明的,則系統(tǒng)直接顯示該圖層的顏色即可膝蜈。而如果圖層是帶透明效果的,則會(huì)引入更多的計(jì)算,因?yàn)樾枰严旅娴膱D層也包括進(jìn)來,進(jìn)行混合后顏色的計(jì)算。
4. 避免過于龐大的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)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)，nib加載代碼會(huì)把圖片和聲音文件寫進(jìn)內(nèi)存他挎。在OS X中筝尾，圖片和聲音資源被緩存在named cache中以便將來用到時(shí)獲取。在iOS中办桨，僅圖片資源會(huì)被存進(jìn)named caches筹淫。取決于你所在的平臺(tái)，使用NSImage 或UIImage 的
imageNamed:方法來獲取圖片資源呢撞。
5. 不要阻塞主線程
永遠(yuǎn)不要使主線程承擔(dān)過多贸街。因?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ò)。或者使用像 AFNetworking這樣的框架來異步地做這些操作娇跟。
如果你需要做其它類型的需要耗費(fèi)巨大資源的操作(比如時(shí)間敏感的計(jì)算或者存儲(chǔ)讀寫)那就用 Grand Central Dispatch岩齿，或者 NSOperation 和 NSOperationQueues.
你可以使用NSURLConnection異步地做網(wǎng)絡(luò)操作:+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
6. 在Image Views中調(diào)整圖片大小
- 如果要在
UIImageView中顯示一個(gè)來自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í)這句話尤其正確关串。
Apple有一個(gè) Collections Programming Topics 的文檔詳盡介紹了可用的classes間的差別和你該在哪些場(chǎng)景中使用它們。這對(duì)于任何使用collections的人來說是一個(gè)必讀的文檔监徘。
呵呵晋修，我就知道你因?yàn)樘L(zhǎng)沒看…這是一些常見collection的總結(jié)：
- Arrays: 有序的一組值。使用index來lookup很快凰盔，使用value lookup很慢飞蚓， 插入/刪除很慢。
- Dictionaries: 存儲(chǔ)鍵值對(duì)廊蜒。 用鍵來查找比較快趴拧。
- Sets: 無序的一組值。用值來查找很快山叮，插入/刪除很快著榴。
8. 打開gzip壓縮
- 大量app依賴于遠(yuǎn)端資源和第三方API，你可能會(huì)開發(fā)一個(gè)需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app屁倔。
- 問題是我們的目標(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ù)來說會(huì)有更顯著的效用。好消息是布轿，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮哮笆，當(dāng)然AFNetworking這些基于它的框架亦然来颤。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出。
