网络图片作为 App 的一个重要组成，自然也需要一些关键指标来衡量，有了指标方便看到优化的效果。不过目前貌似没有比较广泛采用的指标，跟其他公司交流时，当聊到 Crash 率，大家都有统一的认知，但聊到图片体验，就很难进行比较了：我们这块一直都不错，用户反馈也不多。但事实可能并不如此。
为什么图片的指标不好定？因为环境比较复杂，边界也不太好确定（不像 Crash，判断条件非常清晰）。
- 网速比较慢，图片出不来或出来得很慢正不正常。
- 图片本身就比较大，下载过程自然就慢了，耗时长一点也正常。
- 即使下载速度比较快，如果是单线程的话，显示上也是一张一张出来，体验并不好。
- 有时图片即使下载成功了，也有可能无法显示。
- ···
如果把图片从请求到渲染完成作为一个任务，这个任务的成功跟很多因素有关，但核心阻碍只有一个，就是「图片请求」，其他可优化的空间不多或效果不那么明显，且相对成熟（比如后台多线程下载，滑出屏幕时取消下载等）。因此图片体验的指标可以缩小范围为「图片请求指标」。
跟图片请求最相关的几个因素：
- CDN
- 客户端网络状况
- 图片大小
- 图片格式
- 请求协议（http/1.1 http/2）
这些就好像汽车的离合、油门、刹车可以供我们控制，也需要一个仪表盘来看到控制的效果。那这个仪表盘里显示的是什么？
我们希望显示的内容能真实地体现用户的图片体验。在这个前提下，很多因素就不需要考虑了，比如网络环境、机型等。因为同样一张图，如果 3 秒后还没有出来，无论是 wifi 还是 2G，这个体验就是不好的。
接下来再来看图片请求会有哪些结果，很简单，请求成功和请求失败。请求失败比较好办，失败就是失败了，记录一下即可。那么请求成功该怎么细分呢？
我们知道在 web 时代，如果页面 3 秒没有出来，用户离开网页的可能性就会高很多。在图片领域没有相对权威的值，因此结合真实体验，拟定了以下的体验指标：
由于真实环境下图片请求次数会很大，因此可以设置采样率，比如 1/1000，也就是 1000 次图片请求记录 1 次，将样本量缩到恰当的范围。
有了这 5 份数据，对于线上的图片体验就能有一定的了解了，接下来可以针对每份数据进行不同维度的数据聚合，比如：城市、网络类型、页面 URL、error_code、CDN 等。如果某个城市的图片访问出了问题，就能很快知道，或者某个 CDN 调整也能快速定位。
同时可以对每份数据的前 N 位 Top 用户进行记录，因为有可能某几个用户发生异常，贡献了大部分的数据。
在这些指标的基础上，可以再从图片大小、尺寸、CDN、网络请求等维度进行优化，方便验证效果。