iOS App 瘦身實踐總結

文章最後有個人 12 條小總結。
原文始發地址：個人 GitHub

寫在前面

• 最近公司需求很少，正好研究一下 App 瘦身的辦法，寫了點小總結。
• 若是你不知道下面幾個問題，不妨能夠看看文章。
  • 使用 .xcassets 有什麼好處?
  • @1x 、@2x 和 @3x 會一塊兒內置到安裝包中嗎？
  • PDF 和 @1x 、@2x 和 @3x 有什麼區別？
  • 若是我有一個 10 x 10 的控件和一個 50 x 50 的控件，美工須要製做幾張 PDF？
  • Iconfont 是什麼？PDF 和 Iconfont 有什麼區別？
  • 啓動圖的正確打開方式？
  • 使用 Swift 或者 混編會增大多少的包體積？
  • Install Smallest or Coding Fastest ？

分析

• 在瘦身以前，首先須要分析一下，咱們能夠從哪幾個方面入手。(以 Yep 爲例)

Yep是一款很優秀的 Swift 開源軟件。

目錄劃分

• App 的瘦身主要是針對於安裝包，而在 iOS 中安裝包就是一個以 .ipa 結尾的壓縮包。咱們能夠經過 iTunes 下載獲取這個 .ipa 來分析。

Yep IPA

• 稍微整理一下，大體能夠分爲如下幾類。

  • 資源層面：

    • Assets.car：項目中全部 .xcassets 的壓縮包
    • image: 圖片資源文件
    • Video && Audio ：音頻 或者 視頻。

  • 代碼層面：

    • 國際化：國際化適配的 String ===> 89K
    • Xib && Storyboard：Xib 和 Storyboard 編譯後的文件。
    • Yep :項目可執行文件。
    • Frameworks：Embedded Frameworks，項目中使用的動態庫

  • 其餘：

    • other：配置文件

    • PlugIns：YepShare，一個共享的插件。

      

      整理後的目錄

• 雖然 Yep 不能表明全部的 App，可是在對於 Yep 的 ipa 分析以後，大體能夠總結出，對一個 App 的安裝包瘦身，能夠從資源層面和代碼層面兩個層面入手。

資源層面

• 在講資源層面以前，但願咱們能達到一個共識，那就是所謂的資源文件指的是 圖片、視頻、音頻。
• Remote : 將資源文件放在服務器上，當用戶下載完 App 後根據須要再下載。
• Local : 將資源文件集成到安裝包中的。

Remote

• 對於 Remote 的方式，若是作好策略(好比緩存),那麼理論上，咱們能夠把 非必須的資源文件 都放到服務器上，這樣對資源壓縮率達到了 100%。也就是說安裝包 沒有任何非必須資源文件 。
  • 必須資源文件:例如應用圖標、啓動圖的這種配置圖片。
• 蘋果的 On-Demand Resources(翻譯) 也是經過這種按需加載資源的思路給咱們提供了一種階段性加載資源的途徑，具體的不展開描述，你能夠點前面的連接進行查看。可是雖然以關卡、tag這種方式來按需加載資源，可是蘋果的服務器對於中國用戶來講實在是慢的不行，因此暫時不建議採起這種方式。大家能夠在本身服務器上實現這種策略方式來加載圖片。

ODR 模式

ODR 緩存策略

Local

• 固然所有將非必須資源文件放到服務器上明顯是不現實的，對於一些必用資源文件，仍是須要將資源文件 集成到安裝包中的。
  • 必用資源文件：安裝了 App 確定會用到。

Local 集成方式

• Create group 和 Create folder references
  • 這兩種其實就是直接把資源文件 拖 進去，在 Xcode 打包以後，全部圖片都在可執行文件的相同目錄下面。這也是不少老的 App 或者目前部分 App 的使用方式。
• .xcassets
  • 這是蘋果在 Xcode 5 出來以後，推薦咱們使用的圖片管理方式，提供了圖片渲染、拉伸模式模式、機型適配等功能。在 Xcode 打包以後全部的.xcassets 文件都會放入一個Assets.car文件中。

Local 開發使用方式列舉分析。

• 通常 App 的圖片內置方式
  • 採用拖的方式,圖片包含@1x、@2x 和 @3x。
  • 採用拖的方式,圖片只包含 @2x 和 @3x。
  • 採用拖的方式,圖片只包含 @2x 或 @3x。
  • 採用.xcassets的方式,圖片包含@1x、@2x 和 @3x。
  • 採用.xcassets的方式,圖片只包含@2x 和 @3x。
  • 採用.xcassets的方式,圖片只 包含@2x 或 @3x。
  • 採用.xcassets的方式,圖片使用 PDF。
    (可能還有其餘方式，但願你能告訴我。)

• 拖的方式

  • 首先@1x、@2x 和 @3x主要是爲了適配不一樣 ppi 的機子而作了一種策略。@1x 主要是爲了適配 iPhone 4 以前的 非 Retina 屏幕，@2x 主要是爲了適配 非 plus 的 iPhone 設備, @3x 是爲了適配一個點的 3 * 3 個像素的手機。
  • 由於 iPhone 4 以前的機子基本沒有什麼 App 會去適配，因此通常來講都會刪除，因此就有了 『採用拖的方式,圖片只包含@2x 和 @3x』 的方式。可是假如你只提供一張圖片，例如你只提供了一張 @3x 的圖片，iOS 系統在 iPhone 7 上沒法找到 @2x 的圖片，會去查找 @3x 或者 @1x 等，再根據實際分辨率進行拉伸，最後把像素鋪到屏幕上。因此在可以接受查找和拉伸形成的性能消耗的前提下，咱們能夠只用一張通用的圖片，因此就有了 『採用拖的方式,圖片包含@2x 或 @3x』 的方式。
  • 以一個 14M 的圖片資源(包含@1x 、@2x、@3x)來講，若是全部的圖片去除掉 @1x 能減小 1M 左右，去除掉@2x能去掉 4M 左右。所以採用『採用拖的方式,圖片包含@2x 或 @3x』的方式雖然損失了一點性能，單大概圖片資源大概減小了35%左右，。

• 採用.xcassets的方式

  • 咱們都知道了，採用『採用拖的方式,圖片包含@2x 或 @3x』的方式大概圖片資源大概減小了35%左右，可是稍微損失了一點性能。有什麼方式能夠減小掉這點性能消耗呢？

  • 「很幸運」 ，蘋果在 iOS 9 終於意識到了這個問題，而後提供了一個叫作 App Slicing(以下圖所示)的東西。App Slicing大體就是App Store會根據不一樣的設備準備不一樣的安裝包(App Variant)，每一個安裝包(App Variant)都只有相應尺寸的圖片,好比 iPhone 6 去下載時，只會下載到 @2x 的圖片的安裝包(App Variant)。但能實現這個功能的前提是圖片須要放置在.xcassets去管理。
    

    

    APP Slicing

  • 因此，目前許多 App 採用 『.xcassets的方式,圖片只 包含@2x 或 @3x』 實際上是沒意義的，特別是在你不適配 iOS 8 的時候，你這麼作是強行下降了 App 的性能。固然你要以爲爲了 8% 的非 iOS 9 用戶 減小 App 安裝包大小 而去下降另外 92% 的用戶的 App 運行性能 沒什麼問題，那麼你能夠採起上面這種方式。

  • 關於 PDF

    • 我最先是在這一篇博客中看到的，固然 Yep 也是這種方式。大體是刪掉 @2x 和 @3x 的圖片，而後替換成 矢量圖 PDF，最後放入.xcassets中去。
    • 而 Xcode 在打包的過程當中，根據你的矢量PDF圖的大小，生成@1x、@2x和@3x的圖。例如你的PDF圖是4545px，那麼Xcode會在編譯時生成下面3個png：4545px 、9090px、135135px，最後再放入Assets.car中。因此採用@1x、@2x 和 @3x 和 PDF 兩種方式本質上是同樣的。
    • 在這裏有不少人會有一個誤解，例如在 App 中有一個 10 10 pt 和 一個 50 50 pt 的 imageView 都用了一個相同的圖標。不少人會覺得作一個就夠了，由於 pdf 是矢量圖。可是實際上是須要一個 10 10 px 和 50 50 px 的兩張 pdf 才能夠，由於只用一張的話，另一張用的其實就是 10 * 10px 的 PDF 的產物。

• 關於壓縮問題。

  • 我是用tinypng 來壓縮的，應該是以最小的佔用量達到了最適合的效果。可是其實.xcassets 也會爲你作一部分的壓縮。以下圖所示：
    

    

    壓縮過程

  • .xcassets 的壓縮應該還對圖片進行了處理這也就是爲何 840KB 壓縮了 81.5%，Assets.car卻沒有減小那麼多。
  • 同時也有人在試驗中發現，用一些壓縮工具彷佛沒有很麼實際效果，這也有多是由於 Xcode 在打包的時候作了必定的處理。

啓動圖

• 啓動圖在一個項目資源中佔比其實蠻大的，以前見過一個項目 6 張啓動圖大概有5M 左右，最大的是2M。
  • iPad 2 and iPad mini (@1x): 768 x 1024
  • iPad and iPad mini (retina @2x): 1536 x 2048
  • iPhone 4s (retina @2x) 640 x 960
  • iPhone 5 (@2x): 640 x 1136
  • iPhone 6 (@2x): 750 x 1334
  • iPhone 6 Plus (@3x): 1242 x 2208
• 可是自從LaunchScreen.storyboard出來一後徹底不必作這麼多張了。只須要將啓動圖設置爲LaunchScreen.storyboard 而後在LaunchScreen.storyboard上設置一張 imageView 。最後再弄一張啓動圖的 pdf 就能夠了。

iconfont

• 首先這個東西估計不少人不知道，我也是在@卓同窗的提醒下才知道原來 iOS 也是能夠用 iconfont 的。最先這個東西是爲 Web 設計的，主要是由於 網頁的 大小直接影響了加載速度，因此在壓縮上連小 icon 都不放過,固然還有一個最主要的目的就是減小請求次數，由於若是是圖片的話，一個圖片就是一次請求。
• 具體的效果能夠看一下，使用IconFont減少iOS應用體積這篇文章。
• 雖然看上去效果很少，但對於一些比較追求精緻的公司能夠嘗試一下這種方式。

期中，PDF 和 iconfont 兩個都是矢量的概念，可是 iconfont 在整個 App 中無論多少種尺寸只須要一個 iconf，可是 PDF 可能須要多個。

HTML 5

• 一些 APP 的一些功能能夠用 HTML5 + WebView 的方式來實現。而 HTML 5 這個能夠經過下面幾種方式一步步優化：
  • 讓作前段的給一個最小的包內置到 App，去除無用代碼、代碼混淆壓縮等。
  • 將全部圖片 Remote 化。
  • 將全部頁面 Remote 化。

其餘

• 固然，還要注意資源文件重複的問題。而資源文件重複問題主要有幾種：名字相同、名字不一樣內容相同/類似。
  • 對於名字相同的問題，你能夠把原來的拖的方式改成.xcassets，他會自動管理相同名字的圖片。而後把多餘的去掉
  • 名字不一樣內容相同/類似:你可使用Duplicate Photos工具
• 還有一個問題就是資源文件沒有用，卻佔了空間，可使用LSUnusedResources將代碼中沒用到的文件刪除。固然可能存在誤刪，好比用數組加載的圖片，這個工具沒法識別。

---

代碼層面

Install Smallest VS. Coding Fastest

語言選擇

• 雖說我本人更喜歡用 Swift 來寫 App。但從 App 瘦身的角度，不推薦使用 Swift，不論純 Swift 仍是 混編。緣由很簡單。看一下下面的圖：

• 這是任何一個包含有 Swift 代碼的 App 都有的一個爲了支持 Swift 的動態庫集合，在10M 左右。若是你使用 Objective - C 徹底不用這個東西。
• 固然，我是能夠接受安裝包大10M 來用 Swift 寫的😄。

數據庫選擇

• 這個問題也是我在分析 Yep 的第三方庫的時候發現的問題，由於 Yep 使用的是 Realm，聽說是目前是性能最好的移動端數據庫。可是在三方庫中能夠看到，Realm 的支持佔了很大的比重，大約在 8M 左右。可是若是使用 FMDB 話只須要192KB，而 CoreData 幾乎能夠忽略不計。下面是部分截圖。

Realm

MRC VS. ARC

• 最開始是在Bang的這篇文章中看到用ARC比用 MRC 會致使可執行文件大10%。起初我是不相信的，可是在我用 SDWebImage 的1.0 版測試以後，ARC 比 MRC 的可執行程序增長了14% +。因此MRC 比 ARC 編譯成可執行文件以後更小，具體的測試方法能夠去他的博客看，這裏就不重複了。

總結

• 先分析一下前面幾個問題形成的緣由：
  • Swift && Realm : 首先 Swift 是由於不穩定，因此支持的動態庫沒有集成到系統的"dyld的共享緩存"中去。而 Realm 由於不是蘋果本身開發的，因此支持的動態庫也沒有集成到系統的"dyld的共享緩存"中去。因此都內置在了 App 中，並且這兩個功能須要寫不少代碼來實現，所以容量又很大，致使看起來這兩個東西佔了很大的"無用"的容量。(ps.關於iOS 中庫的問題，你能夠去個人筆記中查看~)
  • ARC:由於 ARC 叫作自動引用計數，他的實現方式其實就是 Xcode 在編譯的時候自動給你加內存管的代碼，可是機器畢竟沒人聰明，Xcode 會在不少狀況下增長不少沒用的代碼，這也是爲何 ARC 的底層實現比 MRC 更快，可是實際運行性能上在有些時候卻不及 MRC 的緣由，而正由於增長了不少沒用的代碼，ARC 最終編譯包會比 MRC 大。
• 總結前面的幾個問題，歸根結底於一個問題，那就是Install Smallest VS. Coding Fastest。不少時候爲了追求更快的編碼速度，總會有所損失，可是在我看來這些事值得的，否則爲何咱們不用 C 來代替 objective-c 或者用匯編來代替 C 呢？🤔

Bitcode

• bitcode 是被編譯程序的一種中間形式的代碼。包含 bitcode 配置的程序將會在 App Store 上被編譯和連接。 bitcode 容許蘋果在後期從新優化咱們程序的二進制文件，而不須要咱們從新提交一個新的版本到 App Store 上。
• 當咱們提交程序到 App Store上時， Xcode 會將程序編譯爲一箇中間表現形式( bitcode )。而後 App store 會再將這個 bitcode 編譯爲可執行的64位或32位程序。
• 因此，經過這個方式，咱們能夠作到架構級別的App Slicing。

---

Tips

結合上面的內容，再加上Bang大神寫的博客，我總結了幾條 Tips。排名越往前的我以爲越須要去優化。

Tip 1：去除重複、無用資源文件，解決名字重複問題。

Tip 2：圖片使用.xcassets管理且無須考慮@1x\@2x\@3x 問題。萬不得已再用拖的辦法，同時結合必定策略方案進行包瘦身。

Tip 3：圖片使用PDF 優先級高於 PNG,由於 Xcode 會幫你完成剩下的任務。

Tip 4：使用tinypng壓縮PNG圖片。視頻能夠經過 Final cut 等軟件進行分辨率壓縮。音頻則下降碼率便可。

Tip 5：icon 使用 iconfont

Tip 6：非必須資源文件能夠放到本身服務器上， 但必用資源文件須要內置到安裝包中。

Tip 7：HTML 5 須要將圖片 Remote 化 或者將整個HTML 5 的頁面 Remote化。

Tip 8：Build Settings->Optimization Leve release版應該選擇Fastest, Smalllest

Tip 9：開啓 BitCode

如下是幾乎不可能去作的優化 Tips

Tip 10：儘量的去除無用的代碼、控制類名、方法名長度、冗餘字符串

Tip 11：若是你想的話，不使用 Swift、不使用 Realm更甚至於儘可能不使用 OC 😁

Tip 12：MRC 比 ARC 編譯成可執行文件以後更小。

---

更多:工做之餘，寫了點筆記，若是須要能夠在個人 GitHub 看。

---

參考文章

• App Thinning
• Confirmed: Objective-C ARC is slow. Don’t use it! (sarcasm off)
• 4 XCODE ASSET CATALOG SECRETS YOU NEED TO KNOW
• 使用IconFont減少iOS應用體積

• iOS可執行文件瘦身方法

• 水平有限，如有錯誤，但願多多指正！coderonevv@gmail.com