爱奇艺播放技术——300ms背后的故事

爱奇艺大播放内核运行在 Android Mobile、Android TV、Apple TV、iPhone、iPad、GPad、MAC、Windows PC 等不同业务平台，支持以“直播、点播”为核心的广告、会员、VR、AR、交互视频等业务，经过9年4个大版本迭代，对于用户长视频播放“点击/播放”场景已经达到了相对稳定阶段，性能上基本能满足了所有的长视频播放场景。期间，在播放性能优化上，不同业务均围绕着大播放内核已有的性能展开，大播放内核也会为根据业务场景的不同进行一些迭代优化，犹如同一款发动机，总会针对不同综合工况做出不一样的调校，以便最大限度发挥其性能。

01

   背景

  01 问题  

近两年，随着极速版业务、主 APP 短视频等“瀑布流”模式“滑动/播放”场景的需求增长，原有的开播性能已经无法适应业务场景。为了更好的应对业务需求，业务开发方面，需要创建 2~3 个播放器实例，以便在界面滑动时，采用“预加载+实例切换”的方案达到“零秒”开播的目标，即当前播放的时候，创建另一个或者几个播放器准备后续播放视频，切换的时候，画面可以直接展现出来。多实例的方案在开发上简单快捷，也带来内存使用量、线程数量的暴增，典型的“空间换时间”方式，对于高端设备来讲不会存在性能上的问题，但在中低端设备，则可能会对整个 APP 带来较为严重的卡顿问题。因此，该方案在使用场景上受到了一些限制。

  02 调查  

从平台角度来看，主要是交互相对较多的 Android 移动设备上问题比较集中。由于在早期版本中就已经支持了“预加载”功能，即播放当前影片时，加载接下来可能要播放的视频流，播放下一个视频是否命中缓存比较容易判断。通过测试数据发现，确实如预期一样，问题并不是出在网络层。相比 Apple 的设备的统一性，Android 设备市场价格从几百元到上万元，性能差异也悬殊。

对于视频行业来讲，一般会从视频播放的能力角度，按分辨率⽀持⾼低、码流⽀持⾼低、H.265/H.264 等 Codec ⽀持等维度划分，可以将 Android 设备按性能简单的分为