iOS性能優(yōu)化看這一篇就夠了

處理器優(yōu)化

CPU和GPU

  • 在屏幕成像的過程中，CPU和GPU起著至關重要的作用
    CPU：（Central Processing Unit，中央處理器）
    負責對象的創(chuàng)建和銷毀、對象屬性的調整、布局計算、文本的計算和排版、圖片的格式轉換和解碼、圖像的繪制（Core Graphics）
    GPU：（Graphics Processing Unit，圖形處理器）
    負責紋理的渲染


    視圖顯示流程

  • 在iOS中是雙緩沖機制，有前幀緩存、后幀緩存


    屏幕成像原理

    當垂直同步信號來的時候，開始水平同步信號按行進行刷新屏幕像素。

卡頓產生的原因

按照60FPS的刷幀率，每隔16ms就會有一次VSync信號，一旦垂直同步信號來了，GPU會立馬將幀緩存區(qū)的數據顯示到屏幕上去，并且馬上開始下一幀的操作，在16ms時間內GPU沒有處理完成，GPU就會將這一次的數據拋棄掉，屏幕就會顯示上一次渲染完成的數據，從而產生掉幀，就是卡頓現象。

  • 卡頓解決的主要思路
    盡可能減少CPU、GPU資源消耗
卡頓優(yōu)化 - CPU
  • 盡量用輕量級的對象，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView
  • 不要頻繁地調用UIView的相關屬性，比如frame、bounds、transform等屬性，盡量減少不必要的修改
  • 盡量提前計算好布局，在有需要時一次性調整對應的屬性，不要多次修改屬性，比如tableViewCell刷新時候，每個cell對應一個處理好的layout值。
  • Autolayout會比直接設置frame消耗更多的CPU資源，這個在新版本的iOS里autolayout性能已經接近于frame。
  • 圖片的size最好剛好跟UIImageView的size保持一致，有些廠商的cdn上會包含這個功能，拉取圖片時候可以直接指定圖片大小，無論對渲染還是內存都是一個好的方案。
  • 控制一下線程的最大并發(fā)數量
  • 盡量把耗時的操作放到子線程
    文本處理（尺寸計算、繪制）
    圖片處理（解碼、繪制）
卡頓優(yōu)化 - GPU
  • 盡量避免短時間內大量圖片的顯示，盡可能將多張圖片合成一張進行顯示
  • GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會占用CPU資源進行處理，所以紋理盡量不要超過這個尺寸
  • 盡量減少視圖數量和層次
  • 減少透明的視圖（alpha<1），不透明的就設置opaque為YES
  • 盡量避免出現離屏渲染
離屏渲染
  • 在OpenGL中，GPU有2種渲染方式
    On-Screen Rendering：當前屏幕渲染，在當前用于顯示的屏幕緩沖區(qū)進行渲染操作
    Off-Screen Rendering：離屏渲染，在當前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作
  • 離屏渲染消耗性能的原因
    需要創(chuàng)建新的緩沖區(qū)
    離屏渲染的整個過程，需要多次切換上下文環(huán)境，先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結束以后，將離屏緩沖區(qū)的渲染結果顯示到屏幕上，又需要將上下文環(huán)境從離屏切換到當前屏幕
  • 哪些操作會觸發(fā)離屏渲染？
    光柵化，layer.shouldRasterize = YES
    遮罩，layer.mask
    圓角，同時設置layer.masksToBounds = YES、layer.cornerRadius大于0
    考慮通過CoreGraphics繪制裁剪圓角，或者叫美工提供圓角圖片
    陰影，layer.shadowXXX
    如果設置了layer.shadowPath就不會產生離屏渲染
卡頓檢測

平時所說的“卡頓”主要是因為在主線程執(zhí)行了比較耗時的操作
可以添加Observer到主線程RunLoop中，通過監(jiān)聽RunLoop狀態(tài)切換的耗時，以達到監(jiān)控卡頓的目的

觸發(fā)卡頓的時間閾值，我們可以根據 WatchDog 機制來設置。
WatchDog 在不同狀態(tài)下設置的不同時間，如下所示：
啟動（Launch）：20s；
恢復（Resume）：10s；
掛起（Suspend）：10s；
退出（Quit）：6s；
后臺（Background）：3min（在 iOS 7 之前，每次申請 10min； 之后改為每次申請 3min，可連續(xù)申請，最多申請到 10min）。
通過 WatchDog 設置的時間，我認為可以把啟動的閾值設置為 10 秒，其他狀態(tài)則都默認設置為 3 秒?？偟脑瓌t就是，要小于 WatchDog 的限制時間。當然了，這個閾值也不用小得太多，原則就是要優(yōu)先解決用戶感知最明顯的體驗問題。

耗電優(yōu)化

耗電主要來源

CPU處理，Processing
網絡，Networking
定位，Location
圖像，Graphics

耗電優(yōu)化
  • 盡可能降低CPU、GPU功耗
  • 少用定時器
  • 優(yōu)化I/O操作
    盡量不要頻繁寫入小數據，最好批量一次性寫入
    讀寫大量重要數據時，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API。用dispatch_io系統(tǒng)會優(yōu)化磁盤訪問
    數據量比較大的，建議使用數據庫（比如SQLite、CoreData）
  • 網絡優(yōu)化
    減少、壓縮網絡數據
    如果多次請求的結果是相同的，盡量使用緩存
    使用斷點續(xù)傳，否則網絡不穩(wěn)定時可能多次傳輸相同的內容
    網絡不可用時，不要嘗試執(zhí)行網絡請求
    讓用戶可以取消長時間運行或者速度很慢的網絡操作，設置合適的超時時間
    批量傳輸，比如，下載視頻流時，不要傳輸很小的數據包，直接下載整個文件或者一大塊一大塊地下載。如果下載廣告，一次性多下載一些，然后再慢慢展示。如果下載電子郵件，一次下載多封，不要一封一封地下載
  • 定位優(yōu)化
    如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法。定位完成后，會自動讓定位硬件斷電
    如果不是導航應用，盡量不要實時更新位置，定位完畢就關掉定位服務
    盡量降低定位精度，比如盡量不要使用精度最高的kCLLocationAccuracyBest
    需要后臺定位時，盡量設置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
    盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:
  • 硬件檢測優(yōu)化
    用戶移動、搖晃、傾斜設備時，會產生動作(motion)事件，這些事件由加速度計、陀螺儀、磁力計等硬件檢測。在不需要檢測的場合，應該及時關閉這些硬件

啟動優(yōu)化

  • APP的啟動可以分為2種
    冷啟動（Cold Launch）：從零開始啟動APP
    熱啟動（Warm Launch）：APP已經在內存中，在后臺存活著，再次點擊圖
    啟動APP
  • APP啟動時間的優(yōu)化，主要是針對冷啟動進行優(yōu)化
  • 通過添加環(huán)境變量可以打印出APP的啟動時間分析（Edit scheme -> Run -> Arguments）
    DYLD_PRINT_STATISTICS設置為1
    如果需要更詳細的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設置為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)庫
    當dyld把可執(zhí)行文件、動態(tài)庫都裝載完畢后，會通知Runtime進行下一步的處理
runtime
  • 啟動APP時，runtime所做的事情有
    調用map_images進行可執(zhí)行文件內容的解析和處理
    在load_images中調用call_load_methods，調用所有Class和Category的+load方法
    進行各種objc結構的初始化（注冊Objc類 、初始化類對象等等）
    調用C++靜態(tài)初始化器和attribute((constructor))修飾的函數
  • 到此為止，可執(zhí)行文件和動態(tài)庫中所有的符號(Class，Protocol，Selector，IMP，…)都已經按格式成功加載到內存中，被runtime 所管理

main

  • 總結一下
    APP的啟動由dyld主導，將可執(zhí)行文件加載到內存，順便加載所有依賴的動態(tài)庫
    并由runtime負責加載成objc定義的結構
    所有初始化工作結束后，dyld就會調用main函數
    接下來就是UIApplicationMain函數，AppDelegate的application:didFinishLaunchingWithOptions:方法

APP的啟動優(yōu)化

按照不同的階段

  • dyld
    減少動態(tài)庫、合并一些動態(tài)庫（定期清理不必要的動態(tài)庫）
    減少Objc類、分類的數量、減少Selector數量（定期清理不必要的類、分類）
    減少C++虛函數數量
    Swift盡量使用struct

  • runtime
    用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構造器、ObjC的+load

  • main
    在不影響用戶體驗的前提下，盡可能將一些操作延遲，不要全部都放在finishLaunching方法中
    按需加載

安裝包瘦身

  • 安裝包（IPA）主要由可執(zhí)行文件、資源組成

  • 資源（圖片、音頻、視頻等）
    采取無損壓縮
    去除沒有用到的資源： https://github.com/tinymind/LSUnusedResources

  • 可執(zhí)行文件瘦身
    編譯器優(yōu)化
    Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default設置為YES
    去掉異常支持，Enable C++ Exceptions、Enable Objective-C Exceptions設置為NO， Other C Flags添加-fno-exceptions

  • 利用AppCode（https://www.jetbrains.com/objc/）檢測未使用的代碼：菜單欄 -> Code -> Inspect Code

  • 編寫LLVM插件檢測出重復代碼、未被調用的代碼

LinkMap
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

  • 為了表示我對簡書『飽醉豚』事件的不滿，簡書不再更新，后續(xù)有文章只更新 個人博客和 掘金 歡迎移步 個人博客或者 掘...
    eagleyz閱讀 732評論 0贊 4
  • 前言隨著移動互聯網的發(fā)展，產品的更新迭代，公司業(yè)務的不斷擴展，移動應用頁面布局也越來越復雜，效果越來越炫，自身業(yè)務...
    天空像天空一樣藍閱讀 633評論 0贊 2
  • 目錄一: 卡頓檢測以及原理runloop卡頓檢測消息轉發(fā)解決定時器循環(huán)引用GCD定時器封裝NSProxy消息轉發(fā)T...
    江水東流閱讀 9,262評論 2贊 30
  • 為了表示我對簡書『飽醉豚』事件的不滿，簡書不再更新，后續(xù)有文章只更新 個人博客和 掘金 歡迎移步 個人博客或者 掘...
    eagleyz閱讀 1,105評論 0贊 2
  • 殺生－西南邊陲"長壽鎮(zhèn)"的愛情，親情與人心 西南邊陲偏僻的一個鎮(zhèn)子，在這里，不像城市人給自己的情緒包裹上外...
    拾祁閱讀 1,006評論 0贊 2

友情鏈接更多精彩內容