Un service lié est le serveur dans une interface client-serveur. Il permet aux composants tels que les activités de s'associer au service, d'envoyer des requêtes, de recevoir des réponses et d'effectuer une communication inter-processus (IPC). Un service lié ne s'exécute généralement que pendant qu'il diffuse un autre composant d'application et ne s'exécute pas indéfiniment en arrière-plan.
Ce document explique comment créer un service lié, y compris comment le lier à ce service à partir d'autres composants d'application. Pour plus d'informations sur les services en général, telles que l'envoi de notifications à partir d'un service et le paramétrage du service pour qu'il s'exécute au premier plan, consultez la Présentation des services.
Principes de base
Un service lié est une implémentation de la classe Service
qui permet à d'autres applications de s'y associer et d'interagir avec lui. Pour fournir une liaison à un service, vous devez implémenter la méthode de rappel onBind()
. Cette méthode renvoie un objet IBinder
qui définit l'interface de programmation que les clients peuvent utiliser pour interagir avec le service.
S'associer à un service démarré
Comme indiqué dans la présentation des services, vous pouvez créer un service qui est à la fois démarré et lié. Autrement dit, vous pouvez démarrer un service en appelant startService()
, ce qui permet au service de s'exécuter indéfiniment. Vous pouvez également laisser un client s'associer au service en appelant bindService()
.
Si vous laissez votre service démarrer et être lié, lorsqu'il démarre, le système ne le détruit pas lorsque tous les clients sont dissociés.
À la place, vous devez arrêter explicitement le service en appelant stopSelf()
ou stopService()
.
Bien que vous implémentez généralement onBind()
ou onStartCommand()
, il est parfois nécessaire d'implémenter les deux. Par exemple, un lecteur de musique peut trouver utile de laisser son service s'exécuter indéfiniment et de fournir une liaison. De cette façon, une activité peut démarrer le service pour lire de la musique, qui se poursuit même si l'utilisateur quitte l'application. Ensuite, lorsque l'utilisateur revient dans l'application, l'activité peut être liée au service pour reprendre le contrôle de la lecture.
Pour en savoir plus sur le cycle de vie du service lors de l'ajout d'une liaison à un service démarré, consultez la section Gérer le cycle de vie d'un service lié.
Un client se lie à un service en appelant bindService()
. Dans ce cas, il doit fournir une implémentation de ServiceConnection
, qui surveille la connexion au service. La valeur renvoyée pour bindService()
indique si le service demandé existe et si le client est autorisé à y accéder.
Lorsque le système Android crée la connexion entre le client et le service, il appelle onServiceConnected()
sur le ServiceConnection
. La méthode onServiceConnected()
inclut un argument IBinder
, que le client utilise ensuite pour communiquer avec le service lié.
Vous pouvez connecter plusieurs clients à un service simultanément. Cependant, le système met en cache le canal de communication du service IBinder
.
En d'autres termes, le système n'appelle la méthode onBind()
du service pour générer l'IBinder
que lorsque le premier client se lie. Le système transmet ensuite ce même IBinder
à tous les clients supplémentaires qui sont liés au même service, sans appeler à nouveau onBind()
.
Lorsque le dernier client se dissocie du service, le système le détruit, sauf si celui-ci a été démarré à l'aide de startService()
.
La partie la plus importante de l'implémentation de votre service lié consiste à définir l'interface renvoyée par votre méthode de rappel onBind()
. La section suivante présente plusieurs façons de définir l'interface IBinder
de votre service.
Créer un service lié
Lorsque vous créez un service qui fournit une liaison, vous devez fournir un IBinder
qui fournit l'interface de programmation que les clients peuvent utiliser pour interagir avec le service. Vous pouvez définir l'interface de trois manières:
- Étendre la classe de liaison
- Si votre service est réservé à votre propre application et s'exécute dans le même processus que le client (ce qui est courant), créez votre interface en étendant la classe
Binder
et en renvoyant une instance de celle-ci à partir deonBind()
. Le client reçoit leBinder
et peut l'utiliser pour accéder directement aux méthodes publiques disponibles dans l'implémentationBinder
ouService
.Il s'agit de la technique privilégiée lorsque votre service n'est qu'un nœud de calcul en arrière-plan pour votre propre application. Lorsqu'il ne s'agit pas de la méthode privilégiée pour créer votre interface, le service est utilisé par d'autres applications ou via des processus distincts.
- Utiliser Messenger
- Si votre interface doit fonctionner sur différents processus, vous pouvez la créer pour le service à l'aide d'un
Messenger
. De cette manière, le service définit unHandler
qui répond à différents types d'objetsMessage
.Ce
Handler
est la base d'unMessenger
qui peut ensuite partager unIBinder
avec le client, ce qui lui permet d'envoyer des commandes au service à l'aide d'objetsMessage
. De plus, le client peut définir sa propreMessenger
, afin que le service puisse renvoyer des messages.Il s'agit du moyen le plus simple d'effectuer une communication inter-processus (IPC), car
Messenger
met toutes les requêtes en file d'attente dans un seul thread. Vous n'avez donc pas à concevoir votre service de sorte qu'il soit thread-safe. - Utiliser AIDL
- Le langage AIDL (Android Interface Definition Language) décompose les objets en primitives que le système d'exploitation peut comprendre et les trie entre les processus pour effectuer l'IPC. La technique précédente, qui utilise un
Messenger
, est en fait basée sur AIDL comme structure sous-jacente.Comme indiqué dans la section précédente,
Messenger
crée une file d'attente de toutes les requêtes client dans un seul thread, de sorte que le service reçoit les requêtes une par une. Toutefois, si vous souhaitez que votre service traite plusieurs requêtes simultanément, vous pouvez utiliser directement AIDL. Dans ce cas, votre service doit être thread-safe et compatible avec le multithreading.Pour utiliser directement AIDL, créez un fichier
.aidl
qui définit l'interface de programmation. Les SDK Tools pour Android utilisent ce fichier pour générer une classe abstraite qui implémente l'interface et gère l'IPC, que vous pouvez ensuite étendre dans votre service.
Remarque:Pour la plupart des applications, AIDL n'est pas le meilleur choix pour créer un service lié, car il peut nécessiter des fonctionnalités de multithreading et entraîner une implémentation plus complexe. Par conséquent, ce document n'explique pas comment l'utiliser pour votre service. Si vous êtes certain de devoir utiliser directement AIDL, consultez le document AIDL.
Étendre la classe de liaison
Si seule l'application locale utilise votre service et qu'elle n'a pas besoin de fonctionner sur plusieurs processus, vous pouvez implémenter votre propre classe Binder
qui fournit à votre client un accès direct aux méthodes publiques du service.
Remarque:Cela ne fonctionne que si le client et le service se trouvent dans la même application et le même processus, ce qui est le plus courant. Par exemple, cela fonctionne bien pour une application musicale qui doit lier une activité à son propre service qui lit de la musique en arrière-plan.
Voici comment faire :
- Dans votre service, créez une instance de
Binder
qui effectue l'une des opérations suivantes :- Contient des méthodes publiques que le client peut appeler.
- Renvoie l'instance
Service
actuelle, qui dispose de méthodes publiques que le client peut appeler. - Renvoie une instance d'une autre classe hébergée par le service avec des méthodes publiques que le client peut appeler.
- Renvoyez cette instance de
Binder
à partir de la méthode de rappelonBind()
. - Dans le client, recevez le
Binder
à partir de la méthode de rappelonServiceConnected()
et appelez le service lié à l'aide des méthodes fournies.
Remarque:Le service et le client doivent se trouver dans la même application pour que le client puisse caster l'objet renvoyé et appeler correctement ses API. Le service et le client doivent également être dans le même processus, car cette technique n'effectue pas de séparation entre les processus.
Par exemple, voici un service qui permet aux clients d'accéder à ses méthodes via une implémentation Binder
:
Kotlin
class LocalService : Service() { // Binder given to clients. private val binder = LocalBinder() // Random number generator. private val mGenerator = Random() /** Method for clients. */ val randomNumber: Int get() = mGenerator.nextInt(100) /** * Class used for the client Binder. Because we know this service always * runs in the same process as its clients, we don't need to deal with IPC. */ inner class LocalBinder : Binder() { // Return this instance of LocalService so clients can call public methods. fun getService(): LocalService = this@LocalService } override fun onBind(intent: Intent): IBinder { return binder } }
Java
public class LocalService extends Service { // Binder given to clients. private final IBinder binder = new LocalBinder(); // Random number generator. private final Random mGenerator = new Random(); /** * Class used for the client Binder. Because we know this service always * runs in the same process as its clients, we don't need to deal with IPC. */ public class LocalBinder extends Binder { LocalService getService() { // Return this instance of LocalService so clients can call public methods. return LocalService.this; } } @Override public IBinder onBind(Intent intent) { return binder; } /** Method for clients. */ public int getRandomNumber() { return mGenerator.nextInt(100); } }
LocalBinder
fournit la méthode getService()
pour que les clients récupèrent l'instance actuelle de LocalService
. Cela permet aux clients d'appeler des méthodes publiques dans le service. Par exemple, les clients peuvent appeler getRandomNumber()
à partir du service.
Voici une activité qui est liée à LocalService
et appelle getRandomNumber()
lorsqu'un utilisateur clique sur un bouton:
Kotlin
class BindingActivity : Activity() { private lateinit var mService: LocalService private var mBound: Boolean = false /** Defines callbacks for service binding, passed to bindService(). */ private val connection = object : ServiceConnection { override fun onServiceConnected(className: ComponentName, service: IBinder) { // We've bound to LocalService, cast the IBinder and get LocalService instance. val binder = service as LocalService.LocalBinder mService = binder.getService() mBound = true } override fun onServiceDisconnected(arg0: ComponentName) { mBound = false } } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.main) } override fun onStart() { super.onStart() // Bind to LocalService. Intent(this, LocalService::class.java).also { intent -> bindService(intent, connection, Context.BIND_AUTO_CREATE) } } override fun onStop() { super.onStop() unbindService(connection) mBound = false } /** Called when a button is clicked (the button in the layout file attaches to * this method with the android:onClick attribute). */ fun onButtonClick(v: View) { if (mBound) { // Call a method from the LocalService. // However, if this call is something that might hang, then put this request // in a separate thread to avoid slowing down the activity performance. val num: Int = mService.randomNumber Toast.makeText(this, "number: $num", Toast.LENGTH_SHORT).show() } } }
Java
public class BindingActivity extends Activity { LocalService mService; boolean mBound = false; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); } @Override protected void onStart() { super.onStart(); // Bind to LocalService. Intent intent = new Intent(this, LocalService.class); bindService(intent, connection, Context.BIND_AUTO_CREATE); } @Override protected void onStop() { super.onStop(); unbindService(connection); mBound = false; } /** Called when a button is clicked (the button in the layout file attaches to * this method with the android:onClick attribute). */ public void onButtonClick(View v) { if (mBound) { // Call a method from the LocalService. // However, if this call is something that might hang, then put this request // in a separate thread to avoid slowing down the activity performance. int num = mService.getRandomNumber(); Toast.makeText(this, "number: " + num, Toast.LENGTH_SHORT).show(); } } /** Defines callbacks for service binding, passed to bindService(). */ private ServiceConnection connection = new ServiceConnection() { @Override public void onServiceConnected(ComponentName className, IBinder service) { // We've bound to LocalService, cast the IBinder and get LocalService instance. LocalBinder binder = (LocalBinder) service; mService = binder.getService(); mBound = true; } @Override public void onServiceDisconnected(ComponentName arg0) { mBound = false; } }; }
L'exemple précédent montre comment le client se lie au service à l'aide d'une implémentation de ServiceConnection
et du rappel onServiceConnected()
. La section suivante fournit des informations supplémentaires sur ce processus de liaison au service.
Remarque:Dans l'exemple précédent, la méthode onStop()
dissocie le client du service.
Dissociez les clients des services aux moments opportuns, comme indiqué dans la section Remarques supplémentaires.
Pour plus d'exemples de code, consultez les classes
LocalService.java
et
LocalServiceActivities.java
dans ApiDemos.
Utiliser Chat +
Si vous avez besoin que votre service communique avec des processus distants, vous pouvez utiliser un Messenger
pour fournir l'interface de votre service. Cette technique vous permet d'effectuer une communication inter-processus (IPC) sans avoir besoin d'utiliser AIDL.
Il est plus simple d'utiliser un Messenger
pour votre interface qu'AIDL, car Messenger
met tous les appels au service en file d'attente. Une interface AIDL pure envoie des requêtes simultanées au service, qui doit ensuite gérer le multithreading.
Pour la plupart des applications, le service n'a pas besoin d'effectuer le multithreading. L'utilisation d'un Messenger
lui permet donc de gérer un appel à la fois. S'il est important que votre service soit multithread, utilisez AIDL pour définir votre interface.
Voici un résumé de l'utilisation d'un Messenger
:
- Le service implémente un
Handler
qui reçoit un rappel pour chaque appel d'un client. - Le service utilise
Handler
pour créer un objetMessenger
(qui est une référence àHandler
). Messenger
crée unIBinder
que le service renvoie aux clients à partir deonBind()
.- Les clients utilisent
IBinder
pour instancier leMessenger
(qui fait référence auHandler
du service), que le client utilise pour envoyer des objetsMessage
au service. - Le service reçoit chaque
Message
dans sonHandler
, plus précisément dans la méthodehandleMessage()
.
Ainsi, le client n'a aucune méthode à appeler sur le service. À la place, le client distribue les messages (objets Message
) que le service reçoit dans son Handler
.
Voici un exemple de service simple qui utilise une interface Messenger
:
Kotlin
/** Command to the service to display a message. */ private const val MSG_SAY_HELLO = 1 class MessengerService : Service() { /** * Target we publish for clients to send messages to IncomingHandler. */ private lateinit var mMessenger: Messenger /** * Handler of incoming messages from clients. */ internal class IncomingHandler( context: Context, private val applicationContext: Context = context.applicationContext ) : Handler() { override fun handleMessage(msg: Message) { when (msg.what) { MSG_SAY_HELLO -> Toast.makeText(applicationContext, "hello!", Toast.LENGTH_SHORT).show() else -> super.handleMessage(msg) } } } /** * When binding to the service, we return an interface to our messenger * for sending messages to the service. */ override fun onBind(intent: Intent): IBinder? { Toast.makeText(applicationContext, "binding", Toast.LENGTH_SHORT).show() mMessenger = Messenger(IncomingHandler(this)) return mMessenger.binder } }
Java
public class MessengerService extends Service { /** * Command to the service to display a message. */ static final int MSG_SAY_HELLO = 1; /** * Handler of incoming messages from clients. */ static class IncomingHandler extends Handler { private Context applicationContext; IncomingHandler(Context context) { applicationContext = context.getApplicationContext(); } @Override public void handleMessage(Message msg) { switch (msg.what) { case MSG_SAY_HELLO: Toast.makeText(applicationContext, "hello!", Toast.LENGTH_SHORT).show(); break; default: super.handleMessage(msg); } } } /** * Target we publish for clients to send messages to IncomingHandler. */ Messenger mMessenger; /** * When binding to the service, we return an interface to our messenger * for sending messages to the service. */ @Override public IBinder onBind(Intent intent) { Toast.makeText(getApplicationContext(), "binding", Toast.LENGTH_SHORT).show(); mMessenger = new Messenger(new IncomingHandler(this)); return mMessenger.getBinder(); } }
La méthode handleMessage()
dans Handler
permet au service de recevoir le Message
entrant et de décider de ce qu'il doit faire en fonction du membre what
.
Il suffit au client de créer un Messenger
basé sur le IBinder
renvoyé par le service et d'envoyer un message à l'aide de send()
. Par exemple, voici une activité qui se lie au service et envoie le message MSG_SAY_HELLO
au service:
Kotlin
class ActivityMessenger : Activity() { /** Messenger for communicating with the service. */ private var mService: Messenger? = null /** Flag indicating whether we have called bind on the service. */ private var bound: Boolean = false /** * Class for interacting with the main interface of the service. */ private val mConnection = object : ServiceConnection { override fun onServiceConnected(className: ComponentName, service: IBinder) { // This is called when the connection with the service has been // established, giving us the object we can use to // interact with the service. We are communicating with the // service using a Messenger, so here we get a client-side // representation of that from the raw IBinder object. mService = Messenger(service) bound = true } override fun onServiceDisconnected(className: ComponentName) { // This is called when the connection with the service has been // unexpectedly disconnected—that is, its process crashed. mService = null bound = false } } fun sayHello(v: View) { if (!bound) return // Create and send a message to the service, using a supported 'what' value. val msg: Message = Message.obtain(null, MSG_SAY_HELLO, 0, 0) try { mService?.send(msg) } catch (e: RemoteException) { e.printStackTrace() } } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.main) } override fun onStart() { super.onStart() // Bind to the service. Intent(this, MessengerService::class.java).also { intent -> bindService(intent, mConnection, Context.BIND_AUTO_CREATE) } } override fun onStop() { super.onStop() // Unbind from the service. if (bound) { unbindService(mConnection) bound = false } } }
Java
public class ActivityMessenger extends Activity { /** Messenger for communicating with the service. */ Messenger mService = null; /** Flag indicating whether we have called bind on the service. */ boolean bound; /** * Class for interacting with the main interface of the service. */ private ServiceConnection mConnection = new ServiceConnection() { public void onServiceConnected(ComponentName className, IBinder service) { // This is called when the connection with the service has been // established, giving us the object we can use to // interact with the service. We are communicating with the // service using a Messenger, so here we get a client-side // representation of that from the raw IBinder object. mService = new Messenger(service); bound = true; } public void onServiceDisconnected(ComponentName className) { // This is called when the connection with the service has been // unexpectedly disconnected—that is, its process crashed. mService = null; bound = false; } }; public void sayHello(View v) { if (!bound) return; // Create and send a message to the service, using a supported 'what' value. Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0); try { mService.send(msg); } catch (RemoteException e) { e.printStackTrace(); } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); } @Override protected void onStart() { super.onStart(); // Bind to the service. bindService(new Intent(this, MessengerService.class), mConnection, Context.BIND_AUTO_CREATE); } @Override protected void onStop() { super.onStop(); // Unbind from the service. if (bound) { unbindService(mConnection); bound = false; } } }
Cet exemple ne montre pas comment le service peut répondre au client.
Si vous souhaitez que le service réponde, vous devez également créer un Messenger
dans le client.
Lorsque le client reçoit le rappel onServiceConnected()
, il envoie un Message
au service, qui inclut l'Messenger
du client dans le paramètre replyTo
de la méthode send()
.
Vous trouverez un exemple de communication bidirectionnelle dans les exemples
MessengerService.java
(service) et
MessengerServiceActivities.java
(client).
S'associer à un service
Les composants d'application (clients) peuvent être liés à un service en appelant bindService()
. Le système Android appelle ensuite la méthode onBind()
du service, qui renvoie un IBinder
pour interagir avec le service.
La liaison est asynchrone, et bindService()
renvoie immédiatement un résultat sans renvoyer le IBinder
au client. Pour recevoir le IBinder
, le client doit créer une instance de ServiceConnection
et la transmettre à bindService()
. ServiceConnection
inclut une méthode de rappel que le système appelle pour transmettre le IBinder
.
Remarque:Seuls les activités, les services et les fournisseurs de contenu peuvent être liés à un service. Vous ne pouvez pas établir de lien avec un service à partir d'un broadcast receiver.
Pour créer une liaison avec un service à partir de votre client, procédez comme suit:
- Implémentez
ServiceConnection
.Votre implémentation doit remplacer deux méthodes de rappel:
onServiceConnected()
- Le système appelle cette méthode pour diffuser le
IBinder
renvoyé par la méthodeonBind()
du service. onServiceDisconnected()
- Le système Android appelle cela lorsque la connexion au service est perdue de manière inattendue, par exemple lorsque le service plante ou est arrêté. Elle n'est pas appelée lorsque le client se dissocie.
- Appelez
bindService()
en transmettant l'implémentation deServiceConnection
.Remarque:Si la méthode renvoie la valeur "false", votre client ne dispose pas d'une connexion valide au service. Toutefois, appelez
unbindService()
dans votre client. Sinon, votre client empêche le service de s'arrêter lorsqu'il est inactif. - Lorsque le système appelle votre méthode de rappel
onServiceConnected()
, vous pouvez commencer à appeler le service à l'aide des méthodes définies par l'interface. - Pour vous déconnecter du service, appelez
unbindService()
.Si votre client est toujours lié à un service lorsque votre application le détruit, la destruction entraîne la dissociation du client. Il est recommandé d'annuler la liaison du client dès qu'il a fini d'interagir avec le service. Cela permet d'arrêter le service inactif. Pour en savoir plus sur les moments appropriés pour lier et annuler la liaison, consultez la section Remarques supplémentaires.
L'exemple suivant connecte le client au service créé précédemment en étendant la classe de liaison. Il lui suffit donc de caster le IBinder
renvoyé sur la classe LocalBinder
et de demander l'instance LocalService
:
Kotlin
var mService: LocalService val mConnection = object : ServiceConnection { // Called when the connection with the service is established. override fun onServiceConnected(className: ComponentName, service: IBinder) { // Because we have bound to an explicit // service that is running in our own process, we can // cast its IBinder to a concrete class and directly access it. val binder = service as LocalService.LocalBinder mService = binder.getService() mBound = true } // Called when the connection with the service disconnects unexpectedly. override fun onServiceDisconnected(className: ComponentName) { Log.e(TAG, "onServiceDisconnected") mBound = false } }
Java
LocalService mService; private ServiceConnection mConnection = new ServiceConnection() { // Called when the connection with the service is established. public void onServiceConnected(ComponentName className, IBinder service) { // Because we have bound to an explicit // service that is running in our own process, we can // cast its IBinder to a concrete class and directly access it. LocalBinder binder = (LocalBinder) service; mService = binder.getService(); mBound = true; } // Called when the connection with the service disconnects unexpectedly. public void onServiceDisconnected(ComponentName className) { Log.e(TAG, "onServiceDisconnected"); mBound = false; } };
Avec ce ServiceConnection
, le client peut s'associer à un service en le transmettant à bindService()
, comme illustré dans l'exemple suivant:
Kotlin
Intent(this, LocalService::class.java).also { intent -> bindService(intent, connection, Context.BIND_AUTO_CREATE) }
Java
Intent intent = new Intent(this, LocalService.class); bindService(intent, connection, Context.BIND_AUTO_CREATE);
- Le premier paramètre de
bindService()
est unIntent
qui nomme explicitement le service à lier.Attention:Si vous utilisez un intent pour créer une liaison à un
Service
, assurez-vous que votre application est sécurisée à l'aide d'un intent explicite. L'utilisation d'un intent implicite pour démarrer un service représente un risque de sécurité, car vous ne pouvez pas savoir avec certitude quel service répond à l'intent, et l'utilisateur ne peut pas voir quel service démarre. À partir d'Android 5.0 (niveau d'API 21), le système génère une exception si vous appelezbindService()
avec un intent implicite. - Le deuxième paramètre est l'objet
ServiceConnection
. - Le troisième paramètre est un indicateur spécifiant des options pour la liaison (généralement
BIND_AUTO_CREATE
) permettant de créer le service s'il n'est pas déjà actif. Les autres valeurs possibles sontBIND_DEBUG_UNBIND
,BIND_NOT_FOREGROUND
ou0
, pour aucune.
Remarques supplémentaires
Voici quelques remarques importantes sur la liaison à un service:
- Toujours intercepter les exceptions
DeadObjectException
, qui sont générées lorsque la connexion est interrompue. Il s'agit de la seule exception générée par les méthodes distantes. - Les objets sont des références comptées d'un processus à l'autre.
- Vous devez généralement associer la liaison et la dissociation au cours des moments de mise en correspondance et de suppression du cycle de vie du client, comme décrit dans les exemples suivants :
- Si vous devez interagir avec le service uniquement lorsque votre activité est visible, effectuez une liaison pendant
onStart()
et annulez la liaison pendantonStop()
. - Si vous souhaitez que votre activité reçoive des réponses même lorsqu'elle est arrêtée en arrière-plan, associez-la pendant
onCreate()
et dissociez-la pendantonDestroy()
. Notez que cela implique que votre activité doit utiliser le service pendant tout le temps d'exécution, même en arrière-plan. Par conséquent, lorsque le service se trouve dans un autre processus, vous augmentez la pondération du processus et il est plus susceptible d'être supprimé par le système.
Remarque:En général, vous n'effectuez pas de liaison ni de dissociation lors des rappels
onResume()
etonPause()
de votre activité, car ces rappels se produisent à chaque transition de cycle de vie. Réduisez le plus possible le traitement effectué lors de ces transitions.De plus, si plusieurs activités de votre application sont liées au même service et qu'il existe une transition entre deux de ces activités, le service peut être détruit et recréé lorsque l'activité actuelle se dissocie (lors de la pause) avant que la suivante soit liée (lors de la reprise). Cette transition concernant la manière dont les activités coordonnent leur cycle de vie est décrite dans la section Cycle de vie d'une activité.
- Si vous devez interagir avec le service uniquement lorsque votre activité est visible, effectuez une liaison pendant
Pour plus d'exemples de code montrant comment créer une liaison à un service, consultez la classe
RemoteService.java
dans ApiDemos.
Gérer le cycle de vie d'un service lié
Lorsqu'un service est dissocié de tous les clients, le système Android le détruit (sauf s'il a été démarré à l'aide de startService()
). Vous n'avez donc pas à gérer le cycle de vie de votre service s'il s'agit purement d'un service lié. Le système Android le gère pour vous selon qu'il est lié à un client ou non.
Toutefois, si vous choisissez d'implémenter la méthode de rappel onStartCommand()
, vous devez explicitement arrêter le service, car il est désormais considéré comme démarré. Dans ce cas, le service s'exécute jusqu'à ce qu'il s'arrête avec stopSelf()
ou un autre composant appelle stopService()
, qu'il soit lié ou non à des clients.
De plus, si votre service est démarré et accepte la liaison, lorsque le système appelle votre méthode onUnbind()
, vous pouvez éventuellement renvoyer true
si vous souhaitez recevoir un appel à onRebind()
la prochaine fois qu'un client se liera au service. onRebind()
renvoie la valeur "void", mais le client reçoit toujours le IBinder
dans son rappel onServiceConnected()
.
La figure suivante illustre la logique pour ce type de cycle de vie.
![](https://developer.android.com/static/images/fundamentals/service_binding_tree_lifecycle.png?authuser=5&hl=fr)
Figure 1 : Cycle de vie d'un service qui est démarré et autorise également la liaison.
Pour en savoir plus sur le cycle de vie d'un service démarré, consultez la Présentation des services.