秒开率达90%：腾讯看点客户端 GIF 转视频优化方案
导语 |众所周知，在动图场景中， GIF 一直是应用得最广泛的技术，然而 GIF 文件体积太大的劣势，导致了一些诸如客户端 GIF 加载慢、服务器占用带宽大等问题。那么，在 GIF 占比如此高的今天，有没有一些更合适的动图格式，既能减小文件体积和服务器带宽，又能在客户端有不俗的性能表现？本文将介绍信息流场景下一套 GIF 体验提升的通用解决方案，该方案已经在腾讯看点内短内容场景中落地。
问题背景
看点短内容是看点信息流的重要内容，短内容有些类似微博段子，内容大多以娱乐、搞笑为主，因此有大量的 GIF 动图。我们发现在一些网络较差的情况下，GIF 动图加载极慢，有些甚至达到了 10+s 之久（如下视频所示）。另一方面，信息流动图使用场景密集，大量的GIF图下载导致带宽成本增加。面对体验和成本问题，我们开始预研和寻找优化方案。
为了方便对比动图优化前后的效果，我们首先对 GIF 做了相关数据上报，主要包括 GIF 文件体积以及加载耗时。在大盘数据中，我们的统计数据结果如下：
从以上数据得知，有超过一半的 GIF 文件体积超过了 1M，有大约一半的 GIF 耗时超过了1s ，长尾部分的用户等待时间长达数十秒，在弱网状态下情况变得很糟糕，可见这其中还有许多优化空间。从客户端的角度，如果仅仅是为了减少用户等待动图加载的时间，其实可以使用一些常规的手法，比如预加载等，但是为了节省网络带宽，我们可以直接替换成另一种动图格式来进行优化。最终，我们采用了 GIF 转 MP4 视频的技术方案，方案架构图如下所示，后台在 GIF 入库时会预先将 GIF 转化成 MP4 视频，并生成视频 vid，后台将视频 vid 下发到客户端后，客户端根据视频 vid 向内容中心请求视频链接，获取到视频链接后在客户端进行播放：
动图技术方案
当前的动图技术除了 GIF 外，常用的技术方案有以下几种：
APNG
APNG（Animated Portable Network Graphics）是一种基于 PNG 的拓展动图格式，不同于 GIF 只有 1 位透明通道，APNG 动图格式支持 8 位透明通道，所以 APNG 动图会有更好的质量。APNG 采用 Deflate 算法，另外由于继承 PNG 的 filter，利用相邻像素的近似性使得压缩率大大提高。但是，由于 APNG 未得到 PNG 开发组织的支持（PNG 有自己的亲儿子 MPNG，奈何亲儿子不争气），APNG 在浏览器方面兼容较差，一开始仅得到 Mozila FireFox 的兼容支持，因此没有流行起来。
WebP
WebP 由 Google 主导开发，是一种同时提供了有损压缩与无损压缩的图片文件格式，派生自影像编码格式 PV8，自从谷歌在 2010 年推出以来，应用得越来越广泛。它同时也支持动图（Animated Webp），国内一些 APP 比如抖音在某些场景中就是用 WebP替代了 GIF。
SharpP
SharpP 是公司自主研发的一种图片格式，它基于HEVC 视频压缩编码标准开发，并且已经广泛运用于公司内众多产品（腾讯新闻、空间相册、天天快报等），并支持 Windows、Linux、Android、iOS 四大平台，而且已经移植在 X5 浏览器内核中。
MP4 视频
Facebook 早在2014年就尝试将 GIF 转成 MP4，这帮助他们节省了大量带宽，如下是 Twitter 中的 GIF 动图的展示，实际上这些是一个个 MP4 视频，用户体验非常好：
方案对比
根据相关文章的评测数据，WebP、H264、HEVC 和 SharpP 的压缩率对比如下：
我们自己选取了一张 GIF 图片转换成APNG、WebP（85 质量）、SharpP（两个等级） 和 MP4（H264、H265）四种格式，得到下面的数据：
我们可以看到在压缩率方面，APNG 和 WebP 的压缩率均远低于 SharpP 和 MP4，而且是差距比较大。另外我们还研究了今日头条、微博、Twitter 以及 天天快报这几个 APP 中类似的 GIF 场景，得到的结论如下表所示：
APP | 动图方案 | 弱网表现 |
头条 | GIF | 较差 |
微博 | 大图动图使用H.264 视频，多图动图 沿用 GIF 格式 | 较好 |
只有大图动图，使用H.264 视频 | 较好 | |
天天快报 | SharpP | 较好 |
可见，GIF 转视频是业界比较通用的解决方案，在某些场景下（例如大图 GIF），使用视频替代 GIF 是一个不错的选择。在公司开发的几款产品（天天快报、QQ 浏览器、腾讯新闻）中，SharpP 动图也是应用得比较广泛的动图格式。考虑到文件压缩比，我们将在 SharpP 和 MP4 之间选择动图方案。接下来我们比较两种方案哪种更适合我们的场景。
在 CPU 占用方面，选择一张 GIF 动图转化成 SharpP 和 MP4，并使用 Android Studio 查看两者在播放时的 CPU 占用率，如下图所示，上图为 SharpP，下图为 MP4：
从上面两张图的对比中可以看出，SharpP 整体比较稳定，大概占比在7%到9%之间，而 MP4 在一开始会有个小高峰，随后立马下降。MP4 的这个小高峰实际上是打开链接时产生的消耗，这个过程只会在动图播放时产生一次。因此，在 Android 上两者的 CPU 占比是十分接近的。
SharpP 和视频其他方面的对比如下表：
SharpP | H264 | H265 | |
编码速度比 | 10 | 3 | 140 |
透明通道支持 | 支持 | 不支持 | 不支持 |
通用性 | 第三方平台（浏览器等）不兼容 | 通用 | 通用 |
硬解支持 | 不支持 | 基本支持 | 部分机型不支持 |
可以看到，视频在通用性和硬解支持相对于 SharpP 有优势，另外视频还支持边下边播，可以帮助我们快速出图，加上官方本身缺乏对 SharpP 动图组件的支持，所有的下载和解码需要我们进行开发，开发成本比视频大。此外，视频也很适合我们的场景，因此，我们最终选择了视频作为我们的解决方案。
优化效果
使用视频替代 GIF 的方案在弱网的表现优化效果如下视频所示，可以看到经过优化，动图体验好了很多，基本属于秒开级别：
该方案上线后，我们统计了大盘数据，优化后取得的效果如下图所示，文件大小减小了62%，秒开率（1s 内打开动图的比例）从 50%提高到了 90%，用户等待时间减少了75%：
另外，通过 ABTest，该技术方案有效拉动了业务指标的增长，短内容有效曝光增长约5.62%，极大地提升了短内容的转化效率，如下图所示：
不过，并不是所有的 GIF 场景都适合转化成视频，由于视频在 CPU 上的消耗比 GIF 文件要多，在其他场景比如页面中同时存在多个 GIF 时，非视频的动图格式（比如 GIF、WebP）还是更优的方案。
总结
为了能让这个方案更加通用化，我们的目的是针对信息流搭建一套适用于信息流的动图组件，支持 GIF 和视频动图，并提供多种播放策略控制能力（比如在动图滑出屏幕外、切后台等不可见场景时默认不播放，滑入屏幕内再开始播放）、底层换链能力（兼容不同业务的换链方案）等。
根据上线后的效果来看，GIF 转视频带来的收益不仅包含了网络带宽的节省，用户等待 GIF 加载时长的减少等技术上的收益，在业务上还带来了短内容曝光等指标的增长，是技术推动业务增长的一个不错的案例。长期看来，由于视频编解码技术仍在不断发展中，比如 H.266 ，采用视频格式的动图以后也能进行无缝切换。综上，GIF 转视频是一个值得推广的技术方案。