一 CPU和GPU

• 在屏幕成像的過程中，CPU和GPU起著至關(guān)重要的作用

• CPU（Central Processing Unit眶诈，中央處理器）
  對(duì)象的創(chuàng)建和銷毀聂宾、對(duì)象屬性的調(diào)整晴及、布局計(jì)算箫章、文本的計(jì)算和排版烙荷、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制（Core Graphics）

• GPU（Graphics Processing Unit檬寂，圖形處理器）
  紋理的渲染

下圖展示視圖如何顯示

image.png

在iOS中是雙緩沖機(jī)制奢讨，有前幀緩存、后幀緩存

二 屏幕成像原理

image.png

三 卡頓原因焰薄，解決拿诸，監(jiān)測

卡頓產(chǎn)生的原因：因?yàn)镃PU或者GPU所花費(fèi)的時(shí)間過長，導(dǎo)致垂直信號(hào)來的時(shí)候塞茅，CPU計(jì)算或者GPU渲染未完成亩码，從而掉幀。

掉幀.png

• 卡頓解決的主要思路

(1) 盡可能減少CPU野瘦、GPU資源消耗
(2) 按照60FPS的刷幀率描沟，每隔16ms就會(huì)有一次VSync信號(hào)

我們從CPU和GPU兩方面入手進(jìn)行卡頓優(yōu)化

3.1 卡頓優(yōu)化 - CPU

• 盡量用輕量級(jí)的對(duì)象，比如用不到事件處理的地方鞭光，可以考慮使用CALayer取代UIView

• 不要頻繁地調(diào)用UIView的相關(guān)屬性吏廉，比如frame、bounds惰许、transform等屬性席覆，盡量減少不必要的修改

• 盡量提前計(jì)算好布局，在有需要時(shí)一次性調(diào)整對(duì)應(yīng)的屬性汹买，不要多次修改屬性

• Autolayout會(huì)比直接設(shè)置frame消耗更多的CPU資源

• 圖片的size最好剛好跟UIImageView的size保持一致

• 控制一下線程的最大并發(fā)數(shù)量

• 盡量把耗時(shí)的操作放到子線程

  • 文本處理（尺寸計(jì)算佩伤、繪制）
  • 圖片處理（解碼、繪制）

3.2 卡頓優(yōu)化 - GPU

• 盡量避免短時(shí)間內(nèi)大量圖片的顯示晦毙，盡可能將多張圖片合成一張進(jìn)行顯示

• GPU能處理的最大紋理尺寸是4096x4096生巡，一旦超過這個(gè)尺寸，就會(huì)占用CPU資源進(jìn)行處理见妒，所以紋理盡量不要超過這個(gè)尺寸

• 盡量減少視圖數(shù)量和層次

• 減少透明的視圖（alpha<1）孤荣，不透明的就設(shè)置opaque為YES

• 盡量避免出現(xiàn)離屏渲染

3.3 離屏渲染

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

• On-Screen Rendering：當(dāng)前屏幕渲染须揣，在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作
• Off-Screen Rendering：離屏渲染盐股，在當(dāng)前屏幕緩沖區(qū)以外新開辟一個(gè)緩沖區(qū)進(jìn)行渲染操作

2. 離屏渲染消耗性能的原因

• 需要?jiǎng)?chuàng)建新的緩沖區(qū)
• 離屏渲染的整個(gè)過程，需要多次切換上下文環(huán)境返敬，先是從當(dāng)前屏幕（On-Screen）切換到離屏（Off-Screen）遂庄；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上劲赠，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕

3. 哪些操作會(huì)觸發(fā)離屏渲染涛目？

• 光柵化，layer.shouldRasterize = YES

• 遮罩凛澎，layer.mask

• 圓角霹肝，同時(shí)設(shè)置layer.masksToBounds = YES、layer.cornerRadius大于0
  解決思路：考慮通過CoreGraphics繪制裁剪圓角塑煎，或者叫美工提供圓角圖片

• 陰影沫换，layer.shadowXXX
  解決思路：如果設(shè)置了layer.shadowPath就不會(huì)產(chǎn)生離屏渲染

4. 卡頓檢測

• 平時(shí)所說的“卡頓”主要是因?yàn)樵谥骶€程執(zhí)行了比較耗時(shí)的操作

• 可以添加Observer到主線程RunLoop中，通過監(jiān)聽RunLoop狀態(tài)切換的耗時(shí)最铁，以達(dá)到監(jiān)控卡頓的目的

項(xiàng)目連接地址 - LXDAppFluecyMonitor-master

四 耗電的主要來源

• CPU處理讯赏，Processing

• 網(wǎng)絡(luò)垮兑，Networking

• 定位，Location

• 圖像漱挎，Graphics

4.1 耗電優(yōu)化

1. 盡可能降低CPU系枪、GPU功耗

2. 少用定時(shí)器

3. 優(yōu)化I/O操作

• 盡量不要頻繁寫入小數(shù)據(jù)，最好批量一次性寫入
• 讀寫大量重要數(shù)據(jù)時(shí)磕谅，考慮用dispatch_io私爷，其提供了基于GCD的異步操作文件I/O的API。用dispatch_io系統(tǒng)會(huì)優(yōu)化磁盤訪問
• 數(shù)據(jù)量比較大的膊夹，建議使用數(shù)據(jù)庫（比如SQLite衬浑、CoreData）

4. 網(wǎng)絡(luò)優(yōu)化

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

5. 定位優(yōu)化

• 如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法褥民。定位完成后季春，會(huì)自動(dòng)讓定位硬件斷電
• 如果不是導(dǎo)航應(yīng)用，盡量不要實(shí)時(shí)更新位置消返，定位完畢就關(guān)掉定位服務(wù)
• 盡量降低定位精度载弄，比如盡量不要使用精度最高的kCLLocationAccuracyBest
• 需要后臺(tái)定位時(shí)，盡量設(shè)置pausesLocationUpdatesAutomatically為YES撵颊，如果用戶不太可能移動(dòng)的時(shí)候系統(tǒng)會(huì)自動(dòng)暫停位置更新
• 盡量不要使用startMonitoringSignificantLocationChanges宇攻，優(yōu)先考慮startMonitoringForRegion:

6. 硬件檢測優(yōu)化

• 用戶移動(dòng)、搖晃倡勇、傾斜設(shè)備時(shí)逞刷，會(huì)產(chǎn)生動(dòng)作(motion)事件，這些事件由加速度計(jì)、陀螺儀夸浅、磁力計(jì)等硬件檢測仑最。在不需要檢測的場合，應(yīng)該及時(shí)關(guān)閉這些硬件

五 APP的啟動(dòng)

1. APP的啟動(dòng)可以分為2種

• 冷啟動(dòng)（Cold Launch）：從零開始啟動(dòng)APP
• 熱啟動(dòng)（Warm Launch）：APP已經(jīng)在內(nèi)存中题篷，在后臺(tái)存活著词身，再次點(diǎn)擊圖標(biāo)啟動(dòng)APP

2. APP啟動(dòng)時(shí)間的優(yōu)化，主要是針對(duì)冷啟動(dòng)進(jìn)行優(yōu)化

3. 通過添加環(huán)境變量可以打印出APP的啟動(dòng)時(shí)間分析

• (Edit scheme -> Run -> Arguments) DYLD_PRINT_STATISTICS設(shè)置為1
• 如果需要更詳細(xì)的信息番枚，那就將DYLD_PRINT_STATISTICS_DETAILS設(shè)置為1

image.png

運(yùn)行結(jié)果

image.png

5.1 APP的啟動(dòng)

APP的冷啟動(dòng)可以概括為3大階段

• dyld
• runtime
• main

image.png

5.2 APP的啟動(dòng) - dyld

• dyld（dynamic link editor），Apple的動(dòng)態(tài)鏈接器损敷，可以用來裝載Mach-O文件（可執(zhí)行文件葫笼、動(dòng)態(tài)庫等）

• 啟動(dòng)APP時(shí)，dyld所做的事情有
  <1> 裝載APP的可執(zhí)行文件拗馒，同時(shí)會(huì)遞歸加載所有依賴的動(dòng)態(tài)庫
  <2> 當(dāng)dyld把可執(zhí)行文件路星、動(dòng)態(tài)庫都裝載完畢后，會(huì)通知Runtime進(jìn)行下一步的處理

5.3 APP的啟動(dòng) - runtime

1. 啟動(dòng)APP時(shí)诱桂，runtime所做的事情有

• 調(diào)用map_images進(jìn)行可執(zhí)行文件內(nèi)容的解析和處理
• 在load_images中調(diào)用call_load_methods洋丐，調(diào)用所有Class和Category的+load方法
• 進(jìn)行各種objc結(jié)構(gòu)的初始化（注冊(cè)O(shè)bjc類 、初始化類對(duì)象等等）
• 調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)

2. 到此為止挥等，可執(zhí)行文件和動(dòng)態(tài)庫中所有的符號(hào)(Class友绝，Protocol，Selector肝劲，IMP迁客，…)都已經(jīng)按格式成功加載到內(nèi)存中，被runtime 所管理

5.4 APP的啟動(dòng) - main

總結(jié)一下

• APP的啟動(dòng)由dyld主導(dǎo)辞槐，將可執(zhí)行文件加載到內(nèi)存掷漱，順便加載所有依賴的動(dòng)態(tài)庫
• 并由runtime負(fù)責(zé)加載成objc定義的結(jié)構(gòu)
• 所有初始化工作結(jié)束后，dyld就會(huì)調(diào)用main函數(shù)
• 接下來就是UIApplicationMain函數(shù)榄檬，AppDelegate的application:didFinishLaunchingWithOptions:方法

5.5 APP的啟動(dòng)優(yōu)化

按照不同的階段

1. dyld

• 減少動(dòng)態(tài)庫卜范、合并一些動(dòng)態(tài)庫（定期清理不必要的動(dòng)態(tài)庫）
• 減少Objc類、分類的數(shù)量鹿榜、減少Selector數(shù)量（定期清理不必要的類海雪、分類）
• 減少C++虛函數(shù)數(shù)量
• Swift盡量使用struct

2. runtime

• 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構(gòu)造器犬缨、ObjC的+load

3. main

• 在不影響用戶體驗(yàn)的前提下喳魏，盡可能將一些操作延遲，不要全部都放在finishLaunching方法中
• 按需加載

六 安裝包瘦身

1. 安裝包（IPA）主要由可執(zhí)行文件怀薛、資源組成

2. 資源（圖片刺彩、音頻、視頻等）

• 采取無損壓縮
• 去除沒有用到的資源： LSUnusedResources

3. 可執(zhí)行文件瘦身

• 編譯器優(yōu)化
• Strip Linked Product、Make Strings Read-Only创倔、Symbols Hidden by Default等參數(shù)設(shè)置為YES
• 去掉異常支持嗡害，Enable C++ Exceptions、Enable Objective-C Exceptions設(shè)置為NO畦攘， Other C Flags添加-fno-exceptions
• 利用 AppCode 檢測未使用的代碼：菜單欄 -> Code -> Inspect Code
• 編寫LLVM插件檢測出重復(fù)代碼霸妹、未被調(diào)用的代碼

七 LinkMap

• 生成LinkMap文件，可以查看可執(zhí)行文件的具體組成

image.png

• 可借助第三方工具解析LinkMap文件： LinkMap

本文參考MJ底層原理教程知押，非常感謝

• 多多點(diǎn)贊叹螟，打賞更好，您的支持是我寫作的動(dòng)力台盯。

項(xiàng)目連接地址 - PropertyOptimize_Fluecy
項(xiàng)目連接地址 - LXDAppFluecyMonitor-master