共计 3725 个字符，预计需要花费 10 分钟才能阅读完成。
简介：在所有皆可视频化的明天，短视频内容作为挪动端产品新的促活点，受到了越来越多的器重与投入，同时短视频也是减少用户粘性、减少用户停留时长的一把利器。那么如何疾速实现挪动端短视频性能呢？前两篇咱们介绍了盒马短视频秒播优化（iOS 篇 / Android 篇），本篇咱们聊聊秒播之外，另一个从体感上减少短视频用户体验的能力 – 续播。
作者|少阳
审校|泰一
短视频作为内容重要的承载形式，是吸引用户的重点，短视频的内容与体验间接关系到用户是否违心长时停留。因而，体验的优化就显得尤为重要。
跨页面续播
跨页面续播是除秒播外另一个能够从体感上减少用户体验的能力。因为一些业务场景须要在不同页面上播放同一个视频内容的场景，而这些场景页面切换往往是间断的，这就要求短视频的播放也是间断。这样能力使得体验上会有连贯性，让用户在进入沉迷式页面时，能流畅的适度，并无感知的持续播放，从而产生间断不间断的感触。
在优化前，盒马沉迷式短视频播放页面的体验与支流短视频 App 有显著差距。从卡片列表页面跳转视频沉迷式页面时，雷同视频无奈续播，影响用户参观和体验。上面次要介绍盒马短视频从一般展现页进入沉迷式页面时跨页面续播能力和晦涩的动画切换成果的实现过程。
环境
- 手机：Pixel 4
- os：Android 10
- 播放器：淘宝播放器
成果比照
首先咱们来看一下盒马优化前后与支流短视频 App 的成果比照
** 问题剖析
**
从比照能够看出，续播的关键在于视频流的复用以及页面转场动画。
◆ 视频流的复用
要解决流的复用，同时又要保障进入新的页面时能够立刻播放，不产生声音和画面的顿挫，这里依据上一篇《揭秘盒马鲜生 APP Android 短视频秒播优化计划》的剖析，必须要解决视频下载，加载解码的耗时。
- 依据《揭秘盒马鲜生 APP Android 短视频秒播优化计划》里讲到缓存原理，这里能够利用播放器播放同一个视频（留神对立 URL，盒马全副转为 H.265）来防止屡次下载。
- 加载解码的耗时则须要播放器复用来解决。这里波及到实现计划，可参照下一章的续播计划选型。
◆ 转场动画
转场动画能显著进步体感晦涩度，但实现过程中须要思考各种兼容问题。
续播计划选型
在优化后期，咱们思考了三种续播计划。
1. 播放器 View 跨页面传递长处：思路简略，体验成果好。毛病：业务侵入重大，不具通用性，播放器业务回调无奈隔离，不利于续播放器管控。
2. 基于 Surface (View) 级别的全局播放器治理长处：体验成果好，能扩大内存管控，侵入性低。毛病：实现简单，须要改写底层 HMVideoView 的封装逻辑；革新中易呈现内存透露，较难排查。
3. 基于 MediaPlayer 级别的全局播放器治理 长处：无侵入，能扩大内存管控，实现快（可复用和扩大淘宝播放器底层 token 机制）毛病：须要肯定的革新，体验比计划 1、2 略差（声音有一瞬间的顿挫，不显著）
盒马最终抉择计划 3，这里计划 2 和 3 原理是雷同的，没有显著的优劣之分，最终抉择计划 3 是因为这是目前稳定性最高，老本最低的办法。后续的播放器续播、复用、治理的剖析 同样实用于计划 2。
播放器续播、复用和治理
业务上，咱们须要实现续播，通过问题剖析，咱们曾经晓得，通过视频流的复用即可实现，而视频流的复用这里抉择通过复用 MediaPlayer 实现（也能够复用 Surface+MediaPlayer）。
◆解耦播放器 View 与 MediaPlayer 层
将 MediaPlayer 从 TaobaoPlayerView 中拆解进去，通过 MediaPlayerManager 进行全局治理。全局治理后，所有的播放器的 MediaPlayer 都由 MediaPlayerManager 调配和管制。
各组建间关系
◆业务流程
确保业务流程中，只须要关怀业务与 VideoView 之间的交互，底层播放器复用由 MediaPlayerManager 实现。
◆播放器复用（治理）原理
播放器复用是治理的一个子集，所以这里一起介绍。次要原来有以下几个准则：
1. 全局播放器（MediaPlayer）管制最多创立 4 个。
2. 超过 4 个播放器，创立第 5 个时，先销毁起码应用的播放器的 MediaPlayer。
3. 每个播放器随机调配一个 token（工夫戳 + 随机数），也能够开发者指定。
4. 雷同 token 的播放器，共享 MediaPlayer。
5. 一个 MediaPlayer 同时只能被 1 个播放器 Surface 所绑定和持有。
6. 存在雷同 token 的播放器，以后播放器在销毁时，保留 MediaPlayer 实例。
7. 已创立的播放器复原播放，但 MediaPlayer 被其余后创立的播放器占用时，解绑 MediaPlayer 并从新绑定以后播放器。
◆场景模仿
场景一：APP 共创立 4 个及以内播放器。
场景二：创立超过 4 个播放器时。
场景三：新创建的播放器 token 已存在时，复用 MediaPlayer。
场景四：存在 token 与以后行将被销毁的播放器 token 统一时（或已被解除 MediaPlayer 的播放器播放时）。
逻辑流程图
从场景总结，MediaPlayer 次要提供 复用、复原、销毁、驱赶（创立）四个能力。
转场动画
目前转场动画有两个计划可选：
1. Android 自带的元素动画
长处：动画晦涩顺滑，无需实现动画逻辑，由零碎本人实现。
毛病：侵入重大，须要改写 Nav 层，在 View 复用的计划下有白屏和黑屏。
2. 自定义实现属性动画
长处：侵入小，只须要前置页极少的坐标信息，如果是 View 复用计划，甚至不须要前置页提供坐标信息；兼容性好，实用于各种播放器复用场景。
毛病：须要本人实现动画，有肯定的闪动感。
◆动画原理
1. 前置页跳转到沉迷式，传递播放器坐标 Rect 信息。
2. 沉迷式默认通明，并依据 Rect 坐标信息创立播放器（复用）。
3. 开始动画，将播放器 View 放大至正确地位，同时背景不透明度减少。
（留神：这里最初要将沉迷式页的主题设为不通明，否则前置页不会执行 onStop () 具体参考下一节，生命周期填坑。）
ps：返回动画同理，过程相同即可。
◆生命周期填坑
属性动画原理存在一个坑。
问题形容：
假如页面为 A->B，计划 3 要求 B 页面在动画过程中是全透明的。当 B 的 theme 中 windowIsTranslucent 为 true 时，A->B 过程 A 的生命周期无奈走向 stop（即使 B 页面动画完结，齐全遮蔽 A 页面）。因而，A 的生命周期没有依照预期执行，一些须要 onStop 执行的场景下，业务就无奈失常执行
B Ativity 的款式（注：示例代码）：
<style name="MyTransparent" parent="xxxx">
<item name="android:windowFullscreen">false</item>
<item name="android:windowNoTitle">true</item>
<item name="android:windowBackground">@android:color/transparent</item>
<item name="android:colorBackgroundCacheHint">@null</item>
<item name="android:windowIsTranslucent">true</item>
<item name="android:background">@android:color/transparent</item>
<item name="android:windowAnimationStyle">@style/noAnimation</item>
</style>解决方案：
1. 进入动画完结时，通过反射调用 Activity 的 convertFromTranslucent 办法，使 activity 不通明。
2. 返回动画开始时，通过反射调用 Activity 的 convertToTranslucent 办法，使 activity 通明。
后续优化瞻望
对于多媒体的优化工作还有很多能够做。除了续播和沉迷式秒播等场景外，咱们还能够：
1. 对播放器的一般性场景进行秒播优化，如首页列表的卡片视频。2. 对播放器的全局实例管控，管制播放器创立数量，从而优化内存。
未优化：
操作：间断开启 30～50 个页面及播放器。
景象：内存飙升，手机发烫，影响手机失常应用。
优化后：
操作：每秒开启 1 个页面和播放器，间断开启 100 个。
景象：内存呈锯齿状失常回升，无显著飙升景象，软件运行失常。
下一期咱们将持续分享盒马 iOS 端短视频续播的体验优化实际。欢送关注「视频云技术」公众号。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
