共计 3638 个字符，预计需要花费 10 分钟才能阅读完成。
简介：短视频作为内容重要的承载形式，是吸引用户的重点，短视频的内容与体验间接关系到用户是否违心长时停留。因而，体验的优化就显得尤为重要。上一篇咱们分享了 iOS 短视频秒播优化，这篇咱们来聊聊 Android 端的优化。
作者|少阳
审校|泰一
优化前的盒马沉迷式短视频播放页面，体感和晦涩度上与支流短视频 App 有显著差距。次要问题有播放封面闪屏、出流速度慢两个问题。所以优化的指标是解决盒马沉迷式短视频现有短板，与支流 App 的沉迷式短视频体验对齐，如抖音、手淘等。具体指标有：
- 满足硬性指标：播放成功率、首帧时长、秒开率。
- 满足用户体感晦涩度。
（为反馈用户观看短视频过程中的实在体验，盒马新增秒播体感指标：从用户划到视频，到视频首帧播放的工夫。）
优化成果比照
首先咱们来看一下优化前后与其余 App 的成果比照：
环境
- 手机：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 计划进行革新，步骤如下：
1. 设置缓存数量：利用 RecyclerView 个性，配置 setItemViewCacheSize，确保内存中存在 3 个 holder（缓存的 1 个 holder，预创立 1 个 holder，以后 holder）。
mRecyclerView.setItemViewCacheSize(1); // 设置缓存数量2. 重写 Adapter 的 onBindViewHolder，用于创立播放器，并预加载解码视频内容，播放器管制解析到首帧时暂停。此时 onSurfaceCreated 尚未回调，画面未渲染至屏幕。
3. 监听 onPageRelase 管制行将移除屏幕的播放器暂停，并 seekTo (0)，不便滑回屏幕时立刻播放。
4. 监听 onPageSelected 管制行将进入屏幕的播放器开始播放。留神 ：因为在 onBindViewHolder 期间已解码实现，这里只须要进入屏幕 1px，就会 立刻触发 Surface 的绘制（只会执行一次），即进入窗口的内容会显示视频的首帧画面。
5. 重写 Adapter 的 onViewRecycled，因为以后 holder 行将移出屏幕，移出方向上屏幕外的 holder 将被回收。此时回收并销毁播放器。
多播放器 + RecyclerView 原理图
三播放器让沉迷式短视频的体验大幅提高，次要解决了以下问题：
- 高低滑动过程中，进入屏幕的画面为视频的第一帧画面，并且不会有视觉上的顿挫。
- 正式播放前预创立播放器，并加载和解码，节俭了播放视频之前的筹备工作。（ps：这里还包含了下载的过程）。
- 因为提前加载和解码，进入屏幕时，触发 Surface 霎时渲染，视觉上无感知，因而播放视频前不再须要封面图，防止了封面图和首帧不统一导致的闪屏问题。
预下载优化
后面讲到了多播放器实现翻页秒播能力，在体验上有了十分大的改善，但因为预创立的播放器在加载时，同时须要下载视频文件，导致这里的下一个播放器筹备好视频的工夫会减少到 1s 左右。如果用户在播放器加载解码实现前滑至该视频，则会呈现显著的黑屏，带来十分差的体验。
因为预加载的 工夫过长 ，且无奈预知用户 是否会疾速滑动。这里须要提前进行下载和疾速滑动检测。
对于预下载，咱们首先要晓得播放器外部播放过程。这里的 本地代理 是视频缓存机制实现的，具体参照下一章节。
播放器外部流程
◆ 预下载策略
这里，咱们为了节约 申请网络数据 的过程，在播放之前提前下载视频的首帧片段，采纳如下策略：
- 文件大小：下载 1MB 视频文件的形式进行提前首帧下载。（ps：经测试 1MB 已蕴含了首帧，且文件绝对较小）。
- 提前量：提前 5 个下载量（pageSize 为 10 的状况）。
- 并发状况：下载采纳同步队列下载（防止异步下载导致带宽占用，失常播放的视频卡顿）。
- 快滑优化：快滑革除下载队列，防止快滑过程中频繁触发下载。
- 下载机会：loadMore 时将前 5 个推入队列；onPageSelected 时，跳过下一个开始起算 5 个视频推入队列（下一个视频由预加载的播放器主动下载，这里反复下载会导致视频花屏）。
◆ 快滑定义
当用户疾速翻页时（onPageSelected 调用之前又滑了一下），onPageSelected 不会触发，onPageRelease 会触发屡次。在 onPageRelease 中判断 release position 与 current postion 的差值如果 > 1 则示意用户至多疾速翻页 1 次，此时定义为快滑状态，该当进行预下载和播放器预加载。
当 onPageSelected 回调时，阐明用户没有持续翻页，此时勾销快滑状态。开始执行预下载和复原播放器预加载。
预下载流程图
缓存优化
目前盒马应用的播放器为淘宝外部播放器。播放器自身不存在文件缓存和预下载性能。在播放器从新创立后，即使是同一个视频也不会有文件缓存，须要从新下载。这里引入一个开源缓存框架“com.danikula:videocache”。
◆ 计划原理
播放器播放的地址代理给本地的缓存服务，缓存服务负责转发数据流的同时进行文件保留如：
视频地址为：https://****.mp4。
本地代理地址为：http://127.0.0.1:8888 (假如端口号调配为 8888)。
代理后的地址为：本地代理地址 + 视频地址（URL 编码）。
即：http://127.0.0.1:8888/https%3A%2F%2F****.mp4
后续优化瞻望
对于多媒体的优化工作还有很多能够做。除了沉迷式秒播的场景外，咱们还能够：
1. 对播放器的一般性场景进行秒播优化，如首页列表的卡片视频。目前首页均匀首帧画面须要 550ms，较长的有 1000s 以上，有显著的顿挫感。在沉迷式的计划根底上，咱们能够提供一般性的预下载能力，从而缩小播放器的下载渲染时长。
2. 续播和内存优化。续播是另一个晋升体验的方面，用户可能十分直观的感触连贯与否。
3. 页面单播放器托管。大多场景下，一个页面只有一个播放器在播放，这就能够通过治理惟一的播放器实现页面播放器复用，从而优化内存和体验。
下一期咱们将持续分享盒马 iOS / Android 端短视频续播的体验优化实际。
欢送关注「视频云技术」公众号。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
