问为什么我的安卓服务在进程终止时重启，即使我使用的是START_NOT_STICKY？

EN

查看此document部分:服务生命周期更改(从1.6开始)

已更新

经过一些调查(创建了项目，一步一步地运行所描述的命令等)，我发现代码完全按照“服务生命周期更改”中的描述工作。

我发现：

adb shell am kill com.tavianator.servicerestart杀死nothing

(尝试adb shell，然后在shell am kill com.tavianator.servicerestart中

您将面临error消息Error: Unknown command: kill)

所以,

运行你的应用程序

运行adb shell

在shell中运行ps命令

查找应用程序的PID编号

在shell运行命令kill <app_xx_PID>中

你的PID号在哪里？

对服务重复终止步骤(如果它在自己的进程中运行)

检查服务是否正在运行(不应该)，并在5-7秒后重新启动

更新

一种解决方案(不够好，但在某些情况下可用)是stopSelf()，例如：

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    Toast.makeText(this, "onStartCommand", Toast.LENGTH_LONG).show();
    stopSelf();
    return START_NOT_STICKY;
}

更新

更新的解决方案

void writeState(int state) {
    Editor editor = getSharedPreferences("serviceStart", MODE_MULTI_PROCESS)
            .edit();
    editor.clear();
    editor.putInt("normalStart", state);
    editor.commit();
}

int getState() {
    return getApplicationContext().getSharedPreferences("serviceStart",
            MODE_MULTI_PROCESS).getInt("normalStart", 1);
}

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    if (getState() == 0) {
        writeState(1);
        stopSelf();
    } else {
        writeState(0);
        Toast.makeText(this, "onStartCommand", Toast.LENGTH_LONG).show();
    }
    return START_NOT_STICKY;
}

当进程被终止时，为什么服务受到限制？

根据这个document

当服务启动时，它有一个独立于启动它的组件的生命周期，服务可以在后台无限运行，即使启动它的组件被销毁。因此，当服务的工作完成时，应该通过调用stopSelf()来停止它自己，或者其他组件可以通过调用stopService().来停止它

Caution：重要的是，您的应用程序在完成工作后停止其服务，以避免浪费系统资源和消耗电池电量。如果需要，其他组件可以通过调用stopService()来停止服务。即使您为服务启用了绑定，如果服务收到对onStartCommand()的调用，您也必须自己停止该服务

另一份文件上写道：

*START_NOT_STICKY* -如果在onStartCommand()返回后系统终止了服务，则不要重新创建服务，除非有待交付的意图。这是最安全的选择，可以避免在不必要的情况下运行您的服务，并且当您的应用程序可以简单地重新启动任何未完成的作业时。

所以，在阅读了这篇文档和一些实验后，我认为系统会将手动终止的服务视为未完成(crashed：@see W/ActivityManager(306): Scheduling restart of crashed service)并重新启动它，尽管onStartCommand返回了这个值。

stopSelf()或stopService() - no重启，如果作业完成，为什么不重启呢？

我认为这里的问题是，对于通过调用startService()启动的服务，其绑定的内部记帐(受对bindService()/unbindService()的调用的影响)在某种程度上阻止了服务在被计划在进程终止时重新启动后正确关闭。

根据您的偏好，似乎有三种方法可以避免这个问题(您已经在问题中提到了前两种方法)：

• 仅使用startService()/stopService()，根本不使用bindService()/unbindService()。
• 仅使用bindService()/D12(使用D13)，根本不使用D14/D15。如果您需要D18/D19和E221，请覆盖服务中的C24方法并从中调用D25：

@Override public boolean onUnbind( intent ) { stopSelf()；super.onUnbind(intent)；}

在我的测试中：

使用第一种替代方法的

• 将在日志中打印以下行：

W/活动管理器( nnn)：计划在5000ms中重新启动崩溃的服务xxxx

但在此之后，该服务将不会真正重新启动。

第二个替代方案将导致您的服务在解除绑定后被销毁(在活动的onStop()中，在您的example).

• The第三个替代方案中，第三个替代方案基本上会使您的代码行为与第二个替代方案相似(无需对其进行太多更改)。

希望这能有所帮助！

重新考虑一下你的模式怎么样？

START_NOT_STICKY的旗帜出现在安卓发展过程中的某个时刻(1.6?之后)。最有可能的是，您在服务生命周期中面临着一些微妙的回归，这是在当时引入的。因此，即使现在找到了一个同样微妙的解决方案-并被神奇地验证可以在所有可能的设备上工作-它也不一定会在新的Android版本上工作。

无论如何，这种生命周期模式看起来很不寻常，这可能就是您遇到这个奇怪问题的原因。

让我们考虑两个案例。

1. Normal (?)。某些活动会启动服务。不久之后，它被绑定、使用、解除绑定--然后呢？不知何故停止了？为什么这款case?
2. Abnormal.没有明显的电池消耗？服务在某些地方被终止(随机？)点。当重新启动时，它实现了一些错误的假设，并保持活动，做一些耗尽电池的事情-

这一切看起来都很奇怪。

我会分析你的产品中的并发进程。都是重要的案子。一些图表等。最有可能的结果是，对这种模式的需求将被消除。

否则，任何解决方法看起来都将是一个脆弱的黑客攻击。