在内存不足的情况下终止前台服务START_STICKY后不会重新启动

Question

我知道有类似标题的线程调，但是没有人给出明确的答案。 当前，我们通过对另一个应用程序进行垃圾填满RAM并调查我们的应用程序及其前景服务发生了什么，来对应用程序的前景服务进行压力测试。

因此，我们的前台服务已启动，并且向用户显示了通知，其模式为START_STICKY。但是，当我们模拟极端的内存使用情况时，该应用程序将被终止（这是正常的，我们对此无能为力），但是坏的是，前台服务永远不会重启。也许我混淆了START_STICKY文档中的某些内容，但是我从文档下面可以理解的是系统应该保证重启，不是吗？

  

不断从onStartCommand(Intent, int, int)返回：如果这   服务的进程在启动时被杀死（从中返回后   onStartCommand(Intent, int, int)），然后将其保留为启动状态   但不要保留这种传达的意图。 稍后系统将尝试   重新创建服务。因为它处于启动状态，所以它将   确保创建完后调用onStartCommand(Intent, int, int)   新服务实例；如果没有任何待执行的启动命令   交付给服务时，将以空意图调用它   对象，因此您必须小心检查这一点。

以上文档过于模糊。

第一个问题是

• 是否会总是重新启动该服务？如果没有，那是什么 重新启动服务的条件以及什么是 何时不重启？

第二个问题是

• 以后是什么意思？以后什么时候？明年晚些时候还是什么？ ：D

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

---

编辑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.000ms（即10秒）。而且，在10秒内，设备仍将处于内存紧张状态，并且该应用将无法启动。这意味着，如果服务无法在重新安排的时间启动，则不会进行第二次重新安排，并且服务将永远不会重新启动。但是，如果在重新安排的时间设备处于正常的非内存紧张状态，则重启将成功进行。