面試題
- 你在項目中是怎么優化內存的？
- 優化你是從哪幾方面著手？
- 列表卡頓的原因可能有哪些？你平時是怎么優化的？
- 遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？
渲染卡頓
CPU和GPU
在屏幕成像的過程中，CPU和GPU起著至關重要的作用
- CPU（Central Processing Unit，中央處理器）
- 對象的創建和銷毀、對象屬性的調整、布局計算、文本的計算和排版、圖片的格式轉換和解碼、圖像的繪制（Core Graphics）
- GPU（Graphics Processing Unit，圖形處理器）
-
紋理的渲染
-
- 在iOS中是雙緩沖機制，有前幀緩存、后幀緩存
屏幕成像原理
卡頓產生的原因
- 卡頓解決的主要思路：
盡可能減少CPU、GPU資源消耗 - 按照60FPS的刷幀率，每隔16ms就會有一次VSync信號
卡頓優化 - CPU
- 盡量用輕量級的對象，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView
- 不要頻繁地調用UIView的相關屬性，比如frame、bounds、transform等屬性，盡量減少不必要的修改
- 盡量提前計算好布局，在有需要時一次性調整對應的屬性，不要多次修改屬性
- Autolayout會比直接設置frame消耗更多的CPU資源
- 圖片的size最好剛好跟UIImageView的size保持一致
- 控制一下線程的最大并發數量
- 盡量把耗時的操作放到子線程
- 文本處理（尺寸計算、繪制）
- 圖片處理（解碼、繪制）
卡頓優化 - GPU
- 盡量避免短時間內大量圖片的顯示，盡可能將多張圖片合成一張進行顯示
- GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會占用CPU資源進行處理，所以紋理盡量不要超過這個尺寸
- 盡量減少視圖數量和層次
- 減少透明的視圖（alpha<1），不透明的就設置opaque為YES
- 盡量避免出現離屏渲染
離屏渲染
在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繪制裁剪圓角，或者叫美工提供圓角圖片
- 陰影，layer.shadowXXX
- 如果設置了layer.shadowPath就不會產生離屏渲染
卡頓檢測
- 平時所說的“卡頓”主要是因為在主線程執行了比較耗時的操作
- 可以添加Observer到主線程RunLoop中，通過監聽RunLoop狀態切換的耗時，以達到監控卡頓的目的
耗電優化
耗電的主要來源
- CPU處理，Processing
- 網絡，Networking
- 定位，Location
- 圖像，Graphics
耗電優化
- 盡可能降低CPU、GPU功耗
- 少用定時器
- 優化I/O操作
- 盡量不要頻繁寫入小數據，最好批量一次性寫入
- 讀寫大量重要數據時，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API。用dispatch_io系統會優化磁盤訪問
- 數據量比較大的，建議使用數據庫（比如SQLite、CoreData）
- 網絡優化
- 減少、壓縮網絡數據
- 如果多次請求的結果是相同的，盡量使用緩存
- 使用斷點續傳，否則網絡不穩定時可能多次傳輸相同的內容
- 網絡不可用時，不要嘗試執行網絡請求
- 讓用戶可以取消長時間運行或者速度很慢的網絡操作，設置合適的超時時間
- 批量傳輸，比如，下載視頻流時，不要傳輸很小的數據包，直接下載整個文件或者一大塊一大塊地下載。如果下載廣告，一次性多下載一些，然后再慢慢展示。如果下載電子郵件，一次下載多封，不要一封一封地下載
- 定位優化
- 如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法。定位完成后，會自動讓定位硬件斷電
- 如果不是導航應用，盡量不要實時更新位置，定位完畢就關掉定位服務
- 盡量降低定位精度，比如盡量不要使用精度最高的kCLLocationAccuracyBest
- 需要后臺定位時，盡量設置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動的時候系統會自動暫停位置更新
- 盡量不要使用startMonitoringSignificantLocationChanges，優先考慮startMonitoringForRegion:
- 硬件檢測優化
- 用戶移動、搖晃、傾斜設備時，會產生動作(motion)事件，這些事件由加速度計、陀螺儀、磁力計等硬件檢測。在不需要檢測的場合，應該及時關閉這些硬件
啟動優化
APP的啟動可以分為2種
- 冷啟動（Cold Launch）：從零開始啟動APP
- 熱啟動（Warm Launch）：APP已經在內存中，在后臺存活著，再次點擊圖標啟動APP
APP啟動時間的優化，主要是針對冷啟動進行優化
- 通過添加環境變量可以打印出APP的啟動時間分析（Edit scheme -> Run -> Arguments）
- DYLD_PRINT_STATISTICS設置為1
- 如果需要更詳細的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設置為1
APP的啟動
APP的冷啟動可以概括為3大階段
- dyld
- runtime
-
main
APP的啟動 - dyld
dyld（dynamic link editor），Apple的動態鏈接器，可以用來裝載Mach-O文件（可執行文件、動態庫等）
- 啟動APP時，dyld所做的事情有
- 裝載APP的可執行文件，同時會遞歸加載所有依賴的動態庫
- 當dyld把可執行文件、動態庫都裝載完畢后，會通知Runtime進行下一步的處理
APP的啟動 - runtime
啟動APP時，runtime所做的事情有
- 調用map_images進行可執行文件內容的解析和處理
- 在load_images中調用call_load_methods，調用所有Class和Category的+load方法
- 進行各種objc結構的初始化（注冊Objc類 、初始化類對象等等）
- 調用C++靜態初始化器和attribute((constructor))修飾的函數
到此為止，可執行文件和動態庫中所有的符號(Class，Protocol，Selector，IMP，…)都已經按格式成功加載到內存中，被runtime 所管理
APP的啟動 - main
總結一下
- APP的啟動由dyld主導，將可執行文件加載到內存，順便加載所有依賴的動態庫
- 并由runtime負責加載成objc定義的結構
- 所有初始化工作結束后，dyld就會調用main函數
- 接下來就是UIApplicationMain函數，AppDelegate的application:didFinishLaunchingWithOptions:方法
APP的啟動優化
按照不同的階段
- dyld
- 減少動態庫、合并一些動態庫（定期清理不必要的動態庫）
- 減少Objc類、分類的數量、減少Selector數量（定期清理不必要的類、分類）
- 減少C++虛函數數量
- Swift盡量使用struct
- runtime
- 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態構造器、ObjC的+load
- main
- 在不影響用戶體驗的前提下，盡可能將一些操作延遲，不要全部都放在finishLaunching方法中
- 按需加載
安裝包優化
安裝包瘦身
安裝包（IPA）主要由可執行文件、資源組成
-
資源（圖片、音頻、視頻等）
- 采取無損壓縮
- 去除沒有用到的資源： https://github.com/tinymind/LSUnusedResources
-
可執行文件瘦身
-
編譯器優化
- 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
生成LinkMap文件，可以查看可執行文件的具體組成
可借助第三方工具解析LinkMap文件： https://github.com/huanxsd/LinkMap
