可以看到，完成核心技术要点最核心的一点是如何控制视频的下载，传统的方式是播放器直接塞播放地址给播放器，它就可以直接播放，这其实是一个黑盒。我们在中间加了一个本地代理，播放器与服务器的数据请求，我们完全可以把控。在这个过程中，比如说播放器要数据时，可以给它更多的数据，这样能解决它缓冲的问题。有了这层代理之后，架构也更清晰一点。

　　基于 MVC 架构，在 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 的，负责人是谁，原因是什么，都可以看到。

　　我们也有自己实时的曲线，可以看到各项数据的情况。