App安裝包是由資源和可執(zhí)行文件兩部分組成，安裝包瘦身也是從這兩部分進(jìn)行。

資源瘦身

1. 刪除無用的資源

• 工具：LSUnusedResources
• 效果
• 查找到無用的圖片大概有180個(gè)，總大小1M多（PS:尋歡項(xiàng)目大概有5M+，往期版本的啟動(dòng)圖沒及時(shí)刪除）
• 刪掉了文件較大（10KB+）的一些圖片
• 無用的圖片包括了一些原來尋歡業(yè)務(wù)的圖片
• 由于無用的圖片體積不是很大，刪除無用圖片后安裝包的體積由55.9M減少到55.4M
• Tips:
  • 要選中 ignore similar name 防止誤刪
  • 實(shí)際中會(huì)出現(xiàn)誤報(bào)情況
    1. [UIImage imageNamed:[NSString stringWithFormat:@"01_0000%d.png",i] 這種情況下01_00004.png沒有排除掉
    2. SVGA動(dòng)畫使用的圖片沒有排除掉，刪除的時(shí)候要檢查下路徑
• 總結(jié)
  1. 定期檢查
  2. 注意防止誤刪

2.刪除重復(fù)的資源

重復(fù)資源（主要指圖片）不是指命名重復(fù)而是內(nèi)容相同。

fdupes 是Linux下的一個(gè)工具，可以在指定的目錄及子目錄中查找重復(fù)的文件。fdupes通過對(duì)比文件的MD5簽名，以及逐字節(jié)比較文件來識(shí)別重復(fù)內(nèi)容。

項(xiàng)目中圖片分兩處存放，Assets.xcassets和images文件夾，所以在這兩個(gè)目錄查找就可以。

    fdupes -r xxx/images xxx/Images.xcassets

• 結(jié)果

  搜索到大概 40 個(gè)圖片資源是內(nèi)容相同的

• 原因及處理

  1. 同一張圖片（文件名也相同）同時(shí)存在Assets.xcassets和images 【刪除images文件夾里的】
  2. 不同文件名的圖片它們的尺寸和內(nèi)容都完全相同 【暫不處理】
  3. 2X和3X圖片尺寸和內(nèi)容一樣，都是2X的尺寸 【刪除3X圖片】

• 效果

  刪除了大概15個(gè)圖片，雖然都是小圖片對(duì)安裝包的體積沒多大變化，但解決了同名圖片會(huì)有時(shí)編譯不成功的bug。

• 總結(jié)

  第1，3種情況完全是不小心導(dǎo)致的要避免。

3.無損壓縮圖片

ImageOptim是一款優(yōu)秀的無損圖片壓縮工具，它通過優(yōu)化壓縮參數(shù)，移除無用的文件元數(shù)據(jù)和不必要的顏色配置來實(shí)現(xiàn)圖片的無損壓縮。

壓縮完之后效果還是很明顯的，可能是美術(shù)提供之前沒壓縮過(哭臉狀），Assets.xcassets文件夾壓縮效果
如下：

Assets.xcassets壓縮效果

但發(fā)現(xiàn)實(shí)際生產(chǎn)的安裝包體積沒有變小，因?yàn)?code>COMPRESS_PNG_FILES和STRIP_PNG_TEXT設(shè)置成了YES，Xcode會(huì)重新壓縮一次圖片，但是壓縮之后的圖反而比ImageOptim處理之后的圖更大。改成NO就能讓項(xiàng)目中的PNG保持不變。

• 效果

  無損壓縮后安裝包的體積為53.4MB，比壓縮前減少了2M。

  無損壓縮后安裝包體積

• 總結(jié)

  1. 美術(shù)給資源前要對(duì)圖片壓縮
  2. 發(fā)布前用工具對(duì)圖片壓縮一次

圖片管理方式

主要有兩個(gè)方式管理圖片，一種是在項(xiàng)目中添加文件夾存放，另一種是放在Assets.xcassets管理。推薦使用Assets.xcassets管理，因?yàn)樗鼤?huì)把里邊的所有 png 格式的圖片壓縮成一個(gè)Assets.car文件，壓縮比率比其他方式管理圖片要高，大大減少圖片體積。

其它

1. 上面主要討論的是圖片資源，其它資源文件如音頻、視頻都可以進(jìn)行壓縮處理，項(xiàng)目中還有些沒用的Plist,readme之類的文件可以刪掉。

2. 另外xxx.proto文件也放在項(xiàng)目中，其實(shí)這個(gè)文件在項(xiàng)目中也是不用的，完全可以刪掉！如果包含在bundle里面不僅增加安裝包體積還存在相關(guān)安全隱患。

3. 有些非必要的文件資源可以放在服務(wù)器，結(jié)合本地緩存策略。

可執(zhí)行文件瘦身

LinkMap文件是Xcode產(chǎn)生可執(zhí)行文件的同時(shí)生成的鏈接信息，用來描述可執(zhí)行文件的構(gòu)造成分，包括代碼段（__TEXT）和數(shù)據(jù)段（__DATA）的分布情況。只要設(shè)置Project->Build Settings->Write Link Map File為YES，build完后就可以在設(shè)置的路徑看到LinkMap文件了。

我們可以用腳本從linkmap中統(tǒng)計(jì)出每個(gè).o目標(biāo)文件占用的體積和每個(gè).a靜態(tài)庫(kù)占用的體積 【腳本鏈接】

LinkMap

從統(tǒng)計(jì)結(jié)果來看，靜態(tài)庫(kù)文件和protocal buffer文件占大頭。

• 靜態(tài)庫(kù)瘦身

  項(xiàng)目中多少都會(huì)引入一些第三方靜態(tài)庫(kù)，比如交友項(xiàng)目中引入了第三方分享庫(kù)，通過lipo工具可以查看支持的指令集，比如查看微信SDK

  lipo -info libWeChatSDK.a          
  Architectures in the fat file: libWeChatSDK.a are: armv7 armv7s i386 x86_64 arm64 
  

  i386,x86_64,這不是模擬器的指令集么？去掉看能不能減少體積？armv7可以兼容armv7s，armv7s也可以刪了，只保留armv7和arm64

  lipo libWeChatSDK.a -thin armv7 -output libWeChatSDK-armv7.a
  lipo libWeChatSDK.a -thin arm64 -output libWeChatSDK-arm64.a
  lipo create libWeChatSDK-armv7.a libWeChatSDK-arm64.a -output libWeChatSDK-device.a
  
  ls -ll
  -rw-r--r--  1 Vic  staff   5957080 Jan  6 14:40 libWeChatSDK-device.a
  -rw-r--r--  1 Vic  staff  14410376 Nov 25 11:53 libWeChatSDK.a
  

  由原來的14.4M降低到6M！少了一半多。如果把所有的靜態(tài)庫(kù)都只保留armv7和arm64安裝包體檢豈不是大大減少了~！

  • 解決模擬器無法使用

    刪掉了i386和x86_64后模擬器將可能無法正常運(yùn)行，目前想到的解決方法，有更好的方案請(qǐng)告訴我！

    1. 如果是手工添加靜態(tài)庫(kù)的話可以在發(fā)布前將靜態(tài)庫(kù)替換

    2. 如果用 Cocoapods 管理可以使用兩份podfile文件，一份包含模擬器指令集一份不包括，發(fā)布的時(shí)候更換podfile文件即可；或者用同一份podfile，分配置環(huán)境設(shè)置庫(kù)

       pod libWeChatSDK:configurations => ['Debug']
       pod libWeChatSDK-device:configurations => ['Release']
       

  • 效果

    還沒有申請(qǐng)相關(guān)權(quán)限所以還沒法打包，具體效果以后再補(bǔ)充。。。

• protocolbuf 精簡(jiǎn)

  由于歷史原因項(xiàng)目中用的protocolbuf還是C++版本了，在3.0版本官方已經(jīng)出了OC版本并提供了生成工具，官方生成的文件大小只有現(xiàn)在的1/4，代碼行數(shù)大概是現(xiàn)在的1/10。尋歡項(xiàng)目已經(jīng)更換了，交友要盡快換啦

• 代碼層面優(yōu)化
  主要包括刪除不用的類，不用的函數(shù)，重復(fù)的代碼等，有個(gè)IDE貌似已經(jīng)集成了這些Code Inspection功能---APPCode,這是檢查的結(jié)果

  inspection

  太多了看不過來??，貌似有些是不準(zhǔn)的，不過可以拿來排查，怕手賤刪錯(cuò)代碼就不碰這塊了

思維導(dǎo)圖

api thin

終極大招

如果以上招數(shù)還不能把安裝包降下來，那就放大招吧

砍需求