START_STICKY y START_NOT_STICKY

¿Cuál es la diferencia entre START_STICKY y START_NOT_STICKY al implementar servicios en Android? ¿Alguien podría señalar algunos ejemplos estándar …?

Ambos códigos solo son relevantes cuando el teléfono se queda sin memoria y cancela el servicio antes de que termine de ejecutarse. START_STICKY le dice al sistema operativo que vuelva a crear el servicio después de que tenga suficiente memoria y que onStartCommand() llamar a onStartCommand() con un bash nulo. START_NOT_STICKY le dice al sistema operativo que no se moleste en volver a START_NOT_STICKY el servicio. También hay un tercer código START_REDELIVER_INTENT que le dice al SO que START_REDELIVER_INTENT a crear el servicio y onStartCommand() a onStartCommand() el mismo bash a onStartCommand() .

Este artículo de Dianne Hackborn explicó los antecedentes de esto mucho mejor que la documentación oficial.

Fuente: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

La parte clave aquí es un nuevo código de resultado devuelto por la función, que le dice al sistema qué debería hacer con el servicio si el proceso se cancela mientras se está ejecutando:

START_STICKY es básicamente el mismo que el comportamiento anterior, donde el servicio se deja “iniciado” y luego será reiniciado por el sistema. La única diferencia con las versiones anteriores de la plataforma es que si se reinicia porque su proceso se cancela, onStartCommand () se invocará en la siguiente instancia del servicio con un Intento nulo en lugar de no llamarse en absoluto. Los servicios que utilizan este modo siempre deben verificar este caso y tratarlo adecuadamente.

START_NOT_STICKY dice que, después de regresar de onStartCreated (), si el proceso se cancela sin comandos de inicio restantes para entregar, entonces el servicio se detendrá en lugar de reiniciarse. Esto tiene mucho más sentido para los servicios que están destinados a ejecutarse solo mientras se ejecutan los comandos que se les envían. Por ejemplo, un servicio se puede iniciar cada 15 minutos desde una alarma para sondear un poco el estado de la red. Si se mata al hacer ese trabajo, lo mejor sería dejar que se detenga y comenzar la próxima vez que se active la alarma.

START_REDELIVER_INTENT es como START_NOT_STICKY, excepto si el proceso del servicio se cancela antes de llamar a stopSelf () para un bash determinado, ese bash se volverá a entregar hasta que se complete (a menos que después de algunos bashs más todavía no se complete, en ese punto el sistema se da por vencido). Esto es útil para los servicios que reciben comandos de trabajo por hacer, y quiere asegurarse de que eventualmente completen el trabajo para cada comando enviado.

Respuesta KISS

Diferencia:

START_STICKY

el sistema intentará volver a crear su servicio después de que se mate

START_NOT_STICKY

el sistema no intentará volver a crear su servicio después de que se mate


Ejemplo estándar:

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

La documentación de START_STICKY y START_NOT_STICKY es bastante sencilla.

START_STICKY:

Si el proceso de este servicio se onStartCommand(Intent, int, int)) mientras se inicia (luego de regresar de onStartCommand(Intent, int, int)) , déjelo en el estado de inicio pero no retenga este bash entregado. Más tarde, el sistema intentará volver a crear el servicio. Debido a que está en el estado de inicio, garantizará que se onStartCommand(Intent, int, int) después de crear la nueva instancia de servicio; si no hay comandos de inicio pendientes para entregar al servicio, se llamará con un objeto de bash nulo, por lo que debe asegurarse de verificar esto.

Este modo tiene sentido para las cosas que se iniciarán y se detendrán explícitamente durante periodos de tiempo arbitrarios, como un servicio que realiza la reproducción de música de fondo.

Ejemplo: muestra de servicio local

START_NOT_STICKY:

Si el proceso de este servicio se onStartCommand(Intent, int, int)) mientras se inicia (después de regresar de onStartCommand(Intent, int, int)) , y no hay nuevos bashs de inicio para entregarlo, saque el servicio del estado de inicio y no recree hasta una futura llamada explícita a Context.startService(Intent) . El servicio no recibirá una onStartCommand(Intent, int, int) con un Intento null porque no se reiniciará si no hay Intenciones pendientes para entregar.

Este modo tiene sentido para las cosas que quieren hacer algún trabajo como resultado de su inicio, pero se pueden detener cuando están bajo presión de memoria y se volverán a activar explícitamente más adelante para hacer más trabajo. Un ejemplo de dicho servicio sería uno que sondee los datos de un servidor: podría progtwigr una alarma para sondear cada N minutos haciendo que la alarma inicie su servicio. Cuando se onStartCommand(Intent, int, int) su onStartCommand(Intent, int, int) desde la alarma, progtwig una nueva alarma para N minutos más tarde, y genera un hilo para hacer su red. Si el proceso se cancela mientras se hace esa comprobación, el servicio no se reiniciará hasta que la alarma se apague.

Ejemplo: ServiceStartArguments.java