不要调用一个BroadcastReceiver，当我需要获得唤醒锁 [英] Do I need to acquire wake lock when invoking a BroadcastReceiver

问题描述

在这本书专业版的Andr​​oid 4.0到萨蒂亚Komatineni，戴夫麦克莱恩我发现

  

调用广播服务，并释放时，机器人获得一个局部唤醒锁它时，它从服务在主线程返回

这是否意味着Android操作系统确保设备会醒来的经历的onReceive 的BroadcastReceiver ？在我的情况下的BroadcastReceiver 应该从谷歌播放服务（GoogleLocationServices，并为precise的 Geofences API ）。

它在哪里记录？

编辑：我也发现在这里 < /一>：

  

，因为它保证了BroadcastReceiver.onReceive（）将始终完全执行之前，C​​PU进入睡眠状态

解决方案

有没有这样的事情作为一个广播服务。

此外，您还需要阅读包含你的第二个报价的整个帖子，因为这是仅由 AlarmManager 引发了广播。这是 AlarmManager ，不是广播意图机制，即持有 WakeLock 。另外，在博客中指出，戴安娜Hackborn已经证实了这一行为，她是一个核Android工程师。

  

这是否意味着Adnroid操作系统确保该设备将被唤醒的要去通的BroadcastReceiver的的onReceive时间？

不一般。

  

在我的情况下的BroadcastReceiver应该意图从谷歌播放服务（GoogleLocationServices，并为precise Geofences API）。

如果在谷歌播放业务文档不做出关于你的接收机相对于觉醒的行为的任何要求，你应该假设你是不是 WakeLock 里面。如果工作是什么，将采取1-2MS，因此很可能是安全的做的onReceive（）反正，欢迎您来承担风险，并跳过 WakeLock 和最好的希望。

但通常这样的广播会触发更多的工作，涉及到磁盘I / O和/或网络I / O，你需要获得工作过的主应用程序线程。通常情况下，你可以通过委托给一个 IntentService ，因为它给你带标记的服务后台线程，让操作系统知道你还是做了一些工作在这里。而且，为了确保该装置将保持清醒的工作来完成，使用 WakefulBroadcastReceiver 或我的 WakefulIntentService ，举行一个 WakeLock 从年初的onReceive（）直到完成工作的 onHandleIntent（） 。

  

它在哪里记录？

AFAIK，事实并非如此。习惯了就好了，至于复杂的系统，该系统的行为，通常只有一小部分卷起被记录在案。

In the book Pro Android 4 By Satya Komatineni , Dave MacLean I've found:

Android acquires a partial wake lock when invoking a broadcast service and releases it when it returns from the service in the main thread

Does it mean that the Android OS ensures that the device will wake up for the time of going through onReceive of BroadcastReceiver? In my case the BroadcastReceiver should get an intent from Google Play Services (GoogleLocationServices and to be precise Geofences api).

Where is it documented?

EDIT: I've also found it here:

because it is guaranteed that the BroadcastReceiver.onReceive() will be always fully executed before the CPU goes to sleep

解决方案

There is no such thing as a "broadcast service".

Also, you need to read the entire post containing your second quote, as that is only for a broadcast triggered by AlarmManager. It is AlarmManager, not the broadcast Intent mechanism, that holds the WakeLock. Also, as noted in that blog post, Dianne Hackborn had confirmed this behavior, and she's a core Android engineer.

Does it mean that Adnroid OS ensures that the device will wake up for the time of going thru onReceive of BroadcastReceiver?

Not generally.

In my case the BroadcastReceiver should get intent from Google Play Services (GoogleLocationServices and to be precise Geofences api).

If the Google Play Services documentation does not make any claims regarding the behavior of your receiver with respect to wakefulness, you should assume that you are not inside of a WakeLock. If the work is something that will take 1-2ms, and therefore is probably safe to do in onReceive() anyway, you're welcome to take the risk and skip a WakeLock and hope for the best.

But usually a broadcast like this triggers more work, involving disk I/O and/or network I/O, and you need to get that work off of the main application thread. Frequently, you do that by delegating to an IntentService, as it gives you a background thread with a marker service to let the OS know that you're still doing some work here. And, to ensure that the device will stay awake for that work to complete, use WakefulBroadcastReceiver or my WakefulIntentService, to hold a WakeLock from early in onReceive() until the completion of the work in onHandleIntent().

Where is it documented?

AFAIK, it isn't. Get used to it, as for complex systems, usually only a tiny fraction of the system's behavior winds up being documented.

这篇关于不要调用一个BroadcastReceiver，当我需要获得唤醒锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！