在android中使用廣播recevire與鬧鐘管理器

Question

爲什麼建議通常在使用鬧鐘管理器時傳遞意向服務的待定意圖？在警報管理器調用的廣播接收器的onreceive（）函數中可以做同樣的事情。使用服務有什麼優勢（意向服務）？

Answer 1

如果您需要完成的一切都可以在BroadcastReceiver的onReceive中完成，那麼您應該使用它而不是IntentService。

如果您想在BroadcastReceiver之後執行任何操作，那麼您應該使用IntentService。例如，如果您希望BroadcastReceiver啓動Service，並且您希望該服務獲得WakeLock，則應該使用IntentService代替。

原因是，AlarmManager只保證BroadcastReceiver的onReceive將運行，即使您使用RTC_WAKEUP。所以，如果你使用BroadcastReceiver/Service組合，那麼CPU在Service可以獲得WakeLock之前就會睡着 - 這就是說，除非你在BroadcastReceiver中獲得WakeLock並且你在服務中獲得一個，也許通過staticWakeLock。但是，這是......凌亂，我想。

順便說一句，我從未實施過IntentService。我只是使用BroadcastReceiver和Service組合，並從未報告過問題。我所提供的信息是事情，我從其他SO職位（主要來自CommonsWare）讀

編輯：

我從一些CommonsWare讀取的50ms的時間框架貼在計算器上，並CommonsWare似乎是一個相當Android的可靠知識來源。

我看着它，並The docs不這樣說：

（有被打死10秒，系統 之前允許考慮到被阻擋的接收器和一個候選超時）。

而且他們也說：

如果廣播接收器通過一個標籤推出，那麼對象是從這個函數返回後沒有 不再活着。

1. 你不應該做任何接近10秒的事情，爲了安全起見。
2. 如果您需要等待任何迴應，BroadcastReceiver將會因爲onReceive可能會在您收到回覆之前完成運行而死掉。

雖然，我想50毫秒的時間框架的原因是，所以你不會冒險造成ANR或任何滯後。因爲如果你使用Service，那麼你可以開始一個新的Thread，它不會阻塞。您將無法在BroadcastReceiver中啓動新的Thread，因爲線程之後的代碼將繼續運行，BroadcastReceiver將會死亡，然後Thread也會死亡。