之前写过MP3的demo,那时我是使用service播放的,界面用bind方式绑定service,bind的这种方式在绑定的那个界面消失的时候自己也就消失了,然后我就在播放界面中按下手机的返回按钮,此时activity应该是被压栈了不能说是消失了吧?但是我就发现了播放的音乐也停止了,说明service也被干掉了?是否是这种情况?现在要用service了,查了下start方式与这种方式的区别,start方式不会有这种情况,就是start的那个界面被干掉(销毁)了之后只要没有手动去销毁service,那么service还是在的,但是这种service无法方便的与activity交流,也就是我无法方便的拿到service中数据处理的进度等信息。现在考虑到又要方便的获得service中的一些实时的信息,而且还应该在内存不足的情况下activity被系统回收这样的情况下service还是能够存在,并且仍然处理数据,我使用了先start的方式进行处理数据,然后等到我切换到该界面需要查看信息的时候再去bind上这个service使用aidl去与service通信。高手帮忙指导下这种方式可行吗?
service使用start启动,不会因为界面的关闭而停止服务。
源码中的Alarm 楼主可以看下这个源码,里面的播放音乐
可以这样:当Activity 绑定一个Service的时候,需要传递一个ServiceConnection对象。只要在ServiceConnection.onServiceConnected()方法中调用startService()就可以了。这样一来,
无论是手动使activity 返回(进入堆栈),还是系统销毁activity,service都不会退出,直到你主动调用stopService()。另外没有必要使用remote service 模型。
因为一个local service 也是可以独立存在的。 程序的所有acitivity都销毁了,程序(进程)也不一定退出,如果此时有一个已经被start 的local service 存在,那么该程序(进程)还会运行。相当于后台运行。
之前我测试过了,就直接使用bind的方式的话,当activity按下返回(即进入OnDestroy方法)相应的service也进入了destroy方法,后来在bindservice之前我就先start了,然后再bind上,这样当我的界面destroy后service也不会进入destroy方法,不过要在activity进入destroy后将bind的service给unBind掉不然貌似会出异常
恩,对的。 activity.bindService后需要再activity销毁前unbind。另外,bindservice的主要目的是在contected后得到Service得binder对象,这样可以通过binder对象与service直接交互(通常binderImplement 提供getService接口,可以直接得到这个service的引用)。startService 就是启动service。 可以无数次startService。只要又一次stopService() service 就会被stop。 startService 只能传递一次Intent,个人感觉无法优雅的进行交互。
其实简单的这么说吧,通过bind启动的service是和当前activity绑定在一起的,activity退出了,service当然也会destroy.但是通过start启动的service就不会了,除了主动的调用的stop.
我还是使用的先start后bind,虽然service在unbind后不能再被bind了 手动去bind后service不会进入onBind方法但是还是可以和service建立连接的,同时拿到onBind的返回IBinder对象这样就可以继续和service交互