基于webp的包体缩减方案在自如的实践

2,454 阅读6分钟

背景介绍

自如客使用组件化方式管理app,包体缩减方面做过许多尝试:

  1. 编译优化项
  2. 图片压缩以及图片云控
  3. 根据云控图片使用频率,废弃使用少的图片为url方式管理
  4. 所有资源云端管控

我们本地优化主要是从资源的角度分析包体缩减方案,压缩和废弃图片都已做过,需要另辟蹊径。

寻找可尝试方案

1,安卓将png图片全部换成webp实现了包体缩减,于是考虑iOS也从webp的角度尝试缩减包体积;经过调研发现网上一些大厂对webp的方案并不待见,甚至说替换之后的包体不减反增!但是对于这个结论从理论上并不完全可信,于是开始试验尝试。

2,仍然使用xcasset管理png图片,但是部分图片采用预加载形式,在运行时动态下载图片资源

经过讨论,我们决定尝试第一种方案

验证设想

  1. 为了快速试验,我们新建一空工程,将主工程所有png图片导入,打包,导出iphonex机型包体
  2. 将所有png图片导出3x图,某些图片没有3x导出2x,最终将这些图片转为webp,无压缩

如下是最终测试数据结果: 打出的iphongX上的Assets.car大小在是29.4M,包体263.6M

Png转为webp之后,无压缩 打出的iphongX上的Assets.car大小在是 0M,包体 254.2M 整体减小9.4M

png转webp压缩质量为75,得到的结论如下: 打出的iphongX上的Assets.car大小在是 0M,包体 240.3M 整体减小23M

根据上述测试结果推测,应用整体应该能缩减10-20M,方案目前来看是可行的

转为webp以及压缩方式

转化和压缩方式是使用cwebp,这个命令行工具好像是mac电脑自带的,因为我电脑没单独安装这个,直接就能使用 cwebp -q 75 原图路径 -o webp输出路径

遇到的问题

使用png图片是没问题的,因为png图片有2x和3x,系统会自动选择该使用哪张图片,但是改用webp之后,就没有2x和3x了,全使用3x图片生成并且经过一层压缩,所以替换之后发现,许多小图标都变大了! 问题是如何自适应3x和2x图片呢?

  • UIScreen对象里有个scale只读属性,可以知道当前机型是用2x还是3x图片

一开始我使用scale来进行图片缩放一次,发现还是有部分图片变大!后来经过仔细推敲想到一个遗漏点:我们的图片全是3x图片转化而成,无论你的机型应该用2x还是3x,我们得到的图片都应该直接按照3倍来缩放!

方案在工程中实践

在实践之前还有一个包体计算问题要解决

我们要做包体缩减,最终目的是要缩减包体下载大小,而不是安装大小

我们在appstore看到的包大小是: app文件的二进制部分被加壳之后,在经过App slicing的结果

一般而言,我们需要把包传到test flight之后才能获取准确数据,但是我们也可以通过本地计算出接近的数据

首先导出我们的ipa包的时候选择特定机型,比如iphonex为例,因为不同手机经过苹果优化之后,导出的包体大小差异较大,因此选定一个固定机型来进行对比。

将iphonex机型的ipa包进行解压,获取到app包,这个app包是最接近安装大小的。我们登陆到苹果后台,查看历史版本包体大小,计算出平时上线的时候加壳大小(一般为三四兆),然后用历史版本的安装大小减去下载大小,我们能获取到基本固定的差值。用app包的大小-固定差值=下载大小。这样我们就能估算出优化之后的量化结果。比如自如客在iphonex的固定差值为:自如客包大小-下载大小=64M,那么64M就是固定差值。

为什么iphonex手机导出多个ipa包

我们导出iphonex机型包的时候,苹果会切分出三个ipa包,因为iphonex手机有三种不同的机型和不同的系统,导出包之后会生成一个报告文件: App Thinning Size Report for All Variants of app,这里面有这三个包的详细信息,包括包体大小,例如: App + On Demand Resources size: 123.1 MB compressed, 263.3 MB uncompressed 这里面我们选263.3M作为量化数据进行对比即可,这个数值和app包体基本一致

试验结果

通过导出iphonex机型全部使用png的包和iphonex机型全部使用webp的包,拿到报告文件就可以进行全面对比,另外再导出一份webp经过75或80的压缩之后的包。这三者对比之后,就能预估出优化之后包体缩减能够获取的效果

应用瘦身变体大小os-version=12.2/12os-version=11/10/9os-version=13/14
Png265.1274.7263.3
Webp265.2(+0.1M)265.7(-9M)265.2(+1.9M)
webp压缩20%265.6(-8.5M)257(-17.7M)256.5(-6.8M)
webp压缩25%265 (-9.1M)256.4 (-18.3M)256 (-7.3M)

无压缩情况下 iphonex device: iPhone10,3, os-version: 11.0 机型减小体积较多,其他的不减反增

按照75来压缩,所有机型都有所减小。安卓大图是按照75压缩的,小图不压缩,按照这个比例推算,我们的app保守能优化5M左右(部分图片不进行压缩)

方案评估

  • 是否压缩要有个标准,是否会变虚
  • 2x、3x机型都需要测试一下
  • 优化5M的投入产出比和风险评估,是否有必要做
  • png是否可以再压缩,压缩后是否可以合webp达到一致效果

1,压缩是按照75的质量压缩,有白名单机制,如果图片不适合压缩可以放白名单(我们的图片全是通过系统管理的)。webp用的有损压缩,放大后能看出有变虚的情况,但视觉难以察觉。还有一些图片有透明度且本身也比较小,压缩后反而变大,这种在系统转换webp的时候会检测出来,检测出来后不在使用缩压图片 2,2x和3x在自测和测试都需要覆盖 3,图片管理系统已经有这个机制,如果能优化5M+,还是有必要做的,如有风险可以随时切回,切换的成本较小 4,通过调研发现png图片的压缩远不如webp的压缩

方案实施之后我们会继续补充文章

如果你对技术充满热情,喜欢追求专业的深度和广度,欢迎加入我们,我们期待与你共同成长。我们在北京有招聘需求,简历投递邮箱: lich7@ziroom.com