Suivre les bonnes pratiques concernant les wake locks
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
L'utilisation d'un wakelock peut nuire aux performances de l'appareil. Si vous devez utiliser un verrouillage de réveil, il est important de le faire correctement. Ce document présente quelques bonnes pratiques qui peuvent vous aider à éviter les pièges courants liés aux wake locks.
Nommez correctement le wakelock
Nous vous recommandons d'inclure le nom du package, de la classe ou de la méthode dans la balise de wakelock. Ainsi, en cas d'erreur, il est plus facile de trouver l'emplacement dans votre code source où le verrouillage de réveil a été créé. Voici quelques conseils supplémentaires :
N'indiquez aucune information permettant d'identifier personnellement l'utilisateur dans le nom, comme une adresse e-mail. Si l'appareil détecte des informations permettant d'identifier personnellement l'utilisateur dans le tag de wakelock, il enregistre _UNKNOWN au lieu du tag que vous avez spécifié.
N'obtenez pas le nom de la classe ou de la méthode par programmation, par exemple en appelant getName(). Si vous essayez d'obtenir le nom par programmation, il peut être obscurci par des outils tels que Proguard. Utilisez plutôt une chaîne codée en dur.
N'ajoutez pas de compteur ni d'identifiants uniques pour réactiver les balises de wakelock. Le code qui crée un verrouillage de réveil doit utiliser le même tag chaque fois qu'il s'exécute.
Cette pratique permet au système d'agréger l'utilisation du verrouillage de réveil de chaque méthode.
Assurez-vous que votre application est visible au premier plan.
Lorsqu'un verrouillage de réveil est actif, l'appareil consomme de l'énergie. L'utilisateur de l'appareil doit être informé de ce qui se passe. Pour cette raison, si vous utilisez un wakelock, vous devez afficher une notification à l'utilisateur.
En pratique, cela signifie que vous devez obtenir et conserver le wakelock dans un service de premier plan. Les services de premier plan doivent afficher une notification.
Si un service de premier plan n'est pas le bon choix pour votre application, vous ne devriez probablement pas non plus utiliser de verrouillage de réveil. Consultez la documentation Choisir la bonne API pour maintenir l'appareil en éveil pour découvrir d'autres façons d'effectuer des tâches lorsque votre application n'est pas au premier plan.
Simplifiez la logique
Assurez-vous que la logique d'acquisition et de libération des wakelocks est aussi simple que possible. Lorsque votre logique de wakelock est liée à des machines d'état, à des délais d'exécution, à des pools d'exécuteurs ou à des événements de rappel complexes, tout bug subtil dans cette logique peut entraîner le blocage du wakelock plus longtemps que prévu. Ces bugs sont difficiles à diagnostiquer et à déboguer.
Vérifiez que le wakelock est toujours libéré.
Si vous utilisez un wakelock, vous devez vous assurer que chaque wakelock que vous acquérez est correctement libéré. Ce n'est pas toujours aussi simple qu'il y paraît. Par exemple, le code suivant pose problème :
Kotlin
@Throws(MyException::class)fundoSomethingAndRelease(){wakeLock.apply{acquire()doTheWork()// can potentially throw MyExceptionrelease()// does not run if an exception is thrown}}
Java
voiddoSomethingAndRelease()throwsMyException{wakeLock.acquire();doTheWork();// can potentially throw MyExceptionwakeLock.release();// does not run if an exception is thrown}
Le problème ici est que la méthode doTheWork() peut générer l'exception MyException. Si c'est le cas, la méthode doSomethingAndRelease() propage l'exception vers l'extérieur, et elle n'atteint jamais l'appel release(). Le résultat est que le verrouillage de l'écran est acquis, mais pas libéré, ce qui est très mauvais.
Dans le code corrigé, doSomethingAndRelease() s'assure de libérer le verrouillage de réveil même si une exception est générée :
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/27 (UTC)."],[],[],null,["Using a wake lock can impair device performance. If you need to use a wake\nlock, it's important to do it properly. This document covers some best practices\nthat can help you avoid common wake lock pitfalls.\n| **Note:** Creating and holding wake locks can have a dramatic impact on the device's battery life. You shouldn't use wake locks if there are any suitable alternatives. For other options, see the [Keep the device awake](/develop/background-work/background-tasks/awake) documentation. If you do need to use a wake lock, make sure to hold it for as short a time as possible.\n\nName the wake lock properly\n\nWe recommend including your package, class, or method name in the wakelock\ntag. That way, if an error occurs, it's easier to find the location in your\nsource code where the wake lock was created. Here are some additional tips:\n\n- Leave out any personally identifying information (PII) in the name, such as an email address. If the device detects PII in the wake lock tag, it logs `_UNKNOWN` instead of the tag you specified.\n- Don't get the class or method name programmatically, for example by calling `getName()`. If you try to get the name programmatically, it might get obfuscated by tools like Proguard. Instead use a hard-coded string.\n- Don't add a counter or unique identifiers to wake lock tags. The code that creates a wake lock should use the same tag every time it runs. This practice enables the system to aggregate each method's wake lock usage.\n\nMake sure your app is visible in the foreground\n\nWhile a wake lock is active, the device is using power. The device's user\nshould be aware that this is going on. For this reason, if you're using a\nwake lock, you should display some notification to the user.\nIn practice, this means you should get and hold the wakelock in a\n[foreground service](/develop/background-work/services/fgs). Foreground services are required to display\na notification.\n\nIf a foreground service isn't the right choice for your app,\nyou probably shouldn't be using a wake lock, either. See the\n[Choose the right API to keep the device awake](/develop/background-work/background-tasks/awake)\ndocumentation for other ways to do work while your app isn't in the foreground.\n\nKeep the logic simple\n\nMake sure the logic for acquiring and releasing wake locks is as simple as\npossible. When your wake lock logic is tied to complex state machines, timeouts,\nexecutor pools, or callback events, any subtle bug in that logic can cause the\nwake lock to be held longer than expected. These bugs are difficult to diagnose\nand debug.\n\nCheck that the wake lock is always released\n\nIf you use a wake lock, you must make sure that every wake lock you acquire\nis properly released. This isn't always as easy as it sounds. For example,\nthe following code has a problem: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n acquire()\n doTheWork() // can potentially throw MyException\n release() // does not run if an exception is thrown\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n wakeLock.acquire();\n doTheWork(); // can potentially throw MyException\n wakeLock.release(); // does not run if an exception is thrown\n }\n\nThe problem here is that the method `doTheWork()` can throw the exception\n`MyException`. If it does, the `doSomethingAndRelease()` method propagates\nthe exception outward, and it never reaches the `release()` call. The result\nis that the wake lock is acquired but not released, which is very bad.\n\nIn the corrected code, `doSomethingAndRelease()` makes sure to release the\nwake lock even if an exception is thrown: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n try {\n acquire()\n doTheWork()\n } finally {\n release()\n }\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n try {\n wakeLock.acquire();\n doTheWork();\n } finally {\n wakeLock.release();\n }\n }"]]