在屏幕成像的過程中纺涤,CPU和GPU起著至關(guān)重要的作用
CPU(Central Processing Unit五垮,中央處理器)
對象的創(chuàng)建和銷毀睬棚、對象屬性的調(diào)整第煮、布局計(jì)算、文本的計(jì)算和排版抑党、圖片的格式轉(zhuǎn)換和解碼包警、圖像的繪制(Core Graphics)
-
GPU(Graphics Processing Unit,圖形處理器)
- 紋理的渲染
- 在iOS中是雙緩沖機(jī)制底靠,有前幀緩存害晦、后幀緩存
卡頓產(chǎn)生的原因
- 卡頓解決的主要思路
- 盡可能減少CPU、GPU資源消耗
- 按照60FPS的刷幀率暑中,每隔16ms就會有一次VSync信號
- 卡頓優(yōu)化-CPU
盡量用輕量級的對象券盅,比如用不到事件處理的地方锋八,可以考慮使用CALayer取代UIView
不要頻繁地調(diào)用UIView的相關(guān)屬性枕面,比如frame励翼、bounds、transform等屬性雕凹,盡量減少不必要的修改
盡量提前計(jì)算好布局殴俱,在有需要時(shí)一次性調(diào)整對應(yīng)的屬性政冻,不要多次修改屬性
Autolayout會比直接設(shè)置frame消耗更多的CPU資源
圖片的size最好剛好跟UIImageView的size保持一致
控制一下線程的最大并發(fā)數(shù)量
盡量把耗時(shí)的操作放到子線程
文本處理(尺寸計(jì)算、繪制)
圖片處理(解碼粱挡、繪制)
- 卡頓優(yōu)化-CPU
盡量避免短時(shí)間內(nèi)大量圖片的顯示赠幕,盡可能將多張圖片合成一張進(jìn)行顯示
GPU能處理的最大紋理尺寸是4096x4096,一旦超過這個(gè)尺寸询筏,就會占用CPU資源進(jìn)行處理榕堰,所以紋理盡量不要超過這個(gè)尺寸
盡量減少視圖數(shù)量和層次
減少透明的視圖(alpha<1),不透明的就設(shè)置opaque為YES
盡量避免出現(xiàn)離屏渲染
離屏渲染
-
在OpenGL中嫌套,GPU有2種渲染方式
- On-Screen Rendering:當(dāng)前屏幕渲染逆屡,在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作
- Off-Screen Rendering:離屏渲染,在當(dāng)前屏幕緩沖區(qū)以外新開辟一個(gè)緩沖區(qū)進(jìn)行渲染操作
-
離屏渲染消耗性能的原因
- 需要?jiǎng)?chuàng)建新的緩沖區(qū)
- 離屏渲染的整個(gè)過程踱讨,需要多次切換上下文環(huán)境魏蔗,先是從當(dāng)前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結(jié)束以后痹筛,將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上莺治,又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕
-
哪些操作會觸發(fā)離屏渲染?
光柵化帚稠,layer.shouldRasterize = YES
遮罩谣旁,layer.mask
-
圓角,同時(shí)設(shè)置layer.masksToBounds = YES滋早、layer.cornerRadius大于0
- 考慮通過CoreGraphics繪制裁剪圓角榄审,或者叫美工提供圓角圖片
-
陰影,layer.shadowXXX
- 如果設(shè)置了layer.shadowPath就不會產(chǎn)生離屏渲染
卡頓檢測
平時(shí)所說的“卡頓”主要是因?yàn)樵谥骶€程執(zhí)行了比較耗時(shí)的操作
可以添加Observer到主線程RunLoop中杆麸,通過監(jiān)聽RunLoop狀態(tài)切換的耗時(shí)搁进,以達(dá)到監(jiān)控卡頓的目的
耗電優(yōu)化
盡可能降低CPU、GPU功耗
少用定時(shí)器
-
優(yōu)化I/O操作
- 盡量不要頻繁寫入小數(shù)據(jù)昔头,最好批量一次性寫入
- 讀寫大量重要數(shù)據(jù)時(shí)饼问,考慮用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é)果是相同的,盡量使用緩存
- 使用斷點(diǎn)續(xù)傳茧妒,否則網(wǎng)絡(luò)不穩(wěn)定時(shí)可能多次傳輸相同的內(nèi)容
- 網(wǎng)絡(luò)不可用時(shí)萧吠,不要嘗試執(zhí)行網(wǎng)絡(luò)請求
- 讓用戶可以取消長時(shí)間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作,設(shè)置合適的超時(shí)時(shí)間
- 批量傳輸桐筏,比如纸型,下載視頻流時(shí),不要傳輸很小的數(shù)據(jù)包,直接下載整個(gè)文件或者一大塊一大塊地下載狰腌。如果下載廣告除破,一次性多下載一些,然后再慢慢展示琼腔。如果下載電子郵件瑰枫,一次下載多封,不要一封一封地下載
-
定位優(yōu)化
- 如果只是需要快速確定用戶位置丹莲,最好用CLLocationManager的requestLocation方法光坝。定位完成后,會自動讓定位硬件斷電
- 如果不是導(dǎo)航應(yīng)用甥材,盡量不要實(shí)時(shí)更新位置盯另,定位完畢就關(guān)掉定位服務(wù)
- 盡量降低定位精度,比如盡量不要使用精度最高的kCLLocationAccuracyBest
- 需要后臺定位時(shí)洲赵,盡量設(shè)置pausesLocationUpdatesAutomatically為YES鸳惯,如果用戶不太可能移動的時(shí)候系統(tǒng)會自動暫停位置更新
- 盡量不要使用startMonitoringSignificantLocationChanges,優(yōu)先考慮startMonitoringForRegion:
-
硬件檢測優(yōu)化
- 用戶移動叠萍、搖晃芝发、傾斜設(shè)備時(shí),會產(chǎn)生動作(motion)事件俭令,這些事件由加速度計(jì)后德、陀螺儀、磁力計(jì)等硬件檢測抄腔。在不需要檢測的場合瓢湃,應(yīng)該及時(shí)關(guān)閉這些硬件
APP的啟動優(yōu)化
-
APP的啟動可以分為2種
- 冷啟動(Cold Launch):從零開始啟動APP
- 熱啟動(Warm Launch):APP已經(jīng)在內(nèi)存中,在后臺存活著赫蛇,再次點(diǎn)擊圖標(biāo)啟動APP
APP啟動時(shí)間的優(yōu)化绵患,主要是針對冷啟動進(jìn)行優(yōu)化
-
通過添加環(huán)境變量可以打印出APP的啟動時(shí)間分析(Edit scheme -> Run -> Arguments)
- DYLD_PRINT_STATISTICS設(shè)置為1
- 如果需要更詳細(xì)的信息,那就將DYLD_PRINT_STATISTICS_DETAILS設(shè)置為1
-
APP的啟動步驟
-
dyld
dyld(dynamic link editor)悟耘,Apple的動態(tài)鏈接器落蝙,可以用來裝載Mach-O文件(可執(zhí)行文件、動態(tài)庫等)
-
啟動APP時(shí)暂幼,dyld所做的事情有
- 裝載APP的可執(zhí)行文件筏勒,同時(shí)會遞歸加載所有依賴的動態(tài)庫
- 當(dāng)dyld把可執(zhí)行文件、動態(tài)庫都裝載完畢后旺嬉,會通知Runtime進(jìn)行下一步的處理
-
runtime
-
啟動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)的初始化(注冊O(shè)bjc類 邪媳、初始化類對象等等)
- 調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)
到此為止捐顷,可執(zhí)行文件和動態(tài)庫中所有的符號(Class荡陷,Protocol,Selector迅涮,IMP废赞,…)都已經(jīng)按格式成功加載到內(nèi)存中,被runtime 所管理
-
-
main
- 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:方法
-
-
啟動優(yōu)化
- 按照不同的階段
-
dyld
- 減少動態(tài)庫渣蜗、合并一些動態(tài)庫(定期清理不必要的動態(tài)庫)
- 減少Objc類、分類的數(shù)量旷祸、減少Selector數(shù)量(定期清理不必要的類耕拷、分類)
- 減少C++虛函數(shù)數(shù)量
- Swift盡量使用struct
-
runtime
- 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構(gòu)造器托享、ObjC的+load
-
main
- 在不影響用戶體驗(yàn)的前提下骚烧,盡可能將一些操作延遲,不要全部都放在finishLaunching方法中
按需加載
- 在不影響用戶體驗(yàn)的前提下骚烧,盡可能將一些操作延遲,不要全部都放在finishLaunching方法中
-
- 按照不同的階段
安裝包瘦身
- 安裝的組成
-
資源
- 采取無損壓縮
- 去除沒有用到的資源: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->InspectCode
編寫LLVM插件檢測出重復(fù)代碼、未被調(diào)用的代碼
-
-