QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、上海、旧金山召开。自 2007年 3月份首次举办以来，已经有超万名高级技术人员参加过QCon大会。QCon内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5年以上工作经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和最佳实践。
4月18日性能优化面面观专题会议上，腾讯研发总监王辉以“十亿级视频播放技术优化揭秘”为主题，用QQ空间的日均播放量一年内从千万级突破到十亿级所面临的严峻考验为切入点，为大家分享视频团队在视频组件的整体架构、优化效果衡量、带宽优化、秒开优化、缓冲优化、成功率优化等六个方面的技术实践。
王辉：大家早上好！我叫王辉，来自腾讯，从2009年开始从事QQ空间技术研发，近期主要关注手机短视频、视频直播、AI智能硬件。很高兴能在QCon上与大家一起分享和交流。我今天的话题是“十亿级视频播放技术优化揭密”。主要介绍我们团队在去年一年短视频风口上，我们的视频播放量从5000万到十亿级过程中的一些技术实践，希望我的介绍能给大家做一些借鉴和参考。
众所周知，短视频去年是一个风口，起因是来自Facebook 2015年Q3的财报，财报表明在Facebook平台上每天有80亿次短视频播放，给Facebook带来了强劲的广告收入，正是这个数据给国内核心大公司和创业公司带来的一些新的突破口。其实短视频已经不是一个新的概念，从2006年开始国内就有很多公司在做短视频。随着Facebook吹起短视频风，去年在短视频行业有近百款应用出现，中国网民里面每5个里面就有1个是短视频的用户，短视频成为互联网的流量入口。QQ空间也在这个风口中，从2015年11月份的每天5000万视频播放量，经过一年的耕耘细作，徒增到2016年12月份的10亿量级，现在还在不断增长。
我的演讲主要是按照我们产品迭代的几个关键步骤展开：
首先是快速上线，2015年我也是跟随着大家的体验快速上线了新短视频的体验；
其次面临的是成本问题，在做的过程中做了一些成本的优化工作；
然后是体验优化。在解决成本问题之后，短视频的观看体验要做到极致。比如说视频的秒开、不产生缓冲、不卡、成功率的提升。
快速上线
在开始之前，我先介绍一下我们的团队职责，我们团队负责手机QQ和手机QQ空间两个APP，每个APP有iOS和Android两个团队，一共四个团队，四个团队负责两个APP。在这个项目中，我们四个团队要针对两个平台实现四套逻辑，这里的效率是存在一定的问题。
关于短视频体验，在这之前，我们也只是做到能播放而已，没有做很精细的工作，并且这里的产品观感体验也不是很一致，也不是很好。
技术上，之前也只是做很基础的架构，直接由播放器连接服务器下载数据，达到能播放就可以。之前我们没有积极去做这个事情，导致播放成功率低、失败原因未知、不支持边下边播、缓冲时间比较长等问题，流量浪费也比较严重。在产品上要解决的，是在整个APP里面把所有产品的体验做到一致，比如说每个功能的观看体验，视频浮层的体验，统一观看体验也为我们项目清除了很多障碍。
而这里的技术上的要点是非常关键的，第一个是边下边播，这是基础的要求，是为了加快视频播放速度。第二个是流量的控制，这么大的平台，之前只是做5000万的播放量，如果没有流量控制的云策略，可能到后面流量是无法把控的。第三，刚才讲到团队的现状，团队要负责两个APP，这里要做代码复用，不可能再像之前一样四个团队维护四套代码，第四，我们支持第三方的视频源。第五，需要完善监控上报，对业务知根知底。
可以看到，完成核心技术要点最核心的一点是如何控制视频的下载，传统的方式是播放器直接塞播放地址给播放器，它就可以直接播放，这其实是一个黑盒。我们在中间加了一个本地代理，播放器与服务器的数据请求，我们完全可以把控。在这个过程中，比如说播放器要数据时，可以给它更多的数据，这样能解决它缓冲的问题。有了这层代理之后，架构也更清晰一点。
基于这样的架构，在MODEL一层做一些业务的逻辑，在VideoController这一层做控制视频的播放和下载。有了下载代理之后，就可以通过代理管理下载，在APP里面有很多的视频请求，VideoProxy可以管理这些请求，做流量控制，做预加载，还可以做优先级调度和做监控上报，下载逻辑层则主要关注怎么优化服务器，对接缓存管理层，同时我们抽象出了一个数据层，我的数据源可以是HTTPDataSource，也可以读本地，也可以是来来自腾讯视频的数据源，也可以是第三方APP的数据源，协议层主要是HTTP、HTTPS、HTTP2的解决。
在VideoController的逻辑里，其实都可以放到C层来实现，这样安卓和iOS完全可以通用，这一层的逻辑可以在QQ和QQ空间两个APP里面使用，相当于是我们一套逻辑可以完全复用，不用再开发四套逻辑，我们团队的职能也做了相应调整，之前可能是按团队划分，四个团队负责四个终端，现在可能是按FT的方式划分做视频的团队，iOS做视频的团队可能负责QQ和QQ空间里的业务，安卓也是如此。直播的FT也可以这样划分，iOS的负责iOS的两个APP，安卓的负责安卓的两个APP，这样代码复用更清晰一点，我的团队更专注一点。视频的团队专注视频的研发。
监控上报，肯定是不可缺少的，这是一个成熟的项目必备的要素。
1. 问题定位，老板跟用户反馈说我这个视频播不了，要有一套成熟的问题定位的方式；
2. 耗时统计，用户播放这个视频花多长时间播出来，这也是要了解到的；
3. 成功率统计，外网用户播放视频的成功率是多少？还要通过实时报警，才能及时知道外网发生一些故障。
传统的捞Log方式大家都有，但是这种方式效率太低，需要等用户上线之后才能捞到Log，Log捞到之后还得花时间去分析。我们做法的是在关键问题上做一些插装，把每一类错误和每一个具体的子错误都能定义出来，这样一看错误码就知道播放错误是由什么原因导致的。还可以把每次播放视频的链路所有关键流水上报到统计系统里来，每一次播放都是一组流水，每一条流水里面就包含了例如首次缓冲发生的Seek，或下载的链接是多少，下载的时间是多少，有了这些流水之后，用户反馈播放失败，我首先可以用流水看发生了什么错误？错误在哪一步？每一步信息是什么？几秒钟就可以定位到问题。
有了这个数据上报之后，还可以做一些报表。比如说可以做错误码的报表，有了报表之后就可以跟进哪个错误是在TOP的，负责人是谁，原因是什么，都可以看到。
我们也有自己实时的曲线，可以看到各项数据的情况。在告警方面，基于成功率和失败率的统计，进行实时告警。一出现错误码，微信立即可以收到提醒，提醒说是什么原因导致这次告警，全自动。
成本优化
上线一个月之后，一个坏消息一个好消息。好消息是播放量涨了4倍，坏消息是带宽涨了6倍。带宽优化是每个做视频的人必须要面临的问题，我们也分析这个过程中的原因，发现因为改为边下边播之后用户观看视频的意愿比较强，用户有挑选心理，不是每个视频都去看，看了一下之后不喜欢就划走了，之前下载的那部分其实是浪费的。如果之前不做限速的话，