START_STICKY и START_NOT_STICKY

В чем разница между START_STICKY и START_NOT_STICKY при внедрении сервисов в android? Может ли кто-нибудь указать на некоторые стандартные примеры.?

ОТВЕТЫ

Ответ 1

Оба кода применимы только в том случае, если у телефона заканчивается память, и он убивает службу до того, как она закончит выполнение. 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() для данного намерение, это намерение будет передано ему до тех пор, пока оно не завершится (если после некоторого количества других попыток оно все еще не может быть завершено, что указывает на то, что система отказывается). Это полезно для служб, которые получать команды работы и делать это в конечном итоге завершить работу для каждой отправленной команды.

Ответ 2

KISS answer

Difference:

START_STICKY

система попытается воссоздать вашу службу после ее убийства

START_NOT_STICKY

система будет не пытаться воссоздать вашу службу после ее убийства

Стандартный пример:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_STICKY;
}

Ответ 3

Документация для START_STICKY и START_NOT_STICKY довольно проста.

START_STICKY:

Если этот сервисный процесс убит во время его запуска (после возвращаясь из onStartCommand(Intent, int, int)), затем оставьте его в начальное состояние, но не сохраняют это поставленное намерение. Позже система попытается воссоздать службу. Потому что он находится в запущенном состоянии, он будет называть onStartCommand(Intent, int, int)после создания нового экземпляра службы; если нет ожидающих запуск команд, которые будут доставлены в службу, он будет вызываться с объект нулевого намерения, поэтому вы должны позаботиться об этом.

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

Пример: Пример локальной службы

START_NOT_STICKY:

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

Этот режим имеет смысл для вещей, которые хотят сделать какую-то работу в результате от запуска, но может быть остановлен, когда под давлением памяти и явным образом начнут себя снова позже, чтобы сделать больше работы. Пример такой услуги будет использоваться для опроса данных с сервера: может запрограммировать будильник для опроса каждые N минуты, имея сигнал тревоги начать его обслуживание. Когда его onStartCommand(Intent, int, int)вызванный из тревоги, он планирует новый сигнал тревоги на N минут позже, и создает поток для создания своей сети. Если его процесс убит при выполнении этой проверки служба не будет перезапущена, пока будильник отключается.

Пример: ServiceStartArguments.java

Ответ 4

Наиболее распространенные значения повторного запуска определяются следующими статическими полями службы:

  • START_STICKY: Если процесс Сервиса завершен системой, Служба будет перезапущен, и никакие обработанные намерения не будут доставлены в onStartCommand. Если начальные намерения не ожидаются для доставки, null Intent передается функции onStartCommand. Если запрос на запуск не был вернуться до того, как система убивает Службу, запрос на запуск снова отправляется на перезапущенном прохождении службы START_FLAG_RETRY на onStartCommand второй аргумент.
  • START_NOT_STICKY: Если Служба завершена системой, Служба перезапускается только тогда, когда есть хотя бы один ожидающий запрос на запуск доставлено.
  • START_REDELIVER_INTENT: Если служба завершена системой, Служба будет перезапущена, повторив последнее заданное начало и любое Ожидающие запросы. Этот вид сервиса похож на START_STICKY, но вместо этого предоставления нулевого намерения в стартовой команде, последний успешно доставленный Направление отправлено. Когда запрос на запуск повторно добавлен, флаг START_ FLAG_REDELIVERY передается во втором аргументе onStartCommand.

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

Ответ 5

START_STICKY используется для служб, которые явно запускаются и останавливаются по мере необходимости, тогда как START_NOT_STICKY или START_REDELIVER_INTENT используются для служб, которые должны оставаться только при обработке любых команд, отправленных им.