iOS最全性能優(yōu)化(上)

泡泡糖813 2016-03-14

展開全文

導讀

性能對 iOS 應用的開發(fā)尤其重要,，如果你的應用失去反應或者很慢,，失望的用戶會把他們的失望寫滿App Store的評論。然而由于iOS設備的限制,，有時搞好性能是一件難事,。開發(fā)過程中你會有很多需要注意的事項，你也很容易在做出選擇時忘記考慮性能影響,。

請耐心讀完這篇文章,，為你未來的app提個速！

9. 重用和延遲加載Views
10. Cache, Cache, 還是Cache,！
11. 權衡渲染方法
12. 處理內(nèi)存警告
13. 重用大開銷的對象
14. 使用Sprite Sheets
15. 避免反復處理數(shù)據(jù)
16. 選擇正確的數(shù)據(jù)格式
17. 正確地設定Background Images
18. 減少使用Web特性
19. 設定Shadow Path
20. 優(yōu)化你的Table View
21. 選擇正確的數(shù)據(jù)存儲選項

進階級（這些建議只應該在你確信他們可以解決問題和得心應手的情況下采用）

22. 加速啟動時間
23. 使用Autorelease Pool
24. 選擇是否緩存圖片
25. 盡量避免日期格式轉換

無需贅述，讓我們進入正題吧~

初學者性能提升
這個部分致力于一些能提高性能的基本改變。但所有層次的開發(fā)者都有可能會從這個記錄了一些被忽視的項目的小小的性能備忘錄里獲得一些提升,。

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

ARC(Automatic Reference Counting, 自動引用計數(shù))和iOS5一起發(fā)布,，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露。它自動為你管理retain和release的過程,，所以你就不必去手動干預了,。
下面是你會經(jīng)常用來去創(chuàng)建一個View的代碼段:
```
  UIView *view = [[UIView alloc] init];
   // ...
  [self.view addSubview:view];
   [view release];
```
忘掉代碼段結尾的release簡直像記得吃飯一樣簡單。而ARC會自動在底層為你做這些工作,。除了幫你避免內(nèi)存泄露,，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對象的內(nèi)存,。這都啥年代了,，你應該在你的所有項目里使用ARC!

2.在正確的地方使用 reuseIdentifier

一個開發(fā)中常見的錯誤就是沒有給UITableViewCells， UICollectionViewCells,，甚至是UITableViewHeaderFooterViews設置正確的reuseIdentifier,。
為了性能最優(yōu)化，table view用 tableView:cellForRowAtIndexPath: 為rows分配cells的時候,，它的數(shù)據(jù)應該重用自UITableViewCell,。一個table view維持一個隊列的數(shù)據(jù)可重用的UITableViewCell對象。不使用reuseIdentifier的話,，每顯示一行table view就不得不設置全新的cell,。這對性能的影響可是相當大的，尤其會使app的滾動體驗大打折扣,。

自iOS6起,，除了UICollectionView的cells和補充views，你也應該在header和footer views中使用reuseIdentifiers

3.盡量把views設置為不透明

如果你有透明的Views你應該設置它們的opaque(不透明)屬性為YES,。例如一個黑色半透明的可以設置為一個灰色不透明的View替代.原因是這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views,。這個簡單的屬性在IB或者代碼里都可以設定。
Apple的文檔對于為圖片設置透明屬性的描述是：
(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示,。如果設為YES,，渲染系統(tǒng)就認為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能,。如果設置為NO,，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View。默認值是YES,。
在相對比較靜止的畫面中,，設置這個屬性不會有太大影響。然而當這個view嵌在scroll view里邊,，或者是一個復雜動畫的一部分,，不設置這個屬性的話會在很大程度上影響app的性能,。

4. 避免過于龐大的XIB

iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場景中仍然很有用,。比如你的app需要適應iOS5之前的設備,，或者你有一個自定義的可重用的view,你就不可避免地要用到他們。
如果你不得不XIB的話,，使他們盡量簡單,。嘗試為每個Controller配置一個單獨的XIB，盡可能把一個View Controller的view層次結構分散到單獨的XIB中去,。
需要注意的是,，當你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里，包括任何圖片,。如果有一個不會即刻用到的view,，你這就是在浪費寶貴的內(nèi)存資源了。Storyboards就是另一碼事兒了,，storyboard僅在需要時實例化一個view controller.
當你加載一個引用了圖片或者聲音資源的nib時,，nib加載代碼會把圖片和聲音文件寫進內(nèi)存。在OS X中,，圖片和聲音資源被緩存在named cache中以便將來用到時獲取,。在iOS中，僅圖片資源會被存進named caches,。取決于你所在的平臺，使用NSImage 或UIImage 的imageNamed:方法來獲取圖片資源,。

5. 不要阻塞主線程

永遠不要使主線程承擔過多。因為UIKit在主線程上做所有工作,，渲染,，管理觸摸反應，回應輸入等都需要在它上面完成,。一直使用主線程的風險就是如果你的代碼真的block了主線程,，你的app會失去反應
大部分阻礙主進程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作，比如存儲或者網(wǎng)絡,?；蛘呤褂孟?AFNetworking這樣的框架來異步地做這些操作。
如果你需要做其它類型的需要耗費巨大資源的操作(比如時間敏感的計算或者存儲讀寫)那就用 Grand Central Dispatch,，或者 NSOperation 和 NSOperationQueues.
你可以使用NSURLConnection異步地做網(wǎng)絡操作:
```
    (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
```

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

如果要在UIImageView中顯示一個來自bundle的圖片,，你應保證圖片的大小和UIImageView的大小相同。在運行中縮放圖片是很耗費資源的,，特別是UIImageView嵌套在UIScrollView中的情況下,。
如果圖片是從遠端服務加載的你不能控制圖片大小,，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后,，最好是用background thread,，縮放一次，然后在UIImageView中使用縮放后的圖片,。

7. 選擇正確的Collection

學會選擇對業(yè)務場景最合適的類或者對象是寫出能效高的代碼的基礎,。當處理collections時這句話尤其正確。

Apple有一個 Collections Programming Topics 的文檔詳盡介紹了可用的classes間的差別和你該在哪些場景中使用它們,。這對于任何使用collections的人來說是一個必讀的文檔,。
呵呵，我就知道你因為太長沒看…這是一些常見collection的總結：

Arrays: 有序的一組值,。使用index來lookup很快,，使用value lookup很慢，插入/刪除很慢,。
Dictionaries: 存儲鍵值對,。用鍵來查找比較快。
Sets: 無序的一組值,。用值來查找很快,，插入/刪除很快。

8. 打開gzip壓縮

大量app依賴于遠端資源和第三方API,，你可能會開發(fā)一個需要從遠端下載XML, JSON, HTML或者其它格式的app,。
問題是我們的目標是移動設備，因此你就不能指望網(wǎng)絡狀況有多好,。一個用戶現(xiàn)在還在edge網(wǎng)絡,，下一分鐘可能就切換到了3G。不論什么場景,，你肯定不想讓你的用戶等太長時間,。
減小文檔的一個方式就是在服務端和你的app中打開gzip。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會有更顯著的效用,。好消息是,，iOS已經(jīng)在NSURLConnection中默認支持了gzip壓縮，當然AFNetworking這些基于它的框架亦然,。像Google App Engine這些云服務提供者也已經(jīng)支持了壓縮輸出,。