短视频作为内容重要的承载方式，是吸引用户的重点，短视频的内容与体验直接关系到用户是否愿意长时停留。因此，体验的优化就显得尤为重要。上一篇我们分享了 iOS 短视频秒播优化，这篇我们来聊聊 Android 端的优化。
作者｜少阳
审校｜泰一
优化前的盒马沉浸式短视频播放页面，体感和流畅度上与主流短视频 App 有明显差距。主要问题有播放封面闪屏、出流速度慢两个问题。所以优化的目标是解决盒马沉浸式短视频现有短板，与主流 App 的沉浸式短视频体验对齐，如抖音、手淘等。具体指标有：
满足硬性指标：播放成功率、首帧时长、秒开率。
满足用户体感流畅度。（为反应用户观看短视频过程中的真实体验，盒马新增秒播体感指标：从用户划到视频，到视频首帧播放的时间。）
优化效果对比首先我们来看一下优化前后与其他 App 的效果对比：
https://v.youku.com/v_show/id_XNTgwMzAwNDQ0OA==.html
手机：Pixel 4
OS：Android 10
播放器：淘宝播放器
问题分析 首页闪屏盒马最初为了保证进入画面时不是空白页面而增加了封面图显示，在播放时隐藏。从体感指标可以看出，即便是优化前，体感播放时间很短，只有 200ms 左右（不包含滑动过程）。由于滑动过程中，到视频正式播放有约 600ms 左右时间显示封面，随后又迅速显示播放画面，此时用户仍有强烈的屏幕闪烁和顿挫感，体验极差。
解决思路：在滑动过程中就显示视频首帧画面，不再显示封面，则播放时不再产生顿挫感。这里的优化需要结合出流慢问题一起优化。
服务端：服务端造成的出流速度慢，一般是文件大，网络链路差造成。可用 H.265 和 CDN 加速优化
客户端：客户端播放需要经历下载 -> 加载 + 解码 -> 渲染三个步骤，并且三个步骤为线性执行。所以在窗口播放画面前必然需要经过 1s 左右的准备工作。这里可以考虑提前执行下载 -> 加载 + 解码。
在优化前期，我们考虑了三种优化方案。
方案一：双播放器 + 预下载
优点：占内存小，思路简单。
缺点：优化力度有限，无法同时兼顾上滑和下滑。
方案二：自定义三播放器管理 + 预下载
优点：同时兼顾上下翻页，体验接近抖音。
缺点：播放器管理与回收实现复杂，容易错乱；占用内存高。
方案三：三播放器（基于 RecyclerView 的缓存机制实现）+ 预下载
优点：同时兼顾上下翻页，体验接近抖音，缓存机制由 RecyclerView 托管。
缺点：占用内存高，频繁创建和销毁播放器。
最终因为性价比因素，选择了第三个方案。
方案三原理：翻页前current 播放器开始播放视频 1。
pre,next 播放器分别加载视频数据 0 和 2。
同时视频数据 3-7 加入预下载队列。
被 RecyclerView 回收的 holder 销毁播放器。
RecyclerView onBind 中的 holder 创建新的 next 播放器。
current 播放器开始播放视频 2。
pre 播放器 seek 0 并暂停， next 播放器创建并加载视频 3 文件。
同时预下载清除未消费的队列，视频数据 4-8 加入预下载队列开始下载（此处已有缓存的视频不会被重复下载）。
为了解决体感上的顿挫和出流慢的问题，采用多播放器结合 RecyclerView 方案进行改造，步骤如下：
设置缓存数量：利用 RecyclerView 特性，配置 setItemViewCacheSize，确保内存中存在 3 个 holder（缓存的 1 个 holder，预创建 1 个 holder， 当前 holder）。
mRecyclerView.setItemViewCacheSize(1); // 设置缓存数量