Что такое START_STICKY, START_NOT_STICKY и START_REDELIVER_INTENT Сервис

Ответ 1

Они связаны с услугами. Мы все знаем, что службы продолжают работать в фоновом режиме, и они также потребляют некоторую память для выполнения.

Итак, поскольку больше приложений работает на устройстве Android, память устройства продолжает снижаться, и когда наступает время, когда память устройства становится критически низкой, система андроида начинает завершать процессы, чтобы освободить занятую память процессами.

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

Простейшим объяснением этого может быть,

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

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

START_REDELIVER_INTENT- сообщает системе перезапустить службу после сбоя, а также повторно обновить намерения, которые присутствовали во время сбоя.

Ответ 2

Ну, я прочитал нить в вашей ссылке, и она говорит все это.

если ваша служба была убита Android из-за низкой памяти, а Android очищает некоторую память, затем...

• STICKY:... Android перезапустит вашу службу, потому что этот особый флаг установлен.
• NOT_STICKY:... Android не будет заботиться о том, чтобы начать снова, потому что флаг сообщает Android, что он не должен беспокоить.
• REDELIVER_INTENT:... Android перезапустит службу и повторно отправит то же самое намерение на onStartCommand() службы, потому что снова флаг.

Ответ 3

Оба кода применимы только в том случае, если у телефона заканчивается память, и он убивает службу до того, как она закончит выполнение. START_STICKY сообщает ОС, чтобы воссоздать службу после того, как у нее достаточно памяти, и снова вызовите onStartCommand() с нулевым намерением. START_NOT_STICKY сообщает операционной системе, чтобы не беспокоиться о повторном воссоздании службы. Существует также третий код START_REDELIVER_INTENT, который сообщает ОС о воссоздании службы и повторной доставке того же намерения в onStartCommand().

Эта статья Dianne Hackborn объяснила это намного лучше, чем официальная документация.

Источник: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

Ключевой частью здесь является новый результирующий код, возвращаемый функцией, сообщающий системе, что он должен делать с сервисом, если его процесс убит во время его запуска:

START_STICKY в основном совпадает с предыдущим поведением, сервис остается "запущенным" и позже будет перезапущен системой. Единственное отличие от предыдущих версий платформы заключается в том, что она если он перезапускается, потому что его процесс убит, onStartCommand() будет вызываться в следующем экземпляре службы с нулевым намерением вместо того, чтобы вообще незываться. Службы, которые используют этот режим, должны всегда проверяйте этот случай и относитесь к нему соответствующим образом.

START_NOT_STICKY говорит, что после возвращения из onStartCreated(), если процесс уничтожается без оставшихся команд запуска для доставки, то служба будет остановлена ​​вместо перезапуска. Это делает больше смысла для сервисов, которые предназначены только для запуска выполнение команд, отправленных им. Например, может быть запущена услуга каждые 15 минут от тревоги, чтобы опросить некоторое состояние сети. Если он убил, выполняя эту работу, было бы лучше всего позволить остановится и начнется в следующий раз, когда срабатывает будильник.

START_REDELIVER_INTENT похож на START_NOT_STICKY, за исключением случаев, когда сервисный процесс убит до того, как он называет stopSelf() для данного намерение, это намерение будет передано ему до тех пор, пока оно не завершится (если после некоторого количества других попыток оно все еще не может быть завершено, что указывает на то, что система отказывается). Это полезно для служб, которые получать команды работы и делать это в конечном итоге завершить работу для каждой отправленной команды.