（點(diǎn)擊上方公眾號，可快速關(guān)注）

　　來源：Damonwong（@王浙劍）

　　鏈接：https://www.jianshu.com/p/df52554be812

　　文章最后有我的 12 條小總結(jié)。

　　寫在前面

最近公司需求不多，正好研究一下 App 瘦身的辦法，寫了點(diǎn)小總結(jié)。

如果你不知道下面幾個問題，不妨可以看看文章。

使用 .xcassets 有什么好處?

@1x 、@2x 和 @3x 會一起內(nèi)置到安裝包中嗎？

PDF 和 @1x 、@2x 和 @3x 有什么區(qū)別？

如果我有一個 10 x 10 的控件和一個 50 x 50 的控件，美工需要制作幾張 PDF？

Iconfont 是什么？PDF 和 Iconfont 有什么區(qū)別？

啟動圖的正確打開方式？

使用 Swift 或者 混編會增大多少的包體積？

Install Smallest or Coding Fastest ？

　　分析

在瘦身之前，首先需要分析一下，我們可以從哪幾個方面入手。(以 Yep 為例)

　　Yep是一款很優(yōu)秀的 Swift 開源軟件。

　　https://github.com/CatchChat/Yep

　　目錄劃分

App 的瘦身主要是針對于安裝包，而在 iOS 中安裝包就是一個以 .ipa 結(jié)尾的壓縮包。我們可以通過 iTunes 下載獲取這個 .ipa 來分析。

Yep IPA

　　稍微整理一下，大致可以分為以下幾類。

資源層面：

Assets.car：項(xiàng)目中所有 .xcassets 的壓縮包

image: 圖片資源文件

Video && Audio ：音頻 或者 視頻。

代碼層面：

國際化：國際化適配的 String ===> 89K

Xib && Storyboard：Xib 和 Storyboard 編譯后的文件。

Yep :項(xiàng)目可執(zhí)行文件。

Frameworks：Embedded Frameworks，項(xiàng)目中使用的動態(tài)庫

其他：

other：配置文件

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

整理后的目錄

雖然 Yep 不能代表所有的 App，但是在對于 Yep 的 ipa 分析之后，大致可以總結(jié)出，對一個 App 的安裝包瘦身，可以從資源層面和代碼層面兩個層面入手。

資源層面

在講資源層面之前，希望我們能達(dá)到一個共識，那就是所謂的資源文件指的是 圖片、視頻、音頻。

Remote : 將資源文件放在服務(wù)器上，當(dāng)用戶下載完 App 后根據(jù)需要再下載。

Local : 將資源文件集成到安裝包中的。

Remote

對于 Remote 的方式，如果做好策略(比如緩存),那么理論上，我們可以把 非必須的資源文件 都放到服務(wù)器上，這樣對資源壓縮率達(dá)到了 100%。也就是說安裝包 沒有任何非必須資源文件 。

必須資源文件:例如應(yīng)用圖標(biāo)、啟動圖的這種配置圖片。

蘋果的 On-Demand Resources(https://benbeng.leanote.com/post/On-Demand-Resources-Guide) 也是通過這種按需加載資源的思路給我們提供了一種階段性加載資源的途徑，具體的不展開描述，你可以點(diǎn)前面的鏈接進(jìn)行查看。但是雖然以關(guān)卡、tag這種方式來按需加載資源，但是蘋果的服務(wù)器對于中國用戶來說實(shí)在是慢的不行，所以暫時不建議采取這種方式。你們可以在自己服務(wù)器上實(shí)現(xiàn)這種策略方式來加載圖片。

ODR 模式

ODR 緩存策略

　　Local

當(dāng)然全部將非必須資源文件放到服務(wù)器上明顯是不現(xiàn)實(shí)的，對于一些必用資源文件，還是需要將資源文件 集成到安裝包中的。

必用資源文件：安裝了 App 肯定會用到。

Local 集成方式

Create group 和 Create folder references

這兩種其實(shí)就是直接把資源文件 拖 進(jìn)去，在 Xcode 打包之后，所有圖片都在可執(zhí)行文件的相同目錄下面。這也是很多老的 App 或者目前部分 App 的使用方式。

.xcassets

這是蘋果在 Xcode 5 出來之后，推薦我們使用的圖片管理方式，提供了圖片渲染、拉伸模式模式、機(jī)型適配等功能。在 Xcode 打包之后所有的.xcassets 文件都會放入一個Assets.car文件中。

Local 開發(fā)使用方式列舉分析。

一般 App 的圖片內(nèi)置方式

采用拖的方式,圖片包含@1x、@2x 和 @3x。

采用拖的方式,圖片只包含 @2x 和 @3x。

采用拖的方式,圖片只包含 @2x 或 @3x。

采用.xcassets的方式,圖片包含@1x、@2x 和 @3x。

采用.xcassets的方式,圖片只包含@2x 和 @3x。

采用.xcassets的方式,圖片只 包含@2x 或 @3x。

采用.xcassets的方式,圖片使用 PDF。

　　(可能還有其他方式，希望你能告訴我。)

拖的方式

首先@1x、@2x 和 @3x主要是為了適配不同 ppi 的機(jī)子而做了一種策略。@1x主要是為了適配 iPhone 4 之前的 非 Retina 屏幕，@2x 主要是為了適配 非 plus的 iPhone 設(shè)備, @3x 是為了適配一個點(diǎn)的 3 * 3 個像素的手機(jī)。

因?yàn)?iPhone 4 之前的機(jī)子基本沒有什么 App 會去適配，所以一般來說都會刪除，所以就有了 『采用拖的方式,圖片只包含@2x 和 @3x』 的方式。但是假如你只提供一張圖片，例如你只提供了一張 @3x 的圖片，iOS 系統(tǒng)在 iPhone 7 上無法找到 @2x 的圖片，會去查找 @3x 或者 @1x 等，再根據(jù)實(shí)際分辨率進(jìn)行拉伸，最后把像素鋪到屏幕上。所以在能夠接受查找和拉伸造成的性能消耗的前提下，我們可以只用一張通用的圖片，所以就有了 『采用拖的方式,圖片包含@2x 或 @3x』 的方式。

以一個 14M 的圖片資源(包含@1x 、@2x、@3x)來說，如果所有的圖片去除掉 @1x 能減少 1M 左右，去除掉@2x能去掉 4M 左右。因此采用『采用拖的方式,圖片包含@2x 或 @3x』的方式雖然損失了一點(diǎn)性能，單大概圖片資源大概減少了35%左右，。

采用.xcassets的方式

我們都知道了，采用『采用拖的方式,圖片包含@2x 或 @3x』的方式大概圖片資源大概減少了35%左右，但是稍微損失了一點(diǎn)性能。有什么方式可以減少掉這點(diǎn)性能消耗呢？

“很幸運(yùn)” ，蘋果在 iOS 9 終于意識到了這個問題，然后提供了一個叫做 App Slicing(如下圖所示)的東西。App Slicing大致就是App Store會根據(jù)不同的設(shè)備準(zhǔn)備不同的安裝包(App Variant)，每個安裝包(App Variant)都只有相應(yīng)尺寸的圖片,比如 iPhone 6 去下載時，只會下載到 @2x 的圖片的安裝包(App Variant)。但能實(shí)現(xiàn)這個功能的前提是圖片需要放置在.xcassets去管理。

APP Slicing

所以，目前許多 App 采用 『.xcassets的方式,圖片只 包含@2x 或 @3x』 其實(shí)是沒意義的，特別是在你不適配 iOS 8 的時候，你這么做是強(qiáng)行降低了 App 的性能。當(dāng)然你要覺得為了 8% 的非 iOS 9 用戶 減少 App 安裝包大小 而去降低另外 92% 的用戶的 App 運(yùn)行性能 沒什么問題，那么你可以采取上面這種方式。

關(guān)于 PDF

我最早是在這一篇博客（https://martiancraft.com/blog/2014/09/vector-images-xcode6/）中看到的，當(dāng)然 Yep 也是這種方式。大致是刪掉 @2x 和 @3x 的圖片，然后替換成 矢量圖 PDF，最后放入.xcassets中去。

而 Xcode 在打包的過程中，根據(jù)你的矢量PDF圖的大小，生成@1x、@2x和@3x的圖。例如你的PDF圖是4545px，那么Xcode會在編譯時生成下面3個png：4545px 、9090px、135135px，最后再放入Assets.car中。所以采用@1x、@2x 和 @3x 和 PDF 兩種方式本質(zhì)上是一樣的。

在這里有很多人會有一個誤解，例如在 App 中有一個 10 10 pt 和 一個 50 50 pt 的 imageView 都用了一個相同的圖標(biāo)。很多人會以為做一個就夠了，因?yàn)?pdf 是矢量圖。但是其實(shí)是需要一個 10 10 px 和 50 50 px 的兩張 pdf 才可以，因?yàn)橹挥靡粡埖脑?，另外一張用的其?shí)就是 10 * 10px 的 PDF 的產(chǎn)物。

關(guān)于壓縮問題。

我是用tinypng 來壓縮的，應(yīng)該是以最小的占用量達(dá)到了最適合的效果。但是其實(shí).xcassets 也會為你做一部分的壓縮。如下圖所示：

壓縮過程

.xcassets 的壓縮應(yīng)該還對圖片進(jìn)行了處理這也就是為什么 840KB 壓縮了 81.5%，Assets.car卻沒有減少那么多。

同時也有人在試驗(yàn)中發(fā)現(xiàn)，用一些壓縮工具似乎沒有很么實(shí)際效果，這也有可能是因?yàn)?Xcode 在打包的時候做了一定的處理。

　　啟動圖

啟動圖在一個項(xiàng)目資源中占比其實(shí)蠻大的，之前見過一個項(xiàng)目 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出來一后完全沒必要做這么多張了。只需要將啟動圖設(shè)置為LaunchScreen.storyboard 然后在LaunchScreen.storyboard上設(shè)置一張 imageView 。最后再弄一張啟動圖的 pdf 就可以了。

　　iconfont

首先這個東西估計很多人不知道，我也是在@桌同學(xué)的提醒下才知道原來 iOS 也是可以用 iconfont 的。最早這個東西是為 Web 設(shè)計的，主要是因?yàn)?網(wǎng)頁的 大小直接影響了加載速度，所以在壓縮上連小 icon 都不放過,當(dāng)然還有一個最主要的目的就是減少請求次數(shù)，因?yàn)槿绻菆D片的話，一個圖片就是一次請求。

具體的效果可以看一下，使用IconFont減小iOS應(yīng)用體積（https://johnwong.github.io/mobile/2015/04/03/using-icon-font-in-ios.html）這篇文章。

雖然看上去效果不多，但對于一些比較追求精致的公司可以嘗試一下這種方式。

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

　　HTML 5

　　一些 APP 的一些功能可以用 HTML5 + WebView 的方式來實(shí)現(xiàn)。而 HTML 5 這個可以通過下面幾種方式一步步優(yōu)化：

讓做前端的給一個最小的包內(nèi)置到 App，去除無用代碼、代碼混淆壓縮等。

將所有圖片 Remote 化。

將所有頁面 Remote 化。

　　其他

當(dāng)然，還要注意資源文件重復(fù)的問題。而資源文件重復(fù)問題主要有幾種：名字相同、名字不同內(nèi)容相同/相似。

對于名字相同的問題，你可以把原來的拖的方式改為.xcassets，他會自動管理相同名字的圖片。然后把多余的去掉

名字不同內(nèi)容相同/相似:你可以使用Duplicate Photos工具

還有一個問題就是資源文件沒有用，卻占了空間，可以使用LSUnusedResources將代碼中沒用到的文件刪除。當(dāng)然可能存在誤刪，比如用數(shù)組加載的圖片，這個工具無法識別。

代碼層面 Install Smallest VS. Coding Fastest 語言選擇

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

這是任何一個包含有 Swift 代碼的 App 都有的一個為了支持 Swift 的動態(tài)庫集合，在10M 左右。如果你使用 Objective – C 完全不用這個東西。

當(dāng)然，我是可以接受安裝包大10M 來用 Swift 寫的。

　　數(shù)據(jù)庫選擇

這個問題也是我在分析 Yep 的第三方庫的時候發(fā)現(xiàn)的問題，因?yàn)?Yep 使用的是 Realm，據(jù)說是目前是性能最好的移動端數(shù)據(jù)庫。但是在三方庫中可以看到，Realm 的支持占了很大的比重，大約在 8M 左右。但是如果使用 FMDB 話只需要192KB，而 CoreData 幾乎可以忽略不計。下面是部分截圖。

FMDB

Realm

RealmSwift

　　MRC VS. ARC

最開始是在Bang的這篇文章中看到用ARC比用 MRC 會導(dǎo)致可執(zhí)行文件大10%。起初我是不相信的，但是在我用 SDWebImage 的1.0 版測試之后，ARC 比 MRC 的可執(zhí)行程序增加了14% +。所以MRC 比 ARC 編譯成可執(zhí)行文件之后更小，具體的測試方法可以去他的博客看，這里就不重復(fù)了。

　　總結(jié)

先分析一下前面幾個問題造成的原因：

Swift && Realm : 首先 Swift 是因?yàn)椴环€(wěn)定，所以支持的動態(tài)庫沒有集成到系統(tǒng)的”dyld的共享緩存”中去。而 Realm 因?yàn)椴皇翘O果自己開發(fā)的，所以支持的動態(tài)庫也沒有集成到系統(tǒng)的”dyld的共享緩存”中去。所以都內(nèi)置在了 App 中，而且這兩個功能需要寫很多代碼來實(shí)現(xiàn)，因此容量又很大，導(dǎo)致看起來這兩個東西占了很大的“無用”的容量。(ps.關(guān)于iOS 中庫的問題，你可以去我的筆記中查看~)

ARC:因?yàn)?ARC 叫做自動引用計數(shù)，他的實(shí)現(xiàn)方式其實(shí)就是 Xcode 在編譯的時候自動給你加內(nèi)存管的代碼，但是機(jī)器畢竟沒人聰明，Xcode 會在很多情況下增加很多沒用的代碼，這也是為什么 ARC 的底層實(shí)現(xiàn)比 MRC 更快，但是實(shí)際運(yùn)行性能上在有些時候卻不及 MRC 的原因，而正因?yàn)樵黾恿撕芏鄾]用的代碼，ARC 最終編譯包會比 MRC 大。

總結(jié)前面的幾個問題，歸根結(jié)底于一個問題，那就是Install Smallest VS. Coding Fastest。很多時候?yàn)榱俗非蟾斓木幋a速度，總會有所損失，但是在我看來這些事值得的，不然為什么我們不用 C 來代替 objective-c 或者用匯編來代替 C 呢？

Bitcode

bitcode 是被編譯程序的一種中間形式的代碼。包含 bitcode 配置的程序?qū)?App Store 上被編譯和鏈接。 bitcode 允許蘋果在后期重新優(yōu)化我們程序的二進(jìn)制文件，而不需要我們重新提交一個新的版本到 App Store 上。

當(dāng)我們提交程序到 App Store上時， Xcode 會將程序編譯為一個中間表現(xiàn)形式( bitcode )。然后 App store 會再將這個 bitcode 編譯為可執(zhí)行的64位或32位程序。

所以，通過這個方式，我們可以做到架構(gòu)級別的App Slicing。

　　Tips

　　結(jié)合上面的內(nèi)容，再加上Bang大神寫的博客（https://blog.cnbang.net/tech/2544/），我總結(jié)了幾條 Tips。排名越往前的我覺得越需要去優(yōu)化。

　　Tip 1：去除重復(fù)、無用資源文件，解決名字重復(fù)問題。

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

　　Tip 3：圖片使用PDF 優(yōu)先級高于 PNG,因?yàn)?Xcode 會幫你完成剩下的任務(wù)。

　　Tip 4：使用tinypng壓縮PNG圖片。視頻可以通過 Final cut 等軟件進(jìn)行分辨率壓縮。音頻則降低碼率即可。

　　Tip 5：icon 使用 iconfont

　　Tip 6：非必須資源文件可以放到自己服務(wù)器上， 但必用資源文件需要內(nèi)置到安裝包中。

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

　　Tip 8：Build Settings->Optimization Leve release版應(yīng)該選擇Fastest, Smalllest

　　Tip 9：開啟 BitCode

　　以下是幾乎不可能去做的優(yōu)化 Tips

　　Tip 10：盡可能的去除無用的代碼、控制類名、方法名長度、冗余字符串

　　Tip 11：如果你想的話，不使用 Swift、不使用 Realm更甚至于盡量不使用 OC

　　Tip 12：MRC 比 ARC 編譯成可執(zhí)行文件之后更小。

　　更多:工作之余，寫了點(diǎn)筆記，如果需要可以在我的 GitHub 看。

　　https://github.com/Damonvvong/iOSDevNotes

　　參考文章

App Thinning

　　https://t.cn/RVJ8kNd

Confirmed: Objective-C ARC is slow. Don’t use it! (sarcasm off)

　　https://t.cn/zYkzifW

4 XCODE ASSET CATALOG SECRETS YOU NEED TO KNOW

　　https://t.cn/RVJR2c0

使用IconFont減小iOS應(yīng)用體積

　　https://t.cn/RVU7B3h

iOS可執(zhí)行文件瘦身方法

　　https://t.cn/RZgnVL3

水平有限，若有錯誤，希望多多指正！coderonevv@gmail.com

關(guān)注「 iOS大全 」

看更多精選 iOS 技術(shù)文章

↓↓↓

相關(guān)知識

運(yùn)動減肥計劃app下載
十大好用的減肥食譜軟件推薦 制定減肥計劃的app有哪些
求暑期減肥計劃
華為運(yùn)動健康A(chǔ)PP智能減脂計劃，享“瘦”一“夏”
我的減肥計劃（精編12篇）
求健康減肥計劃
我的減肥計劃(實(shí)用13篇)
免費(fèi)的健身計劃app排行榜前十名
放開我！我還能瘦！健身、減肥不要錯過這幾個APP
運(yùn)動減肥計劃app2023手機(jī)最新版下載

網(wǎng)址: 我的 App 『減肥計劃』(一) http://www.u1s5d6.cn/newsview135636.html