gpt4 book ai didi

android - MediaPlayer setDataSource 需要最佳实践建议

转载 作者:塔克拉玛干 更新时间:2023-11-02 19:52:10 37 4
gpt4 key购买 nike

阅读“Media Playback”和“MediaPlayer”android 文档后,我仍然感到困惑,需要有关 setDataSource 的有经验的建议重载方法。

我在项目的 Service 组件中使用 MediaPlayer,它将成为 foregroundService在播放音乐时。我的音乐文件 (.mp3) 在我的 apk 的 res/raw 文件夹中。要开始播放,我知道我必须准备 MediaPlayer 对象。因为 android 应用程序中的服务默认使用单进程和主线程,我不希望我的用户得到 ANR当 MediaPlayer 准备好自己时(想想 raw 文件夹中的媒体文件是否有很大的尺寸)。然后我使用 prepareAsync 而不是 prepare(Sync)。所以我不能使用:

mp = MediaPlayer.create(context, R.raw.myfile);

因为这已经在内部调用了 prepare() 而不是 prepareAsync()。所以基本上我有两个选择(四个中的两个):

Uri myUri = Uri.parse("android.resource://" + context.getPackageName() + "/" + R.raw.myfile);
mp.setDataSource(context, myUri);

AssetFileDescriptor afd = context.getResources().openRawResourceFd(R.raw.myfile);
mp.setDataSource(fd.getFileDescriptor());
afd.close();

使用其中之一后我可以简单地使用:

mp.prepareAsync();

最后我的问题是“包括这些不同的方法,哪一个是最好的选择?是否有任何好处?我是否遗漏了什么?”

最佳答案

调用 createsetDataSource 的各种方式并没有任何真正的好处。静态create 方法只调用setDataSourceprepare。各种 setDataSource 方法在内部相互调用。最终它们归结为两种可能的 native 调用,一种使用描述远程 URI 的字符串,另一种使用本地文件描述符。自己创建文件描述符可能会有非常轻微的性能优势,但在上下文中不会很明显。

对于本地文件播放,正如您在代码中所演示的那样,简单地调用 prepare (或静态 create 方法)根本不是一个坏习惯。无论文件大小,底层播放器都应该能够确定相关元数据并快速返回。 prepareAsync 方法对网络流更有用,在这种情况下,任何数量的情况都可能导致一些意外延迟。如果您正在设计一个通用播放器,那么使用 prepareAsync 方法是可行的方法,但如果您只是在播放原始 Assets ,它应该没有任何区别。提供的各种方法只是为了方便(请注意 create 的 javadoc)。

关于android - MediaPlayer setDataSource 需要最佳实践建议,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18977809/

37 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com