1

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

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;
    }
}

当我从活动中使用 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没有任何改进。

我对此感到困惑 - 任何人都可以解释这种行为并提出让它按预期运行的方法吗？

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

4

3 回答 3

4

经过一番调查和工作，我发现了很多事情。完成所有这些后，这个问题看起来已经消失了：

  1. 如果您在服务中覆盖 onStart 和 onStartCommand（以允许较旧的设备）并将 super.onStartCommand 放在后者中，它将调用 onStart，这意味着您将每个意图都输入两次！

  2. 根据其他答案之一（及其评论），AlarmManager 被设计和指定为传递广播意图，而不是其他类型。然而，在实践中，它并不挑剔，似乎尊重其他形式。我认为这是解决问题的关键之一。

  3. 如果该服务与其他活动等处于同一进程中，则该服务有时似乎“刚刚重新启动”。这可能是此问题中指出的问题的实际原因。请参阅Android 服务 onCreate 被多次调用而不调用 onDestroy。

  4. 仅使用意图与服务通信而不是绑定和使用 Messenger 或绑定和访问方法时，事情似乎更稳定。虽然这两个都是正确的，但它们管理起来相当复杂（尽管您可以使用这种方法：从服务线程调用 Android Activity 的首选方法是什么和使用 Android 应用程序类来持久化数据）。虽然我完全理解 android 文档不同意我的观点，但在我观察到转向广播意图时，只有交流似乎是关键。如果您采用单独的流程方法，无论如何您都必须这样做。

  5. 在声明和处理类的方式上保持一致是值得的。这有点混乱，但是，因为有时使用全名（“com.company.superapp.CleverService”）而不是短名（“CleverService”或“.CleverService”）似乎是值得的。所以，最好总是使用全名。

  6. 关于上下文的经验法则（“使用getApplicationContext”）并不是真正的正确方法。请参阅何时调用活动上下文或应用程序上下文？; 本质上使用它，除非你真的需要使用更广泛的上下文，并很好地管理你的变量。

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

  8. 启动服务的一种比通常建议的更简洁的方法是给服务一个 intentFilter，并以它的全名作为操作。然后，您可以创建意图以仅使用类名作为字符串来启动它。这意味着您不必担心上下文。请参阅呼叫服务中的问题。

于 2013-03-28T20:00:07.733 回答
1

好吧，我真的很惊讶它完全运行你Service！PendingIntent您传递给AlarmManager需要的是广播Intent。所以你需要重新架构你的代码。将AlarmManager触发 a BroadcastReceiver，BroadcastReciever然后可以调用startService()。

见描述AlarmManager.set()

于 2013-03-15T14:44:45.550 回答
0

我通过使用以下代码使其工作：

AlarmManager almgr = (AlarmManager)MyContext.getSystemService(Context.ALARM_SERVICE);
Intent timerIntent = new Intent(MyUniqueLabel);
timerIntent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
PendingIntent pendingOffLoadIntent = PendingIntent.getBroadcast(MyContext, 1, timerIntent, 0);

你必须做这些事情才能让它工作。
1.) 调用 addFlags 和意图并将其传递到 FLAG_RECEIVER_FORGROUND
2.) 在 PendingIntent.getBroadcast 中使用非零请求代码

如果您将这些步骤中的任何一个排除在外，它将无法正常工作。

于 2013-11-26T01:30:26.720 回答