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

　　來(lái)源：Damonwong（@王浙劍）

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

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

　　寫(xiě)在前面

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

如果你不知道下面幾個(gè)問(wèn)題，不妨可以看看文章。

使用 .xcassets 有什么好處?

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

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

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

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

啟動(dòng)圖的正確打開(kāi)方式？

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

Install Smallest or Coding Fastest ？

　　分析

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

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

　　https://github.com/CatchChat/Yep

　　目錄劃分

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

Yep IPA

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

資源層面：

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

image: 圖片資源文件

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

代碼層面：

國(guó)際化：國(guó)際化適配的 String ===> 89K

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

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

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

其他：

other：配置文件

PlugIns：YepShare，一個(gè)共享的插件。

整理后的目錄

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

資源層面

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

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

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

Remote

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

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

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

ODR 模式

ODR 緩存策略

　　Local

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

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

Local 集成方式

Create group 和 Create folder references

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

.xcassets

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

Local 開(kāi)發(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 是為了適配一個(gè)點(diǎn)的 3 * 3 個(gè)像素的手機(jī)。

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

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

采用.xcassets的方式

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

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

APP Slicing

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

關(guān)于 PDF

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

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

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

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

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

壓縮過(guò)程

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

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

　　啟動(dòng)圖

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

　　iconfont

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

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

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

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

　　HTML 5

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

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

將所有圖片 Remote 化。

將所有頁(yè)面 Remote 化。

　　其他

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

對(duì)于名字相同的問(wèn)題，你可以把原來(lái)的拖的方式改為.xcassets，他會(huì)自動(dòng)管理相同名字的圖片。然后把多余的去掉

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

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

代碼層面 Install Smallest VS. Coding Fastest 語(yǔ)言選擇

雖然說(shuō)我本人更喜歡用 Swift 來(lái)寫(xiě) App。但從 App 瘦身的角度，不推薦使用 Swift，不論純 Swift 還是 混編。原因很簡(jiǎn)單?？匆幌孪旅娴膱D：

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

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

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

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

FMDB

Realm

RealmSwift

　　MRC VS. ARC

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

　　總結(jié)

先分析一下前面幾個(gè)問(wèn)題造成的原因：

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

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

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

Bitcode

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

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

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

　　Tips

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

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

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

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

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

　　Tip 5：icon 使用 iconfont

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

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

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

　　Tip 9：開(kāi)啟 BitCode

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

　　Tip 10：盡可能的去除無(wú)用的代碼、控制類名、方法名長(zhǎng)度、冗余字符串

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

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

　　更多:工作之余，寫(xiě)了點(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

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

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

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

↓↓↓

相關(guān)知識(shí)

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

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