在我的应用中，我需要在事件发生后立即通知用户（即地理围栏转换或到达推送消息）。通知我的意思是发布振动，声音和LED闪烁的系统通知，
当然，我直接从BroadcastReceiver通过android.app.NotificationManager发布通知 - 它可以正常工作。但是如果设备长时间处于非活动状态，我可以发现发送GCM消息和通知声音/振动之间有一些延迟（甚至可能是几分钟）。如果我早点放弃等待并手动唤醒设备，我会在屏幕开启后立即收到通知。
起初，Google的GCM样本使用了相同的模式（从BR发布通知）。但是，他们在8月更改了示例，现在通知从IntentService发布，在启动服务之前获得了部分唤醒锁。
我认为即使设备处于睡眠模式，我的BR中的代码也会被执行。问题是，如果NotificatonManager可以发布通知并在该状态下发出声音/振动？在对两种实现进行了一些测试之后，我没有注意到任何显着的差异，但我想确保它以这种方式工作。
在GCM的情况下，我知道有一个问题被讨论here，这也可能是延迟的原因。
修改
对我来说很明显，如果设备休眠，它不会在应用程序级别运行任何代码。但在内核级别，它可以响应一些基本事件（例如来电/短信），唤醒设备并为为此事件注册的BR生成广播。
对我来说，在所有BR回调完成（原子地）之前，这样的事件保持唤醒是合乎逻辑的 - 这可能就是为什么onReceive无法执行长时间运行的操作。 我找不到任何关于它的文档，所以如果你能证明这不是真的，请纠正我。
但是，如果上述假设是正确的，我的广播应立即收到并执行，因为GCM有一个唤醒锁。因此，接收GCM消息和通知用户之间的唯一延迟将由NotificationManager引起。 这是我的主要问题 - 这种延迟是否可能（例如由于某些异步处理）？