一 CPU和GPU
在屏幕成像的過(guò)程中乏沸,CPU和GPU起著至關(guān)重要的作用
CPU(Central Processing Unit竞惋,中央處理器)
對(duì)象的創(chuàng)建和銷(xiāo)毀撕彤、對(duì)象屬性的調(diào)整沐飘、布局計(jì)算、文本的計(jì)算和排版桩皿、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制(Core Graphics)GPU(Graphics Processing Unit幢炸,圖形處理器)
紋理的渲染
下圖展示視圖如何顯示
在iOS中是雙緩沖機(jī)制泄隔,有前幀緩存、后幀緩存
二 屏幕成像原理
三 卡頓原因阳懂,解決梅尤,監(jiān)測(cè)
卡頓產(chǎn)生的原因:因?yàn)镃PU或者GPU所花費(fèi)的時(shí)間過(guò)長(zhǎng),導(dǎo)致垂直信號(hào)來(lái)的時(shí)候岩调,CPU計(jì)算或者GPU渲染未完成,從而掉幀赡盘。
- 卡頓解決的主要思路
(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保持一致
控制一下線(xiàn)程的最大并發(fā)數(shù)量
-
盡量把耗時(shí)的操作放到子線(xiàn)程
- 文本處理(尺寸計(jì)算、繪制)
- 圖片處理(解碼蔬啡、繪制)
3.2 卡頓優(yōu)化 - GPU
盡量避免短時(shí)間內(nèi)大量圖片的顯示诲侮,盡可能將多張圖片合成一張進(jìn)行顯示
GPU能處理的最大紋理尺寸是4096x4096,一旦超過(guò)這個(gè)尺寸箱蟆,就會(huì)占用CPU資源進(jìn)行處理沟绪,所以紋理盡量不要超過(guò)這個(gè)尺寸
盡量減少視圖數(shù)量和層次
減少透明的視圖(alpha<1),不透明的就設(shè)置opaque為YES
盡量避免出現(xiàn)離屏渲染
3.3 離屏渲染
- 在OpenGL中空猜,GPU有2種渲染方式
-
On-Screen Rendering
:當(dāng)前屏幕渲染绽慈,在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作 -
Off-Screen Rendering
:離屏渲染,在當(dāng)前屏幕緩沖區(qū)以外新開(kāi)辟一個(gè)緩沖區(qū)進(jìn)行渲染操作
- 離屏渲染消耗性能的原因
- 需要?jiǎng)?chuàng)建新的緩沖區(qū)
- 離屏渲染的整個(gè)過(guò)程辈毯,需要多次切換上下文環(huán)境坝疼,先是從當(dāng)前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結(jié)束以后漓摩,將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上裙士,又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕
- 哪些操作會(huì)觸發(fā)離屏渲染?
光柵化
管毙,layer.shouldRasterize = YES遮罩
腿椎,layer.mask圓角
桌硫,同時(shí)設(shè)置layer.masksToBounds = YES
、layer.cornerRadius
大于0
解決思路:考慮通過(guò)CoreGraphics繪制裁剪圓角啃炸,或者叫美工提供圓角圖片陰影
铆隘,layer.shadowXXX
解決思路:如果設(shè)置了layer.shadowPath就不會(huì)產(chǎn)生離屏渲染
- 卡頓檢測(cè)
平時(shí)所說(shuō)的“卡頓”主要是因?yàn)樵谥骶€(xiàn)程執(zhí)行了比較耗時(shí)的操作
可以添加Observer到主線(xiàn)程RunLoop中,通過(guò)監(jiān)聽(tīng)RunLoop狀態(tài)切換的耗時(shí)南用,以達(dá)到監(jiān)控卡頓的目的
項(xiàng)目連接地址 - LXDAppFluecyMonitor-master
四 耗電的主要來(lái)源
CPU處理膀钠,
Processing
網(wǎng)絡(luò),
Networking
定位裹虫,
Location
圖像肿嘲,
Graphics
4.1 耗電優(yōu)化
盡可能降低CPU、GPU功耗
少用定時(shí)器
優(yōu)化I/O操作
- 盡量不要頻繁寫(xiě)入小數(shù)據(jù)筑公,最好批量一次性寫(xiě)入
- 讀寫(xiě)大量重要數(shù)據(jù)時(shí)雳窟,考慮用dispatch_io,其提供了基于GCD的異步操作文件I/O的API匣屡。用dispatch_io系統(tǒng)會(huì)優(yōu)化磁盤(pán)訪(fǎng)問(wèn)
- 數(shù)據(jù)量比較大的封救,建議使用數(shù)據(jù)庫(kù)(比如SQLite、CoreData)
- 網(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)求
- 讓用戶(hù)可以取消長(zhǎng)時(shí)間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作惩坑,設(shè)置合適的超時(shí)時(shí)間
- 批量傳輸,比如嘱朽,下載視頻流時(shí)旭贬,不要傳輸很小的數(shù)據(jù)包,直接下載整個(gè)文件或者一大塊一大塊地下載搪泳。如果下載廣告稀轨,一次性多下載一些,然后再慢慢展示岸军。如果下載電子郵件奋刽,一次下載多封,不要一封一封地下載
- 定位優(yōu)化
- 如果只是需要快速確定用戶(hù)位置艰赞,最好用CLLocationManager的requestLocation方法佣谐。定位完成后,會(huì)自動(dòng)讓定位硬件斷電
- 如果不是導(dǎo)航應(yīng)用方妖,盡量不要實(shí)時(shí)更新位置狭魂,定位完畢就關(guān)掉定位服務(wù)
- 盡量降低定位精度,比如盡量不要使用精度最高的kCLLocationAccuracyBest
- 需要后臺(tái)定位時(shí),盡量設(shè)置pausesLocationUpdatesAutomatically為YES雌澄,如果用戶(hù)不太可能移動(dòng)的時(shí)候系統(tǒng)會(huì)自動(dòng)暫停位置更新
- 盡量不要使用startMonitoringSignificantLocationChanges斋泄,優(yōu)先考慮startMonitoringForRegion:
- 硬件檢測(cè)優(yōu)化
- 用戶(hù)移動(dòng)、搖晃镐牺、傾斜設(shè)備時(shí)炫掐,會(huì)產(chǎn)生動(dòng)作(motion)事件,這些事件由加速度計(jì)睬涧、陀螺儀募胃、磁力計(jì)等硬件檢測(cè)。在不需要檢測(cè)的場(chǎng)合畦浓,應(yīng)該及時(shí)關(guān)閉這些硬件
五 APP的啟動(dòng)
- APP的啟動(dòng)可以分為2種
-
冷啟動(dòng)(Cold Launch)
:從零開(kāi)始啟動(dòng)APP -
熱啟動(dòng)(Warm Launch)
:APP已經(jīng)在內(nèi)存中痹束,在后臺(tái)存活著,再次點(diǎn)擊圖標(biāo)啟動(dòng)APP
APP啟動(dòng)時(shí)間的優(yōu)化宅粥,主要是針對(duì)冷啟動(dòng)進(jìn)行優(yōu)化
通過(guò)添加環(huán)境變量可以打印出APP的啟動(dòng)時(shí)間分析
- (Edit scheme -> Run -> Arguments)
DYLD_PRINT_STATISTICS
設(shè)置為1 - 如果需要更詳細(xì)的信息参袱,那就將
DYLD_PRINT_STATISTICS_DETAILS
設(shè)置為1
運(yùn)行結(jié)果
5.1 APP的啟動(dòng)
APP的冷啟動(dòng)可以概括為3大階段
- dyld
- runtime
- main
5.2 APP的啟動(dòng) - dyld
dyld(dynamic link editor)
,Apple的動(dòng)態(tài)鏈接器秽梅,可以用來(lái)裝載Mach-O
文件(可執(zhí)行文件、動(dòng)態(tài)庫(kù)等)啟動(dòng)APP時(shí)剿牺,dyld所做的事情有
<1> 裝載APP的可執(zhí)行文件企垦,同時(shí)會(huì)遞歸加載所有依賴(lài)的動(dòng)態(tài)庫(kù)
<2> 當(dāng)dyld把可執(zhí)行文件、動(dòng)態(tài)庫(kù)都裝載完畢后晒来,會(huì)通知Runtime進(jìn)行下一步的處理
5.3 APP的啟動(dòng) - runtime
- 啟動(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類(lèi) 湃崩、初始化類(lèi)對(duì)象等等)
- 調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)
- 到此為止荧降,可執(zhí)行文件和動(dòng)態(tài)庫(kù)中所有的符號(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)存,順便加載所有依賴(lài)的動(dòng)態(tài)庫(kù)
- 并由runtime負(fù)責(zé)加載成objc定義的結(jié)構(gòu)
- 所有初始化工作結(jié)束后邓梅,dyld就會(huì)調(diào)用main函數(shù)
- 接下來(lái)就是UIApplicationMain函數(shù)脱盲,AppDelegate的application:didFinishLaunchingWithOptions:方法
5.5 APP的啟動(dòng)優(yōu)化
按照不同的階段
dyld
- 減少動(dòng)態(tài)庫(kù)、合并一些動(dòng)態(tài)庫(kù)(定期清理不必要的動(dòng)態(tài)庫(kù))
- 減少Objc類(lèi)日缨、分類(lèi)的數(shù)量钱反、減少Selector數(shù)量(定期清理不必要的類(lèi)、分類(lèi))
- 減少C++虛函數(shù)數(shù)量
- Swift盡量使用struct
runtime
- 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構(gòu)造器面哥、ObjC的+load
main
- 在不影響用戶(hù)體驗(yàn)的前提下哎壳,盡可能將一些操作延遲,不要全部都放在finishLaunching方法中
- 按需加載
六 安裝包瘦身
安裝包(IPA)主要由可執(zhí)行文件幢竹、資源組成
資源(圖片耳峦、音頻、視頻等)
- 采取無(wú)損壓縮
- 去除沒(méi)有用到的資源: LSUnusedResources
- 可執(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 檢測(cè)未使用的代碼:菜單欄 -> Code -> Inspect Code
- 編寫(xiě)LLVM插件檢測(cè)出重復(fù)代碼、未被調(diào)用的代碼
七 LinkMap
- 生成LinkMap文件疙咸,可以查看可執(zhí)行文件的具體組成
- 可借助第三方工具解析LinkMap文件: LinkMap
本文參考:
路飛_Luck (http://www.reibang.com/p/07f7b96bb03f)
以及借鑒MJ的教程視頻
非常感謝.
項(xiàng)目連接地址 - PropertyOptimize_Fluecy
項(xiàng)目連接地址 - LXDAppFluecyMonitor-master