很早之前写过一篇相关文章,不过博客主机上跑路了之后数据没了,凭着记忆补了下相关资料
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
。dynamic_cast
关键字) Enable C++ Runtime Types
选项设置为NO
。如果是OC
和Swift
混编工程还可以
如果工程还有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
里到底有些啥图片,有没有何项目无关的图片就知道了
如果已经超过60MB,在不修改任何代码的情况下可以做以下几件事:
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或者已经贴近这个值,会导致平台组(负责最终整合的团队)隔一段时间就需要站出来解决这个问题,因为平台组的小伙伴不确定是哪个业务组提交新功能里面的代码又增大了,查找起来费时费力,沟通成本也很大。
arvm7
架构(芯片指令集以及支持的最高和最低 iOS 版本)首先明确一点功能不支持某个架构或者iOS系统版本,并不代表这部分用户永远下不了我们的产品,能在App Store上下载到,只不过是停留在某一个版本。
这里需要结合自己已有用户数据以及新增用户趋势来取舍
譬如:如果最低支持iOS8,那么iPhone 4S,iPhone 5,iPhone 5C这部分用户在某些功能点上是否本来就已经很卡近乎到不能用的地步,最典型的就是直播场景(因为直播场景会涉及到很多SDK)
那么是否可以考虑,在这部分功能上做让步直接将相应SDK的arvm7架构剥离掉。
text
段贴近60MB,是否考虑在iOS8做一个最终版本,让iOS8用户就停留在这边版本,后续版本最低从iOS9开始,这个方案需要综合各方面数据考虑。原文:https://www.cnblogs.com/tanglei/p/10722703.html