最底层我们称作CDN源站，这里我们部署了图片格式转换工具，业务方不需要care JPG制作出来后再生成sharpP还是WebP，只需要把图片发布在CDN源站上就能自动转成对应的格式和屏幕分辨率；

往上是用户手机接入的CDN节点，部署全国各地用于加速和缓存文件的server。

我们和浏览器团队做了合作，把sharpP的解码格式放在浏览器内核中，这样最上层的业务不需要关心当前的浏览器是否支持WebP还是sharpP。

在打开页面的时候，WebView会自动带上终端的屏幕尺寸以及支持哪些图片格式给CDN节点，CDN节点再从源站获取最新的图片，源站这个时候有可能已经离线或实时生成好对应的图片了。

拆开来看WebView这一层，除了集成sharpP的解码库之外，其他事情相对简单，例如：

在请求header里面额外添加了字段，比如User-Agent里添加了“Pixel/750”，如果是480px的机器这个值就变成480;

在Accept里增加了sharpP的协议头：image/sharpP

在源站里会存储3*3数量的图片，每一张业务图片提交给源站发布的时候，都会生成9张图片。CDN节点会根据WebView的请求，在回源的时候向CDN源站请求对应类型的图片，但对于业务和WebView来看请求的还是同一个链接，这样手机QQ所有的H5页面都不需要任何一行前端代码的修改，就能享受图片格式所带来的尺寸自适应和流量节省。

以下是更形象的过程，在Accept增加字段，然后返回对应的图片：

这个技术并不复杂，我个人认为不存在太深的技术门槛，更多的是从客户端、Web到CDN后台这整个链条的打通。但过程中我们也踩了一些坑：我们在灰度的时候发现很多iOS用户来投诉说页面展示时图片不能展示。

这个让我们非常惊讶，因为当时还没有把这项技术部署到iOS上，只是Android在应用。我们检查了CDN的代码也没有问题，那为什么会把sharpP的图片下发到iOS用户呢？

后来分析发现，中国不同地区运营商之间，会做类似CDN Cache的缓存服务。当Android用户第一次请求sharpP图片的时候，运营商的server从我们的CDN拿到了sharpP格式链接。当缓存生效期间内，同一个地区其他iOS用户上来请求时，运营商发现URL一样，直接就把sharpP格式的图片返回给iOS用户。

这个问题是我们整体架构上没有去全盘review而踩中的坑，HTTP有个标准的约定可以解决这种缓存问题。在CDN分发内容的时候，通过Vary字段指定缓存的时候要去参考Accept和User-Agent里的字段，我们把这个Vary加上之后问题基本解决了。

这个案例给了我们额外的启发。我们现网中，Pixel字段有三种取值：480px、640px、750px。我们内部讨论过是否可以把屏幕尺寸直接写在User-Aagent里，这样以后Android出了一些新的屏幕分辨率我们也能在后台做更好的自适应，为每种机型去生成不同格式的图片。

假如真的这么做的话，会给运营商和我们自己的CDN缓存带来巨大的回源开销。每个分辨率的图片都要缓存一份，例如498px，中间运营商没有这机型的缓存，就会到我们的服务去回源，这样N个屏幕尺寸会给我们CDN带来N倍的回源压力。

　　数据以及效果

言归正传，最后数据效果也是比较明显的，下图是我们在Android灰度的效果数据。我们H5业务的图片流量从40+GB下降了20+GB。对于腾讯来说20+GB的带宽不是特别大的成本，但是在春节活动场景下，可以增加近一倍的业务空间。额外带来的好处，是用户看到页面图片所等待的时间相对缩减了，用户侧的流量也节省了一半。

　　H5快速运营时的稳定性

我们解决了页面加载速度和流量消耗的问题时，也开始考虑H5在快速运营下的稳定性问题。相信前端开发都有遇到过某个页面代码一改，其他功能就不正常了的情况。采用hybrid开发很有可能native是要给JS页面提供很多API的，客户端小小的改动可能导致JS API受到影响，从而导致全网的H5页面功能不正常。