关于WakefulBroadcastReceiver的困惑 [英] Confusion about WakefulBroadcastReceiver

查看:552
本文介绍了关于WakefulBroadcastReceiver的困惑的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在通过以下链接研究WakefulBroadcastReceiver: https: //developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html

I've been studying WakefulBroadcastReceiver from this link : https://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html

对此我有些困惑:


  1. 即使设备处于睡眠模式,此接收器也可以确保您将接收广播吗? (我想不,它只是使设备在接收到广播之后一直保持唤醒状态,直到调用completeWakefulIntent()为止。)

  2. 该文档说明了在接收器内部以及之后使用Intent服务的情况。完成工作后,将调用completeWakefulIntent。

CODE:

import android.app.IntentService;
import android.content.Intent;
import android.os.SystemClock;
import android.util.Log;

public class SimpleWakefulService extends IntentService {
    public SimpleWakefulService() {
        super("SimpleWakefulService");
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        // At this point SimpleWakefulReceiver is still holding a wake lock
        // for us.  We can do whatever we need to here and then tell it that
        // it can release the wakelock.  This sample just does some slow work,
        // but more complicated implementations could take their own wake
        // lock here before releasing the receiver's.
        //
        // Note that when using this approach you should be aware that if your
        // service gets killed and restarted while in the middle of such work
        // (so the Intent gets re-delivered to perform the work again), it will
        // at that point no longer be holding a wake lock since we are depending
        // on SimpleWakefulReceiver to that for us.  If this is a concern, you can
        // acquire a separate wake lock here.
        for (int i=0; i<5; i++) {
            Log.i("SimpleWakefulReceiver", "Running service " + (i+1)
                    + "/5 @ " + SystemClock.elapsedRealtime());
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
            }
        }
        Log.i("SimpleWakefulReceiver", "Completed service @ " + SystemClock.elapsedRealtime());
        SimpleWakefulReceiver.completeWakefulIntent(intent);
    }
}

现在,因为文档说此接收者持有一个唤醒锁,我非常怀疑从接收方启动诸如意图服务之类的好习惯。由于服务通常用于长时间操作,因此这将防止接收器释放唤醒锁并消耗大量电池。

Now, as the docs say that this receiver holds a wake lock, I highly doubt that it's a good practice to start something like an intent service from the receiver. This would prevent the receiver from releasing the wake lock and drain a lot of battery as services are generally used for long operations.

即使上方的代码段突出显示,释放锁之前要延迟25秒。这是使用此接收器的正确方法,还是仅应用于短时间操作?谢谢您的帮助。

Even as the code snippet above highlights, there's a delay of 25 seconds before releasing the lock. Is this the right way to use this receiver or should it be used only for short operations? Any help is appreciated.

推荐答案


此接收器可以确保即使在以下情况下也能接收广播设备处于睡眠模式?

Does this receiver ensures that you'll receive the broadcast even when the device is in sleep mode?

否。


(我想不,它只是使设备在接收到广播之后一直保持唤醒状态,直到调用completeWakefulIntent()为止。)

(I think no, it just keeps the device awake after receiving the broadcast until a call to completeWakefulIntent() is made.)

正确。


我非常怀疑从接收方启动诸如意图服务之类的好习惯

I highly doubt that it's a good practice to start something like an intent service from the receiver

是的,这是一个好习惯。

Yes, it is a good practice. That's the entire point.


这将阻止接收器释放唤醒锁

This would prevent the receiver from releasing the wake lock

唤醒锁保存在 static 数据成员中,这就是为什么 static 方法( completeWakefulWork())可以释放它。

The wake lock is held in a static data member, which is why a static method (completeWakefulWork()) is able to release it.


as服务通常用于长期操作

as services are generally used for long operations

长期的定义各不相同。我开始将 WakefulBroadcastReceiver (或我的 WakefulIntentService 的前身)用于可能超过10秒的任何内容。但是,任何形式的 IntentService 实际上仅设计用于事务性工作(例如,下载大文件),因此它不适用于该服务可能需要无限期地运行(例如,只要用户想与某个聊天服务器对话)。

The definition of "long" varies. I start using WakefulBroadcastReceiver (or my WakefulIntentService predecessor) for anything that is likely to exceed 10 seconds. However, an IntentService of any form is really only designed for transactional work (e.g., downloading a large file), and so it is not well-suited for cases where the service might need to run indefinitely (e.g., as long as the user wants to talk to a certain chat server).

您仅使用 WakefulBroadcastReceiver 当您要确保CPU保持活动状态以便服务完成其工作时。否则,您可以直接使用 IntentService

You only use WakefulBroadcastReceiver when you want to ensure that the CPU will stay alive for the service to complete its work. Otherwise, you use the IntentService directly.


这是正确的使用方式该接收器还是仅应用于短时间操作?

Is this the right way to use this receiver or should it be used only for short operations?

25秒对于使用 WakefulBroadcastReceiver 及其关联的 IntentService

25 seconds is a perfectly reasonable time frame for using WakefulBroadcastReceiver and its associated IntentService.


但是更复杂的实现可以在释放接收者的

but more complicated implementations could take their own wake lock here before releasing the receiver's

之前采取自己的唤醒锁,尽管目前尚不清楚这会为您带来什么好处。唤醒锁是唤醒锁。服务拥有的唤醒锁将对电池的影响与接收者拥有的唤醒锁完全相同。

Sure, though it is unclear what this would gain you. A wake lock is a wake lock. A service-owned wake lock will have the exact same impact on battery as will a receiver-owned wake lock.

这篇关于关于WakefulBroadcastReceiver的困惑的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆