服务和 Android 应用程序生命周期

Question

我有点困惑。我读过使用启动服务的最大好处是它独立于应用程序，因此，即使 android 杀死您的应用程序，您的服务仍然存在。我的问题是：

1) 如果我的服务与应用程序在同一个进程中工作，那么该服务也会存活吗？

2) 我正在使用 BroadcastReceiver 来检测设备连接的变化，所以，如果应用程序被终止但服务没有被终止，我还会收到连接变化吗？

3) 如果我想从服务中获取当前的连接状态，我可以使用 getApplicationContext() 来做到这一点，还是可能返回 null？在第二种情况下，我如何获得网络的当前状态？

4) 与连接性类似，每次应用程序将其状态从前台更改为后台时（在应用程序暂停/恢复时），我都会通过 Otto 的总线发送一个事件。因此，我的服务订阅了这些更改，以便了解当前的应用程序状态。如果我的应用程序被终止，我可以信任那些事件吗？或者他们无法发送？

Answer 1

首先，如果使用 foreground Service，它不太可能被突然杀死。话说回来：

如果我的服务在与应用程序相同的进程中工作，那么该服务也会处于活动状态吗？

嗯，不。您Service是应用程序的一个组件。如果它是活动的，那么应用程序也是活动的（另见第三个问题）。但是，如果您返回START_STICKY或START_REDELIVER_INTENT从onStartCommand()，那么如果系统终止（而不是强制停止），它将尽快重新创建。

我正在使用 BroadcastReceiver 来检测设备连接的变化，所以，如果应用程序被终止但服务没有被终止，我是否仍然会收到连接变化？

对于静态BroadcastReceiver（在 中注册Manifest）：这取决于您的应用程序是如何终止的。如果用户强制停止它，那么接收器只会在用户再次启动您的应用程序后重新开始工作。在所有其他情况下：静态接收器将完好无损，如果接收器是动态创建和注册的，那么在关闭Activity/时应及时取消注册Service以避免内存泄漏，因此这种接收器不适合工作 24 /7 无论如何。

如果我想从服务中获取当前的连接状态，是否可以使用 getApplicationContext() 来实现，或者它可能返回 null？

那个更容易：Service，就像Activity， extends ContextWrapper。因此，如果它已启动并正在运行，您可以调用getApplicationContext().

每次应用程序将其状态从前台更改为后台（在应用程序暂停/恢复时）时，我都会通过 Otto 的总线发送一个事件...如果我的应用程序被终止，我可以信任该事件吗？或者他们无法发送？

我想在这里你可能混淆了Application和Activity。因为如果Service需要通知，那么您很可能会考虑应用程序的可见部分，例如著名的来电。

在这种情况下，您的 Activity 可以通知ServiceinonPause()或 in onStop()。两者都保证自 以来被调用Version HONEYCOMB。

现在我必须承认，我不确定 Otto 的 EventBus，但肯定可行的一种选择是Service使用START_REDELIVER_INTENT并通过调用startService(myNotifyingIntent).

通常，您的应用程序进程不会因为当前Activity不再处于前台而立即被杀死。因此很可能Service会收到您发送的任何通知onPause()。