android – 由AlarmManager重新创建的服务

2019-09-26 07:37:03 阅读：180 来源： 互联网

标签：android android-service android-alarms

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

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并将上下文替换为MyService.this而没有任何改进.

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

编辑 – 导致解决方案的行动集合在我的答案中.

解决方法:

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

>如果您在服务中覆盖onStart和onStartCommand(以允许使用旧设备)并且将super.onStartCommand放在后者中,它将调用onStart,这意味着您将获得两次所有意图！
>根据其他答案之一(及其评论),AlarmManager的设计和指定是为了提供广播意图,而不是其他类型.然而,在实践中,它并不挑剔,似乎尊重其他形式.我认为这是解决问题的关键之一.
>如果服务与其他活动处于相同的过程中,则服务有时似乎“刚刚重新启动”.这可能是此问题中提到的问题的实际原因.见Android service onCreate is called multiple times without calling onDestroy.
>当仅使用意图与服务进行通信而不是绑定和使用Messenger或绑定和访问方法时,事情似乎更稳定.虽然这些都是正确的,但它们管理起来相当复杂(尽管您可以使用这种方法：What is the preferred way to call an Android Activity back from a Service thread和Using the Android Application class to persist data).虽然我完全理解android文档不同意我,但在我的观察中,转向广播意图只是沟通似乎很关键.如果你采用单独的过程方法,你无论如何都必须这样做.
>在声明和解决课程方面保持一致是值得的.这有点乱,但是,因为有时似乎需要使用全名(“com.company.superapp.CleverService”)而不是short(“CleverService”或“.CleverService”).因此,总是使用全名更好.
>关于上下文浮动的经验法则(“使用getApplicationContext”)实际上并不是正确的方法.见When to call activity context OR application context?;本质上使用它,除非你真的需要使用更广泛的上下文,并很好地管理你的变量.
>如果垃圾收集器在不再存在的Activity,Service,Thread,AsyncTask等中创建,它可能会清除仍在使用的内容.如果应用程序基于服务,那么制作一个类的副本可能是明智的,这样它们就不会在以后被清除.
>启动服务的比通常建议的更简洁的方法是为服务提供一个intentFilter,其全名作为操作.然后,您可以使用类名作为字符串创建启动它的意图.这意味着您不必担心上下文.见Issue in Calling Service.

标签：android,android-service,android-alarms
来源： https://codeday.me/bug/20190926/1819240.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

android – 由AlarmManager重新创建的服务