需要在IntentService中喚醒鎖定：爲什麼要通過WakefulBroadcastReceiver？

Question

我有一個IntentService這是從我的應用程序從別處調用（從組件X說）。我想要它的onHandleIntent以喚醒鎖運行。似乎有兩種方法可以做到這一點：

1. 獲取並釋放onHandleIntent中的喚醒鎖。
2. 創建一個新的WakefulBroadcastReceiver啓動此服務。在組件X中，直接調用此接收器而不是服務。

第二個選項似乎是recommended。但爲什麼？增加的間接和樣板文件是否比第一種方法有優勢？

Answer 1

Back in 2010，我們被告知，與AlarmManager和_WAKEUP風格報警的唯一保證是如果我們用廣播PendingIntent，然後的Android將保持清醒設備足夠長onReceive()完成。任何其他類型的PendingIntent都沒有這種保證。

但是，在主應用程序線程上調用BroadcastReceiver的onReceive()，我們無法安全地在此處花費太多時間。理想情況下，這是毫秒級的，至於你所知道的，你的用戶界面恰好在前臺，而你不希望這個接收器引起混亂。

所以，配方變成了：

• 有報警觸發BroadcastReceiver
• 有接收器獲取WakeLock
• 有接收器工作委託給一個Service，通常是IntentService
• 當工作完成後，服務發佈WakeLock

My WakefulIntentService是第一個爲此配方提供支持的圖書館。後來過來了WakefulBroadcastReceiver。它們都以不同的語義完成相同的目標。

請注意，「爲什麼我們不只是在服務中獲得WakeLock？」因爲設備可能會在onReceive()結束與服務可能有機會獲得WakeLock的第一個位置之間入睡。

現在，對於其他情況，不涉及AlarmManager，服務管理自己的WakeLock是完全合理的。事實上，這是我帶着特殊的IntentService（WakefulIntentService）而不是特殊的BroadcastReceiver（WakefulBroadcastReceiver）去的原因之一。