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
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Spring Cloud OAuth 微服务内部Token传递的源码实现解析
背景分析 1.客户端携带认证中心发放的token,请求资源服务器A(Spring Security OAuth 发放Token 源码解析) 2.客户端携带令牌直接访问资源服务器,资源服务器通过对token 的校验 ([Spring Cloud OAuth2 资源服务器CheckToken 源码解析](https://my.oschina.net/giegie/blog/3005999)) 判断用户的合法性,并保存到上下文中 3.A服务接口接收到请求,需要通过Feign或者其他RPC框架调用B服务来组装返回数据 本文主要来探讨第三部 A --> B ,token 自定维护的源码实现 如何实现token 传递 配置OAuth2FeignRequestInterceptor 即可 此类是Feign 的拦截器实现 @Bean @ConditionalOnProperty("security.oauth2.client.client-id") public RequestInterceptor oauth2FeignRequestInterceptor(OAuth2ClientContex...
- 下一篇
企业应该选择哪种区块链
随着探索如何把区块链应用在各种场景,许多人就想到,也许不需要全世界的人共同参与,也不需要挖矿,我们只需要用到区块链的可信任、可追溯特性,通过较少节点达到拜占庭将军容错,于是私有链就诞生了。但私有链仍是中心化的,难以维持去中心化的优势。因此又有了为企业联盟而生的联盟链(consortium blockchain)。 公有链vs联盟链vs私有链公有链公有链向全世界任何人公开,所有人都可访问,发送、接收、认证交易。所有人都能参与其中的区块链——共识过程决定哪个区块可被添加到区块链中,也因此公有链通常被认为是完全去中心化的。特点:不可篡改,匿名公开,技术门槛低,是真正的去中心化。每个参与者可以看到所有的帐户余额和其所有的交易活动。缺点:分布式治理仰赖共识决策,更新迭代慢、自行开发的话,目前技术发展框架,初期建设成本高昂。若企业直接采用公有链,则会受限于扩容问题、以及企业需求无法满足(通常会以侧链妥协,但侧链则容易引起中心化隐患)。举例:以太坊、EOS、MAC多原链。私有链私有链是完全私有的区块链,指写入权限仅限于在一个组织手里的区块链。读取权限或者对外开放,或者被一定程度地进行了限制。整个网络...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7设置SWAP分区,小内存服务器的救世主
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8编译安装MySQL8.0.19