App瘦身

資源瘦身

• 使用tinypng壓縮PNG圖片。視訊可以通過 Final cut等軟體進行解析度壓縮。音訊則降低位元速率即可。
• 非必須資原始檔可以放到自己伺服器上
• 啟動圖使用 LaunchScreen.storyboard，啟動圖在一個專案資源中佔比其實蠻大的，但是使用 LaunchScreen.storyboard 只需要設定一張ImageView即可。
• IconFont的使用很方便，專案中圖示太多或者隨時需要轉換圖示顏色的話，建議使用

放棄使用 Realm

Realm，據說是目前是效能最好的移動端資料庫。但是在三方庫中可以看到，Realm 的支援佔了很大的比重，大約在 8M 左右。但是如果使用 FMDB

刪除重複程式碼

重複程式碼的稽核、無用的開源庫刪除

效能優化

imageWithContentsOfFile 、 Assets.xcassets

• 對於大的圖片且偶爾需要顯示的應放到工程目錄下，不要放到Assets.xcassets中；並使用imageWithContentsOfFile載入不讓系統快取
• 對於經常需要展示的小圖片放到Assets.xcassets中讓系統快取，使用imageNamed載入

儘量使用非逃逸閉包

非逃逸閉包是有利於記憶體優化的，所以儘量使用非逃逸閉包

NSSet、NSArray

NSSet（用hash實現）和NSArray功能性質一樣，用於儲存物件，屬於集合。但是和NSArray不一樣的是它屬於 “無序集合”，在記憶體中儲存方式是不連續的，而NSArray是“有序集合”它記憶體中儲存位置是連續的。 所以在集合中尋找一個元素的時候使用NSSet，而如果需要迴圈集合中的所有物件來找到所需要的目標則使用NSArray

頁面卡頓

螢幕顯示影象的原理

• CPU（中央處理器）

物件的建立和銷燬，物件屬性的調整、佈局計算、文字的計算和排版、圖片格式轉碼和解碼、影象的繪製（Core Graphics）

• GPU（圖形處理器）

紋理的渲染（OpenGL）

• FrameBuffer（幀快取）

• 1、CPU計算控制元件的位置、大小
• 2、計算完成後CPU會將這些資料提交給GPU來進行渲染
• 3、GPU將收到的資料轉成螢幕能顯示的資料格式，快取到在FrameBuffer
• 4、然後視訊控制器從FrameBuffer讀取的資料顯示在顯示器上

卡頓產生的原因和解決方案

由於垂直同步的機制，如果在一個 VSync 時間內，CPU 或者 GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留之前的內容不變。這就是介面卡頓的原因。

從上面的圖中可以看到，CPU 和 GPU 不論哪個阻礙了顯示流程，都會造成掉幀現象。所以開發時，也需要分別對 CPU 和 GPU 壓力進行評估和優化。

卡頓優化-CPU

• 1、儘量用輕量級的物件，比如用不到事件處理的地方，可以考慮使用CAlayer取代UIView
• 2、不要頻繁地跳用UIVIew的相關屬性，比如frame、bounds、transform等屬性，儘量減少不必要的修改
• 3、儘量提前計算好佈局，在有需要時一次性調整對應的佈局，不要多次修改屬性
• 4、Autolayout會比直接設定frame消耗更多的CPU資源
• 5、圖片的size最好剛好跟UIImageView的size保持一致
• 6、控制一下執行緒的最大併發數量
• 7、儘量把耗時的操作放到子執行緒
• 8、文字處理（尺寸的計算，繪製）
• 9、圖片處理（解碼、繪製）

卡頓優化-GPU

• 1、儘量減少檢視數量和層次
• 2、GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會佔用CPU資源進行處理，所以紋理儘量不要超過這個尺寸
• 3、儘量避免短時間內大量圖片的顯示，儘可能將多張圖片合成一張圖片顯示
• 4、減少透明的檢視（alpha<1），不透明的就設定opaque為yes
• 5、儘量避免出現離屏渲染

離屏渲染

指的是在GPU在當前螢幕緩衝區以外開闢一個緩衝區進行渲染操作

導致產生離屏渲染的原因：

• shouldRasterize（光柵化）
• masks（遮罩）
• shadows（陰影）
• edge antialiasing（抗鋸齒）
• group opacity（不透明）
• 複雜形狀設定圓角等
• 漸變

可通過 Instruments 的 Core Animation 檢測離屏渲染。

TableView 調優

• 提前計算好cell的高度,快取在相應的資料來源模型中，減少CPU的計算時間
• 儘可能的降低Storyboard、Xib等使用度
• 非同步繪製
• 減少層級
• Cell中的view儘可能不要使用透明
• 避免離屏渲染