社区精选 | 与小程序的 2M 空间斗智斗勇之图片优化

今天小编为大家带来的是社区作者 林小志 的文章，让我们一起来学习手写编程语言-实现运算符重载。

现在的网站或者 app 等各类应用，但凡有图片资源，基本上都是通过 CDN 的方式加载，而 CDN 方面大概率也就是阿里云或者腾讯云了。在 CDN 中会做的一个事情，必然是对图片资源的优化、压缩。久而久之，大家似乎也开始逐渐淡忘了图片格式应该如何选择，图片是不是要进一步压缩以节约带宽。

这个节约并不只是针对用户访问网站时，通过 4G 或者 5G 所使用的流量节约，而是企业方在 CDN 上的带宽费用。

背景

在《闲来无事，折腾一个小程序玩玩，漫脸不是曼联，是捏脸的……》一文中提到过，目前所开发的捏脸小程序并未考虑使用任何服务器，所以图片资源都是打包在小程序内部，也就需要考虑如何利用有限的 2M 大小来加载更多图片素材。

对于图片优化我所认为的普遍认知

基本上大家都知道现在的图片都是通过 CDN 请求加载，并且在 CDN 中是可以设置图片加载的方式，包括是否使用压缩率很高的 .webp 格式，比如这样一个 URL：

https://gw.alicdn.com/..省略一串..saturn_solar.jpg_300x300q90.jpg_.webp

可以看到有 300x300 以及 .webp，如果我们直接修改 300x300 为 800x800 的话，那么看到的图片是大的；如果查看 http 请求头信息呢，会看到 content-type: image/webp 图片类型是 .webp 格式的；假如我们把 URL 后面 _300x300q90.jpg_.webp 这部分去掉，看到的就应该是后台上传到 CDN 上原始图片了。

简单来说，站点中使用的图片会根据需要，结合 CDN 的功能去选择图片大小和格式，以节约带宽资源。当然，CDN 默认一般来说是会对图片进行一次压缩。

在小程序包中我所做的事情

既然打算把图片丢到小程序包中，且所有静态资源和代码文件总大小不能超过 2M，那么想要存放更多图片素材，只能从图片上着手。代码上再怎么节约，最多也就是那么几 K 的事情，完全可忽略不计。

图片格式选择

在图片格式的选择中，捏脸的素材基本上都是带 alpha 通道的 png24/32 图，也就是那种无损的带透明效果的 .png 图，仅有类似背景这样的图片可以考虑转为 .jpg 格式图片。

图片的二次压缩

在对图片格式选择，导出之后，基本上也已经考虑了大小的压缩。当时拿到素材包的时候，被告知已经经过某款图片压缩软件进行过一次压缩了。

可能是我个人习惯性的行为吧，拿到图片就直接丢到自己一直在使用的图片压缩工具 ImageOptim 再进行一次压缩，结果发现还是有压榨的空间。

我以为我已经压缩到极致了

5 个小程序，从一开始，通过 ImageOptim 压缩后，我以为已经是压缩到极致了，从小程序包这样的提示

逐步演变到这样的提示

理论上应该是很满足了。的确，从 4368 kb 到 2168 kb 这样十分接近 2048 kb 的情况下，实在不行那就删掉几张捏脸素材不就可以了。

是的，前面个别小程序我的确是这样做了，捏脸素材虽然是黑白色，但还是删掉了一些素材，最终满足小于 2M 的要求，然后发布上线。

我以为的以为其实是错误的

在后来几个版本的捏脸小程序中，使用的素材是彩色的，素材大小也更大了，刚开始我很纠结。无意间突然想到，既然不能把图片尺寸变小，图片格式也不能换，那么要改变图片大小只能尝试更换不同的图片压缩工具了。

因为，早期曾经参与的一个图片压缩项目中，大概了解到，对于 png 的压缩算法是有多种的。既然如此，那么换一个图片压缩工具是不是就可以呢。于是，首选大家普遍会去使用的 tinypng（https://tinypng.com/），没想到结果让我很意外。

这压缩率，真的是杠杠的啊。原本已经被压缩过的图片，结果还有这么大的压缩空间。于是直接找@地狱京 同学要更多素材。

刚开始他还以为我把图片质量降低很多，后来看了看，也就没说什么了。

关注公众号：拾黑（shiheibook）了解更多

赞助链接：

关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/