我有一个在服务中运行的 MediaPlayer,它正在播放来自 URL(流)的音频。到目前为止,它似乎运行良好,甚至在我将手机置于待机状态时还能继续播放。
我目前没有获得唤醒锁。我的问题是:
- 在我的情况下真的有必要获得唤醒锁吗?
- 如果有必要,我应该获取什么类型的唤醒锁?
是的,这是唤醒锁的合法用例,因为我的用户明确希望音频继续播放。
我有一个在服务中运行的 MediaPlayer,它正在播放来自 URL(流)的音频。到目前为止,它似乎运行良好,甚至在我将手机置于待机状态时还能继续播放。
我目前没有获得唤醒锁。我的问题是:
是的,这是唤醒锁的合法用例,因为我的用户明确希望音频继续播放。
编辑:如果你想安全地玩,那么你想使用 WakeLock。这样,如果 MediaPlayer 发生变化并在手机挂起时允许进入睡眠状态,您的程序仍然可以正常工作。添加 WakeLock 确实没有什么可失去的,只要您在不再需要它时正确地释放它。如果你不这样做,你只会消耗比你想要的更多的电池,在最坏的情况下,你会立即看到一个错误,表明你在应用程序终止时没有释放锁。添加 WakeLock - 虽然可能是多余的 - 是一种很好的做法,因为它可以使您的应用程序更健壮地抵抗它所依赖的软件的更改。
默认情况下,MediaPlayer 不会自动为您执行此操作。
但是,您不必获取唤醒锁,它有一个方法,您可以调用它来告诉它在玩游戏时为您保留一个:
请注意,正如文档所述,它仍然是您的应用程序持有唤醒锁,因此要使用此功能,您需要请求唤醒锁权限。
您可能需要 WakeLock,因为您不能保证 PowerManager 在播放期间不会启动和休眠。PARTIAL_WAKE_LOCK 将确保使用最低级别的电池消耗(CPU 开启;屏幕/键盘关闭)。您总是可以测试电池消耗的影响,但我怀疑它会很大,因为无论如何都必须打开 CPU 才能播放音乐。这种方法将确保无论使用什么手机(或该手机上的设置),播放都不会从 CPU 进入睡眠状态被切断。
我认为您不需要为此使用 WakeLock。刚开始使用 MediaPlayer 时,我很快发现它不会在待机状态下关闭。为了克服这个问题,我做了一些工作,但我从未见过待机导致流媒体播放器对象死亡的情况。
mediaPlayer.setScreenOnWhilePlaying(true);
文档说:“在可能的情况下,这是优于‘setWakeMode’的首选方法,因为它不需要应用程序具有低级唤醒锁访问权限。”
您不需要 WAKE LOCK。如果您使用 WAKE LOCK,您将强制用户保持屏幕开启,我个人更喜欢在播放媒体时关闭屏幕。
长时间运行的服务示例here示例