一、啟動優(yōu)化

1、冷啟動（從零開始的啟動）

冷啟動可以分為三個階段

1.1 Main函數(shù)執(zhí)行前

• 加載可執(zhí)行文件（mach-o文件）
• 加載動態(tài)鏈接庫，進(jìn)行rebase指針調(diào)整和bind符號綁定
• Objc運(yùn)行時的初始化處理，包括Objc相關(guān)類的注冊、category注冊、selector唯一性檢查
• 初始化，包括執(zhí)行了+load()方法、attribute((constructor))修飾的函數(shù)調(diào)用、創(chuàng)建C++靜態(tài)全局變量

優(yōu)化方案

• 減少動態(tài)庫加載。每個庫本身都有依賴關(guān)系，蘋果公司建議使用更少的動態(tài)庫，并且建議在使用動態(tài)庫的數(shù)量較多時，盡量將多個動態(tài)庫進(jìn)行合并。數(shù)量上，蘋果公司建議最多使用 6 個非系統(tǒng)動態(tài)庫。
• 減少加載啟動后不會去使用的類或者方法
• +load() 方法里的內(nèi)容可以放到首屏渲染完成后再執(zhí)行，或使用 +initialize() 方法替換掉。 因為，在一個+load() 方法里，進(jìn)行運(yùn)行時方法替換操作會帶來 4 毫秒的消耗。不要小看這 4 毫秒，積少成多，執(zhí)行 +load() 方法對啟動速度的影響會越來越大
• 控制 C++ 全局變量的數(shù)量

1.2 Main函數(shù)執(zhí)行后

主要是指main()函數(shù)執(zhí)行開始，到Appdelegate的didFinishLaunchingWithOptions方法里首屏渲染相關(guān)方法的執(zhí)行

• 首屏初始化所需要配置文件的讀寫操作
• 首屏列表大數(shù)據(jù)的讀取
• 首屏渲染的大量計算

優(yōu)化方案

從功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是 App 啟動必要的初始化功能，而哪些是只需要在對應(yīng)功能開始使用時才需要初始化的。梳理完之后，將這些初始化功能分別放到合適的階段進(jìn)行。

1.3 首屏渲染完成

從渲染完成時開始，到 didFinishLaunchingWithOptions 方法作用域結(jié)束時結(jié)束

優(yōu)化方案

• 功能級別優(yōu)化
  main() 函數(shù)開始執(zhí)行后到首屏渲染完成前只處理首屏相關(guān)的業(yè)務(wù)，其他非首屏業(yè)務(wù)的初始化、監(jiān)聽注冊、配置文件讀取等都放到首屏渲染完成后去做
• 方法級別去優(yōu)化
  我們需要進(jìn)一步做的，是檢查首屏渲染完成前主線程上有哪些耗時方法，將沒必要的耗時方法滯后或者異步執(zhí)行。通常情況下，耗時較長的方法主要發(fā)生在計算大量數(shù)據(jù)的情況下，具體的表現(xiàn)就是加載、編輯、存儲圖片和文件等資源

2、熱啟動

• App在內(nèi)存中，在后臺存活著，再次點(diǎn)擊圖標(biāo)進(jìn)入App

3、APP啟動的監(jiān)控手段

• 1、定時抓取主線程上的方法調(diào)用堆棧，計算一段時間里各個方法的耗時
• 2、對 objc_msgSend 方法進(jìn)行 hook 來掌握所有方法的執(zhí)行耗時。

二、卡頓問題

2.1 CPU和GPU

CUP(Central processing Unit,中央處理器)

• 對象的創(chuàng)建和銷毀、對象屬性的調(diào)整、布局計算、文本的計算和排版、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制(Core Graphics)

GPU (Graphics Processing Unit，圖形處理器)

• 紋理的渲染

可以優(yōu)化的點(diǎn)

1. 盡可能減少CPU、GPU資源消耗
2. 盡量用輕量級的對象，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView
3. 不要頻繁地調(diào)用UIView的相關(guān)屬性，比如frame、bounds、transform等屬性，盡量減少不必要的修改
4. 盡量提前計算好布局，在有需要時一次性調(diào)整對應(yīng)的屬性，不要多次修改屬性
5. Autolayout會比直接設(shè)置frame消耗更多的CPU資源
6. 圖片的size最好剛好跟UIImageView的size保持一致
7. 控制一下線程的最大并發(fā)數(shù)量
8. 盡量避免短時間內(nèi)大量圖片的顯示，盡可能將多張圖片合成一張進(jìn)行顯示
9. GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會占用CPU資源進(jìn)行處理，所以紋理盡量不要超過這個尺寸
10. 盡量減少視圖數(shù)量和層次
11. 減少透明的視圖(alpha<1)，不透明的就設(shè)置opaque為YES
12. 盡量把耗時的操作放到子線程（文本尺寸、圖片處理）

2.2 離屏渲染（盡量避免出現(xiàn)離屏渲染）

• 在OpenGL中，GPU有2種渲染方式

1. On-Screen Rendering:當(dāng)前屏幕渲染，在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作
2. Off-Screen Rendering:離屏渲染，在當(dāng)前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進(jìn)行渲染操作

2.3 離屏渲染消耗性能的原因

• 1、需要創(chuàng)建新的緩沖區(qū)
• 2、離屏渲染的整個過程，需要多次切換上下文環(huán)境，先是從當(dāng)前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕

2.4 哪些操作會觸發(fā)離屏渲染?

• 光柵化，layer.shouldRasterize = YES
• 遮罩，layer.mask
• 圓角，同時設(shè)置layer.masksToBounds = YES、layer.cornerRadius大于0（考慮通過CoreGraphics繪制裁剪圓角，或者叫UI提供圓角圖片）
• 陰影，layer.shadowXXX (如果設(shè)置了layer.shadowPath就不會產(chǎn)生離屏渲染)

三、耗電優(yōu)化

• 1、盡可能降低CPU、GPU功耗
• 2、少用定時器
• 3、優(yōu)化I/O操作
• 4、盡量不要頻繁寫入小數(shù)據(jù)，最好批量一次性寫入
• 5、讀寫大量重要數(shù)據(jù)時，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API。用dispatch_io系統(tǒng)會優(yōu)化磁盤訪問
• 6、數(shù)據(jù)量比較大的，建議使用數(shù)據(jù)庫(比如SQLite、CoreData)

四、網(wǎng)絡(luò)優(yōu)化

• 1、減少、壓縮網(wǎng)絡(luò)數(shù)據(jù)
• 2、如果多次請求的結(jié)果是相同的，盡量使用緩存
• 3、使用斷點(diǎn)續(xù)傳，否則網(wǎng)絡(luò)不穩(wěn)定時可能多次傳輸相同的內(nèi)容
• 4、網(wǎng)絡(luò)不可用時，不要嘗試執(zhí)行網(wǎng)絡(luò)請求
• 5、讓用戶可以取消長時間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作，設(shè)置合適的超時時間
• 6、批量傳輸，比如，下載視頻流時，不要傳輸很小的數(shù)據(jù)包，直接下載整個文件或者一大塊一大塊地下載。如果下載廣告，一 次性多下載一些，然后再慢慢展示。如果下載電子郵件，一次下載多封，不要一封一封地下載

五、定位優(yōu)化

• 1、如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法。定位完成后，會自動讓定位硬件斷電
• 2、如果不是導(dǎo)航應(yīng)用，盡量不要實時更新位置，定位完畢就關(guān)掉定位服務(wù)
• 3、盡量降低定位精度，比如盡量不要使用精度最高的kCLLocationAccuracyBest
• 4、需要后臺定位時，盡量設(shè)置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
• 5、盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:
• 6、用戶移動、搖晃、傾斜設(shè)備時，會產(chǎn)生動作(motion)事件，這些事件由加速度計、陀螺儀、磁力計等硬件檢測。在不需要檢測的場合，應(yīng)該及時關(guān)閉這些硬件