浅浅地优化下视频流播放体验(下)

简介: 浅浅地优化下视频流播放体验

有限的解码资源


用上面的代码实现视频流,当不停地往下翻看视频时,视频会加载不出来,ExoPlayer会抛如下异常:


com.google.android.exoplayer2.ExoPlaybackException: MediaCodecAudioRenderer error, index=1, format=Format(null, null, null, audio/raw, null, -1, null, [-1, -1, -1.0], [2, 48000]), format_supported=YES
com.google.android.exoplayer2.audio.AudioSink$InitializationException: AudioTrack init failed 0 Config(48000, 12, 65600) ... 13 more Caused by: java.lang.UnsupportedOperationException: Cannot create AudioTrack


音频解码错误,源于无法创建音轨。


手机的音轨资源是有限的,如果每个视频都占用一个音轨并且不释放的话,就会导致上述问题。


可以使用下面这个命令查看当前手机音轨占用情况:


adb shell dumpsys media.audio_flinger


打印出来的日志长这个样子:


3 Tracks of which 1 are active
    Type     Id Active Client Session Port Id S  Flags   Format Chn mask  SRate ST Usg CT  G db  L dB  R dB  VS dB   Server FrmCnt  FrmRdy F Underruns  Flushed   Latency
          25136     no  15781   82753   25105 P  0x400 00000001 00000003  44100  3   1  0  -inf     0     0     0  0000485A  11025   11025 A         0        0  293.91 k
          25137    yes  15781   82761   25106 A  0x000 00000001 00000003  44100  3   1  0   -26     0     0     0  0001102E  11025   11025 A         0        0  307.29 t
          25138     no  15781   82737   25107 I  0x000 00000001 00000003  44100  3   1  0  -inf     0     0     0  00000000  11025    6144 I         0        0       new


该日志表示已经创建3个音轨,其中一个是活跃的。


每一个新的 ExopPlayer 实例就会重新申请解码资源,而不是复用已有资源。


上述代码中,每次构建新的VideoFragment,都会新建ExoVideoPlayer实例,而其内部对应一个ExoPlayer实例。气人的是 ViewPager2 中 Fragment 的实例并不会被复用,而是每次新建,这就导致滑动过程中,ExoPlayer 实例被不断地新建,最终导致音轨资源被耗尽。


那就得及时释放播放器持有的资源:


class VideoFragment(private val url: String) : Fragment() {
    private val player by lazy { PlayerManager.getVideoPlayer() }
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
        val itemView = inflater.inflate(R.layout.playerview, container, false) as StyledPlayerView
        return itemView.also { it.player = player }
    }
    override fun onResume() {
        super.onResume()
        player.url = url
        player.load()
        player.play()
    }
    override fun onDestroy() {
        super.onDestroy()
        player.release()
    }
}


在 Fragment 生命周期方法 onDestroy() 中调用 release() 释放播放器资源。


这样不管往下翻多少视频,都不会报异常了。


播放器生命周期控制


我本以为当视频流向下滑动时,播放器的构建及回收时机如下图所示:


image.png


即当表项移入视窗时对应的 Fragment 被构建(播放器实例也被构建),当表项移出视窗时对应的 Fragment 被销毁(播放器资源被释放)。


但 ViewPager2 内部机制不是这样的,它会缓存比预想更多的 Fragment:


image.png


上图中索引为4的红色表示当前正在播放的视频,两块蓝色的表示因预加载而保留在内存中的视图(预加载数=1)。


虽然视频1和2也移出了屏幕,但它们依然存在于内存中(不会回调onDestroy()),这是 RecyclerView 的 cached View 缓存机制,本意是缓存移出屏幕的视图以便回滚时快速展示。ViewPager 的实现基于 RecyclerView,复用了这套机制。


当手向上滑动,视频6进入视窗开始预加载(onResume()),视频1被回收(onDestroy())。


ViewPager2 持有比预期更多的 Fragment 除了对内存造成压力之外,还会占用更多解码资源,当有多个视频流叠加时依然会耗尽解码资源(比如从推荐流点击作者头像进入作者视频流)。


ViewPager2 是有预加载(offscreenPageLimit),RecyclerView 中 cached View 机制意义已经不大了。但 ViewPager2 是 final 类型了,而且也并未公开其内部的 RecyclerView 实例。


所以只能将 ViewPager2 的源码都原样拷贝出来:


image.png


把源码中的这些类拷贝出来后,所有源码中的报错都可以消除。


修改其中的 FragmentStateAdapter:


public abstract class FragmentStateAdapter extends RecyclerView.Adapter<FragmentViewHolder> implements StatefulAdapter {
    // 持有所有活跃的 Fragment 实例
    public final LongSparseArray<Fragment> mFragments = new LongSparseArray<>();
    // 将下面的方法改为 public
    @Override
    public void onAttachedToRecyclerView(@NonNull RecyclerView recyclerView) {
        if (mFragmentMaxLifecycleEnforcer != null) throw new IllegalArgumentException();
        mFragmentMaxLifecycleEnforcer = new FragmentMaxLifecycleEnforcer();
        mFragmentMaxLifecycleEnforcer.register(recyclerView);
    }
    // 将下面的方法改为 public
    @Override
    public void onDetachedFromRecyclerView(@NonNull RecyclerView recyclerView) {
        mFragmentMaxLifecycleEnforcer.unregister(recyclerView);
        mFragmentMaxLifecycleEnforcer = null;
    }
    // 新增方法:获取指定 Fragment
    public Fragment getFragment(long key) {
        return mFragments.get(key);
    }
    ...
}


修改onAttachedToRecyclerView()onDetachedFromRecyclerView()为 public,让子类可以重写该方法。并且新增方法,使得子类中可以方便地获取到指定的 Fragment 实例。


然后改写视频流适配器:


class VideoPageAdapter(
    private val fragmentManager: FragmentManager,
    lifecycle: Lifecycle,
    private val urls: List<String>
) : FragmentStateAdapter(fragmentManager, lifecycle) {
    override fun onViewAttachedToWindow(holder: FragmentViewHolder) {
        super.onViewAttachedToWindow(holder)
        // 获取刚进入视窗的 Fragment 实例
        val attachFragment = getFragment(getItemId(holder.absoluteAdapterPosition))
        (attachFragment as? VideoFragment)?.load()
    }
    override fun onViewDetachedFromWindow(holder: FragmentViewHolder) {
        // 获取刚移出视窗的 Fragment 实例
        val detachFragment = getFragment(getItemId(holder.absoluteAdapterPosition))
        (detachFragment as? VideoFragment)?.release()
    }
}


重写列表中视图依附窗口/脱离窗口的回调,在其中获取对应的 Fragment 实例,并触发播放/回收资源。


现在播放器的生命周期不再基于 Fragment 的生命周期,改为基于列表滚动时视图的生命周期,而视图生命周期是相对于当前屏幕对称的。(就像本小节的第一张图所示)


这样一来,内存中播放器的数量就可以进一步减少,并且可以更精准地控制预加载/释放视频资源。


播放器数量控制


上述代码虽然可以精准控制播放器的生命周期,但依然无法避免不停地销毁/重建播放器造成的内存抖动。


有没有什么办法将整个App中播放器的实例控制在一个固定的数值之下?


有!播放器池!


在使用播放器池之前,还有一个障碍,回看一下之前对播放器接口的抽象:


interface VideoPlayer : View {
    // 视频url
    var url: URL? 
    // 视频控制器,用于上层绘制进度条
    var playControl: MediaPlayerControl 
    // 视频状态回调
    var listener: IVideoStateListener? 
    // 播放视频
    fun play()
    // 加载视频
    fun load()
    // 停止视频
    fun stop()
    // 释放资源
    fun relese()
}


这个接口设计将播放器和视图混为一体,即从接口层面规定一个播放器实例对应一个视图,且生命周期同步。当视频流滚动时,播放器会随着视图被不断地新建。


如果在这个接口基础上使用播放器池,则会造成内存泄漏。因为播放器池是一个单例,它的生命周期要长于视图,但由于接口设计的不合理,播放器就是视图,视图就是播放器,存在着交叉持有关系,导致内存泄漏(最终导致解码资源耗尽)。


播放器和视图分离


从播放流畅度、内存占用、CPU 使用率方面考虑,ExoPlayer 官方建议将单个播放器实例复用于多个播放视图。因为每新建一个播放器实例,就会重新申请解码资源,这是一个耗时/耗资源的过程。


为了实现播放器实例的复用,不得不重构上层接口,将原先的接口拆分成职责更单一的多个接口:


  1. 播放器视图接口


// 播放器视图接口(向上层屏蔽不同播放器视图实现的细节)
interface VideoPlayerView : View {
    // 视频重力方位,用于指定从哪个方位裁剪视频
    var gravity: Int
    // 将播放视图和播放器解绑
    fun clearPlayer()
    // 将视频宽高传递给视图
    fun setResizeMode(width: Int, height: Int)
}


  1. 播放器接口


// 播放器接口(向上层屏蔽不同播放器实现的细节)
interface VideoPlayer {
    // 资源地址
    var url: URL?
    // 视频控制器,用于上层绘制进度条
    var playControl: MediaPlayerControl
    // 状态监听器
    var listener: IVideoStateListener?
    // 开始播放
    fun play()
    // 加载视频
    fun load()
    // 停止播放
    fun stop()
    // 销毁资源 
    fun release()
    // 将播放器和视图绑定
    fun attachPlayerView(view: VideoPlayerView)
}


视图归视图,播放器归播放器。前者的生命周期由 ViewPager 控制,后者的生命周期通过一个播放器池来管理:


  1. 播放器池接口


// 播放器池
interface VideoPlayerPool {
    // 获取播放器实例
    fun getVideoPlayer(index: Int): VideoPlayer
    // 清空池
    fun clear()
}


上层通过VideoPlayerPool接口获取播放器实例。


播放器池接口实现如下:


class VideoPlayerPool : VideoPlayerPool {
    // 池大小
    val POOL_SIZE = 2 * manager.config.movie.prefetchCount + 1 + 1
    // 池设计为循环数组
    private val pool: Array<VideoPlayer?> = arrayOfNulls(POOL_SIZE)
    // 构建新的播放器实例
    private fun createVideoPlayer(context: Context): VideoPlayer {
        return ExoVideoPlayer(context)
    }
    // 从池中获取播放器实例
    override fun getVideoPlayer(index: Int): VideoPlayer {
        val realIndex = index.mod(POOL_SIZE)
        return pool[realIndex] ?: createVideoPlayer(ContextUtil.applicationContext).also {
            pool[realIndex] = it
        }
    }
    // 释放池中所有播放器资源
    override fun clear() {
        (pool.indices).forEach { index ->
            pool[index]?.release()
            pool[index] = null
        }
    }
}


播放器池长度


播放器池通过一个固定长度的循环数组实现播放器复用:


image.png


上图表示当前正在播放视频流中索引为2的视频。此时播放器池中有四个播放器实例正好用于视频流中的前四个视图。


视频流索引和播放器池索引的对应关系通过取余实现,即播放器池索引 = 视频流索引对池长度取余。当列表向上滚动,即索引为4的视图进入视窗,它加载视频会复用到池中索引为0的播放器实例。通过取余运算实现循环数组复用机制。


理论上池大小应该等于视窗大小,但使用 ViewPager2 实现视频流有一个特殊情况会导致播放器实例复用失败。还是以上图的场景举例:


image.png


此图表示播放器池大小为3,所以视频3会复用索引为0的播放器实例。


当用手拖住视频2向上滚动一点点(即视频3从屏幕底部露出一点点)后松手,此时不会产生翻页而是停留在视频2,但滚动使得视频4进入了视窗触发了加载,它会复用到索引为1的播放器实例,导致视频1的内容被抹去,但视频1又在视窗内,所以回滚到视频1时并不会触发它再次加载,最终导致黑屏。


为了避免这种情况,播放器池大小要大于视窗大小。


播放器池数量


多个视频流共存的场景也很常见,比如从推荐流跳转到剧集流。随着业务的迭代,共存的视频流可以无限叠加。


让共存的视频流共享同一个播放器池应该怎么实现?


“在发生视频流跳转时,释放当前池中所有播放器资源以便在新流中复用。”


这个方案有一个缺点,当返回旧视频流时,当前视频需重新加载,即会先黑屏一下再开始播放。


可不可以保留当前正播放的实例,释放其余播放器资源?


可是可以,但增加了播放器和视图映射关系的复杂度,即新视频流中不能简单地按索引值取余的方式拿到复用的播放器实例,得跳过保留的播放器。或者将保留播放器挪到池尾,并将池长度-1。这样的话,每有一个新的视频流,播放器池长度就减少1,这限制了共存视频流的数量。


最终采用的方案是:


每个视频流分配一个播放器池。在跳转到新视频流时,释放旧池中播放器资源(除了当前视频和下一个视频,因为大概率返回时会往下滑)。在返回时,清空新建的播放器池。


滑动体验


视频流滑动过程中,通过复用播放器实例避免了内存抖动、减少了 GC 次数、加速了视频解码速度(解码资源复用),一定程度上提升了滑动的流畅度。除此之外,松手之后的动画也会影响滑动的手感。


若使用 ViewPager2 默认的滑动实现,在松手后,视频也会匀速地滚动到下一页。在参考了各大视频平台App之后,发现在松手之后,会有一个加速滑动,到终点之前又逐渐减速的过程。


ViewPager2 松手后自动滑至下一页是通过自定义的 SnapHelper 实现的:


class PagerSnapHelperImpl extends PagerSnapHelper {
    PagerSnapHelperImpl() {
    }
    private float MILLISECONDS_PER_INCH = 100f;
    private int MAX_SCROLL_ON_FLING_DURATION = 120;
    // 新增减速插值器
    private Interpolator interpolator =new DecelerateInterpolator(2.1f);
    // 重写 createScroller 以使用自定义的插值器
    @Nullable
    @Override
    protected RecyclerView.SmoothScroller createScroller( RecyclerView.LayoutManager layoutManager) {
        if (!(layoutManager instanceof RecyclerView.SmoothScroller.ScrollVectorProvider)) {
            return null;
        }
        return new LinearSmoothScroller(mRecyclerView.getContext()) {
            @Override
            protected void onTargetFound(View targetView, RecyclerView.State state, Action action) {
                int[] snapDistances = calculateDistanceToFinalSnap(mRecyclerView.getLayoutManager(),
                        targetView);
                final int dx = snapDistances[0];
                final int dy = snapDistances[1];
                final int time = calculateTimeForDeceleration(Math.max(Math.abs(dx), Math.abs(dy)));
                if (time > 0) {
                    // 使用自定义插值器
                    action.update(dx, dy, time, interpolator);
                }
            }
            @Override
            protected float calculateSpeedPerPixel(DisplayMetrics displayMetrics) {
                return MILLISECONDS_PER_INCH / displayMetrics.densityDpi;
            }
            @Override
            protected int calculateTimeForScrolling(int dx) {
                return Math.min(MAX_SCROLL_ON_FLING_DURATION, super.calculateTimeForScrolling(dx));
            }
        };
    }
}


将 ViewPager2 源码拷贝出来,修改其中的PagerSnapHelperImpl的实现,重写createScroller()方法,并将插值器替换为DecelerateInterpolator。该插值器的参数越大,松手后的滑动速度就越快,而到达终点的速度就会越慢。还可以通过调整MAX_SCROLL_ON_FLING_DURATION来改变整个动画的持续时间。


无缝播放体验


除了预加载、复用播放器实例、滑动动画插值器之外,播放视频的时机也是影响视频流体验的因素之一。


如果在 Fragment.onResume() 中才开始播放视频,就意味着下一个视频要等到滚动动画完成后才开始播放视频,视觉上的体验就是下一个视频的第一帧会卡一下再播。


更好的方案是在松手时就暂停上一个视频并播放下一个视频:


viewPager2.registerOnPageChangeCallback(object :OnPageChangeCallback(){
    // 上一次滚动偏移量
    private var lastOffset = 0f
    // 是否向下滚动
    private var isScrollDown = false
    override fun onPageScrollStateChanged(state: Int) {
        super.onPageScrollStateChanged(state)
        // 当松手后
        if(state == SCROLL_STATE_SETTLING){
            // 获取下一个播放视频的索引
            val playIndex = if(isScrollDown) viewPager.currentItem  +1 else viewPager.currentItem - 1;
            // 播放下一个视频
            videoPageAdapter?.getFragment(playIndex)?.play()
            // 暂停当前视频
            videoPageAdapter?.getFragment(viewPager.currentItem)?.pause()
        }
    }
    override fun onPageScrolled(position: Int, positionOffset: Float, positionOffsetPixels: Int) {
        super.onPageScrolled(position, positionOffset, positionOffsetPixels)
        // 如果偏移量在变大意味着向下滚动
        isScrollDown = positionOffset > lastOffset
        lastOffset = positionOffset
    }
})


通过onPageScrollStateChanged()中的SCROLL_STATE_SETTLING状态捕捉松手时机,通过onPageScrolled()中的偏移量判定滚动方向,以此确定该暂停哪个视频,该播放哪个视频。

目录
相关文章
|
5月前
|
Web App开发 编解码 资源调度
在阿里云直播解决方案中,当使用ARTC协议观看直播并进行清晰度切换时出现画面卡顿或马赛克现象,可能存在以下几种原因
【6月更文挑战第30天】阿里云直播中,ARTC协议下清晰度切换出现卡顿或马赛克可能由网络带宽、缓冲策略、转码效率、播放器解码、协议特点及服务器资源调度引起。解决措施包括优化网络、智能切换算法、播放器与服务器优化。通过监控和日志分析定位问题,参照官方最佳实践进行优化。
219 1
|
3月前
|
编解码 vr&ar 图形学
惊世骇俗!Unity下如何实现低至毫秒级的全景RTMP|RTSP流渲染,颠覆你的视觉体验!
【8月更文挑战第14天】随着虚拟现实技术的进步,全景视频作为一种新兴媒体形式,在Unity中实现低延迟的RTMP/RTSP流渲染变得至关重要。这不仅能够改善用户体验,还能广泛应用于远程教育、虚拟旅游等实时交互场景。本文介绍如何在Unity中实现全景视频流的低延迟渲染,并提供代码示例。首先确保Unity开发环境及所需插件已就绪,然后利用`unity-rtsp-rtmp-client`插件初始化客户端并设置回调。通过FFmpeg等工具解码视频数据并更新至全景纹理,同时采用硬件加速、调整缓冲区大小等策略进一步降低延迟。此方案需考虑网络状况与异常处理,确保应用程序的稳定性和可靠性。
64 1
|
6月前
文字转语音后的音频结束以后,再播放一段时间的背景音乐。什么方案能实现
【2月更文挑战第13天】文字转语音后的音频结束以后,再播放一段时间的背景音乐。什么方案能实现
64 2
|
6月前
|
Linux C++ iOS开发
VLC源码解析:视频播放速度控制背后的技术
VLC源码解析:视频播放速度控制背后的技术
558 0
|
6月前
|
编解码
音视频录制播放原理
音视频录制播放原理
112 1
|
XML 存储 编解码
浅浅地优化下视频流播放体验
浅浅地优化下视频流播放体验
594 0
|
6月前
|
XML Java 调度
Android开发音效增强中铃声播放Ringtone及声音池调度SoundPool的讲解及实战(超详细 附源码)
Android开发音效增强中铃声播放Ringtone及声音池调度SoundPool的讲解及实战(超详细 附源码)
298 0
|
编解码 人工智能 前端开发
如何实现丝滑转码?
如何实现丝滑转码?
62 0
|
编解码 开发工具 C#
RTSP/RTMP播放端录像不可忽视的几个设计要点
很多开发者提到,拉取的摄像机(一般RTSP流)或RTMP流,如果需要录制,需要考虑哪些因素,本文以大牛直播SDK的Windows平台拉流端录像为例(github),做个简单的介绍:
168 0