我正在写一个播放音乐的Android应用。当Activity是foregroud时,媒体控制按钮(播放,暂停,停止等)可见。当用户退出活动时,音乐应该继续播放。如果他选择,他可以重新启动活动以点击停止按钮。
目前,MediaPlayer的实例由一个单独的类包装:
public class MediaPlayerPresenter {
public static final String TAG = MediaPlayerPresenter.class.getSimpleName();
MediaPlayer _player;
PlayerState _state;
public MediaPlayerPresenter() {
_state = PlayerState.Idle;
_player = createMediaPlayer(); // calls new MediaPlayer and hooks up event callbacks
}
static public MediaPlayerPresenter getInstance() {
if (_staticInstance == null) {
_staticInstance = new MediaPlayerPresenter();
}
return _staticInstance;
}
// not shown - code that keeps track of MediaPlayer events, state, updating the
// view, handling view events, etc...
现在,由于用户离开应用程序,活动可能会被销毁或停止,但随着音乐的继续播放,运行过程(显然)会继续存在。当活动重新启动或返回到前台时,视图的媒体控件将通过上面的单例实例与已经运行的MediaPlayer重新关联。
到目前为止,这么好。但我一直在读background music should be managed by a service。所以我的问题:
为什么使用服务来维护MediaPlayer实例的生命周期而不是普通的旧单例类更好?是因为没有活动或服务的流程中运行的单身人士的生命周期得不到保证?或者是其他东西?
我可以使用服务代替单身人士。如果我理解正确,应用程序的服务和活动在同一个线程中运行。如果是这种情况,当我的Activity再次启动时,是否可以直接访问Service类所拥有的MediaPlayer类的实例?我认为使用活动代码的活页夹界面在同一过程中与本地服务进行通信并没有多大价值。
使用服务模式的背景音乐播放器的任何好例子?
答案 0 :(得分:4)
Background playback
是关键。
当用户退出活动时,音乐应继续播放。
如果那是你真正想要的,那么恐怕单身人士不是一个好选择。无法保证一旦用户退出活动,您的单例对象是否会保持活跃状态。一旦活动被销毁,你的单身人士将有资格获得gc(),当你的设备内存不足时,它将被销毁,因此你的MediaPlayer生命周期也会被破坏。
如果您要在设备上对此进行测试,请转到Developer options
并查看“不要保留活动......”#34;。退出活动并查看结果
我个人会使用服务,并尝试使用onResume()连接回服务。
关于本教程,请参阅本文
Background audio streaming tutorial
答案 1 :(得分:0)