前沿
很早之前寫過一篇相關文章，不過博客主機上跑路了之後數據沒了，憑着記憶補了下相關資料
ipa安裝包瘦身
清理無用圖片，圖片壓縮（PNG換WebP和JPG），處於某種不可抗拒的原因，導致有部分3X圖沒有被App Thining處理，這部分3x圖是否可以刪除只用2x圖。（這一條一般收益很小，因爲大部分團隊都會注意）
特殊字體文件
如果有自己封裝的庫，檢查下靜態庫和動態庫情況，不要該打靜態庫的不注意輸出的是動態庫，這個我們之前犯過錯
App Code重構，找出無用代碼（這個工作量大，但是對下面text段也有好處）
檢查編譯優化設置（有些設置項最好檢查下因爲老工程很多都是以前老版本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混編工程還可以
有逐幀動畫的圖片資源改成用lottie，逐幀動畫的圖片還是挺大的
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，在不修改任何代碼的情況下可以做以下幾件事：
刪除無用的代碼文件（一個空文件佔的text段很少記得是2KB，但是無用文件多了量還是可觀）
Optimization Level 等編譯項優化：Build Settings -> Optimization Level 有幾個編譯優化選項，release 版應該選擇 Fastest, Smalllest ，這個選項會開啓那些不增加代碼大小的全部優化，並讓可執行文件儘可能小。
Strip Linked Product / Deployment Postprocessing / Symbols Hidden by Default 在 release 版本應該設爲 YES ，可以去除不必要的調試符號。Symbols Hidden by Default 會把所有符號都定義成 ”private extern” 。（ 這些選項目前都是 XCode 裏 release 的默認選項，但舊版 XCode 生成的項目可能不是，可以檢查一下 )
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開始，這個方案需要綜合各方面數據考慮。
EOF
作 者：goingta
出 處：https://www.cnblogs.com/tanglei/p/10722703.html