iOS 性能優化套路

***

 一級套路

***

 使用ARC管理內存
- 防止內存泄露
- 保證釋放掉再也不須要的內存，提升性能

在正確的地方使用 reuseIdentifier
平時接觸的須要考慮重用的視圖有UICollectionView,UITableView。須要考慮它們內部的cell,header,footer。
CollectionView和TableView原理類似，內部存在着兩個容器對象，分別是：
- 當前展現視圖容器，裏面是當前展現的cell,footer,header
- 可重用視圖容器，裏面是帶有重用標識符的cell,footer,header

儘可能把View設置爲徹底不透明
須要將View屬性opaque設置成YES
當opaque設置成NO時，app在進行圖片展現時，會讓圖片處理器（GPU）進行圖像混合計算（blending操做）。
圖片處理器會將透明View的像素與它相臨的像素點相加，從新計算出一個新的像素值。若是app帶有動畫，滾動效果，性能會受到明顯的影響。

避免過於龐大的XIB
XIB是推出比較早的繪圖工具，後面在iOS5的時候推出了StoryBoard來取代XIB的地位。不過到目前它們兩個是共存的狀態，緣由是它們的適用場景不一樣。
- XIB使用子View控件的定製，偏小型。可是在使用時會將整個XiB都加載到內存，若是XIB過大的話，會致使內存浪費。
- StoryBoard是偏重宏觀的，通常作控制器跳轉，能夠定義整個控制器視圖。在使用時，StoryBoard是用到哪一個控制器加載哪一個，不會將全部的都加載。

嚴格要求對主線程的使用
主線程是用戶對app的直接體驗，全部的交互都是靠主線程接受和反饋的。終於程度可見一斑。因此須要把++耗時的操做都移動到子線程++去，等有告終果再切換回主線程來。

避免在Image Views中調整圖片大小
若是給予==UIImageView==的image的尺寸不合適，那麼==UIImageView==就須要對image進行自動縮放，這個縮放操做是比較耗費資源的。對於從網絡加載後須要滾動的，動畫的==UIImageView==影響更大。因此image和==UIImageView==的尺寸儘可能匹配。匹配方式：

- 要求切圖尺寸符合要求
- 將得到的圖片在本地縮放規定的尺寸後，再返回給==UIImageView==

根據業務場景選擇合適的集合（不一樣的數據結構）
- 數組（增刪慢；改查快）：有序集合，存儲在一段連續的內存空間，可方便利用下標查看，增長刪除都會讓後序元素總體移動
- Set(增刪改查快) ：無序集合，添加劇復的對象會自動覆蓋掉前面的，作到整個集合只有一份
- 字典（增刪改查快）：健值集合，可根據key對應操做value

合理使用gzip
在網絡請求時，若數據比較大，可考慮採用壓縮格式，提升用戶體驗

***
 二級套路
***

重用view和懶加載view
- 對於重複出現的子View，考慮模仿tableview的重用機制
- 對於不必定使用的子view，考慮使用懶加載機制（懶加載是犧牲體驗提升性能）

重視緩存
緩存的種類不少，主要按狀況來進行緩存，以下所示：
- 建立麻煩而常用（好比NSDateFormatter和NSCalendar），對於這樣的對象緩存，能夠放在單例或者類屬性上。對頻繁時提供性能有大的改變。
- 請求麻煩而資源不常常改變（網絡請求），
- 頻繁計算而結果不變的（tableview的行高）

圖片渲染方式選擇
- 使用UI給的切圖，渲染快，效率高。可是bundle體積大。
- 使用CoreGraphics,UIBezir曲線進行代碼繪製，消耗性能。可是減小bundle體積

內存警告處理
系統提供了很多處理內存警告的方式，在受到內存通過時釋放一些能夠重建的對象，能夠提供app的穩定性，它們適用多種場景：
AppDelegate中的
`applicationDidReceiveMemoryWarning: `
UIViewController類中的
`didReceiveMemoryWarning`
系統提供的通知
`UIApplicationDidReceiveMemoryWarningNotification`

避免在內存中頻繁轉換數據結構
儘可能使後臺返回的數據結構與app場景使用的一致，並選擇合適的容器保存。
Array,Dictory,Set，根據數據使用的特性，進行合理選擇。

View背景設置的方案選擇
- 小圖平鋪
```
self.view.backgroundColor = [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background"]];
```

- 全圖背景

```
BuilderUIImageView*backgroundView = [[UIImageViewalloc] initWithImage:[UIImageimageNamed:@"background"]];[self.view addSubview:backgroundView];
```

選擇適當的方式爲shadowPath賦值
在開發中常常須要給View、Layer設置隱形，常見的設置方式有兩種

- 經過屬性設置

```
// Setup the shadow ...
UIView*view = [[UIViewalloc] init];
view.layer.shadowOffset=CGSizeMake(-1.0f,1.0f);
view.layer.shadowRadius =5.0f;
view.layer.shadowOpacity =0.6;
```
這種方式須要Core Animation在後臺提早根據圖像frame計算出圖像和陰影。增長了計算操做，消耗性能。

- 經過貝塞爾曲線賦值
```
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
```
因爲路徑是指定好的，無需再次計算，提升了性能。

TableView優化方案
1.reuseIdentifier規範使用，cell,header,footer。
2.view的opaque爲YES，避免色素計算
3.避免cell中圖片縮放
4.耗時任務子線程處理，避免阻塞主線程（網絡請求，數據處理）
5.減小subviews的層級
6.用貝塞爾曲線設置陰影路徑
7.儘可能避免代理賦值（tableview直接設置rowHeight, sectionFooterHeight 和 sectionHeaderHeight）
8.cell動態行高時，預先計算並存儲，提升性能

數據持久化方案
1.NSUerDefaults：至關於電腦中的偏好設置
2.plist：存儲簡單列表（城市對應的郵編列表）
3.歸檔：須要實現NSCoding協議
4.SQLite、Realm：大數據的存儲方案

***
三級套路
***

提升App啓動時間
1.異步處理耗時任務（網絡加載，數據庫訪問，批量預處理）
2.避免大規模內存加載（大致積xib加載）
3.主要看門狗問題

合理使用Autorelease Pool
對象過了做用域，引用計數會自動減一。若是在做用域中忽然大量建對象，則內存會直線降低。這中狀況下要適量加Autorelease Pool，進行及時釋放
合理使用圖片的加載方式1.小體積而重複使用的圖片，用imageNamed，此時圖片對象會保存在內存中2.大致積而不長用的圖片，用imageWithContentsOfFile，圖片每次都是從本地加載。不緩存