iOS性能優化

時間 2019-11-07

標籤 ios 性能優化欄目 iOS 简体版

原文原文鏈接

本文首發於我的博客php

1、App啓動優化

1.App的啓動能夠分爲2種

冷啓動(Cold Launch):從零開始啓動APP
熱啓動(Warm Launch):APP已經在內存中，在後臺存活着，再次點擊圖標啓動APP
- APP啓動時間的優化，主要是針對冷啓動進行優化
- 經過添加環境變量能夠打印出APP的啓動時間分析(Edit scheme -> Run -> Arguments) DYLD_PRINT_STATISTICS設置爲1
- 若是須要更詳細的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設置爲1

2.App 冷啓動分爲四大階段

dyld 加載可執行文件，動態庫(遞歸加載)
runtime
main() 函數執行後
首屏渲染完成後

2.1關於dyld

在Mac 、iOS中，是使用了/usr/lib/dyld程序來加載動態庫html
dynamic link editor，動態連接編輯器ios
dynamic loader，動態加載器git
dyld 的源碼 opensource.apple.com/tarballs/dy…github
- ```
initializeMainExecutable 方法開始的.dyld會優先初始化動態庫，而後初始化App的可執行文件。
複製代碼
```
用MachOView (github.com/gdbinit/Mac…)查看加載過程如上圖數據庫

（備註1: 若是設置了 DYLD_PRINT_LIBRARIES，或者選中run/diagnostics 下面的 dynamic library loads 那麼 dyld將會打印出什麼庫被加載了緩存

備註2：DYLD_PRINT_STATISTICS_DETAILS 打印啓動時間性能優化

備註3：dyly還能夠抽取蘋果原生庫方法： 1： launch-cache/dsc_extractor.cpp文件中把#if(0) 以及以前的都刪除，#endif也刪除 2：編譯clang++ -o dsc_extractor dsc_extractor.cpp 生成可執行文件 3：./dsc_extractor dyld_shared_cache_armv7s armv7s 進行抽取）bash

2.2 runtime

源碼： opensource.apple.com/source/objc… 源碼分析可參考：www.jianshu.com/p/3019605a4…網絡

啓動APP時，runtime所作的事情有

調用map_images進行可執行文件內容的解析和處理
在load_images中調用call_load_methods，調用全部Class和Category的+load方法進行各類objc結構的初始化(註冊Objc類、初始化類對象等等)
調用C++靜態初始化器和__attribute__((constructor))修飾的函數
到此爲止，可執行文件和動態庫中全部的符號(Class，Protocol，Selector，IMP，...)都已經按格式成功加載到內存中，被 runtime 所管理

關於load和initialize 可參考iOS中load和initialize一文詳細分析

2.3main函數執行後

main() 函數執行後的階段，指的是從 main() 函數執行開始，到 appDelegate 的 didFinishLaunchingWithOptions 方法裏首屏渲染相關方法執行完成。

首屏初始化所需配置文件的讀寫操做
首屏列表大數據的讀取
首屏渲染的大量計算等

總結：

APP的啓動由dyld主導，將可執行文件加載到內存，順便加載全部依賴的動態庫, 並由runtime負責加載成objc定義的結構,全部初始化工做結束後，dyld就會調用main函數, 接下來就是UIApplicationMain函數，AppDelegate的application:didFinishLaunchingWithOptions:方法

3.App啓動優化

按照不一樣的階段

dyld
- 減小動態庫、合併一些動態庫(按期清理沒必要要的動態庫)。減小動態庫加載。每一個庫自己都有依賴關係，蘋果公司建議使用更少的動態庫，蘋果最多支持6個非系統的動態庫合併爲一個。
- 減小Objc類、分類的數量、減小Selector數量(按期清理沒必要要的類、分類)
- 減小C++虛函數數量，減小C++全局變量的數量
- Swift儘可能使用struct
runtime
用+initialize方法和dispatch_once取代全部的__attribute__((constructor))、C++靜態構造器、ObjC的+load，由於在一個+load()方法裏，運行時進行方法替換操做會帶來4毫秒的損耗。
main() 函數執行後
功能級別的優化：main()函數開始執行後到首屏渲染完成前，只處理首屏相關的業務，其餘的非首屏業務的初始化，監聽註冊，配置文件讀取放在首屏渲染完成後去作
ReactiveCocoa建立一個信號6毫秒，+load()執行一次，4毫秒
檢測App耗時
- 抓取主線程的方法調用堆棧，計算一段時間各個方法的耗時，Xcode自帶的Time Profiler
- 對objc_msgSend方法進行hook來掌握全部方法的執行耗時 objc_msgSend源碼 opensource.apple.com/source/objc…
  - fackbook開源了fishhook的代碼https://github.com/facebook/fishhook 其大體思路爲：經過從新綁定符號，實現對c方法的hook。dyld是經過更新Mach-O二進制的_DATA segment特定的部分中的指針來綁定lazy和non-lazy符號，經過確認傳遞給rebind_symbol裏每一個符號更新的位置，就能夠找出替換來從新綁定這些符號。
在不影響用戶體驗的前提下，儘量將一些操做延遲，不要所有都放在finishLaunching方法中按需加載
不使用xib，直接視用代碼加載首頁視圖
NSUserDefaults其實是在Library文件夾下會生產一個plist文件，若是文件太大的話一次能讀取到內存中可能很耗時，這個影響須要評估，若是耗時很大的話須要拆分(需考慮老版本覆蓋安裝兼容問題)
每次用NSLog方式打印會隱式的建立一個Calendar，所以須要刪減啓動時各業務方打的log，或者僅僅針對內測版輸出log
梳理應用啓動時發送的全部網絡請求，是否能夠統一在異步線程請求

2、安裝包瘦身

一、安裝包(IPA)主要由可執行文件、資源組成

資源(圖片、音頻、視頻等)
採起無損壓縮
去除沒有用到的資源: github.com/tinymind/LS…

二、可執行文件瘦身

2.1 編譯器優化

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

2.2利用AppCode

(www.jetbrains.com/objc/)檢測未使用的代碼:菜單欄 -> Code -> Inspect Code

2. 3編寫LLVM插件檢測出重複代碼、未被調用的代碼

2.4 生成LinkMap文件，能夠查看可執行文件的具體組成

2.5 可藉助第三方工具解析LinkMap文件: github.com/huanxsd/Lin…

3、卡頓問題

3.一、CPU 和GPU

CPU (Central Processing Unit，中央處理器)

對象的建立和銷燬、對象屬性的調整、佈局計算、文本的計算和排版、圖片的格式轉換和解碼、圖像的繪製(Core Graphics)
GPU (Graphics Processing Unit，圖形處理器)

紋理的渲染
在iOS中是雙緩衝機制，有前幀緩存、後幀緩存

3.2優化方向

儘量減小CPU、GPU資源消耗
儘可能用輕量級的對象，好比用不到事件處理的地方，能夠考慮使用CALayer取代UIView
不要頻繁地調用UIView的相關屬性，好比frame、bounds、transform等屬性，儘可能減小沒必要要的修改
儘可能提早計算好佈局，在有須要時一次性調整對應的屬性，不要屢次修改屬性
Autolayout會比直接設置frame消耗更多的CPU資源
圖片的size最好恰好跟UIImageView的size保持一致
控制一下線程的最大併發數量
儘可能避免短期內大量圖片的顯示，儘量將多張圖片合成一張進行顯示
GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會佔用CPU資源進行處理，因此紋理儘可能不要超過這個尺寸
儘可能減小視圖數量和層次
減小透明的視圖(alpha<1)，不透明的就設置opaque爲YES
儘可能把耗時的操做放到子線程
- 文本處理(尺寸計算、繪製) p
- 圖片處理(解碼、繪製)

3.三、離屏渲染

儘可能避免出現離屏渲染
在OpenGL中，GPU有2種渲染方式
On-Screen Rendering:當前屏幕渲染，在當前用於顯示的屏幕緩衝區進行渲染操做
Off-Screen Rendering:離屏渲染，在當前屏幕緩衝區之外新開闢一個緩衝區進行渲染操做
離屏渲染消耗性能的緣由
須要建立新的緩衝區
離屏渲染的整個過程，須要屢次切換上下文環境，先是從當前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結束之後，將離屏緩衝區的渲染結果顯示到屏幕上，又須要將上下文環境從離屏切換到當前屏幕
哪些操做會觸發離屏渲染?
光柵化，layer.shouldRasterize = YES
遮罩，layer.mask
圓角，同時設置layer.masksToBounds = YES、layer.cornerRadius大於0（考慮經過CoreGraphics繪製裁剪圓角，或者叫UI提供圓角圖片）
陰影，layer.shadowXXX (若是設置了layer.shadowPath就不會產生離屏渲染)

內存泄露

1、查找泄漏點 (兩種工具)

1 > Analyze

- 學 名:  靜態分析工具- 查 找:  能夠經過 Product ->Analyze 菜單項啓動- 快捷鍵:  CMD+shift +b.- Analyze主要分析如下四種問題:
  1) 邏輯錯誤：訪問空指針或未初始化的變量等；
  2) 內存管理錯誤：如內存泄漏等；
  3) 聲明錯誤：從未使用過的變量；
  4) Api調用錯誤：未包含使用的庫和框架。
複製代碼

2 >Instruments

- 學 名:   動態分析工具- 查 找:   Product ->Profile 菜單項啓動- 快捷鍵:  CMD + i.
簡 介:它有不少跟蹤模塊能夠動態分析和跟蹤內存, CPU 和文件系統.
複製代碼

4、耗電優化

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