首先,如果您使用前台
Service
,很可能不会突然被杀死。话虽如此:
如果我的服务在与应用程序相同的进程中工作,那么服务也会保持活动状态吗?
好吧,不是这样的。您的
Service
是应用程序的一个组件。如果它存在,则应用程序也存在(另请参见第三个问题)。但是,如果您从
onStartCommand()
返回
START_STICKY
或
START_REDELIVER_INTENT
,则当系统终止它时(而不是强制停止),它将尽快重新创建。
我正在使用广播接收器检测设备连接性的更改,因此,如果应用程序被杀死但服务未被杀死,我仍然会收到连接性更改吗?
对于静态
BroadcastReceiver
(在
Manifest
中注册):这取决于应用程序的终止方式。如果用户强制停止它,则接收器只会在用户再次启动应用程序后开始工作。在所有其他情况下:静态接收器将保持完整,如果接收器是动态创建和注册的,则应及时取消注册,以避免内存泄漏,因此,这种接收器并不适合24/7工作。
如果我想从服务中获取当前连接状态,我可以使用getApplicationContext()吗?或者它可能返回null吗?
这个比较简单:
Service
和
Activity
一样,都扩展了
ContextWrapper
。因此,如果它正在运行,您可以调用
getApplicationContext()
。
每当应用程序从前台转为后台(在应用程序暂停/恢复时)更改其状态时,我通过Otto的总线发送一个事件...如果我的应用程序被杀死,我可以信任这些事件吗?或者它们可能无法发送?
我认为您可能混淆了
Application
和
Activity
。因为如果需要通知
Service
,则您很可能正在考虑应用程序的可见部分和类似于著名的来电。
在这种情况下,您的活动可以在
onPause()
或
onStop()
中通知
Service
。自
HONEYCOMB版本
以来,两者都有保证会被调用。
现在我必须承认我不确定Otto的EventBus,但是肯定可行的一个选项是具有具有
START_REDELIVER_INTENT
的
Service
,并通过调用
startService(myNotifyingIntent)
来通知该服务。
通常情况下,即使当前的
Activity
不再处于前台,您的应用程序进程也不会立即被杀死。因此,很可能
Service
将从
onPause()
接收到您发送的任何通知。