版本記錄
| 版本號 | 時間 |
|---|---|
| V1.0 | 2021.04.20 星期二 |
前言
隨着App的持續功能迭代和常年的運營，最終包都會越來越大，包太大蘋果那邊會給限制，不利於用戶下載。所以App瘦身也是一項需要持續做的事。正好我這幾天就在做瘦身的事，這裏記錄一下，大家一起學習和交流。
爲什麼要進行包的瘦身？
隨着產品不停的進行功能迭代，代碼以及圖片都越來越多，包的體積越來越大，但是包太大的話一個是用戶下載的流量消耗很大，二是蘋果也對用戶包大小下載有限制。所以，都是需要注意的，所以我們就要進行包的瘦身。
測量方案
在瘦身之前你需要知道你的包現在有多大，同時也需要在某一個階段需要查看最終包的大小。
蘋果這邊體積計算方式有很多種：
- 1） 安裝體積（
App Store看到的體積）。 - 2） 下載體積（實際下載佔用的流量大小，用戶是無感知的，因爲看不到）
200M限制下載看的是這個體積。 - 3） 自己的腳本計算體積，使用構建後的
LinkMap文件計算arm64架構下代碼段的體積 + 工程目錄下Pods文件夾下出去代碼的資源文件得出。
因爲前兩種蘋果會根據系統和機型做不同處理，所以體積是不同的，也不具有衡量性。所以我們採用第三種方式作爲我們的衡量指標，這種相對比較穩定，也易於衡量。
1. LinkMap文件測量
我這邊使用LinkMap-master對可執行文件大小進行計算，這裏放的都是你的代碼等鏈接數據，比如說你新增加了代碼，那麼這個linkMap就會變大。首先你需要獲取linkMap文件，選中一個target，在Xcode Build Setting裏Write Link Map File設置爲YES，然後設置linkMap文件的輸出路徑，在Path to Link Map File裏填寫你要輸出文件的路徑即可。
獲取到linkMap文件以後，就使用一個常用的Mac程序進行解析了，還可以給出各個業務線不同的體積大小。這裏由於敏感性我就不給出來我們項目的大小截圖了。
注意：這裏一定不能用
debug包的linkMap，而是要用release的，這兩個包因爲優化的差異，親測大小要差不少。
2. 資源包測量
還有一個就是資源包大小的測量，這裏我就是跑的腳本，直接計算項目裏資源包有多大，最終會生成一個各個業務線的資源包體積大小，然後將這個結果和上面linkMap測量結果加起來就是最終的包估計大小。腳本最終還生成了excel文檔，給出了各個業務線不同的包的大小。
瘦身方案
包縮減的方案有很多，但是不管使用任何方法，歸根結底都是從兩個地方出發：
- 減少包內資源的體積，包括圖片等
- 減少代碼，即可執行文件的體積
1. 減少資源包體積
這裏可以從下面幾個方向入手：
- 減少不用的圖片，比如使用
LSUnusedResources進行掃描，裏面還可以設置白名單，排除對某一個資源包的掃描。 - 壓縮現有的圖片資源，由於
png是無損壓縮，所以你不用擔心壓縮導致失真的問題。壓縮工具比較多，比如熟知的tinyPng網站就很不錯，簡單好用，不用下載任何程序。
2. 減少代碼體積
- 刪除廢棄的代碼
- 有些三方模塊比較重的話可以廢棄或者用一些小的替換。
除了我上面提到的兩種我實踐過的方案外，還有另外幾個方向可以嘗試：
- 圖片格式的轉化，比如
png可以轉化爲webp。- 蘋果提供的
ODR的使用。
我們目前的包體積，還在可控範圍內，所以還沒有這兩張方式進行縮減，同時，業務線比較多，也需要和平臺各個業務線一起統籌做這個事。
參考文章
後記
本篇主要講述了
App的包瘦身計算，感興趣的給個贊或者關注~~~
