используя широковещательный прием с диспетчером тревоги в Android - PullRequest
Новая
       53

используя широковещательный прием с диспетчером тревоги в Android

0 голосов
/ 02 апреля 2012

Почему обычно предлагается передать ожидающее намерение для Службы намерений при использовании диспетчера аварийных сигналов? То же самое можно сделать в функции onreceive () приемника вещания, вызываемого менеджером аварийной сигнализации. В чем преимущество использования службы (Intent Service)?

1 Ответ

1 голос
/ 02 апреля 2012

Если все, что вам нужно сделать, может быть выполнено за onReceive из BroadcastReceiver, то вам следует использовать это, а не IntentService.

Если вы хотите что-то сделать после BroadcastReceiver, вам следует использовать IntentService. Например, если вы хотите, чтобы ваш BroadcastReceiver запустил Service, и вы хотите, чтобы сервис набрал WakeLock, вам следует вместо этого использовать IntentService.

Причина в том, что AlarmManager гарантирует только то, что onReceive из BroadcastReceiver будет запущен, даже если вы используете RTC_WAKEUP. Таким образом, вполне возможно, что если вы используете комбинацию BroadcastReceiver / Service, то процессор засыпает до того, как Service сможет получить WakeLock - это, если вы не приобретете WakeLock в BroadcastReceiver и вы приобретаете его в службе, возможно, через static WakeLock. Но это ... грязно, я полагаю.

Кстати, я никогда не реализовывал IntentService. Я просто использую комбо BroadcastReceiver и Service и никогда не сообщал о проблеме. Вся информация, которую я предоставил, - это то, что я читаю из других сообщений SO (в основном из CommonsWare)

EDIT:

Временной интервал в 50 мс, который я прочитал из чего-то, что CommonsWare опубликовал в StackOverflow, и CommonsWare кажется довольно надежным источником знаний для Android.

Я посмотрел и Документы действительно говорят:

(есть тайм-аут 10 секунд, который система позволяет считая, что получатель заблокирован, а кандидат убит).

И они также говорят:

Если этот BroadcastReceiver был запущен через тег, то объект не является дольше жив после возвращения из этой функции.

  1. Вы не должны делать ничего, что занимает около 10 секунд, просто чтобы быть в безопасности.
  2. Если вы сделаете что-либо, что должно ждать ответа, BroadcastReceiver умрет, потому что onReceive, скорее всего, завершит работу, прежде чем вы получите ответ обратно.

Хотя, я полагаю, причина в 50 мсек такова, что вы не рискуете вызвать ANR или какое-либо отставание. Потому что если вы используете Service, то вы можете запустить новый Thread, и он не будет блокироваться. Вы не сможете запустить новый Thread в BroadcastReceiver, потому что код после потока продолжит работать, BroadcastReceiver умрет, а затем умрет Thread.

...