處理器優(yōu)化
CPU和GPU
-
在屏幕成像的過程中戒幔，CPU和GPU起著至關(guān)重要的作用
CPU：（Central Processing Unit，中央處理器）
負(fù)責(zé)對象的創(chuàng)建和銷毀份氧、對象屬性的調(diào)整唯袄、布局計算、文本的計算和排版蜗帜、圖片的格式轉(zhuǎn)換和解碼恋拷、圖像的繪制（Core Graphics）
GPU：（Graphics Processing Unit，圖形處理器）
負(fù)責(zé)紋理的渲染
視圖顯示流程 -
在iOS中是雙緩沖機制厅缺，有前幀緩存蔬顾、后幀緩存
屏幕成像原理當(dāng)垂直同步信號來的時候，開始水平同步信號按行進行刷新屏幕像素湘捎。
卡頓產(chǎn)生的原因
按照60FPS的刷幀率诀豁，每隔16ms就會有一次VSync信號，一旦垂直同步信號來了消痛，GPU會立馬將幀緩存區(qū)的數(shù)據(jù)顯示到屏幕上去且叁，并且馬上開始下一幀的操作，在16ms時間內(nèi)GPU沒有處理完成秩伞，GPU就會將這一次的數(shù)據(jù)拋棄掉逞带，屏幕就會顯示上一次渲染完成的數(shù)據(jù)，從而產(chǎn)生掉幀纱新，就是卡頓現(xiàn)象展氓。
- 卡頓解決的主要思路
盡可能減少CPU、GPU資源消耗
卡頓優(yōu)化 - CPU
- 盡量用輕量級的對象脸爱，比如用不到事件處理的地方遇汞，可以考慮使用CALayer取代UIView
- 不要頻繁地調(diào)用UIView的相關(guān)屬性，比如frame簿废、bounds空入、transform等屬性，盡量減少不必要的修改
- 盡量提前計算好布局族檬，在有需要時一次性調(diào)整對應(yīng)的屬性歪赢，不要多次修改屬性，比如tableViewCell刷新時候单料，每個cell對應(yīng)一個處理好的layout值埋凯。
- Autolayout會比直接設(shè)置frame消耗更多的CPU資源点楼，這個在新版本的iOS里autolayout性能已經(jīng)接近于frame。
- 圖片的size最好剛好跟UIImageView的size保持一致白对，有些廠商的cdn上會包含這個功能掠廓，拉取圖片時候可以直接指定圖片大小，無論對渲染還是內(nèi)存都是一個好的方案甩恼。
- 控制一下線程的最大并發(fā)數(shù)量
- 盡量把耗時的操作放到子線程
文本處理（尺寸計算蟀瞧、繪制）
圖片處理（解碼、繪制）
卡頓優(yōu)化 - GPU
- 盡量避免短時間內(nèi)大量圖片的顯示媳拴，盡可能將多張圖片合成一張進行顯示
- GPU能處理的最大紋理尺寸是4096x4096黄橘，一旦超過這個尺寸，就會占用CPU資源進行處理屈溉，所以紋理盡量不要超過這個尺寸
- 盡量減少視圖數(shù)量和層次
- 減少透明的視圖（alpha<1）塞关，不透明的就設(shè)置opaque為YES
- 盡量避免出現(xiàn)離屏渲染
離屏渲染
- 在OpenGL中，GPU有2種渲染方式
On-Screen Rendering：當(dāng)前屏幕渲染子巾，在當(dāng)前用于顯示的屏幕緩沖區(qū)進行渲染操作
Off-Screen Rendering：離屏渲染帆赢，在當(dāng)前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作 - 離屏渲染消耗性能的原因
需要創(chuàng)建新的緩沖區(qū)
離屏渲染的整個過程，需要多次切換上下文環(huán)境线梗，先是從當(dāng)前屏幕（On-Screen）切換到離屏（Off-Screen）椰于；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上仪搔，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕 - 哪些操作會觸發(fā)離屏渲染瘾婿？
光柵化，layer.shouldRasterize = YES
遮罩烤咧，layer.mask
圓角偏陪，同時設(shè)置layer.masksToBounds = YES、layer.cornerRadius大于0
考慮通過CoreGraphics繪制裁剪圓角煮嫌，或者叫美工提供圓角圖片
陰影笛谦，layer.shadowXXX
如果設(shè)置了layer.shadowPath就不會產(chǎn)生離屏渲染
卡頓檢測
平時所說的“卡頓”主要是因為在主線程執(zhí)行了比較耗時的操作
可以添加Observer到主線程RunLoop中，通過監(jiān)聽RunLoop狀態(tài)切換的耗時昌阿，以達到監(jiān)控卡頓的目的
觸發(fā)卡頓的時間閾值饥脑，我們可以根據(jù) WatchDog 機制來設(shè)置。
WatchDog 在不同狀態(tài)下設(shè)置的不同時間懦冰，如下所示：
啟動（Launch）：20s灶轰；
恢復(fù)（Resume）：10s；
掛起（Suspend）：10s刷钢；
退出（Quit）：6s框往；
后臺（Background）：3min（在 iOS 7 之前，每次申請 10min闯捎； 之后改為每次申請 3min椰弊，可連續(xù)申請，最多申請到 10min）瓤鼻。
通過 WatchDog 設(shè)置的時間秉版，我認(rèn)為可以把啟動的閾值設(shè)置為 10 秒，其他狀態(tài)則都默認(rèn)設(shè)置為 3 秒茬祷∏寤溃總的原則就是，要小于 WatchDog 的限制時間祭犯。當(dāng)然了秸妥，這個閾值也不用小得太多，原則就是要優(yōu)先解決用戶感知最明顯的體驗問題沃粗。
耗電優(yōu)化
耗電主要來源
CPU處理粥惧，Processing
網(wǎng)絡(luò)，Networking
定位最盅，Location
圖像突雪，Graphics
耗電優(yōu)化
- 盡可能降低CPU、GPU功耗
- 少用定時器
- 優(yōu)化I/O操作
盡量不要頻繁寫入小數(shù)據(jù)涡贱，最好批量一次性寫入
讀寫大量重要數(shù)據(jù)時咏删，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API问词。用dispatch_io系統(tǒng)會優(yōu)化磁盤訪問
數(shù)據(jù)量比較大的督函，建議使用數(shù)據(jù)庫（比如SQLite、CoreData） - 網(wǎng)絡(luò)優(yōu)化
減少激挪、壓縮網(wǎng)絡(luò)數(shù)據(jù)
如果多次請求的結(jié)果是相同的辰狡，盡量使用緩存
使用斷點續(xù)傳，否則網(wǎng)絡(luò)不穩(wěn)定時可能多次傳輸相同的內(nèi)容
網(wǎng)絡(luò)不可用時灌灾，不要嘗試執(zhí)行網(wǎng)絡(luò)請求
讓用戶可以取消長時間運行或者速度很慢的網(wǎng)絡(luò)操作搓译，設(shè)置合適的超時時間
批量傳輸，比如锋喜，下載視頻流時些己，不要傳輸很小的數(shù)據(jù)包，直接下載整個文件或者一大塊一大塊地下載嘿般。如果下載廣告段标，一次性多下載一些，然后再慢慢展示炉奴。如果下載電子郵件逼庞，一次下載多封，不要一封一封地下載 - 定位優(yōu)化
如果只是需要快速確定用戶位置瞻赶，最好用CLLocationManager的requestLocation方法赛糟。定位完成后派任，會自動讓定位硬件斷電
如果不是導(dǎo)航應(yīng)用，盡量不要實時更新位置璧南，定位完畢就關(guān)掉定位服務(wù)
盡量降低定位精度掌逛，比如盡量不要使用精度最高的kCLLocationAccuracyBest
需要后臺定位時，盡量設(shè)置pausesLocationUpdatesAutomatically為YES司倚，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
盡量不要使用startMonitoringSignificantLocationChanges豆混，優(yōu)先考慮startMonitoringForRegion: - 硬件檢測優(yōu)化
用戶移動、搖晃动知、傾斜設(shè)備時皿伺，會產(chǎn)生動作(motion)事件，這些事件由加速度計盒粮、陀螺儀鸵鸥、磁力計等硬件檢測。在不需要檢測的場合拆讯，應(yīng)該及時關(guān)閉這些硬件
啟動優(yōu)化
- APP的啟動可以分為2種
冷啟動（Cold Launch）：從零開始啟動APP
熱啟動（Warm Launch）：APP已經(jīng)在內(nèi)存中脂男，在后臺存活著，再次點擊圖
啟動APP - APP啟動時間的優(yōu)化种呐，主要是針對冷啟動進行優(yōu)化
- 通過添加環(huán)境變量可以打印出APP的啟動時間分析（Edit scheme -> Run -> Arguments）
DYLD_PRINT_STATISTICS設(shè)置為1
如果需要更詳細(xì)的信息宰翅，那就將DYLD_PRINT_STATISTICS_DETAILS設(shè)置為1 -
APP的冷啟動可以概括為3大階段
dyld
runtime
main
三個階段
dyld
- dyld（dynamic link editor），Apple的動態(tài)鏈接器爽室，可以用來裝載Mach-O文件（可執(zhí)行文件汁讼、動態(tài)庫等）
- 啟動APP時，dyld所做的事情有
裝載APP的可執(zhí)行文件阔墩，同時會遞歸加載所有依賴的動態(tài)庫
當(dāng)dyld把可執(zhí)行文件嘿架、動態(tài)庫都裝載完畢后，會通知Runtime進行下一步的處理
runtime
- 啟動APP時啸箫，runtime所做的事情有
調(diào)用map_images進行可執(zhí)行文件內(nèi)容的解析和處理
在load_images中調(diào)用call_load_methods耸彪，調(diào)用所有Class和Category的+load方法
進行各種objc結(jié)構(gòu)的初始化（注冊O(shè)bjc類 、初始化類對象等等）
調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù) - 到此為止忘苛，可執(zhí)行文件和動態(tài)庫中所有的符號(Class蝉娜，Protocol，Selector扎唾，IMP召川，…)都已經(jīng)按格式成功加載到內(nèi)存中，被runtime 所管理
main
- 總結(jié)一下
APP的啟動由dyld主導(dǎo)胸遇，將可執(zhí)行文件加載到內(nèi)存荧呐，順便加載所有依賴的動態(tài)庫
并由runtime負(fù)責(zé)加載成objc定義的結(jié)構(gòu)
所有初始化工作結(jié)束后，dyld就會調(diào)用main函數(shù)
接下來就是UIApplicationMain函數(shù)，AppDelegate的application:didFinishLaunchingWithOptions:方法
APP的啟動優(yōu)化
按照不同的階段
dyld
減少動態(tài)庫倍阐、合并一些動態(tài)庫（定期清理不必要的動態(tài)庫）
減少Objc類概疆、分類的數(shù)量、減少Selector數(shù)量（定期清理不必要的類收捣、分類）
減少C++虛函數(shù)數(shù)量
Swift盡量使用structruntime
用+initialize方法和dispatch_once取代所有的attribute((constructor))届案、C++靜態(tài)構(gòu)造器、ObjC的+loadmain
在不影響用戶體驗的前提下罢艾，盡可能將一些操作延遲，不要全部都放在finishLaunching方法中
按需加載
安裝包瘦身
安裝包（IPA）主要由可執(zhí)行文件尽纽、資源組成
資源（圖片咐蚯、音頻、視頻等）
采取無損壓縮
去除沒有用到的資源： https://github.com/tinymind/LSUnusedResources可執(zhí)行文件瘦身
編譯器優(yōu)化
Strip Linked Product弄贿、Make Strings Read-Only春锋、Symbols Hidden by Default設(shè)置為YES
去掉異常支持，Enable C++ Exceptions差凹、Enable Objective-C Exceptions設(shè)置為NO期奔， Other C Flags添加-fno-exceptions利用AppCode（https://www.jetbrains.com/objc/）檢測未使用的代碼：菜單欄 -> Code -> Inspect Code
編寫LLVM插件檢測出重復(fù)代碼、未被調(diào)用的代碼
LinkMap
-
XCode生成LinkMap文件危尿，可以查看可執(zhí)行文件的具體組成
- 可借助第三方工具解析LinkMap文件： https://github.com/huanxsd/LinkMap
