L'utilizzo di un wakelock può compromettere le prestazioni del dispositivo. Se devi utilizzare un wakelock, è importante farlo correttamente. Questo documento illustra alcune best practice che possono aiutarti a evitare le insidie comuni dei wakelock.
Assegnare un nome corretto al wakelock
Ti consigliamo di includere il nome del pacchetto, della classe o del metodo nel tag wakelock. In questo modo, se si verifica un errore, è più facile trovare la posizione nel codice sorgente in cui è stato creato il wakelock. Ecco alcuni suggerimenti aggiuntivi:
- Non includere informazioni che consentono l'identificazione personale (PII) nel nome, ad esempio un indirizzo email. Se il dispositivo rileva PII nel tag wakelock, registra
_UNKNOWNanziché il tag specificato. - Non recuperare il nome della classe o del metodo a livello di programmazione, ad esempio chiamando
getName(). Se provi a recuperare il nome a livello di programmazione, potrebbe essere offuscato da strumenti come Proguard. Utilizza invece una stringa hardcoded. - Non aggiungere un contatore o identificatori univoci ai tag wakelock. Il codice che crea un wakelock deve utilizzare lo stesso tag ogni volta che viene eseguito. Questa pratica consente al sistema di aggregare l'utilizzo del wakelock di ogni metodo.
Assicurarsi che l'app sia visibile in primo piano
Quando un wakelock è attivo, il dispositivo consuma energia. L'utente del dispositivo deve essere consapevole di questa situazione. Per questo motivo, se utilizzi un wakelock, devi mostrare una notifica all'utente. In pratica, devi recuperare e mantenere il wakelock in un servizio in primo piano. I servizi in primo piano sono obbligati a mostrare una notifica.
Se un servizio in primo piano non è la scelta giusta per la tua app, probabilmente non dovresti utilizzare nemmeno un wakelock. Consulta la documentazione Scegliere l'API giusta per mantenere attivo il dispositivo per altri modi per lavorare mentre l'app non è in primo piano.
Mantenere la logica semplice
Assicurati che la logica per acquisire e rilasciare i wakelock sia il più semplice possibile. Quando la logica del wakelock è legata a macchine a stati complesse, timeout, pool di esecutori o eventi di callback, qualsiasi bug sottile in questa logica può causare il mantenimento del wakelock più a lungo del previsto. Questi bug sono difficili da diagnosticare ed eseguire il debug.
Verificare che il wakelock venga sempre rilasciato
Se utilizzi un wakelock, devi assicurarti che ogni wakelock acquisito venga rilasciato correttamente. Non è sempre così facile come sembra. Ad esempio, il seguente codice presenta un problema:
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
}
Il problema è che il metodo doTheWork() può generare l'eccezione MyException. In questo caso, il metodo doSomethingAndRelease() propaga l'eccezione verso l'esterno e non raggiunge mai la chiamata release(). Il risultato è che il wakelock viene acquisito ma non rilasciato, il che è molto grave.
Nel codice corretto, doSomethingAndRelease() si assicura di rilasciare il wakelock anche se viene generata un'eccezione:
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();
}
}