Intereting Posts

START_STICKY и START_NOT_STICKY

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

Solutions Collecting From Web of "START_STICKY и START_NOT_STICKY"

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

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

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

Ответ KISS

Разница:

START_STICKY

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

START_NOT_STICKY

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


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

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

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

START_STICKY:

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

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

Пример: пример местной службы

START_NOT_STICKY:

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

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

Пример: ServiceStartArguments.java

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

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

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