时间戳

首页 > 解决方案 > 前台服务 START_STICKY 在内存不足的情况下被杀死后未重新启动

android - 前台服务 START_STICKY 在内存不足的情况下被杀死后未重新启动

问题描述

我知道有类似标题的线程音调，但没有一个给出明确的答案。我们目前正在对我们的应用程序的前台服务进行压力测试，方法是用另一个应用程序用垃圾填满 RAM，并调查我们的应用程序及其前台服务会发生什么。

因此，我们的前台服务已启动并向用户显示通知，其模式为START_STICKY. 然而，当我们模拟极端内存使用时，应用程序被杀死（这没关系，我们对此无能为力），但坏事是我们的前台服务永远不会重新启动。也许我对 START_STICKY 文档中的某些内容感到困惑，但我可以从下面的文档中了解到系统应该保证重启，不是吗？

返回 from 的常量onStartCommand(Intent, int, int)：如果此服务的进程在启动时（从 返回后 onStartCommand(Intent, int, int)）被杀死，则将其保持在启动状态，但不保留此传递的意图。稍后系统将尝试重新创建服务。因为处于started状态，所以会保证onStartCommand(Intent, int, int)在创建新的服务实例后调用；如果没有任何待处理的启动命令要传递给服务，它将使用 null 意图对象调用，因此您必须注意检查这一点。

上面的文档太模糊了。

第一个问题是

第二个问题是

总而言之，我们确实需要保证我们的前台服务会重新启动。有任何想法吗？

编辑 1： 我确实对 logcat 日志进行了更多调查。这就是发生的事情。

Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS 
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms

显然，系统会终止应用程序并安排重新启动。在这种情况下，大约需要 21 分钟。在其他情况下，我会看到重新安排时间是 10.000 毫秒，也就是 10 秒。并且，在 10 秒内，设备仍会处于内存压力状态，并且应用程序不会启动。这意味着，如果服务未能在重新安排的时间启动，则不会进行任何第二次重新安排，并且服务将永远不会重新启动。但是，如果在重新安排的时间设备处于正常的非内存压力状态，则重新启动将成功发生。

标签： androidservice

解决方案

推荐阅读