一、CPU和GPU 的介紹

• 1.1、在螢幕成像的過程中，CPU和GPU起著至關重要的作用
  • CPU（Central Processing Unit，中央處理器），物件的建立和銷燬、物件屬性的調整、佈局計算、文字的計算和排版、圖片的格式轉換和解碼、影象的繪製（Core Graphics）

  • GPU（Graphics Processing Unit，圖形處理器），紋理的渲染，說白了就是介面的展示

    
    CPU和GPU的機制圖
  • 在iOS中是雙緩衝機制，有前幀快取、後幀快取

• 1.2、螢幕成像原理

  
  螢幕成像原理

• 1.3、卡頓產生的原因

  
  卡頓產生的原因：CPU與GPU的消耗時間太長
  • 卡頓解決的主要思路
    ：儘可能減少CPU、GPU資源消耗
  • 按照60FPS(1秒鐘重新整理60幀)的刷幀率，每隔16ms(1000s/60 = 16ms)就會有一次VSync訊號,就可以保證不會卡，也不會掉幀

二、卡頓優化 - CPU

• 2.1、儘量用輕量級的物件，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView
• 2.2、不要頻繁地呼叫UIView的相關屬性，比如frame、bounds、transform等屬性，儘量減少不必要的修改
• 2.3、儘量提前計算好佈局，在有需要時一次性調整對應的屬性，不要多次修改屬性
• 2.4、Autolayout會比直接設定frame消耗更多的CPU資源
• 2.5、圖片的size最好剛好跟UIImageView的size保持一致
• 2.6、控制一下執行緒的最大併發數量
• 2.7、儘量把耗時的操作放到子執行緒
  • 文字處理（尺寸計算、繪製）
  • 圖片處理（解碼、繪製）

三、卡頓優化 - GPU

• 3.1、儘量避免短時間內大量圖片的顯示，儘可能將多張圖片合成一張進行顯示
• 3.2、GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個尺寸，就會佔用CPU資源進行處理，所以紋理儘量不要超過這個尺寸
• 3.3、儘量減少檢視數量和層次
• 3.4、減少透明的檢視（alpha<1），不透明的就設定opaque為YES(預設就是YES)
• 3.5、儘量避免出現離屏渲染
• 3.6、離屏渲染

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

四、耗電優化

• 4.1、耗電的主要來源

  耗電的主要來源
  • CPU處理，Processing
  • 網路，Networking
  • 定位，Location
  • 影象，Graphics

• 4.2、耗電優化

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

• 五、APP的啟動的優化

  • 5.1、APP的啟動可以分為2種
    • 冷啟動（Cold Launch）：從零開始啟動APP
    • 熱啟動（Warm Launch）：APP已經在記憶體中，在後臺存活著，再次點選圖示啟動APP
  • 5.2、APP啟動時間的優化，主要是針對冷啟動進行優化
    • 通過新增環境變數可以打印出APP的啟動時間分析（Product -> Scheme-> Edit scheme -> Run -> Arguments->Environment Variables下新增）
    • DYLD_PRINT_STATISTICS設定為1
      DYLD_PRINT_STATISTICS 大概的耗時統計
    • 如果需要更詳細的資訊，那就將DYLD_PRINT_STATISTICS_DETAILS設定為1
      更詳細的資訊

  • 5.3、APP的冷啟動可以概括為3大階段

    
    APP的冷啟動可以概括為3大階段
    • dyld（dynamic link editor），Apple的動態連結器，可以用來裝載Mach-O檔案（可執行檔案、動態庫等）
      • 啟動APP時，dyld所做的事情有，1.裝載APP的可執行檔案，同時會遞迴載入所有依賴的動態庫，2.當dyld把可執行檔案、動態庫都裝載完畢後，會通知Runtime進行下一步的處理
    • runtime，啟動APP時所做的事情有
      • 呼叫map_images進行可執行檔案內容的解析和處理
      • 在load_images中呼叫call_load_methods，呼叫所有Class和Category的+load方法
      • 進行各種objc結構的初始化（註冊Objc類 、初始化類物件等等）
      • 呼叫C++靜態初始化器和attribute((constructor))修飾的函式
      • 到此為止，可執行檔案和動態庫中所有的符號(Class，Protocol，Selector，IMP，…)都已經按格式成功載入到記憶體中，被runtime 所管理
    • main
      • APP的啟動由dyld主導，將可執行檔案載入到記憶體，順便載入所有依賴的動態庫
      • 並由runtime負責載入成objc定義的結構
      • 所有初始化工作結束後，dyld就會呼叫main函式
      • 接下來就是UIApplicationMain函式，AppDelegate的application:didFinishLaunchingWithOptions:方法
  • 5.4、APP的啟動優化方案(按照不同的階段)

    • dyld

      • 減少動態庫、合併一些動態庫（定期清理不必要的動態庫）
      • 減少Objc類、分類的數量、減少Selector數量（定期清理不必要的類、分類）
      • 減少C++虛擬函式數量
      • Swift儘量使用struct

    • runtime

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

    • main

      • 在不影響使用者體驗的前提下，儘可能將一些操作延遲，不要全部都放在finishLaunching方法中
      • 按需載入(舉個例子，剛進入app只需要載入首頁的收據就好了，不需要載入所有頁面的資料)

• 六、安裝包瘦身

  • 6.1、安裝包（IPA）主要由可執行檔案、資源組成
  • 6.2、資源（圖片、音訊、視訊等）
    • 採取無失真壓縮(資源質量不會發生變化，但是大小會變小，必須圖片用 png圖片壓縮神器)
    • 去除沒有用到的資源，下面是我測試圖片資源的情況，我在桌面有一個專案CPU&GPU,裡面放了幾張圖片，都沒有使用
      CPU&GPU
      利用LSUnusedResources檢測沒有使用的資源
  • 6.3、可執行檔案瘦身
    • 編譯器優化
      • (1)Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default設定為YES，xcode 預設這些都是 YES
        編譯器優化
      • (2)去掉異常支援，Enable C++ Exceptions、Enable Objective-C Exceptions設定為NO， Other C Flags新增-fno-exceptions
        Enable C++ Exceptions
      • (3)利用 AppCode 檢測未使用的程式碼：選單欄 ->Code->InspectCode
        • AppCode 使用以及註冊說明，下載以後使用註冊碼註冊，AppCode2018.2安裝（破解） Mac , AppCode2018 註冊碼獲取
          AppCode破解後
        • AppCode 的使用
          AppCode來檢測未使用類和屬性
      • (4)編寫LLVM外掛檢測出重複程式碼、未被呼叫的程式碼(這個比較難)
      • (5) LinkMap，生成LinkMap檔案，可以檢視 可執行檔案的具體組成(生成檔案後記得回覆原樣)
        LinkMap
        上面的地址我寫為了/Users/wangchong/Desktop/,執行之後再桌面生成了CPU&GPU-LinkMap-normal-x86_64.txt檔案
        CPU&GPU-LinkMap-normal-x86_64.txt

      • 分析LinkMap檔案

        
        分析LinkMap檔案
      • 藉助第三方工具解析LinkMap檔案：https://github.com/huanxsd/LinkMap
        解析LinkMap檔案

• 七、下面是幾個問題(不懂的看上面)

  • 你在專案中是怎麼優化記憶體的？
  • 優化你是從哪幾方面著手？
  • 列表卡頓的原因可能有哪些？你平時是怎麼優化的？
  • 遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？