（一）卡頓優化

【了解CPU和GPU】

在屏幕成像過程中，CPU和GPU的作用是至關重要的。

• CPU - Central Processing Unit，中央處理器，在iOS程序中，負責對象的創建和銷毀、對象屬性的調整、布局的計算、文本的計算和排版規格、圖片的格式轉碼和解碼、圖像的繪制（Core Graphic）
• GPU - Graphics Processing Unit，圖形處理器，負責紋理的渲染。如果沒有接觸過OpenGL的朋友，可能不太好理解紋理渲染這個概念，我們知道，屏幕上面的物理元件是像素，我們在屏幕上面看到的圖片，文字，視頻，就是由屏幕上的所有像素，通過控制色值變化而呈現出來的。那么像素的色值數據，就是由GPU計算得出的，然后將這些數據提交給視頻控制器，由它負責顯示到屏幕上。
  
  
  iOS中采用的是雙緩沖機制，分為前幀緩存和后幀緩存。

【屏幕成像原理】

屏幕成像原理是一個非常龐大的知識體系，這里僅介紹一下我們當前所需要了解的部分，以便我們接下來的話題。
屏幕的顯示，是受控于兩種信號

• 垂直同步信號（VSync）
  屏幕發出VSync之后，就表示將要進行新一幀畫面的顯示，于是開始從幀緩存里面讀取經過GPU渲染好的用于顯示的數據
• 水平同步信號（HSync）
  顯示器從幀緩存里拿到數據之后，是從上到下一行一行的刷新的，刷新完一行，就發出一個HSync，直到最下面一層顯示出來，這樣，一幀的畫面就完成了顯示。
  

我們可以把屏幕想象成刷墻師傅，每一幀的數據就是桶里的油漆，而GPU就是負責提供油漆的店老板。

【卡頓產生的原因】

我們手機屏幕的刷幀率是60FPS（Frame per Second 幀/秒），也就是會所1秒鐘的時間，屏幕可以刷新60幀（次）。完成一幀刷新的用時是16.6毫秒。因此垂直同步信號VSync就是每16.6毫秒發出一次。

兩次VSync之間的這16.6毫秒，就是被CPU和GPU共同完成下一幀畫面的計算和渲染工作的時間。但是CPU計算和GPU渲染所用的時間是取決于任務的運算量的，因此就有可能大于16.6毫秒，也有可能小于或者等于16.6毫秒。

這里我們假設Tc=CPU計算時間，Tg=GPU渲染時間。如果Tc+Tg <= 16.6ms，那么完美，下一幀畫面的數據可以在VSync到來之間就準備好；但是如果Tc+Tg > 16.6ms，意味著屏幕將要開始顯示下一幀畫面了，但是CPU和GPU那里卻還在咔咔咔的準備著畫面數據，那么沒辦法，在接下來的16.6ms周期里面，屏幕就繼續用上一幀的畫面數據來顯示。同一個畫面被顯示了過長的時間，就造成了視覺上可感知到的卡頓現象。再通過下圖來體會一下

畫面卡頓的產生

【卡頓優化-CPU】

上看我們了解了產生的原因，就是由于CPU計算時間和GPU的渲染時間過長導致的。因此想要優化卡頓問題，無非就是從CPU和GPU下手，減輕它們的工作量，以控制它們的操作耗時。

首先開看看CPU，我們有如下途徑來減輕它的計算任務

盡量用輕量級的對象，比如簡單的數字，盡量選擇基礎數據類型，不要使用NSNumber，對象操作的開銷肯定大于基礎數據類型的開銷。

CALayer是用來顯示圖像的，UIView是負責處理觸摸交互事件的，UIView內部封裝了CALayer屬性，因此UIView的圖像顯示實際上是它內部的這個CALayer來完成的。因此如果我們不需要考慮觸摸事件，只是單純的要顯示內容的話，可以考慮用CALayer取代UIView。

盡量提前計算好布局，在有需要的時候一次性調整對應屬性，不要多次修改

圖片的size最好是跟UIImageView的size剛好一致，可以省去圖片剪裁的操作開銷

控制一下線程的最大并發數

盡量把耗時操作放到子線程處理（比如文本的尺寸計算、繪制，圖片的解碼、繪制）

【卡頓優化-GPU】

對與GPU，有下列方案可以減少渲染開銷

• 盡量避免段時間內大量的圖片顯示，盡可能將多張圖片合成一張圖片顯示，比如說三張圖片同時顯示，不如將這三張圖片合成到一塊作為一張圖片來顯示
• GPU能處理的最大紋理尺寸是4096*4096，一旦超過這個尺寸，就會占用CPU資源進行處理，這樣勢必影響CPU的運算效率，因此紋理盡量不要超過這個尺寸
• 盡量減少視圖的數量和層級
• 減少不必要的透明的視圖
• 盡量避免離屏渲染

【離屏渲染】

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

• 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就不會產生離屏渲染??

【卡頓檢測】

平時我們所碰到的卡頓，主要是在主線程執行了比較耗時的操作，可以在主線程RunLoop中添加observer，通過監聽RunLoop的狀態切換耗時，來監控卡頓。

（二）耗電優化

iOS設備耗電來源

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

耗電優化方案

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

（三）啟動優化

【App啟動過程分析】

App的啟動可以分為兩種

• 冷啟動：從零開始啟動App
• 熱啟動：App已經在內存中，處在后臺狀態中，在次點擊圖標啟動App

App的啟動時間優化，主要是針對冷啟動來進行優化的。那么首先我們就需要了解一下App的冷啟動過程包含哪些步驟。

• （一）dyld階段：dyld1dynamic link editor），Apple的動態鏈接器，可用來加載Mach-O文件（可執行文件、動態庫等等）。冷啟動一個app之后，首先是dyld開始工作，它負責兩件事情：
  1. 加載App的可執行文件，同時會遞歸加載所有依賴庫的動態庫。
  2. 當完成可執行文件和動態庫的加載之后，就通知Runtime進行下一步處理。
• （二）Runtime階段：在這個階段，Runtime做了如下的工作：
  1. 調用map_images函數對可執行文件的內容進行解析和處理。
  2. 在load_images函數中調用call_load_methods，以調用所有Class和Category的+load方法。
  3. 進行各種objc結構的初始化（例如objc類的注冊，初始化類對象等等）
  4. 調用C++靜態初始化器以及被_attribute_((constructor))修飾的函數

到此為止，可執行文件和動態庫中的所有所有Symbols（符號，包括 Class， Protocol， Selector， IMP等等）都已經按照規定格式加載到內存中，并且被runtime所管理

• （三）main函數階段
  小結
• App的冷啟動由dyld主導，將可執行文件加載到內存，順便把所依賴的動態庫也加載到內存，然后通知runtime進行相應處理
• runtime負責將上面的內容初始化成`bjc定義的結構體
• 最后當初始化工作完成后，dyld就會調用main函數。接下來便是main函數-->UIApplicationMain函數 -->didFinishLaunchingWithOptions方法。

【App啟動優化】

dyld階段優化

• 減少動態庫，合并一些動態庫，定期清理不必要的動態庫
• 減少Objc類、Category的數量，減少Selector數量，定期清理不再需要的Class和Category
• 減少C++虛函數的數量，因為虛函數會導致額外的虛表的存在
• 如果是Swift盡量使用struct

Runtime階段優化

• 用+initialize方法+dispatch_once的組合來取代所有的 _attribute_((constructor))、C++靜態構造器、Objc的+load方法。

main階段優化
在不影響用戶體驗的前提下，盡可能講一些操作延遲，不要全都放在didFinishLaunchingWithOptions方法中。

（四）安裝包瘦身

iOS的安裝包（ipa）主要有可執行文件和資源組成
可執行文件——就是由我們iOS項目的代碼經過編譯連接產生的二進制文件，要想對可執行文件進行瘦身，有如下幾種思路：

• 編譯器優化
  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檢測項目中用不到的代碼：菜單 --> Code --> Inspect Code
  資源——包括我們iOS項目中的圖片、音頻、視頻、storyboard等，對其進行優化的思路有
• 對資源進行無損壓縮
• 去除沒有用到的資源（第三方檢測工具）