iOS ipa包瘦身，iOS8及如下text段超60MB

前沿

很早以前寫過一篇相關文章，不過博客主機上跑路了以後數據沒了，憑着記憶補了下相關資料

ipa安裝包瘦身

1. 清理無用圖片，圖片壓縮（PNG換WebP和JPG），處於某種不可抗拒的緣由，致使有部分3X圖沒有被App Thining處理，這部分3x圖是否能夠刪除只用2x圖。（這一條通常收益很小，由於大部分團隊都會注意）
2. 特殊字體文件
3. 若是有本身封裝的庫，檢查下靜態庫和動態庫狀況，不要該打靜態庫的不注意輸出的是動態庫，這個咱們以前犯過錯
4. App Code重構，找出無用代碼（這個工做量大，可是對下面text段也有好處）

5. 檢查編譯優化設置（有些設置項最好檢查下由於老工程不少都是之前老版本Xcode創建的，會致使設置仍是之前老Xcode的設置），可參考：

   • BuildSettings->Optimization Level，Xcode默認設置 爲「Fastest ,Smallest」，保持默認便可。
   • Build Settings-> Linking->Dead Code Stripping 設置成 YES
   • Deployment Postprocessing 設置成YES
   • Strip Linked Product 設置成YES
   • 工程的Enable C++ Exceptions和Enable Objective-C Exceptions選項都設置爲NO。手動管理異常。
   • symbols hidden by default選項設置爲YES。
   • 全部沒有使用C++動態特性的lib庫（搜索工程沒有使用dynamic_cast關鍵字） Enable C++ Runtime Types選項設置爲NO。

若是是OC和Swift混編工程還能夠

1. 有逐幀動畫的圖片資源改爲用lottie，逐幀動畫的圖片仍是挺大的
2. Swift與OC混編ipa包增大

若是工程還有Pod+Carthage 的狀況，在Build Phases裏面加上一個腳本：

#這個腳本要在copy pods Resources執行以前執行，否則會致使打包出來的asserts.car會附加Checkouts目錄下的xcasserts
carthageCheckoutsPath=${SRCROOT}/Carthage/Checkouts
echo carthageCheckoutsPath is :${carthageCheckoutsPath}
if [ -d "${carthageCheckoutsPath}" ]; then
rm -rf ${carthageCheckoutsPath}
echo "removed ${carthageCheckoutsPath}"
else
echo "Checkouts not found"
fi

確認這個問題的方法是把打出來的包解壓出來看，看看asserts.car裏到底有些啥圖片，有沒有何項目無關的圖片就知道了

text段（iOS7，8 text段不能超過60MB）

若是已經超過60MB，在不修改任何代碼的狀況下能夠作如下幾件事：

1. 刪除無用的代碼文件（一個空文件佔的text段不多記得是2KB，可是無用文件多了量仍是可觀）
2. Optimization Level 等編譯項優化：Build Settings -> Optimization Level 有幾個編譯優化選項，release 版應該選擇 Fastest, Smalllest ，這個選項會開啓那些不增長代碼大小的所有優化，並讓可執行文件儘量小。
3. Strip Linked Product / Deployment Postprocessing / Symbols Hidden by Default 在 release 版本應該設爲 YES ，能夠去除沒必要要的調試符號。Symbols Hidden by Default 會把全部符號都定義成 」private extern」 。（ 這些選項目前都是 XCode 裏 release 的默認選項，但舊版 XCode 生成的項目可能不是，能夠檢查一下 )
4. Symbols Hidden by Default 在 release 版本應該設爲 YES

從功能出發

走到這一步是最萬不得已的，text段大小問題若是一旦超過官方規定60MB或者已經貼近這個值，會致使平臺組（負責最終整合的團隊）隔一段時間就須要站出來解決這個問題，由於平臺組的小夥伴不肯定是哪一個業務組提交新功能裏面的代碼又增大了，查找起來費時費力，溝通成本也很大。

• 剝離部分收益較小功能（對應的SDK）的arvm7架構（芯片指令集以及支持的最高和最低 iOS 版本）

首先明確一點功能不支持某個架構或者iOS系統版本，並不表明這部分用戶永遠下不了咱們的產品，能在App Store上下載到，只不過是停留在某一個版本。

這裏須要結合本身已有用戶數據以及新增用戶趨勢來取捨

譬如：若是最低支持iOS8，那麼iPhone 4S，iPhone 5，iPhone 5C這部分用戶在某些功能點上是否原本就已經很卡近乎到不能用的地步，最典型的就是直播場景（由於直播場景會涉及到不少SDK）

那麼是否能夠考慮，在這部分功能上作讓步直接將相應SDK的arvm7架構剝離掉。

• 有可能剝離仍是會致使text段貼近60MB，是否考慮在iOS8作一個最終版本，讓iOS8用戶就停留在這邊版本，後續版本最低從iOS9開始，這個方案須要綜合各方面數據考慮。