29-性能優(yōu)化詳細(xì)講解

一 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幢炸,圖形處理器)
    紋理的渲染

下圖展示視圖如何顯示

image.png

在iOS中是雙緩沖機(jī)制泄隔,有前幀緩存、后幀緩存

二 屏幕成像原理
image.png
三 卡頓原因阳懂,解決梅尤,監(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渲染未完成,從而掉幀赡盘。

image.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保持一致

  • 控制一下線(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 離屏渲染
  1. 在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)行渲染操作
  1. 離屏渲染消耗性能的原因
  • 需要?jiǎng)?chuàng)建新的緩沖區(qū)
  • 離屏渲染的整個(gè)過(guò)程辈毯,需要多次切換上下文環(huán)境坝疼,先是從當(dāng)前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結(jié)束以后漓摩,將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上裙士,又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕
  1. 哪些操作會(huì)觸發(fā)離屏渲染?
  • 光柵化管毙,layer.shouldRasterize = YES

  • 遮罩腿椎,layer.mask

  • 圓角桌硫,同時(shí)設(shè)置layer.masksToBounds = YESlayer.cornerRadius大于0
    解決思路:考慮通過(guò)CoreGraphics繪制裁剪圓角啃炸,或者叫美工提供圓角圖片

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

  1. 卡頓檢測(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)化
  1. 盡可能降低CPU、GPU功耗

  2. 少用定時(shí)器

  3. 優(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)
  1. 網(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è)文件或者一大塊一大塊地下載搪泳。如果下載廣告稀轨,一次性多下載一些,然后再慢慢展示岸军。如果下載電子郵件奋刽,一次下載多封,不要一封一封地下載
  1. 定位優(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:
  1. 硬件檢測(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)
  1. 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
  1. APP啟動(dòng)時(shí)間的優(yōu)化宅粥,主要是針對(duì)冷啟動(dòng)進(jìn)行優(yōu)化

  2. 通過(guò)添加環(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)鏈接器秽梅,可以用來(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
  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類(lèi) 湃崩、初始化類(lèi)對(duì)象等等)
  • 調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)
  1. 到此為止荧降,可執(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)化

按照不同的階段

  1. 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
  1. runtime
  • 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構(gòu)造器面哥、ObjC的+load
  1. main
  • 在不影響用戶(hù)體驗(yàn)的前提下哎壳,盡可能將一些操作延遲,不要全部都放在finishLaunching方法中
  • 按需加載
六 安裝包瘦身
  1. 安裝包(IPA)主要由可執(zhí)行文件幢竹、資源組成

  2. 資源(圖片耳峦、音頻、視頻等)

  1. 可執(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í)行文件的具體組成
image.png
  • 可借助第三方工具解析LinkMap文件: LinkMap

本文參考:
路飛_Luck (http://www.reibang.com/p/07f7b96bb03f)
以及借鑒MJ的教程視頻
非常感謝.


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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末县匠,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子撒轮,更是在濱河造成了極大的恐慌乞旦,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,378評(píng)論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件题山,死亡現(xiàn)場(chǎng)離奇詭異兰粉,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)顶瞳,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,356評(píng)論 2 382
  • 文/潘曉璐 我一進(jìn)店門(mén)玖姑,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人慨菱,你說(shuō)我怎么就攤上這事焰络。” “怎么了符喝?”我有些...
    開(kāi)封第一講書(shū)人閱讀 152,702評(píng)論 0 342
  • 文/不壞的土叔 我叫張陵闪彼,是天一觀(guān)的道長(zhǎng)。 經(jīng)常有香客問(wèn)我洲劣,道長(zhǎng)备蚓,這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 55,259評(píng)論 1 279
  • 正文 為了忘掉前任囱稽,我火速辦了婚禮郊尝,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘战惊。我一直安慰自己流昏,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,263評(píng)論 5 371
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著况凉,像睡著了一般谚鄙。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上刁绒,一...
    開(kāi)封第一講書(shū)人閱讀 49,036評(píng)論 1 285
  • 那天闷营,我揣著相機(jī)與錄音,去河邊找鬼知市。 笑死傻盟,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的嫂丙。 我是一名探鬼主播娘赴,決...
    沈念sama閱讀 38,349評(píng)論 3 400
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼跟啤!你這毒婦竟也來(lái)了诽表?” 一聲冷哼從身側(cè)響起,我...
    開(kāi)封第一講書(shū)人閱讀 36,979評(píng)論 0 259
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤隅肥,失蹤者是張志新(化名)和其女友劉穎竿奏,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體腥放,經(jīng)...
    沈念sama閱讀 43,469評(píng)論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡议双,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,938評(píng)論 2 323
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了捉片。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,059評(píng)論 1 333
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡汞舱,死狀恐怖伍纫,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情昂芜,我是刑警寧澤莹规,帶...
    沈念sama閱讀 33,703評(píng)論 4 323
  • 正文 年R本政府宣布,位于F島的核電站泌神,受9級(jí)特大地震影響良漱,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜欢际,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,257評(píng)論 3 307
  • 文/蒙蒙 一母市、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧损趋,春花似錦患久、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 30,262評(píng)論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)返帕。三九已至,卻和暖如春篙挽,著一層夾襖步出監(jiān)牢的瞬間荆萤,已是汗流浹背。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 31,485評(píng)論 1 262
  • 我被黑心中介騙來(lái)泰國(guó)打工铣卡, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留链韭,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 45,501評(píng)論 2 354
  • 正文 我出身青樓算行,卻偏偏與公主長(zhǎng)得像梧油,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子州邢,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,792評(píng)論 2 345

推薦閱讀更多精彩內(nèi)容

  • 一 CPU和GPU 在屏幕成像的過(guò)程中儡陨,CPU和GPU起著至關(guān)重要的作用 CPU(Central Processi...
    路飛_Luck閱讀 3,348評(píng)論 0 23
  • 為了表示我對(duì)簡(jiǎn)書(shū)『飽醉豚』事件的不滿(mǎn),簡(jiǎn)書(shū)不再更新量淌,后續(xù)有文章只更新 個(gè)人博客和 掘金 歡迎移步 個(gè)人博客或者 掘...
    eagleyz閱讀 663評(píng)論 0 4
  • 前言隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展骗村,產(chǎn)品的更新迭代,公司業(yè)務(wù)的不斷擴(kuò)展呀枢,移動(dòng)應(yīng)用頁(yè)面布局也越來(lái)越復(fù)雜胚股,效果越來(lái)越炫,自身業(yè)務(wù)...
    天空像天空一樣藍(lán)閱讀 492評(píng)論 0 2
  • 目錄一: 卡頓檢測(cè)以及原理runloop卡頓檢測(cè)消息轉(zhuǎn)發(fā)解決定時(shí)器循環(huán)引用GCD定時(shí)器封裝NSProxy消息轉(zhuǎn)發(fā)T...
    江水東流閱讀 8,956評(píng)論 2 30
  • 或許有一天 你忘記了我的模樣 我也不會(huì)遺忘 曾經(jīng)的念想 你依附在我身旁 我悄悄地對(duì)你說(shuō) 我喜歡你 請(qǐng)?jiān)徫业呐橙?...
    胡小X閱讀 90評(píng)論 0 2