Best Practices für Wakelocks beachten

Die Verwendung einer Wakelock kann die Geräteleistung beeinträchtigen. Wenn Sie eine Sperre für den Ruhemodus verwenden müssen, ist es wichtig, dies richtig zu tun. In diesem Dokument werden einige Best Practices beschrieben, mit denen Sie häufige Fallstricke bei Wakelocks vermeiden können.

Geben Sie dem Wakelock einen korrekten Namen.

Wir empfehlen, den Namen Ihres Pakets, Ihrer Klasse oder Ihrer Methode in das Wakelock-Tag aufzunehmen. So können Sie bei einem Fehler leichter den Ort im Quellcode finden, an dem die Wakelock erstellt wurde. Hier einige weitere Tipps:

  • Fügen Sie dem Namen keine personenidentifizierbaren Informationen wie eine E-Mail-Adresse hinzu. Wenn das Gerät PII im Tag „wake_lock“ erkennt, wird _UNKNOWN anstelle des von Ihnen angegebenen Tags protokolliert.
  • Der Klassen- oder Methodenname darf nicht programmatisch abgerufen werden, z. B. durch Aufruf von getName(). Wenn Sie versuchen, den Namen programmatisch abzurufen, wird er möglicherweise von Tools wie Proguard verschleiert. Verwenden Sie stattdessen einen hartcodierten String.
  • Fügen Sie Wakelock-Tags keinen Zähler oder eindeutige Kennzeichnungen hinzu. Der Code, der eine Wakelock erstellt, sollte jedes Mal, wenn er ausgeführt wird, dasselbe Tag verwenden. So kann das System die Nutzung der Wakelock-Funktion für jede Methode zusammenfassen.

Achten Sie darauf, dass Ihre App im Vordergrund sichtbar ist.

Solange eine Aktivierungssperre aktiv ist, verbraucht das Gerät Strom. Der Nutzer des Geräts muss darüber informiert werden. Wenn Sie also einen Sperrbildschirm verwenden, sollten Sie dem Nutzer eine Benachrichtigung anzeigen. In der Praxis bedeutet dies, dass Sie den Wakelock in einem Dienst im Vordergrund abrufen und halten sollten. Für die Anzeige einer Benachrichtigung sind Dienste im Vordergrund erforderlich.

Wenn ein Dienst im Vordergrund für Ihre App nicht die richtige Wahl ist, sollten Sie wahrscheinlich auch keine Wakelock verwenden. In der Dokumentation Die richtige API auswählen, um das Gerät aktiv zu halten finden Sie weitere Möglichkeiten, Aufgaben auszuführen, während Ihre App nicht im Vordergrund ist.

Die Logik sollte einfach sein

Die Logik zum Erfassen und Freigeben von Aktivierungssperren sollte möglichst einfach sein. Wenn die Logik für die Aktivierungssperre mit komplexen Zustandsmaschinen, Zeitüberschreitungen, Executor-Pools oder Rückrufereignissen verknüpft ist, kann ein kleiner Fehler in dieser Logik dazu führen, dass die Aktivierungssperre länger als erwartet gehalten wird. Diese Fehler sind schwer zu diagnostizieren und zu beheben.

Prüfen, ob die Aktivierungssperre immer aufgehoben wird

Wenn Sie einen Wakelock verwenden, müssen Sie darauf achten, dass jeder von Ihnen erworbene Wakelock ordnungsgemäß freigegeben wird. Das ist nicht immer so einfach, wie es klingt. Im folgenden Code gibt es beispielsweise ein Problem:

Kotlin

@Throws(MyException::class)
fun doSomethingAndRelease() {
    wakeLock.apply {
        acquire()
        doTheWork() // can potentially throw MyException
        release()   // does not run if an exception is thrown
    }
}

Java

void doSomethingAndRelease() throws MyException {
    wakeLock.acquire();
    doTheWork();         // can potentially throw MyException
    wakeLock.release();  // does not run if an exception is thrown
}

Das Problem besteht darin, dass die Methode doTheWork() die Ausnahme MyException auslösen kann. In diesem Fall überträgt die doSomethingAndRelease()-Methode die Ausnahme nach außen und sie erreicht nie den release()-Aufruf. Das Ergebnis ist, dass die Wake-Lock zwar erworben, aber nicht freigegeben wird. Das ist sehr schlecht.

Im korrigierten Code sorgt doSomethingAndRelease() dafür, dass die Wake-Sperre auch dann freigegeben wird, wenn eine Ausnahme ausgelöst wird:

Kotlin

@Throws(MyException::class)
fun doSomethingAndRelease() {
    wakeLock.apply {
        try {
            acquire()
            doTheWork()
        } finally {
            release()
        }
    }
}

Java

void doSomethingAndRelease() throws MyException {
    try {
        wakeLock.acquire();
        doTheWork();
    } finally {
        wakeLock.release();
    }
}