iOS 啟動速度優化和安裝包優化簡單總結

orilme發表於2019-04-14
iOS優化

啟動速度優化

main()呼叫之前的耗時我們可以優化的點有：

  1. 減少不必要的framework，因為動態連結比較耗時
  2. check framework應當設為 optional 和 required ，如果該framework在當前App支援的所有iOS系統版本都存在，那麼就設為required，否則就設為 optional，因為 optional 會有些額外的檢查
  3. 合併或者刪減一些OC類，關於清理專案中沒用到的類，使用工具AppCode程式碼檢查功能
  4. 刪減一些無用的靜態變數
  5. 刪減沒有被呼叫到或者已經廢棄的方法 stackoverflow.com/questions/3… developer.Apple.com/library/ios…
  6. 將不必須在 +load 方法中做的事情延遲到 +initialize 中
  7. 儘量不要用 C++ 虛擬函式(建立虛擬函式表有開銷)

main()呼叫之後的載入時間

  • 分析
    在main()被呼叫之後，App的主要工作就是初始化必要的服務，顯示首頁內容等。而我們的優化也是圍繞如何能夠快速展現首頁來開展。
    App通常在 AppDelegate 類中的didFinishLaunchingWithOptions: 方法中建立首頁需要展示的view，然後在當前runloop的末尾，主動呼叫CA::Transaction::commit完成檢視的渲染。
    而檢視的渲染主要涉及三個階段：
    1. 準備階段 這裡主要是圖片的解碼
    2. 佈局階段 首頁所有UIView的 layoutSubViews 執行
    3. 繪製階段 首頁所有UIView的 drawRect: 執行 再加上啟動之後必要服務的啟動、必要資料的建立和讀取，這些就是我們可以嘗試優化的地方
  • main()函式呼叫之後可以優化的點：
    1. 不使用是storyboard、xib，直接視用程式碼載入首頁檢視
    2. NSUserDefaults實際上是在Library資料夾下會生產一個plist檔案，如果檔案太大的話一次能讀取到記憶體中可能很耗時，這個影響需要評估，如果耗時很大的話需要拆分(需考慮老版本覆蓋安裝相容問題)
    3. 每次用NSLog方式列印會隱式的建立一個Calendar，因此需要刪減啟動時各業務方打的log，或者僅僅針對內測版輸出log
    4. 梳理應用啟動時傳送的所有網路請求，是否可以統一在非同步執行緒請求

具體優化點

  1. 對 didFinishLaunching 裡的函式考慮能否挖掘可以延遲載入或者懶載入
  2. 已經下線的業務，刪減冗餘程式碼
  3. 一些與UI展示無關的業務，如微博認證過期檢查、圖片最大快取空間設定等做延遲載入
  4. 啟動之後展示閃屏廣告圖的同時初始化首頁的列表頁，當廣告展示完成之後列表頁也就渲染完成了。經過這一次優化之後的main()之後的啟動總時長通過上線之後收集資料的驗證達到了預期的效果。
  5. didFinishLaunchingWithOptions：
    • 梳理各個二方/三方庫，找到可以延遲載入的庫，做延遲載入處理，比如放到首頁控制器的viewDidAppear方法裡。
    • 梳理業務邏輯，把可以延遲執行的邏輯，做延遲執行處理。比如檢查新版本、註冊推送通知等邏輯。
    • 避免複雜/多餘的計算。避免在首頁控制器的viewDidLoad和viewWillAppear做太多事情，這2個方法執行完，首頁控制器才能顯示，
    • 部分可以延遲建立的檢視應做延遲建立/懶載入處理。
    • 採用效能更好的API。
    • 首頁控制器用純程式碼方式來構建。

文章推薦

阿里資料iOS端啟動速度優化的一些經驗
iOS端啟動速度優化
iOS效能優化：Instruments使用實戰

安裝包優化

App安裝包（ipa檔案）是由資源（圖片+文件）和可執行檔案（二進位制檔案）兩部分組成，安裝包瘦身也是從這兩部分進行。

1. 資原始檔優化（主要指圖片資源）

  • 用LSUnusedResource這個軟體查詢專案中沒有用到的圖片，然後刪除，當然不一定特別準確，有一些[UIImage imageNamed:[NSString stringWithFormat:@"icon_%d",index]]這樣使用的圖片也會被列在未使用圖片中。
  • 壓縮圖片資源（用imageoptim壓縮圖片的大小、一些比較大體積的背景圖片壓縮成.jpg格式的）
  • 使用Assets.xcassets來管理圖片也可以減小安裝包的體積

2. 程式碼優化

  • 技術手段排查冗餘程式碼（刪除無用類、方法、第三方庫、readme檔案）
  • 注意平時的開發習慣，廢棄模組及早清理
  • 程式碼結構重構： 程式碼重構是對一個或者幾個類的重複程式碼的抽象封裝，使程式碼看上去更清晰，複用性更好。

3. Xcode編譯選項優化：

  1. 配置編譯選項
    （Levels選項內）Generate Debug Symbols 設定為NO，這個配置選項應該會讓你減去小半的體積。注意這個如果設定成NO就不會在斷點處停下；
  2. 編譯器優化級別
    Build Settings->Optimization
    Level有幾個編譯優化選項，release版應該選擇Fastest, Smalllest[-Os]，這個選項會開啟那些不增加程式碼大小的全部優化，並讓可執行檔案儘可能小。
  3. 去除符號資訊
    Strip Debug Symbols During Copy 和 Symbols Hidden by Default 在release版本應該設為yes，可以去除不必要的除錯符號。Symbols Hidden by Default會把所有符號都定義成”private extern”，設了後會減小體積。
  4. Strip Linked Product：DEBUG下設為NO，RELEASE下設為YES，用於RELEASE模式下縮減app的大小；
  5. 編譯器優化，去掉異常支援。Enable C++ Exceptions、Enable Objective-C Exceptions設定為NO，Other C Flags新增-fno-exceptions

解釋：
Generate Debug Symbols：這個設定在DEBUG和RELEASE下均預設為YES。除錯符號是在編譯時生成的。
在Xcode中檢視構建過程，可以發現，當Generate Debug Symbols選項設定為YES時，每個原始檔在編譯成.o檔案時，編譯引數多了-g和-gmodules兩項。但連結等其他的過程沒有變化。
當Generate Debug Symbols設定為YES時，編譯產生的.o檔案會大一些，當然最終生成的可執行檔案也大一些。
當Generate Debug Symbols設定為NO的時候，在Xcode中設定的斷點不會中斷。但是在程式中列印[NSThread callStackSymbols]，依然可以看到類名和方法名。
Strip Linked Product：設為NO，在Xcode中設定的斷點不會中斷。
配置具體解釋

參考文章：

乾貨|今日頭條iOS端安裝包大小優化

相關文章