图片格式
开发中常见的图片格式有 GIF、PNG8、PNG24、JPEG、WEBP。
我们需要根据图片格式的特性和场景需要选取适合的图片格式，而不是设计给什么用什么。
PNG
PNG 的目的是替代GIF和TIFF文件格式，同时增加一些GIF文件格式所不具备的特性。流式网络图形格式(Portable Network Graphic Format，PNG)名称来源于非官方的“PNG’s Not GIF”，是一种位图文件(bitmap file)存储格式，读成“ping”。PNG用来存储灰度图像时，灰度图像的深度可多到16位，存储彩色图像时，彩色图像的深度可多到48位，并且还可存储多到16位的α通道数据。PNG使用从LZ77派生的无损数据压缩算法。
特性
- 支持256色调色板技术，文件体积小。
- 无损压缩
- 最高支持48位真彩色图像以及16位灰度图像。
- 支持Alpha通道的透明/半透明特性。
- 支持图像亮度的Gamma校准信息。
- 支持存储附加文本信息，以保留图像名称、作者、版权、创作时间、注释等信息。
- 渐近显示和流式读写，适合在网络传输中快速显示预览效果后再展示全貌。
- 使用CRC防止文件出错。
- 最新的PNG标准允许在一个文件内存储多幅图像。
更多
PNG官方站 - PNG General Information
JPEG
JPEG是一种针对照片视频而广泛使用的一种有损压缩标准方法.
特性
- 适用于储存24位元全采影像
- 采取的压缩方式通常为有损压缩
- 不支持透明或动画
- 压缩比越高影像耗损越大，失真越严重
- 压缩比在10左右肉眼无法辨出压缩图与原图的差别
更多
WEBP
WebP，是一种同时提供了有损压缩与无损压缩的图片文件格式，WebP支持无损压缩和透明色的功能。
特性
- 同时提供有损压缩和无损压缩两种图片文件格式
- 文件体积小，无损压缩后，比 PNG 文件少了 45％ 的文件大小；有损压缩后，比 JPEG 文件少了 25% - 34% 文件大小
- 浏览器兼容差，目前只支持客户端 Chrome 和 Opera 浏览器以及安卓原生浏览器(Andriod 4.0+)，WebP兼容性
更多
更多关于WebP：
GIF
GIF图象是基于颜色列表的（存储的数据是该点的颜色对应于颜色列表的索引值），最多只支持8位（256色）。GIF文件内部分成许多存储块，用来存储多幅图象或者是决定图象表现行为的控制块，用以实现动画和交互式应用。
特性
- 优秀的压缩算法使其在一定程度上保证图像质量的同时将体积变得很小。
- 可插入多帧，从而实现动画效果。
- 可设置透明色以产生对象浮现于背景之上的效果。
- 由于采用了8位压缩，最多只能处理256种颜色，故不宜应用于真彩色图片
更多
团队约定
内容图
内容图多以商品图等照片类图片形式存在，颜色较为丰富，文件体积较大。
- 优先考虑 JPEG 格式，条件允许的话优先考虑 WebP 格式
- 尽量不使用PNG格式，PNG8 色位太低，PNG24 压缩率低，文件体积大
背景图
背景图多为图标等颜色比较简单、文件体积不大、起修饰作用的图片。
- PNG 与 GIF 格式，优先考虑使用 PNG 格式,PNG格式允许更多的颜色并提供更好的压缩率
- 图像颜色比较简单的，如纯色块线条图标，优先考虑使用 PNG8 格式，避免不使用 JPEG 格式
- 图像颜色丰富而且图片文件不太大的（40KB 以下）或有半透明效果的优先考虑 PNG24 格式
- 图像颜色丰富而且文件比较大的（40KB - 200KB）优先考虑 JPEG 格式
- 条件允许的，优先考虑 WebP 代替 PNG 和 JPEG 格式
优化
图片是页面显示中很重要的部分，图片加载关系到用户体验、应用性能
常见处理方式
减少文件体积大小
上线的图片都应该经过压缩处理，压缩后的图片不应该出现肉眼可感知的失真区域。
压缩优化图片大小
采用合适的图片格式
减少图片资源请求数
合成雪碧图
使用建议
- 适合使用频率高更新频率低的小图标
- 尽量不留太多的空白
- 体积较大的图片不合并
- 确保要合并的小图坐标数值和合并后的 Sprites 图尺寸均为偶数
预加载
图片预加载可以提高用户体验，对于图片长列表和图片占比很大的背景图尤其重要。
css 预加载
利用css的background属性可以预先加载图片。加载后隐藏。在其他地方在请求一样的地址时会优先去加载缓存内的图片进行显示，达到一个预加载的效果。不好的地方就是会影响影响页面渲染速度
显性预加载
显性预加载指的则是处于预加载过程时页面有明确的加载提示，比如进度条或者是Loading图标，让用户有个心理预期，减少等待的烦躁感。
隐形预加载（基于用户行为的资源预加载
通过触屏页面进度加载对应的资源。常见tabs切换，通常的处理是当用户去点击选项卡按钮的时候，在对应面板呈现的时候，我们再去加载图片内容。于是，就存在这样一个不好的体验——由于内容呈现瞬时，而图片呈现是异步的，就很容易出现选项卡主体内容切换过来了，结果是个空白，过了会儿图片才出现。
预加载组件
先加载一张缩略图，该缩略图通过样式设置为和原图一样的宽高，这样用户首先能很快速地看到一张模糊的图片，此时再去对原图做预加载，加载完成之后对缩略图进行替换，因为此时图片已经下载过了，所以界面上能无缝地切换为原图显示
链接：https://aotu.io/notes/2017/01/06/wxapp-img-loader/index.html
懒加载
指的是图片在页面渲染的时候先不加载，页面渲染完成后在指定动作触发后再加载图片。
这种方式通常比较合适于篇幅较长的页面，并且图片内容的重要性低于页面信息内容，能够快速地先将重要的页面信息呈现给用户。
lazy-load
image 自带属性。 图片懒加载，在即将进入一定范围（上下三屏）时才开始加载。
lazy-loadbooleanfalse图片懒加载，在即将进入一定范围（上下三屏）时才开始加载
官方推荐优化方式–关于图片资源的优化
目前图片资源的主要性能问题在于大图片和长列表图片上，这两种情况都有可能导致 iOS 客户端内存占用上升，从而触发系统回收小程序页面。建议开发者尽量减少使用大图片资源
控制代码包内的图片资源
小程序代码包经过编译后，会放在微信的 CDN 上供用户下载，CDN 开启了 GZIP 压缩，所以用户下载的是压缩后的 GZIP 包，其大小比代码包原体积会更小。 但我们分析数据发现，不同小程序之间的代码包压缩比差异也挺大的，部分可以达到 30%，而部分只有 80%，而造成这部分差异的一个原因，就是图片资源的使用。GZIP 对基于文本资源的压缩效果最好，在压缩较大文件时往往可高达 70%-80% 的压缩率，而如果对已经压缩的资源（例如大多数的图片格式）则效果甚微。
写在最后
凡事都是实践出真知。围绕着业务，切合实际的进行优化处理。
不要为了优化而优化。
参考链接： https://guide.aotu.io/index.html
https://aotu.io/notes/2017/01/06/wxapp-img-loader/index.html
强力驱动