iOS ipa包瘦身，iOS8及以下text段超60MB
前沿
很早之前写过一篇相关文章，不过博客主机上跑路了之后数据没了，凭着记忆补了下相关资料
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
