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端安裝包大小優化