|
如果要使用持久连接，我们很有可能要经过客户端的加密解密以及组包等步骤，并且要等到整个HTML下载完成之后才能进行显示，我们认为这个时间反而拖慢了性能。
QQHybrid架构 经过上述的介绍后，大家对QQHybrid可能有了大概直观的印象：1. 我们在WebScope的前端开发同学做了一部分工作；2. 我们的native层终端开发同学做了bridge桥接，3.我们后台的同学做了很多的自动集成和offlineServer推送等工作。该部分架构如下：
接下来我将介绍架构图右边关于页面流量的部分。我们统计过各业务中关于流量的分布，如下图，我们可以明显看到大部分的流量都消耗在图片资源上，但我们做这个分析时也曾经有怀疑，是不是业务特性决定了我们图片消耗是最多的？手机QQ其他H5业务是不是也这样？
春节红包的流量分析 恰好我们有了一次机会，在2016年春节时手机QQ做了一次几乎所有业务都有参与的活动——春节红包，大家可能还有印象在2016年春节晚上时不停戳屏幕领红包的操作。这种全民狂欢的背后带来了巨大的流量压力，每秒钟大概给用户发出30万左右的礼包，引导用户的web流量大概每秒钟会有十几万次H5页面的打开，当时评估的流量峰值超过1TB。 我们分析了里面的图片流量，确实占据了接近一半的水平，有一部分我们已经走离线包预推的方式提前下发到用户的手机中，但在活动期间现网的图片流量仍超过了200GB。 流量并不是简单花钱向运营商买就能解决的问题，春节的活动我们几乎遇到了单域名下流量接近200GB的情况，当时CDN的架构已经快扛不住了。
我们都认为这里大有可为，如果图片流量能节省的话，带宽成本能够降低。用户侧所消耗的网络流量和手机电量等等体验都能更好，所以我们团队check了有关图片格式方面的新东西。 SharpP的应用 大家都比较熟悉WebP，而且Android对其支持也比较好，而QQ团队内部自己研发了叫SharpP的图片格式，在文件大小上能比WebP节省10%左右的体积。下面是抽取我们CDN服务器上已有图片进行的数据比对。
图片体积是占优的，但解码速度方面呢？我们分别使用了高、中、低端的机型分析，很不幸SharpP确实会比WebP甚至比JPG要慢一点，但幸运的是我们业务的图片尺寸还不算太大，页面中多花几十毫秒也能接受，相比节省等待网络的时间我们觉得这是更有利的。
于是我们准备在手机QQ H5业务中推广SharpP格式，但推广新图片格式会带来很大的应用成本。首先大部分的图片链接都是写死在代码里面，而且页面并不知道移动终端有没有能力去解码SharpP的格式。 难道H5页面要针对不同的手机QQ版本去准备不同的HTML？或者图片资源发布到CDN上时生成两个不同格式的链接，然后在H5内部根据终端版本选择不同的链接？这个开发成本当然是不可接受的。
除了图片格式的问题，我们发现用户的不同机型会存在流量浪费的情况。我们的UI设计通常都是针对iPhone6的屏幕尺寸做的，默认是750px的图片素材。小屏幕的手机，比如640px和480px，同样是下载750px的图片，然后在渲染的时候进行缩小。 这样实际浪费了非常大的带宽，所以我们思考CDN是否能根据用户手机屏幕尺寸来下发不同格式的图片。 reshape架构 这种屏幕自适应的策略也面临近似私有格式的成本，因为CDN也不知道手机的情况，最后我们提出了reshape的架构，从图片下载完整的环节来看，大概可以分成4个层级：
(责任编辑：本港台直播) |
