android - AlarmManager 正在重新创建服务

Question

我有一个相当标准的服务，我希望使用警报来触发它。这是服务的启动部分:

class MyService extends Service {
    private Context context;
    private AlarmManager  alarmManager = null;

    private final String startReason = "com.stuff.myreason";
    private final int REASON_NO_INTENT = 0;
    private final int REASON_ALARM     = 1;
    private final int REASON_X         = 2; // and so on.

    @Override
    void onCreate() {
        super.onCreate();
        context = getApplicationContext();
        alarmManager = (AlarmManager)getSystemService(ALARM_SERVICE);
        // do onCreate stuff
    }

    @Override
    int onStartCommand (Intent intent, int flags, int startId) {
        int reason = REASON_NO_INTENT;
        if (intent != null) {
            reason = intent.getExtra(startReason, REASON_NO_INTENT);
        }

        switch(reason) {
            // handle the different reasons we may have been "started"
        }

        return START_STICKY;
    }
}

当我使用 Activity 中的 context.startService 触发它时，它绝对正常启动。特别是，如果它已经在运行，它不会(重新)从头开始，而只是通过 onStartCommand() 进入现有的实例化。这是预期的行为。但是，当我使用 AlarmManager 触发它时:

Intent intent = new Intent(context, MyService.class);
intent.putExtra(purposeOfStartCode, REASON_ALARM);

PendingIntent pi = PendingIntent.getService(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);

alarmManager.set(AlarmManager.RTC_WAKEUP, /* A time in the future */, pi);

当警报到期时，它似乎从头开始重新启动服务:它开始一个新的实例化，调用 onCreate() 然后调用 onStartCommand() 而不是仅仅调用onStartCommand() 在已经运行的实例中。

我已经尝试将 PendingIntent 标志更改为 FLAG_ONE_SHOT 并将 context 替换为 MyService.this 没有改进。

我对此感到很困惑 - 任何人都可以解释这种行为并建议如何让它按预期运行吗？

编辑 - 导致解决方案的操作集合在我下面的回答中。

Answer 1

经过一些调查和工作，我发现了很多东西。完成所有这些后，这个问题看起来就消失了:

1. 如果您在服务中重写 onStart 和 onStartCommand(以允许较旧的设备)，并将 super.onStartCommand 放在后者中，它会调用 onStart，这意味着您会收到两次 intent!

2. 根据其他答案之一(及其评论)，AlarmManager 的设计和指定是为了提供广播 Intent ，而不是其他类型。然而，在实践中，它并不挑剔，而且似乎尊重其他形式。我认为这是解决问题的关键之一。

3. 如果该服务与其他 Activity 等处于同一进程中，则该服务有时似乎“刚刚重新启动”。这可能是这个问题中提到的问题的实际原因。参见 Android service onCreate is called multiple times without calling onDestroy .

4. 当仅使用 Intent 与服务通信而不是绑定(bind)和使用 Messenger 或绑定(bind)和访问方法时，事情似乎更稳定。虽然这两个都是正确的，但它们管理起来相当复杂(尽管您可以使用这种方法:What is the preferred way to call an Android Activity back from a Service thread 和 Using the Android Application class to persist data)。虽然我完全理解 android 文档不同意我的观点，但根据我的观察，转向广播 Intent 仅通信似乎是关键。如果您采用单独的流程方法，则无论如何都必须这样做。

5. 声明和处理类的方式保持一致是值得的。这有点困惑，但是，因为有时使用全名(“com.company.superapp.CleverService”)而不是短名称(“CleverService”或“.CleverService”)似乎是值得的。因此，最好始终使用全名。

6. 关于上下文的经验法则(“使用 getApplicationContext”)并不是真正正确的方法。参见 When to call activity context OR application context? ;本质上使用它，除非你真的需要使用更广泛的上下文，并很好地管理你的变量。

7. 如果某些东西是在不再存在的 Activity、Service、Thread、AsyncTask 等中创建的，那么垃圾收集器可能会清除仍在使用的东西。如果应用程序是基于服务的，那么复制传入的类可能是明智的，这样它们以后就不会被清除。

8. 启动服务的一种比通常建议的更简洁的方法是为服务提供一个 intentFilter，并将其全名作为操作。然后，您可以创建仅以类名称作为字符串的 Intent 来启动它。这意味着您不必担心上下文。参见 Issue in Calling Service .