START_STICKY y START_NOT_STICKY

¿Cuál es la diferencia entre START_STICKY y START_NOT_STICKY al implementar servicios en android? ¿Podría alguien señalar algunos ejemplos estándar ..?

Ambos códigos sólo son relevantes cuando el teléfono se queda sin memoria y elimina el servicio antes de que finalice la ejecución. START_STICKY le dice al sistema operativo que vuelva a crear el servicio después de que haya suficiente memoria y que llame a onStartCommand() nuevo con una intención nula. 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 sistema operativo que START_REDELIVER_INTENT a crear el servicio y redirigir la misma intención a onStartCommand() .

Este artículo de Dianne Hackborn explicó el fondo 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, diciéndole al sistema qué debe hacer con el servicio si su proceso se destruye mientras se está ejecutando:

START_STICKY es básicamente el mismo que el comportamiento anterior, en el que el servicio se deja "iniciado" y será reiniciado más tarde por el sistema. La única diferencia con respecto a versiones anteriores de la plataforma es que si se reinicia porque su proceso se destruye, onStartCommand () será llamado en la siguiente instancia del servicio con un intento nulo en lugar de no ser llamado en absoluto. Los servicios que utilizan este modo siempre deben comprobar este caso y tratar con él apropiadamente.

START_NOT_STICKY dice que, después de regresar de onStartCreated (), si el proceso se destruye sin comandos de inicio restantes para entregar, el servicio se detendrá en lugar de reiniciarse. Esto tiene mucho más sentido para los servicios que están destinados a ejecutarse sólo al ejecutar comandos enviados a ellos. Por ejemplo, un servicio puede iniciarse cada 15 minutos desde una alarma para consultar algún estado de la red. Si se mata mientras se hace ese trabajo, lo mejor sería dejar que se detuviera y empezar la próxima vez que se disparara la alarma.

START_REDELIVER_INTENT es como START_NOT_STICKY, excepto si el proceso del servicio se cancela antes de llamar a stopSelf () para una intención dada, esa intención se re-entregará a ella hasta que finalice (a menos que después de algunos intentos adicionales todavía no pueda completarse, Momento en el que el sistema abandona). Esto es útil para los servicios que están recibiendo órdenes de trabajo que hacer y desea asegurarse de que eventualmente completen el trabajo para cada comando enviado.

Respuesta de KISS

Diferencia:

START_STICKY

El sistema intentará volver a crear su servicio después de que se haya matado

START_NOT_STICKY

El sistema no intentará volver a crear su servicio después de que se muera


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 (después de regresar de onStartCommand(Intent, int, int)) , déjelo en el estado iniciado pero no retenga esta intención entregada. Posteriormente, el sistema intentará volver a crear el servicio. Debido a que está en el estado iniciado, garantizará llamar a onStartCommand(Intent, int, int) después de crear la nueva instancia de servicio; Si no hay ningún comando de inicio pendiente que se entregue al servicio, se llamará con un objeto de intención nula, por lo que debe tener cuidado para comprobarlo.

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

Ejemplo: Ejemplo 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 nuevas intenciones de inicio para entregar a él, a continuación, sacar el servicio del estado iniciado y no volver a crear 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 intentos pendientes de entregar.

Este modo tiene sentido para las cosas que quieren hacer algún trabajo como resultado de ser iniciado, pero se puede detener cuando bajo presión de memoria y se explícita empezar de nuevo más tarde para hacer más trabajo. Un ejemplo de un servicio de este tipo sería una encuesta de datos de un servidor: podría programar una alarma para hacer sondeos cada N minutos haciendo que la alarma inicie su servicio. Cuando su onStartCommand(Intent, int, int) es llamado desde la alarma, programa una alarma nueva durante N minutos más tarde, y genera un hilo para hacer su conexión en red. Si el proceso se elimina mientras realiza esa comprobación, el servicio no se reiniciará hasta que se active la alarma.

Ejemplo: ServiceStartArguments.java

Los valores int de reinicio más comunes se definen mediante los siguientes campos estáticos de Servicio:

  • START_STICKY: Si el sistema interrumpe el proceso de servicio, se va a reiniciar el servicio y no se entregarán intents procesados ​​a la función onStartCommand . Cuando no hay intentos de inicio pendientes para la entrega, se pasa un intento nulo a la función onStartCommand . Si no se devuelve una solicitud de inicio antes de que el sistema mate el Servicio, la solicitud de inicio se envía de nuevo en el Servicio reiniciado que pasa START_FLAG_RETRY en el segundo argumento onStartCommand .
  • START_NOT_STICKY: Si el servicio termina el servicio, el servicio sólo se reinicia cuando hay al menos una solicitud de inicio pendiente que se va a entregar.
  • START_REDELIVER_INTENT: Si el servicio termina el servicio, el servicio se reiniciará reenviando la última solicitud de inicio entregada y las solicitudes pendientes. Este tipo de servicio es similar a START_STICKY , pero en lugar de entregar un intento nulo en el comando de inicio, se envía el último intento entregado con éxito. Cuando se devuelve la solicitud de inicio, el indicador START_ FLAG_REDELIVERY se transmite en el segundo argumento onStartCommand .

El onStartCommand , que se ejecuta en el Thread principal, es el punto de entrada para su servicio, por lo que en los casos en que ejecuta operaciones largas en su Servicio, el flujo de su operación en un hilo de fondo es imprescindible para mantener la respuesta de su aplicación a niveles soportables .

  • No se puede solucionar la excepción MediaController.show ()
  • Androide broadcastreceiver vs oyentes
  • ¿Puede iniciar un IntentService en un proceso separado?
  • Aplicación de Android como servicio sin actividad
  • ¿Está garantizado un servicio android para llamar a onDestroy ()?
  • AVD no se está ejecutando
  • Cómo detener un servicio de Android desde un hilo
  • Suscripción o vinculación a un servicio de Intent existente
  • ¿Cómo mantener un servicio ejecutándose en segundo plano incluso después de que el usuario abandone la aplicación?
  • Cómo configurar el permiso WRITE_SECURE_SETTINGS en android?
  • Android: startActivityForResult no llamando aActivityResult
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.