// 停止视频
fun stop()
// 释放资源
fun relese()
}

该接口为上层提供了操纵播放器的统一接口，这样做的好处是向上层屏蔽了播放器实现的细节，为以后更换播放器提供了便利。

其中IVideoStateListener是播放状态的抽象：

interface IVideoStateListener {
fun onStateChange(state: State)
}

//视频状态
sealed interface State {
//第一帧被渲染
object FirstFrameRendered : State
//缓冲结束，随时可播放。
object Ready : State
//播放出错
class Error(val exception: Exception) : State
//播放中
object Playing : State
//播放手动停止
object Stop : State
//播放结束
object End : State
//缓冲中
object Buffering : State
}

ExoPlayer 对于上述接口的实现如下，它作为一个单独的库 player-exo 存在：

class ExoVideoPlayer(context: Context) : FrameLayout(context), VideoPlayer {
private var playerView: StyledPlayerView? = null
private val skipStates = listOf(Player.STATE_BUFFERING, Player.STATE_ENDED)
private val exoListener: Listener by lazy {
object : Listener {
override fun onPlaybackStateChanged(playbackState: Int) {
when (playbackState) {
Player.STATE_ENDED -> listener?.onStateChange(State.End)
Player.STATE_BUFFERING -> listener?.onStateChange(State.Buffering)
Player.STATE_IDLE -> resumePosition = _player.currentPosition
Player.STATE_READY -> listener?.onStateChange(State.Ready)
}
}

override fun onRenderedFirstFrame() {
listener?.onStateChange(State.FirstFrameRendered)
}

override fun onIsPlayingChanged(isPlaying: Boolean) {
if (isPlaying) {
listener?.onStateChange(State.Playing)
} else {
if (_player.playbackState !in skipStates && _player.playerError != null) {
listener?.onStateChange(State.Stop)
}
}
}

override fun onPlayerError(error: PlaybackException) {
listener?.onStateChange(State.Error(error))
}
}
}

private var _player = ExoPlayer.Builder( context, DefaultRenderersFactory(context).apply { setEnableDecoderFallback(true) })
.build().also { player ->player.addListener(listener}
override var listener: IVideoStateListener? = null
private var cache: Cache? = null
private var mediaItem: MediaItem? = null

private fun buildMediaSource(context: Context): MediaSource {
if (mediaItem == null) mediaItem = MediaItem.fromUri(url.toString())
val cacheFile = context.cacheDir.resolve(CACHE_FOLDER_NAME + File.separator + abs(mediaItem.hashCode()))
cache = SimpleCache(
cacheFile,
LeastRecentlyUsedCacheEvictor(MAX_CACHE_BYTE),
StandaloneDatabaseProvider(context)
)
return run {
val cacheDataSourceFactory = CacheDataSource.Factory().setCache(cache)
.setUpstreamDataSourceFactory(DefaultDataSource.Factory(context))
.setFlags(CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR)
if (url.toString().endsWith(“m3u8”)) {
HlsMediaSource.Factory(cacheDataSourceFactory).createMediaSource(mediaItem!!) //m3u8
} else {
ProgressiveMediaSource.Factory(cacheDataSourceFactory).createMediaSource(mediaItem!!)
}
}
}

init {
playerView = LayoutInflater.from(context).inflate(R.layout.playerview, null) as StyledPlayerView
this.addView(playerView)
playerView?.player = _player
}

override var url: URL? = null
get() = field
set(value) {
field = value
mediaItem = MediaItem.fromUri(value.toString())
}

override var playControl: MediaController.MediaPlayerControl = PlayerControl(_player)

override fun play() {
if (_player.isPlaying) return
if (_player.playbackState == Player.STATE_ENDED) {
_player.seekTo(0)
}
_player.playWhenReady = true
}

override fun load() {
_player.takeIf { !it.isLoading }?.apply {
setMediaSource(buildMediaSource(context))
prepare()
}
}

override fun stop() {
_player.stop()
}

override fun release() {
_player.release()
}
}

然后在一个单独库 player-pseudo 中定义一个构建VideoPlayer的抽象行为：

package com.demo.player

fun createVideoPlayer(context: Context): VideoPlayer = throw NotImplementedError()

在库 player-exo 中同样的包名下，定义一个同样的文件，并给出基于 ExoPlayer 的实现：

package com.demo.player

fun createVideoPlayer(context: Context): VideoPlayer = ExoVideoPlayer(context)

这些库的上层有一个管理器库 player-manager，它作为业务层使用播放器的入口：

package com.demo.player

fun createVideoPlayer(context: Context): VideoPlayer = ExoVideoPlayer(context)

player-manager 库需要依赖 player-pseudo：

object PlayerManager {
fun getVideoPlayer(context: Context) = createVideoPlayer(context)
}

使用 compileOnly 是为了在编译时不报错并且不将 player-pseudo 源码打入包。在打包时 player-manager 真正应该依赖的是 player-exo。所以最上层的 app 依赖关系应该如下：

implementation project(‘player-manager’)
implementation project(‘player-exo’)

这样就通过 gradle 实现了依赖倒置，即上层（player-manager）不依赖于下层（player-exo）具体的实现，上层和下层都依赖于中间的抽象层（player-pseudo）

视频流

上一小节解决了播放单个视频的问题，这一节介绍如何构建视频流。

视频流就是像抖音那样的纵向列表，每一个表项都是一个全屏视频。

我使用 ViewPager2 + Fragment 实现。

下面是 Fragment 的实现：

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()
}
}

然后在 FragmentStateAdapter 中构建 Frament 实例：

class VideoPageAdapter(
private val fragmentManager: FragmentManager,
lifecycle: Lifecycle,
private val urls: List
) : FragmentStateAdapter(fragmentManager, lifecycle) {

override fun getItemCount(): Int {
return urls.size
}

override fun createFragment(position: Int): Fragment {
return VideoFragment(urls[position])
}
}

最后为业务界面的 ViewPager2 设置适配器:

class VideoActivity : AppCompatActivity() {
private lateinit var viewPager: ViewPager2
private var videoPageAdapter: VideoPageAdapter? = null
private val urls = listOf {“xxx”,“xxx”}

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.video_player_activity)

videoPageAdapter = VideoPageAdapter(supportFragmentManager, lifecycle, urls)
viewPager = findViewById(R.id.vp)
viewPager.apply {
orientation = ViewPager2.ORIENTATION_VERTICAL
offscreenPageLimit = 1 // 预加载一个视频
adapter = videoPageAdapter
}
}
}

一个简单的视频流就完成了。

预加载及其原理

上述代码使用了ViewPager2.offscreenPageLimit = 1实现预加载一个视频。该参数的意思是 “将视窗上下都扩大1” 。默认的视窗大小是1，如下图所示：

上图表示 ViewPager2 正在展示索引为2的视频，其视窗大小为1（视窗占满屏幕），只有当手向上滑动视频3从视窗的底部出现时，才会触发视频3的加载。

若 offscreenPageLimit = 1，则表示视窗在当前屏幕的上下拓宽了一格：

图中的红色+蓝色区域就是视窗大小，只有当列表项进入视窗后才会发出其加载。当前屏幕停留在视频2，当手向上滑动视频4会进入视窗底部，所以当你滑动到视频3时，视频4已经被预加载了。

从源码上，ViewPager2 是基于 RecyclerView 实现的，在内部它自定义了一个 LinearLayoutManager：

// ViewPager2 内部自定义的 LayoutManager
private class LinearLayoutManagerImpl extends LinearLayoutManager {
// 在布局表项时，计算额外布局空间
@Override
protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state, NonNull int[] extraLayoutSpace) {
int pageLimit = getOffscreenPageLimit();
// 如果 OffscreenPageLimit 等于 OFFSCREEN_PAGE_LIMIT_DEFAULT，则不进行预加载
if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
super.calculateExtraLayoutSpace(state, extraLayoutSpace);
return;
}
// 进行预加载表现为“额外布局 OffscreenPageLimit 个 page“
final int offscreenSpace = getPageSize() * pageLimit;
extraLayoutSpace[0] = offscreenSpace;
extraLayoutSpace[1] = offscreenSpace;
}
}

ViewPager2 重写了calculateExtraLayoutSpace()方法，它用于计算在滚动时是否需要预留额外空间以布局更多表项，若需要则将额外空间赋值给extraLayoutSpace，它是一个数组，第一个元素表示额外的宽，第二元素表示额外的高。当设置了 offscreenPageLimit 后，ViewPager2 申请了额外的宽和高。

额外的宽高会被记录在LinearLayoutManager.mLayoutState.mLayoutState中：

// androidx.recyclerview.widget.LinearLayoutManager
private void updateLayoutState(int layoutDirection, int requiredSpace,boolean canUseExistingSpace, RecyclerView.State state) {
mReusableIntPair[0] = 0;
mReusableIntPair[1] = 0;
// 计算额外布局空间
calculateExtraLayoutSpace(state, mReusableIntPair);
int extraForStart = Math.max(0, mReusableIntPair[0]);
int extraForEnd = Math.max(0, mReusableIntPair[1]);
// 存储额外布局空间
mLayoutState.mExtraFillSpace = layoutToEnd ? extraForEnd : extraForStart;
…
}

额外布局空间最终会在填充表项时被使用：

public class LinearLayoutManager{
// 向列表中填充表项
int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) {
…
// 计算剩余空间=现有空间+额外空间
int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;
// 循环填充表项，直到没有剩余空间
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
layoutChunkResult.resetInternal();
// 填充单个表项
layoutChunk(recycler, state, layoutState, layoutChunkResult);
…
// 在列表剩余空间中扣除刚填充表项所消耗的空间
if (!layoutChunkResult.mIgnoreConsumed || layoutState.mScrapList != null || !state.isPreLayout()) {
layoutState.mAvailable -= layoutChunkResult.mConsumed;
remainingSpace -= layoutChunkResult.mConsumed;
}
…
}
…
}
}

有限的解码资源

用上面的代码实现视频流，当不停地往下翻看视频时，视频会加载不出来，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() 释放播放器资源。

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

播放器生命周期控制

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

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

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

上图中索引为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 的源码都原样拷贝出来：

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

修改其中的 FragmentStateAdapter：

public abstract class FragmentStateAdapter extends RecyclerView.Adapter implements StatefulAdapter {
// 持有所有活跃的 Fragment 实例
public final LongSparseArray 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
) : FragmentStateAdapter(fragmentManager, lifecycle) {
override fun onViewAttachedToWindow(holder: FragmentViewHolder) {
super.onViewAttachedToWindow(holder)

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

且极易碰到天花板技术停滞不前！**

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-QM3CN6Rj-1712780484926)]
[外链图片转存中…(img-6GlxMHWP-1712780484927)]
[外链图片转存中…(img-DMz1mcq7-1712780484927)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）
[外链图片转存中…(img-bPEIzThf-1712780484927)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！