BroadcastReceivers и использование памяти

Question

У меня не было времени поиграть с приемниками, а также я незнаком с чем-либо выше 2.3.x, поэтому я был совершенно озадачен, когда прочитал этот вопрос:
Может ли BroadcastReceiver, зарегистрированный в AndroidManifest, получать намерения после завершения процесса приложения?

Его автор может видеть приложение BroadcastReceiver в списке диспетчера задач, и, когда приложение убито, широковещательный приемник больше не вызывается. Это связано с новым механизмом, представленным в 3.1:
http://developer.android.com/sdk/android-3.1.html

В этой ссылке упоминается остановленное состояние для Приложения. Жизненный цикл приложения нигде не описан в документах AFAIK, поэтому я думаю, что приложение может находиться в одном из следующих трех состояний:

• Остановлено (не в ОЗУ)
• Запущено (в оперативной памяти не работает)
• Работает (в оперативной памяти)

Чтобы пользователь мог видеть приложение в диспетчере задач, оно должно быть либо в запущенном, либо в запущенном состоянии (я предполагаю здесь, потому что я не знаю, есть ли еще состояния). И кажется, что приложение показывалось в списке в течение значительного периода времени. Если приложение-получатель запущено или работает, оно должно иметь процесс размещения Linux с собственным экземпляром Dalvik VM. Это противоречит моим предыдущим убеждениям о том, как должны работать приемники:

• Когда приемник не работает, система не снижает производительность.
• Как только получатель должен получить уведомление, создается новый процесс переднего плана (если он еще не запущен), создается новый получатель, и onReceive метод называется.
• После максимального времени обработки 10 секунд, onReceive возвращается, и при условии отсутствия дополнительных услуг или действий, процесс хостинга, скорее всего, будет остановлен, освобождая ресурсы.

Итак, мои вопросы:

1. Если приложение отображается в диспетчере задач (следовательно, есть процесс), но еще не было уведомлено, почему ОС порождает процесс для получателя, который даже не был уведомлен (и может вообще не быть уведомлен), Если приложение было уведомлено, но процесс еще не завершен (и поэтому он указан в диспетчере задач), почему ОС не уничтожает его вскоре после завершения? Здесь я предполагаю, что диспетчер задач показывает приложение, только если у него есть выделенный процесс, но это поднимает следующий вопрос:
2. Каковы шансы включения процесса получателя в диспетчере задач? Диспетчер задач показывает приложение получателя, даже если оно остановлено? Если да, то является ли это новым поведением для 3.1+, чтобы пользователь мог заметить его существование и принудительно закрыть его? Если нет, приложение должно быть указано там, только если оно находится в середине вызова onReceive или после того, как он возвращается и имеет право быть убитым, что, согласно документам, должно быть коротким интервалом.

Заранее спасибо.

Answer 1

поэтому я предполагаю, что приложение может находиться в одном из следующих трех состояний: остановлено (не в ОЗУ), запущено (в ОЗУ, не запущено), запущено (в ОЗУ)

Не совсем так, по крайней мере, как я бы сказал, хотя это может быть терминология и / или языковая проблема.

Процесс либо запущен, либо не запущен. Это не может быть "в оперативной памяти" и "не работает".

Независимо от этой концепции, приложение может иметь зарегистрированный манифест BroadcastReceivers быть отключенным или включенным, начиная с Android 3.1. Документы ссылаются на отключенное состояние как "остановлено", что является очень неудачным выбором терминов со стороны Google, на который я несколько раз жаловался. Когда вы видите ссылки на это состояние, игнорируйте любые другие определения термина "остановлено". На самом деле, вы могли бы хотеть придумать какой-то другой термин для этого состояния, например, "snicklefritzed".

Ваше приложение перехватывается сразу после установки. Ваше приложение переводится в "нормальное" состояние, когда что-то явно запускает один из ваших компонентов (например, пользователь вручную запускает действие с главного экрана). Ваше приложение будет перемещено обратно, чтобы быть смешанным, когда пользователь принудительно остановит ваше приложение в Настройках. Информация о том, является ли приложение нормальным или смешанным, содержится в некотором управляемом ОС файле и (AFAIK) кэшируется в процессе ОС.

Следовательно, приложение является либо:

• Не работает (без процесса) и фыркнул
• Не работает (без процесса) и не смешивается
• Бег (имеет процесс) и не смешанный

(невозможно быть запущенным и смешанным, потому что сам процесс запуска чего-то вывел бы вас из смешанного состояния, а принудительный останов завершил бы ваш процесс)

Когда приемник не работает, система не снижает производительность.

Правильный.

Как только получатель должен получить уведомление, создается новый процесс переднего плана (если он еще не запущен), создается новый Receiver и вызывается метод onReceive.

Правильный.

После максимального времени обработки, равного 10 с, onReceive возвращается и при условии, что нет дополнительных Сервисов или Активностей, процесс хостинга, скорее всего, будет остановлен, что приведет к освобождению ресурсов.

Я бы сказал это так: "Процесс хостинга может быть уничтожен и будет относительно высоким в очереди приоритетов для уничтожения, поскольку ОС требует ОЗУ для других процессов".

Почему ОС порождает процесс для получателя, который даже не был уведомлен (и может вообще не быть уведомлен).

Это не так. Зарегистрированный манифест приложения BroadcastReceivers игнорируются

Каковы шансы включения процесса получателя в диспетчере задач?

100% во время работы процесса. 0%, когда процесс не запущен.

Это новое поведение для 3.1+, чтобы пользователь мог заметить его существование и принудительно закрыть его?

Я понятия не имею, что вы имеете в виду, когда говорите "это" и "это".

Или это нормальное поведение, когда в системе достаточно памяти, даже для ОС 2.x?

Я до сих пор понятия не имею, что вы имеете в виду, когда говорите "это".