START_STICKY et START_NOT_STICKY

Question

Quelle est la différence entre START_STICKY et START_NOT_STICKY lors de l'implémentation de services dans Android ? Quelqu'un pourrait-il m'indiquer quelques exemples standard ?

Answer 1

Les deux codes ne sont pertinents que lorsque le téléphone manque de mémoire et tue le service avant qu'il ne finisse de s'exécuter. START_STICKY indique au système d'exploitation de recréer le service lorsqu'il aura suffisamment de mémoire et d'appeler onStartCommand() encore une fois avec une intention nulle. START_NOT_STICKY indique au système d'exploitation de ne pas prendre la peine de recréer le service. Il existe également un troisième code START_REDELIVER_INTENT qui dit au système d'exploitation de recréer le service et de redonner la même intention à l'utilisateur. onStartCommand() .

Cet article de Dianne Hackborn explique le contexte bien mieux que la documentation officielle.

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

L'élément clé ici est un nouveau code de résultat renvoyé par la fonction, indiquant au système ce qu'il doit faire avec le service si son processus est tué alors qu'il est en cours d'exécution :

START_STICKY est fondamentalement le même que le comportement précédent, dans lequel le est laissé "démarré" et sera redémarré plus tard par le système. La seule différence par rapport aux versions précédentes de la plate-forme est qu'il s'il est redémarré parce que son processus est tué, onStartCommand() sera appelée sur la prochaine instance du service avec un Intent nul au lieu de ne pas être appelée du tout. Les services qui utilisent ce mode doivent toujours vérifier ce cas et le traiter de manière appropriée.

START_NOT_STICKY dit que, après le retour de onStartCreated(), si le processus est tué sans qu'il reste de commandes de démarrage à délivrer, alors le service sera arrêté au lieu d'être redémarré. Cela a beaucoup plus de sens Cela a beaucoup plus de sens pour les services qui sont destinés à ne fonctionner que lorsque l'exécution des commandes qui leur sont envoyées. Par exemple, un service peut être démarré toutes les 15 minutes à partir d'une alarme pour interroger un certain état du réseau. S'il est Si le service est tué pendant qu'il effectue ce travail, il serait préférable de le laisser s'arrêter et de le relancer la prochaine fois que l'alarme sera déclenchée. l'arrêter et le relancer au prochain déclenchement de l'alarme.

START_REDELIVER_INTENT est similaire à START_NOT_STICKY, sauf que si le service est tué avant qu'il n'appelle stopSelf() pour une intention donnée. intention donnée, cette intention lui sera re-délivrée jusqu'à ce qu'elle soit complétée (sauf si après un certain nombre d'essais supplémentaires, elle ne peut toujours pas auquel cas le système abandonne). Ceci est utile pour les services qui qui reçoivent des commandes de travail à faire, et qui veulent s'assurer qu'ils qu'ils finissent par terminer le travail pour chaque commande envoyée.

Answer 2

KISS réponse

Différence :

START_STICKY

le système va essayer de recréer votre service après qu'il ait été tué.

START_NOT_STICKY

le système pas essayez de recréer votre service après qu'il soit tué

---

Exemple standard :

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

Answer 3

La documentation pour START_STICKY et START_NOT_STICKY est assez simple.

START_STICKY :

Si le processus de ce service est tué alors qu'il est démarré (après avoir retour de onStartCommand(Intent, int, int)) alors laissez-le dans l'état l'état démarré mais ne conservez pas cette intention de livraison. Plus tard, le système essaiera de recréer le service. Comme il est dans l'état démarré il garantira l'appel à onStartCommand(Intent, int, int) après la création de l'instance du nouveau service ; s'il n'y a pas de commandes de démarrage en attente commandes de démarrage en attente à livrer au service, il sera appelé avec un objet d'intention nul. un objet d'intention nul, vous devez donc prendre soin de le vérifier.

Ce mode est utile pour les choses qui seront explicitement démarrées et explicitement démarrées et arrêtées pour s'exécuter pendant des périodes arbitraires, telles qu'un service qui lit de la musique en arrière-plan.

Exemple : Exemple de service local

START_NOT_STICKY :

Si le processus de ce service est tué alors qu'il est démarré (après avoir retour de onStartCommand(Intent, int, int)) et qu'il n'y a pas et qu'il n'y a pas de nouvelles intentions de démarrage à lui fournir, alors et ne le recrée pas avant un futur appel explicite à la commande Context.startService(Intent) . Le service ne recevra pas de onStartCommand(Intent, int, int) appel avec un null Intent car il ne sera pas relancé s'il n'y a pas d'intention à délivrer.

Ce mode est utile pour les choses qui veulent effectuer un certain travail à la suite d'avoir été démarrées, mais qui peuvent être arrêtées sous la pression de la mémoire et qui se relanceront explicitement plus tard pour faire plus de travail. Un exemple exemple d'un tel service est celui qui interroge un serveur pour obtenir des données pourrait programmer une alarme pour qu'elle interroge tous les N minutes en faisant en sorte que l'alarme démarre son service. Lorsque son onStartCommand(Intent, int, int) est est appelé depuis l'alarme, il programme une nouvelle alarme pour N minutes plus tard, et crée un thread pour faire son travail en réseau. Si son processus est tué pendant cette vérification, le service ne sera pas redémarré avant que l'alarme ne soit l'alarme se termine.

Exemple : ServiceStartArguments.java

Answer 4

• START_STICKY : Il redémarre le service s'il s'est interrompu et les données d'intention qui sont transmises à la fonction onStartCommand() La méthode est NULL . Cela convient aux services qui n'exécutent pas de commandes, mais qui fonctionnent indépendamment et attendent le travail.
• START_NOT_STICKY : Il ne redémarrera pas le service et il est utile pour les services qui seront exécutés périodiquement. Le service ne redémarrera que s'il y a une demande d'intervention en attente. startService() appels. C'est la meilleure option pour éviter de faire fonctionner un service s'il n'est pas nécessaire.
• START_REDELIVER_INTENT : C'est la même chose que STAR_STICKY et il recrée le service, appelez onStartCommand() avec la dernière intention qui a été livrée au service.