seolu于2022-05-15发布在盒马最初添加了封面图片显示，以确保进入屏幕时不是空白页，并在播放时隐藏。从体感指标可以看出，即使在优化之前，体感播放时间也很短，只有左右（不包括滑动过程）。滑动过程中，在视频正式播放之前，大约需要一段时间才能显示封面，然后快速显示播放画面。此时，用户仍然有强烈的屏幕闪烁和挫败感，体验极差。
解决方法：滑动过程中显示视频的第一帧，不再显示封面，播放时不再有挫败感。这里的优化需要结合慢流出问题。
2 串流速度慢（播放感觉慢）
服务器：服务器造成的流出速度慢，一般是文件大，网络连接不好造成的。通过 H.265 和 CDN 加速进行了优化
客户端：客户端播放需要经过下载->加载+解码->渲染三个步骤，三个步骤线性执行。因此，在窗口播放屏幕之前，必须进行 1s 左右的准备工作。这里可以考虑提前下载->加载+解码。
优化方案选择
在优化的初期，我们考虑了三种优化方案。
选项 1：双播放器 + 预下载
优点：内存占用小，思路简单。
缺点：优化力度有限，无法兼顾上下滑动。
方案二：自定义三人管理+预下载
优点：同时兼顾页面上下，体验接近抖音。
缺点：播放器管理和回收的实现比较复杂，容易混淆；内存使用率很高。
方案三：三个播放器（基于缓存机制实现）+预下载
优点：同时翻页翻页，体验接近抖音，托管缓存机制。
缺点：内存占用高，玩家创建和销毁频繁。
最后，由于成本效益因素，选择了第三种方案。
方案三原则：翻页前
方案三原则：翻页后
具体优化方案
多人改装
为解决体力受挫、流出缓慢的问题，采用多人组合方案进行改造。步骤如下：
1. 设置缓存数量：利用特性，配置，确保内存中有 3 个（1 个用于缓存，1 个用于预创建，当前）。
mRecyclerView.setItemViewCacheSize(1); // 设置缓存数量2. 被覆盖，用于创建播放器，并预加载解码后的视频内容短视频优化，播放器控件解析到第一帧时暂停。此时还没有被回调，图片还没有渲染到屏幕上。
3. 控件可暂停即将移除屏幕的播放器，以及 (0)，以便在滑回屏幕时立即播放。
4. 监视器控制即将进入屏幕的播放器开始播放。
注意：由于期间解码已经完成，只需要进入屏幕1px，就会立即触发绘制（只执行一次），即进入窗口的内容会显示第一帧视频。
5. 被覆盖，由于当前即将被移出屏幕快速排名，因此移出方向的屏幕外将被回收。此时玩家被回收和销毁。
多人游戏 + 示意图
三位播放器大幅提升沉浸式短视频的体验，主要解决以下问题：
预下载优化
如前所述，多人秒翻页的能力大大提升了体验。但是，由于预先创建的播放器在加载时需要下载视频文件，所以这里的下一个播放器已经为视频做好了准备。时间会增加到1s左右。如果用户在播放器未完成加载解码之前滑动到视频，会出现明显的黑屏，导致体验很差。
因为预加载时间太长，无法预测用户是否会快速刷卡。这里需要提前下载快速滑动检测。
关于预下载，我们首先要了解播放器内部的播放流程。这里的本地代理是通过视频缓存机制实现的，具体请参考下一章。
播放器内部流程
1 预下载策略
这里，为了节省请求网络数据的过程，我们在播放前提前下载了视频的第一帧，采用如下策略：
2 快速滑动的定义
当用户快速翻页时（调用前再次滑动）不会触发seo优化，会触发多次。如果判断和in的差值>1，则表示用户至少快速翻页一次，定义为快滑状态，应该停止预下载和播放器预加载。
回调时，表示用户不再继续翻页，此时取消快速滑动状态。开始执行预下载并恢复播放器预加载。
预下载流程图
缓存优化
目前盒马使用的播放器是淘宝内部播放器。播放器本身不具备文件缓存和预下载功能。重新创建播放器后，即使是相同的视频也不会有文件缓存，需要重新下载。这里介绍一个开源缓存框架“com.:”。
方案原理
播放器播放的地址代理到本地缓存服务，缓存服务负责转发数据流和保存文件短视频优化，如：
视频地址为：****.mp4。
本地代理地址为：:8888（假设端口号分配为 8888)。
代理地址为：本地代理地址+视频地址（URL编码）。
