image

好的app應該有好的性能流暢度，本篇文章就大概講一下ios性能優(yōu)化。

先來談談CPU和GPU

• 在屏幕成像的過程中，CPU和GPU起著至關重要的作用
• CPU( Central Processing Unit, 中央處理器)就是機器的“大腦”，也是布局謀略、發(fā)號施令、控制行動的“總司令官”。
• CPU的結構主要包括運算器（ALU, Arithmetic and Logic Unit）、控制單元（CU, Control Unit）、寄存器（Register）、高速緩存器（Cache）和它們之間通 訊的數(shù)據(jù)、控制及狀態(tài)的總線。
• GPU全稱為Graphics Processing Unit，中文為圖形處理器，就如它的名字一樣，GPU最初是用在個人電腦、工作站、游戲機和一些移動設備（如平板電腦、智能手機等）上運行繪圖運算工作的微處理器。
• 為什么GPU特別擅長處理圖像數(shù)據(jù)呢？這是因為圖像上的每一個像素點都有被處理的需要，而且每個像素點處理的過程和方式都十分相似，也就成了GPU的天然溫床。

image

在iOS中是雙緩沖機制，有前幀緩存、后幀緩存，即GPU會預先渲染好一幀放入一個緩沖區(qū)內（前幀緩存），讓視頻控制器讀取，當下一幀渲染好后，GPU會直接把視頻控制器的指針指向第二個緩沖器（后幀緩存）。當你視頻控制器已經(jīng)讀完一幀，準備讀下一幀的時候，GPU會等待顯示器的VSync信號發(fā)出后，前幀緩存和后幀緩存會瞬間切換，后幀緩存會變成新的前幀緩存，同時舊的前幀緩存會變成新的后幀緩存。

屏幕成像原理

image

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

image

在Sync信號到來后，系統(tǒng)圖形服務會通過CADisplayLink等機制通知App，App主線程開始在CPU中計算顯示內容，比如視圖的創(chuàng)建，布局計算，圖片解碼，文本繪制等。隨后CPU會將計算好的內容提交到GPU去，由GPU進行交換，合成，渲染。隨后GPU會把渲染結果提交到幀緩沖區(qū)，等待下一次VSync信號（垂直同步信號）到來時顯示到屏幕上。由于垂直同步機制，如果在一個VSync時間內，CPU或者GPU沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏因為沒有新的刷新，會保留之前的內容不變。這就造成了卡頓。

• 按照60FPS的刷幀率，每隔16ms就會有一次VSync信號

卡頓優(yōu)化 -CPU

• 盡量用輕量級的對象，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView
• 不要頻繁地調用UIView的相關屬性，比如frame、bounds、transform等屬性，盡量減少不必要的修改
• 盡量提前計算好布局，在有需要時一次性調整對應的屬性，不要多次修改屬性
• Autolayout會比直接設置frame消耗更多的CPU資源
• 圖片的size最好剛好跟UIImageView的size保持一致
• 控制一下線程的最大并發(fā)數(shù)量
• 盡量把耗時的操作放到子線程

卡頓優(yōu)化 -GPU

• 盡量避免短時間內大量圖片的顯示，盡可能將多張圖片合成一張進行顯示
• 盡量減少視圖數(shù)量和層次
• 減少透明的視圖（alpha<1），不透明的就設置opaque為YES
• 盡量避免出現(xiàn)離屏渲染

離屏渲染

• 在OpenGL中，GPU有2種渲染方式
  1.On-Screen Rendering：當前屏幕渲染，在當前用于顯示的屏幕緩沖區(qū)進行渲染操作
  2.Off-Screen Rendering：離屏渲染，在當前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作
• 離屏渲染消耗性能的原因
  1.需要創(chuàng)建新的緩沖區(qū)
  2.離屏渲染的整個過程，需要多次切換上下文環(huán)境，先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結束以后，將離屏緩沖區(qū)的渲染結果顯示到屏幕上，又需要將上下文環(huán)境從離屏切換到當前屏幕
• 哪些操作會觸發(fā)離屏渲染？
  1.光柵化，layer.shouldRasterize = YES
  2.遮罩，layer.mask
  3.圓角，同時設置layer.masksToBounds = YES、layer.cornerRadius大于0
  考慮通過CoreGraphics繪制裁剪圓角，或者叫美工提供圓角圖片
  4.陰影，layer.shadowXXX
  如果設置了layer.shadowPath就不會產(chǎn)生離屏渲染

耗電優(yōu)化

耗電的主要來源？

image

• CPU處理，Processing
• 網(wǎng)絡，Networking
• 定位，Location
• 圖像，Graphics

1. 定位優(yōu)化

• 如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法。定位完成后，會自動讓定位硬件斷電
• 如果不是導航應用，盡量不要實時更新位置，定位完畢就關掉定位服務
• 盡量降低定位精度，比如盡量不要使用精度最高的kCLLocationAccuracyBest
• 需要后臺定位時，盡量設置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
• 盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:

APP啟動優(yōu)化

先來看app啟動流程

APP的啟動可以分為2種

1、冷啟動（Cold Launch）：從零開始啟動APP
2、熱啟動（Warm Launch）：APP已經(jīng)在內存中，在后臺存活著，再次點擊圖標啟動APP

APP啟動時間的優(yōu)化，主要是針對冷啟動進行優(yōu)化

• 通過添加環(huán)境變量可以打印出APP的啟動時間分析（Edit scheme -> Run -> Arguments）
  1、DYLD_PRINT_STATISTICS設置為1
  2、如果需要更詳細的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設置為1

APP的冷啟動概括為三大階段

• dyld，Apple的動態(tài)鏈接器，可以用來裝載Mach-O文件（可執(zhí)行文件、動態(tài)庫等）
  啟動APP時，dyld所做的事情有
  1.裝載APP的可執(zhí)行文件，同時會遞歸加載所有依賴的動態(tài)庫
  2.當dyld把可執(zhí)行文件、動態(tài)庫都裝載完畢后，會通知Runtime進行下一步的處理

• runtime
啟動APP時，runtime所做的事情有
  1.調用map_images進行可執(zhí)行文件內容的解析和處理
  2.在load_images中調用call_load_methods，調用所有Class和Category的+load方法
  3.進行各種objc結構的初始化（注冊Objc類 、初始化類對象等等）
  4.調用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)
  到此為止，可執(zhí)行文件和動態(tài)庫中所有的符號(Class，Protocol，Selector，IMP，…)都已經(jīng)按格式成功加載到內存中，被runtime 所管理

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

image

優(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)構造器、ObjC的+load

三、main

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

后面會分享自己的優(yōu)化過程

• Follow: https://github.com/sallenhandong
• Source: slimsallen.com/#/detail/iosperformance.md