让我首先承认我正在学习（或努力学习）Android，同时也在做一些看起来有些挑战性的事情。
虽然我认为我已经了解了 BroadcastReceivers 的基本用法，并且我可以使用它来接收 SMS 并进行一些处理，但我希望即使在设备进入睡眠状态时也能进行这种处理。阅读并提出一个问题（这个），我知道我需要获取部分唤醒锁（以保持 CPU 处于活动状态，而屏幕+键盘处于睡眠状态），以处理传入的 SMS 请求，就像主消息应用程序（或者说环聊或其他一般消息应用程序），可以接收传入的 SMS 并闪烁通知 LED 并振动（如果配置为这样做）。
但是，我感到困惑的是以下几点：
- 有工作要做的时候需要获取唤醒锁，没有工作要做的时候释放。如果获取了唤醒锁并且从未释放，您会更快地耗尽电池电量。
- 如果上述情况属实，那么如何期望短信阅读应用程序立即收到传入消息的通知（可能使用广播接收器），而不必永久获取唤醒锁？
- 我想到的一种方法是，使用一个大部分时间都在休眠并且只定期唤醒的服务来检查是否有任何短信。然而，这与传入的 SMS 及其相应的广播意图可能随时发生的逻辑相反，显然有足够的机会让应用程序错过广播。
那么，如何开发一个应用程序：
- 绝不会错过任何传入的短信，并希望在它到达时立即得到通知（即使设备处于休眠状态）
- 消耗最少的电池，特别是因为 SMS 广播意图的处理非常小且简单……计算量最少。
编辑（2014 年 9 月 12 日）
虽然我已经接受了答案，但我想补充一下我的理解，尽管我仍然不能 100% 确定我的理解是正确的。
我的理解是，在低级别（操作系统、固件和设备硬件）中，在 Android 设备中，当设备进入睡眠状态时，有多个事件可能导致它“唤醒”。网络事件、键盘事件、一些（如果不是全部）传感器事件、定时器事件等会导致设备快速唤醒处理事件，并尝试最好尽快回去睡觉。据我了解，最后一点是关键。这意味着，诸如来电、传入 SMS、按键或其他导致广播 Intent 的原因的事件，总是会导致生成一个 Intent 并将其传递给所有已注册的 BroadcastReceiver。这部分是有保障的。但是，不能保证所有的 BroadcastReceiver 都会有足够的时间来花费他们需要的时间来处理 Intent。相反，他们需要获取唤醒锁（适当类型的）并确保设备在唤醒锁被释放之前不会重新进入睡眠状态。现在，我意识到，有多种获取唤醒锁的方法。它可以直接在 BroadcastReceiver 中完成，但对于管理它的最佳和最有效方法显然并不总是直观，st 它被保留的时间最少，并在不需要时立即释放。为此，SDK 提供了“WakefulBroadcastReceiver”机制，使得编写处理 BroadcastIntent 的软件的任务在需要保持唤醒锁时变得更简单。然后是由 CommonsWare 开发的名为 WakefulIntentService 的替代方案（除非我没记错，它不是来自 SDK，而是来自第 3 方）。
我希望我是对的:)
编辑（2014 年 9 月 13 日）
此 SO Q&A中提供了更多信息