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

Question

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

androidandroid-serviceandroid-lifecycleandroid-service-binding

4

我有点困惑。我看到最大的使用启动服务的好处是它独立于应用程序，所以即使Android终止您的应用程序，您的服务仍然存在。那么我的问题是：

1）如果我的服务与应用程序在同一进程中工作，服务也会保持活动状态吗？

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

3）如果我想从服务中获取当前的连接状态，我可以使用getApplicationContext()吗？还是它可能返回null？如果是后者，我该如何获取网络的当前状态？

4）与连接性类似，每当应用程序从前台转换到后台（在应用程序暂停/恢复时）时，我都会通过Otto总线发送事件。因此，我的服务已订阅这些更改以了解当前应用程序状态。如果我的应用程序被终止，我可以相信这些事件吗？或者它们可能不会被发送？

- FVod

3个回答

0

1) 默认情况下服务会停止。但是你可以重写onStartCommand并返回START_STICKY。还有其他标志，所以请阅读更多相关信息https://developer.android.com/reference/android/app/Service.html#START_STICKY

2) 是的，我会从接收器中获取更改。

3) getApplicationContext() 不应该返回 NULL。

4) 如果您的应用程序已经被杀死，onPause 应该已经被调用了。因此服务知道应用程序在后台运行。当您启动应用程序时，onResume 被调用，因此服务也将知道应用程序在前台运行。

- Alexander

0

你误解了Android中的Activity和Application。你可以在这里找到更多关于Service生命周期的信息

- amukhachov

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bö macht Blau · Accepted Answer

首先，如果您使用前台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()接收到您发送的任何通知。