前段时间部门开需求会,砍掉了应用中的部分需求. 这简直就是给应用瘦身的良机! 这个时候测试又提出来:安卓端的app在应用市场的包只有26M,而iOS端的app在App Store上却有88M.
会后,我就找来安卓的测试机,对比了百度. 支付宝. 微信. 京东. 新浪和抖音几个app在应用市场和App Store上的大小,数据如下:
显而易见,相同的应用,安卓端的应用安装包远小于iOS端.究其原因,笔者虽也查阅了一些资料,鉴于对安卓系统的机制不了解不敢妄言.但由此确定了一点, iOS端的包体难以做到安卓端那么小.
回归到给应用瘦身的实际问题上来, 先来一波常规操作: 删除项目中冗余的图片资源! 删除项目中要砍掉的功能, 各种冗余的文件/xib/storyboard! 移除迭代掉的三方SDK! 这一个版本简化下来,App Store中的安装包大小由88.1M降为61.7M, 安装包大小直线下降了百分之三十!
这个版本的简化成效是较为可观的,但也值得反思:
· 陈旧冗余代码/文件的大量存在: 一方面,据说是因为项目的核心功能是从前几个实验app中迭代而来,简单的copy看似大大缩短了开发工期,但公司的项目本身一直并非组件化开发,冗余庞杂在所难免. 在这里,组件化的优势就显现出来.
· 反复无常的需求变动,加之研发本身的惰性: 需求的经常变更多少会摧残研发敏感的心灵, 一个功能今天要明天不要后天放一放也是蛮常见.久而久之,一个熬夜写出来&自己又实在喜欢的功能板块在面临夭折时,研发可能就会先放着不管.这样的操作多了,时间一长,几经转手,这样的代码/文件就会沉睡在项目中.和同行的一些大牛交流,他们也普遍吐槽项目中存在很多这样的问题.最为离奇的是,一个做音视频SDK的大牛说,他接手的功能里有个控制器代码有5000行, 这个文件有三四年几乎没怎么动过.一系列惨痛的教训告诉我们: 当删则删,良好的编程习惯非常重要! 做好提交工作,写清楚提交内容即可!
说完这些表象,我们具体来谈谈App Thinning,有些人将App Thinning和Bitcode混为一谈.其实不然, Apple Guides and Sample Code 中介绍App Thinning的三个组成部分: App Slicing, Bitcode和On Demand Resources这三个部分:
· App Slicing(应用切片):
切片是为不同的目标设备创建和交付应用程序包变体的过程.从iOS9.0开始, 你跟往常一样往iTunes上提交.ipa文件. App Store将根据您的应用支持的设备来创建和提供不同的变体.图片资源根据其分辨率和设备系列进行切片.GPU资源根据设备功能进行切片.
用户在支持的设备上安装应用程序, 应用商店会下载基于用户设备的应用程序变体.
从图(2)中我们可以清楚看到: 同一个应用的相同版本,在同使用2x图片的机型(iPhone5s/iPhone6)上的包体大小相同,却比使用3x图片的iPhone6plus略小 .也就证明了以上观点.
· On Demand Resources(随需应变资源):
按需资资源是一种资源,例如图像和声音,您可以使用标记关键字和组内请求.商店托管Apple服务器上的资源并为您管理下载.按需资源可实现更快的下载速度和更小的应用程序大小,从而改善首次发布体验.例如,游戏应用可以将资源划分为游戏级别,并且仅当应用预期用户将移动到该级别时才请求下一级资源.同样,只有当用户购买相应的应用购买时,应用才能请求应用内购买资源.
当不再需要资源并且磁盘空间不足时,操作系统会清除按需资源.如果您导出应用程序以在商店外进行测试或者分发,则必须自己托管按需资源.请注意,不支持可执行的按需资源.
对于用户而言,按需资源在后台透明地工作,在用户浏览应用程序功能时根据需要提供资源.
备注:要在应用程序中设置按需资源,请参阅Apple Guides and Sample Code 中"On-Demand Resources Guide ".
· Bitcode(位码):
Bitcode通过消除针对不同架构的优化,以及只下载相关优化,从而使下载变得更小.
Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store.
Xcode hides symbols generated during build time by default, so they are not readable by Apple. Only if you choose to include symbols when uploading your app to iTunes Connect would the symbols be sent to Apple. You must include symbols to receive crash reports from Apple.
----Apple Guides and Sample Code
位码是编译程序的中间表示形式.你上传到iTunes Connect中包含位码的应用程序将被编译并链接到商店.包括位码将允许苹果在未来重新优化你的应用程序二进制而不需要提交一个新的应用程序版本到App Store.
Xcode隐藏了默认情况下在构建期间生成的符号,因此苹果无法读取这些符号,只有当你的应用程序上传到iTunes Connect时包含符号,这些符号才会被发送到苹果.你必须包含一些符号来接收来自苹果的崩溃报告.
Xcode默认启用Bitcode, 但笔者在一次集成三方SDK时,文档上要求关闭Bitcode. 因此,是否开启该属性也要灵活决定.
综上可见, 苹果官方对于应用瘦身的机制已然相当完善, 开发者养成良好的编程习惯至关重呀. 在探究应用瘦身的过程中, 笔者也看到有关于“无损压缩图片”“静态库瘦身”的这样一些观点, 大家也可观摩学习.
参考资料:
1. Working with App Thinning in iOS 9
2. Apple Guides and Sample Code
