iOS底層原理（六）：性能優(yōu)化

前言
性能優(yōu)化包括：卡頓檢測和優(yōu)化、耗電優(yōu)化、啟動優(yōu)化、安裝包瘦身幾部分組成

一、卡頓檢測和優(yōu)化

1. 屏幕成像原理
  • CPU計(jì)算完成后，將結(jié)果交給GPU渲染，GPU會把渲染的結(jié)果放到幀緩存中，視頻控制器從幀緩存中讀取，并顯示到屏幕上，如下圖所示：
image.png
2. 顯示器的顯示原理
電子槍掃描

  • 顯示器的電子槍按照上面方式，從上到下一行行掃描，掃描完成后顯示器就呈現(xiàn)一幀畫面，隨后電子槍回到初始位置繼續(xù)下一次掃描。為了把顯示器的顯示過程和系統(tǒng)的視頻控制器進(jìn)行同步，顯示器（或者其他硬件）會用硬件時鐘產(chǎn)生一系列的定時信號。

  • 當(dāng)電子槍換到新的一行，準(zhǔn)備進(jìn)行掃描時，顯示器會發(fā)出一個HSync水平同步信號（horizonal synchronization） ；而當(dāng)一幀畫面繪制完成后，電子槍回復(fù)到原位，準(zhǔn)備畫下一幀前，顯示器會發(fā)出一個VSync垂直同步信號（vertical synchronization）。

  • 接收到VSync垂直同步信號后，App主線程就會在CPU中計(jì)算顯示內(nèi)容，例如視圖的創(chuàng)建、布局計(jì)算、圖片解碼、文本繪制等等，然后將結(jié)果提交給GPU渲染，由GPU進(jìn)行變換、合成、渲染，然后將渲染結(jié)果提交到幀緩沖區(qū)中，等待下一次VSync垂直同步信號到來之時，顯示到屏幕上。

3. 卡頓產(chǎn)生的原因

  • 由于垂直同步的機(jī)制，如果在一個VSync垂直同步信號時間內(nèi)，CPU 或者 GPU 沒有完成內(nèi)容提交，則那一幀就會被丟棄，等待下一次機(jī)會再顯示，而這時顯示屏?xí)Ａ糁暗膬?nèi)容不變。這就是界面卡頓的原因。

  • 所以無論CPU 和 GPU 哪個阻礙了顯示流程，都會造成掉幀現(xiàn)象。開發(fā)時也需要分別對 CPU 和 GPU 壓力進(jìn)行評估和優(yōu)化。

4. 卡頓優(yōu)化
(1).CPU優(yōu)化：
  • 盡量使用輕量級的對象，例如用不到事件處理的地方 ，可以考慮使用CALayer代替UIView
  • AutoLayout會比直接設(shè)置frame消耗更多的CPU資源
  • 圖片的Size最好和UImageView的size保持一致，盡量不要動態(tài)縮放(contentMode)
  • 控制線程最大并發(fā)數(shù)量
  • 盡量把耗時操作放到子線程中，例如：圖片解碼、圖片繪制、文本處理等
  • 不要用JPEG圖片，應(yīng)當(dāng)使用PNG圖片
  • 在tableViewCell高度需要自適應(yīng)時，需要緩存高度，以避免重復(fù)無意義的計(jì)算，可以使用字典或者NSCache緩存，或者UITableView-FDTemplateLayoutCell
(2).GPU優(yōu)化：
  • 盡量避免短時間內(nèi)大量圖片顯示，盡可能將多張圖片合成一張進(jìn)行顯示
  • GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會占用CPU資源進(jìn)行處理，所以紋理盡量不要超過這個尺寸
  • 盡量減少視圖數(shù)量和層次
  • 減少透明的視圖，不透明的就設(shè)置opaque為YES
  • 盡量避免離屏渲染
  • 在cellForRowAtIndexPath:回調(diào)的時候只創(chuàng)建實(shí)例，快速返回cell，不綁定數(shù)據(jù)。在willDisplayCell: forRowAtIndexPath:的時候綁定數(shù)據(jù)（賦值）
  • 少用clearColor，maskToBounds，陰影效果等。
(3).盡量避免離屏渲染：

在OpenGL中，GPU有兩種渲染方式：

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

離屏渲染消耗性能的原因：

  • 需要創(chuàng)建新的緩沖區(qū)
  • 離屏渲染的整個過程，需要多次切換上下文環(huán)境：先是從當(dāng)前屏幕切換到離屏，等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕

哪些操作會觸發(fā)離屏渲染：

  • 光柵化，例如：layer.shouldRasterize = YES;
  • 遮罩，例如：layer.mask
  • 圓角，同時設(shè)置layer.maskToBounds = YES和layer.cornerRadius大于0就會觸發(fā)離屏渲染，可以考慮通過CoreGraphics繪制圓角，或者叫美工提供圓角圖片
  • 陰影，例如：layer.shadowXXX，可以用layer.shadowPath代替
5. 卡頓檢測

二、耗電優(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é)果是相同，盡量使用緩存
    • 使用斷點(diǎn)續(xù)傳，否則網(wǎng)絡(luò)不穩(wěn)定時可能重復(fù)下載
    • 網(wǎng)絡(luò)不可用時，不要嘗試執(zhí)行網(wǎng)絡(luò)請求
    • 讓用戶可以取消長時間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作，設(shè)置合適的超時時間
    • 批量傳輸，比如下載視頻時，不要傳輸很小的數(shù)據(jù)包，直接下載整個文件或者一大塊一大塊的下載；如果下載廣告，一次性多下載一些，然后在慢慢展示；

  • 定位優(yōu)化

    • 如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法，定位完成后，會自動讓定位硬件斷點(diǎn)
    • 如果不是導(dǎo)航應(yīng)用，盡量不要實(shí)時更新位置，定位完畢就關(guān)掉定位服務(wù)
    • 盡量降級定位精度，盡量不要使用精度最高的
    • 盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:

  • 硬件檢測優(yōu)化

    • 用戶移動、搖晃、傾斜設(shè)備時，會產(chǎn)生動作motion事件，這些事件由加速器、陀螺儀、磁力計(jì)等硬件檢測，在不需要檢測的場合，及時關(guān)閉這些硬件

三、啟動優(yōu)化

1. APP的啟動

  • APP的啟動分為冷啟動和熱啟動：

    • 冷啟動：從零開始啟動APP
    • 熱啟動：APP已經(jīng)在內(nèi)存中了，再次點(diǎn)擊圖標(biāo)啟動APP

  • 熱啟動的速度已經(jīng)非常快了，所以啟動優(yōu)化主要針對于冷啟動

2. 查看APP的啟動時間

  • 通過添加環(huán)境變量可以打印出APP的啟動時間：Product -> Scheme -> Edit Scheme -> Run -> Arguments

  • 在環(huán)境變量Environment Variables中增加：DYLD_PRINT_STATISTICS為YES，然后運(yùn)行APP，即可在控制臺中打印出來

  • 如果需要更詳細(xì)的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設(shè)置為YES

3. APP啟動的三大階段

APP啟動分為三大階段：dyld加載可執(zhí)行文件和動態(tài)庫、Runtime初始化OC結(jié)構(gòu)、dyld調(diào)用main函數(shù)及代理方法，如下圖所示

三大階段

(1).dyld

  • dyld是Apple的動態(tài)鏈接器，全稱是dynamic link editor，可以用來裝載Mach-O文件，包括可執(zhí)行文件、動態(tài)庫等

  • 啟動APP時，dyld所做的事情有：

    • 裝載APP的可執(zhí)行文件，同時會遞歸加載所有依賴的動態(tài)庫

    • 當(dāng)dyld把可執(zhí)行文件、動態(tài)庫都裝載完畢后，會通知Runtime進(jìn)行下一步處理

(2).runtime

  • 啟動APP時，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é)果的初始化，包括注冊Objc類、初始化類對象等等

    • 調(diào)用C++靜態(tài)初始化器和__attribute__((constructor))修飾的函數(shù)

  • 到此為止，可行文件和動態(tài)庫中所有的符號，包括Class、Protocol、Selector、IMP等等，都已經(jīng)按格式成功加載到內(nèi)存中，被runtime所管理了

(3).main
  • 所有初始化工作完成后，dyld就會調(diào)用main函數(shù)，然后調(diào)用UIApplicationMain函數(shù)，`然后就是``AppDelegate的application:didFinishLaunchingWithOptions:```方法
(4).總結(jié)

  • APP的啟動由dyld主導(dǎo)，將可執(zhí)行文件加載到內(nèi)存中，順便加載所有依賴的動態(tài)庫

  • 然后runtime負(fù)責(zé)將可執(zhí)行文件等加載成objc定義的結(jié)構(gòu)

  • 所有初始化工作結(jié)束后，dyld就是調(diào)用main函數(shù)，進(jìn)而調(diào)用application:didFinishLaunchingWithOptions:方法

4. APP啟動優(yōu)化

根據(jù)不同的階段，進(jìn)行不同的優(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方法中
    • 按需加載

四、安裝包瘦身

安裝包IPA主要由可執(zhí)行文件、資源組成，所以安裝包瘦身也是從這兩方面考慮

(1). 對于資源的瘦身，包括圖片、音頻、視頻等

(2). - 對可行性文件瘦身

  • 編譯器優(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檢測未使用代碼，打開AppCode后在，在菜單欄->Code->Inspect Code

    • 或者編寫LLVM插件檢測出重復(fù)代碼、未被調(diào)用的代碼

    • 生成LinkMap文件，可以查看可執(zhí)行文件的具體組成，可以借助第三方工具解析LinkMap文件，如下圖所示

image.png
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。