网络图片作为 App 的一个重要组成，自然也需要一些关键指标来衡量，有了指标方便看到优化的效果。不过目前貌似没有比较广泛采用的指标，跟其他公司交流时，当聊到 Crash 率，大家都有统一的认知，但聊到图片体验，就很难进行比较了：我们这块一直都不错，用户反馈也不多。但事实可能并不如此。

为什么图片的指标不好定？因为环境比较复杂，边界也不太好确定（不像 Crash，判断条件非常清晰）。

• 网速比较慢，图片出不来或出来得很慢正不正常。
• 图片本身就比较大，下载过程自然就慢了，耗时长一点也正常。
• 即使下载速度比较快，如果是单线程的话，显示上也是一张一张出来，体验并不好。
• 有时图片即使下载成功了，也有可能无法显示。

如果把图片从请求到渲染完成作为一个任务，这个任务的成功跟很多因素有关，但核心阻碍只有一个，就是「图片请求」，其他可优化的空间不多或效果不那么明显，且相对成熟（比如后台多线程下载，滑出屏幕时取消下载等）。因此图片体验的指标可以缩小范围为「图片请求指标」。

跟图片请求最相关的几个因素：

• 客户端网络状况
• 请求协议（http/1.1 http/2）

这些就好像汽车的离合、油门、刹车可以供我们控制，也需要一个仪表盘来看到控制的效果。那这个仪表盘里显示的是什么？

我们希望显示的内容能真实地体现用户的图片体验。在这个前提下，很多因素就不需要考虑了，比如网络环境、机型等。因为同样一张图，如果 3 秒后还没有出来，无论是 wifi 还是 2G，这个体验就是不好的。

接下来再来看图片请求会有哪些结果，很简单，请求成功和请求失败。请求失败比较好办，失败就是失败了，记录一下即可。那么请求成功该怎么细分呢？

我们知道在 web 时代，如果页面 3 秒没有出来，用户离开网页的可能性就会高很多。在图片领域没有相对权威的值，因此结合真实体验，拟定了以下的体验指标：

图片请求失败率: 
	图片请求失败次数 / 图片请求次数

图片请求耗时：
	优: 耗时在 (0, 1] 的次数 / 图片请求次数
	良: 耗时在 (1, 2] 的次数 / 图片请求次数
	中: 耗时在 (2, 3] 的次数 / 图片请求次数
	差: 耗时在 (3, ∞) 的次数 / 图片请求次数

由于真实环境下图片请求次数会很大，因此可以设置采样率，比如 1/1000，也就是 1000 次图片请求记录 1 次，将样本量缩到恰当的范围。

有了这 5 份数据，对于线上的图片体验就能有一定的了解了，接下来可以针对每份数据进行不同维度的数据聚合，比如：城市、网络类型、页面 URL、error_code、CDN 等。如果某个城市的图片访问出了问题，就能很快知道，或者某个 CDN 调整也能快速定位。

同时可以对每份数据的前 N 位 Top 用户进行记录，因为有可能某几个用户发生异常，贡献了大部分的数据。

在这些指标的基础上，可以再从图片大小、尺寸、CDN、网络请求等维度进行优化，方便验证效果。