I processi in background possono richiedere molta memoria e batteria. Ad esempio, un la trasmissione implicita può avviare molti processi in background registrati resta in ascolto, anche se questi processi potrebbero non produrre molto lavoro. Questo può avere un un impatto significativo sia sulle prestazioni del dispositivo sia sull'esperienza utente.
Per evitare limitazioni di sistema, assicurati di utilizzare l'API giusta per il tuo in background. La La documentazione della panoramica delle attività in background ti aiuta a scegliere l'API giusta per le tue esigenze.
Limitazioni avviate dall'utente
Se un'app mostra alcuni dei comportamenti dannosi descritti in Android vitals, il sistema chiede all'utente di limitare l'accesso di quell'app alle risorse di sistema.
Se il sistema rileva un consumo eccessivo di risorse, invia una notifica l'utente, offrendogli la possibilità di limitare le azioni dell'app. I comportamenti che possono attivare la notifica includono:
- Wakelock eccessivi: 1 wakelock parziale mantenuto per un'ora quando lo schermo è attivo non attivo
- Servizi in background eccessivi: se l'app ha come target livelli API inferiori a 26. e ha servizi in background eccessivi
Le precise limitazioni imposte sono stabilite dal produttore del dispositivo. Per Ad esempio, nelle build AOSP, le app con restrizioni non possono eseguire job, attivare gli allarmi o utilizzare verso la rete, tranne quando l'app è in primo piano.
Limitazioni relative alla ricezione di annunci di attività di rete
Le app non ricevono annunci su CONNECTIVITY_ACTION se si registrano a
riceverle nel file manifest e i processi che dipendono da questa
non verrà avviata. Questo potrebbe rappresentare un problema per le app che vogliono ascoltare la rete
modifiche o eseguire attività di rete in blocco quando il dispositivo si connette a
non a consumo. Diverse soluzioni per aggirare questa limitazione
esiste nel framework Android, ma la scelta di quella giusta dipende da cosa
che la tua app possa raggiungere.
Programma il lavoro su connessioni unmetered
Quando crei un WorkRequest, aggiungi un NetworkType.UNMETERED Constraint.
fun scheduleWork(context: Context) {
val workManager = WorkManager.getInstance(context)
val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
.setConstraints(
Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.build()
)
.build()
workManager.enqueue(workRequest)
}
Quando le condizioni del tuo lavoro sono soddisfatte, la tua app viene richiamata per l'esecuzione
il metodo doWork() nella classe Worker specificata.
Monitora la connettività di rete mentre l'app è in esecuzione
Le app in esecuzione possono comunque ascoltare CONNECTIVITY_CHANGE con un
ha registrato BroadcastReceiver. Tuttavia, l'API ConnectivityManager
fornisce un metodo più affidabile per richiedere un callback solo quando la rete specificata
che le condizioni siano soddisfatte.
Gli oggetti NetworkRequest definiscono i parametri del callback di rete in
termini di NetworkCapabilities. Puoi creare oggetti NetworkRequest
con il corso NetworkRequest.Builder. registerNetworkCallback
poi passa l'oggetto NetworkRequest al sistema. Quando la rete
se vengono soddisfatte determinate condizioni, l'app riceve un callback per eseguire
onAvailable() definito nel suo
ConnectivityManager.NetworkCallback.
L'app continua a ricevere callback finché non viene chiusa o non viene avviata la chiamata unregisterNetworkCallback().
Limitazioni relative alla ricezione di trasmissioni di immagini e video
Le app non possono inviare o ricevere ACTION_NEW_PICTURE o Trasmissioni ACTION_NEW_VIDEO. Questa restrizione aiuta ad alleviare le prestazioni e l'esperienza utente influiscono sul momento in cui diverse app devono attivarsi in ordine per elaborare una nuova immagine o un nuovo video.
Determinare quali autorità dei contenuti hanno attivato il lavoro
WorkerParameters consente alla tua app di ricevere informazioni utili su cosa
le autorità relative ai contenuti e gli URI hanno attivato l'operazione:
List<Uri> getTriggeredContentUris()
Restituisce un elenco di URI che hanno attivato l'operazione. Il campo è vuoto se o nessun URI ha attivato l'operazione (ad esempio, l'operazione è stata attivata a causa di una scadenza o qualche altro motivo), oppure il numero di URI modificati è maggiore di 50.
List<String> getTriggeredContentAuthorities()
Restituisce un elenco di stringhe di autorità sui contenuti che hanno attivato l'elaborazione. Se
l'elenco restituito non è vuoto, utilizza getTriggeredContentUris() per recuperare
i dettagli di quali URI sono stati modificati.
Il seguente codice campione sostituisce il metodo CoroutineWorker.doWork()
e registra le autorità competenti per i contenuti e gli URI che hanno attivato il job:
class MyWorker(
appContext: Context,
params: WorkerParameters
): CoroutineWorker(appContext, params)
override suspend fun doWork(): Result {
StringBuilder().apply {
append("Media content has changed:\n")
params.triggeredContentAuthorities
.takeIf { it.isNotEmpty() }
?.let { authorities ->
append("Authorities: ${authorities.joinToString(", ")}\n")
append(params.triggeredContentUris.joinToString("\n"))
} ?: append("(No content)")
Log.i(TAG, toString())
}
return Result.success()
}
}
Testa l'app in base alle limitazioni di sistema
L'ottimizzazione delle app per l'esecuzione su dispositivi con memoria ridotta o in condizioni di memoria ridotta: possono migliorare le prestazioni e l'esperienza utente. Rimozione delle dipendenze in background e i broadcast receiver impliciti registrati nel manifest possono aiutare la tua app funzionano meglio su questi dispositivi. Ti consigliamo di ottimizzare l'app per l'esecuzione senza dover utilizzare del tutto questi processi in background.
Alcuni comandi aggiuntivi di Android Debug Bridge (ADB) possono aiutarti a testare l'app comportamento con i processi in background disattivati:
Per simulare condizioni in cui le trasmissioni implicite e i servizi in background sono non disponibile, inserisci il seguente comando:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignorePer riattivare le trasmissioni implicite e i servizi in background, inserisci quanto segue :
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow
Ottimizza ulteriormente la tua app
Scopri altri modi efficaci per ottimizzare le tue attività in background: il comportamento degli utenti, consulta Ottimizzare l'utilizzo della batteria per le API di pianificazione delle attività documentazione.