（这个问题部分与为什么Android的MediaPlayer准备一些直播流播放需要这么长时间有关？）
我尝试使用 android MediaPlayer 在不同设备上播放以下音频流：http: //newsstream1.publicradio.org。
我终于注意到设备 <= 2.2（不到 1 秒）和设备 > 2.2（最多可能需要 30 秒...）之间的 prepare() 方法的持续时间存在巨大差异
它与底层音频框架有关吗？（OpenCore VS StageFright）
有人已经经历过吗？您知道使用 StageFright 媒体播放器读取 mp3 流的更好解决方案吗？
好吧，在四处挖掘之后，我得出结论，加载时间取决于 MediaPlayer 的缓冲区大小（在固件中以某种方式硬编码）并且没有什么可以改变它的。
看起来它正在缓冲固定数量的数据，而不是固定的时间。对于任何不知道各种类型 NPR 流的比特率的人来说，数据如下所示：
MPR 新闻流：27 秒（http://newsstream1.publicradio.org:80/），64 kbps MPR 古典音乐流：15 秒（http://classicalstream1.publicradio.org:80/），128 kbps MPR The Current流：7 秒（http://currentstream1.publicradio.org:80/），128 kbps PRI 流：52 秒（http://pri-ice.streamguys.biz/pri1），32 kbps两个 128 kbps 流，比特率和缓冲持续时间之间有很好的相关性。
无论如何，Android 是开源的，所以你可以随时查看它在做什么。不幸的是，prepareAsync()andprepare()是本机方法，并且似乎与缓冲区相关的事件也是从本机进程分派的。
您是否尝试将 an 附加OnBufferingUpdateListener到MediaPlayer以获取有关缓冲区状态的更细粒度的更新？比较事件传递的速率以及缓冲区在不同流中每个事件的填充百分比可能会很有趣。您可以将其与流比特率交叉引用，如果 4 秒的 32 kbps 缓冲填充缓冲区的百分比与 1 秒 128 kbps 的缓冲相同，那么我认为您会找到答案。
源自这里。
应该不会花那么长时间，但 MediaPlayer API 有一种asyncPrepare()方法，他们建议您使用该方法来保持应用程序平稳运行。