Ottimizzazione in background

I processi in background possono consumare molta memoria e batteria. Ad esempio, una trasmissione implicita può avviare molti processi in background registrati per ascoltarla, anche se questi processi potrebbero non svolgere molto lavoro. Questo può avere un impatto significativo sia sulle prestazioni del dispositivo sia sull'esperienza utente.

Per alleviare questo problema, Android 7.0 (livello API 24) applica le seguenti limitazioni:

Se la tua app utilizza uno di questi intent, devi rimuovere le dipendenze il prima possibile per poter scegliere come target correttamente i dispositivi con Android 7.0 o versioni successive. Il framework Android fornisce diverse soluzioni per ridurre la necessità di queste trasmissioni implicite. Ad esempio, JobScheduler e il nuovo WorkManager forniscono meccanismi robusti per pianificare operazioni di rete quando vengono soddisfatte condizioni specifiche, ad esempio una connessione a una rete non a consumo. Ora puoi utilizzare anche JobScheduler per reagire alle modifiche apportate ai fornitori di contenuti. Gli oggetti JobInfo incapsulano i parametri che JobScheduler utilizza per pianificare il job. Quando le condizioni del job vengono soddisfatte, il sistema esegue questo job sul JobService della tua app.

In questa pagina scopriremo come utilizzare metodi alternativi, ad esempio JobScheduler, per adattare la tua app a queste nuove limitazioni.

Limitazioni avviate dall'utente

Nella pagina Utilizzo batteria all'interno delle impostazioni di sistema, l'utente può scegliere tra le seguenti opzioni:

  • Senza limitazioni. Consenti tutte le attività in background, che potrebbero consumare più batteria.
  • Ottimizzata (impostazione predefinita): ottimizza la capacità di un'app di eseguire operazioni in background, in base al modo in cui l'utente interagisce con l'app.
  • Con limitazioni. Impedisce completamente l'esecuzione di un'app in background. Le app potrebbero non funzionare come previsto.

Se un'app mostra alcuni dei comportamenti dannosi descritti in Android Vitals, il sistema potrebbe chiedere all'utente di limitare l'accesso dell'app alle risorse di sistema.

Se il sistema rileva che un'app consuma risorse eccessive, invia una notifica all'utente e gli offre la possibilità di limitare le azioni dell'app. I comportamenti che possono attivare l'avviso includono:

  • Wakelock eccessivi: 1 wakelock parziale mantenuto per un'ora quando lo schermo è spento
  • Servizi in background eccessivi: se l'app ha come target livelli API inferiori a 26 e ha servizi in background eccessivi

Le limitazioni precise imposte sono determinate dal produttore del dispositivo. Ad esempio, nelle build AOSP che eseguono Android 9 (livello API 28) o versioni successive, le app in esecuzione in background che si trovano nello stato "con limitazioni" presentano le seguenti limitazioni:

  • Impossibile avviare i servizi in primo piano
  • I servizi in primo piano esistenti vengono rimossi dal primo piano
  • Le sveglie non vengono attivate
  • I job non vengono eseguiti

Inoltre, se un'app ha come target Android 13 (livello API 33) o versioni successive e si trova nello stato "con limitazioni", il sistema non invia la trasmissione BOOT_COMPLETED o la trasmissione LOCKED_BOOT_COMPLETED finché l'app non viene avviata per altri motivi.

Le limitazioni specifiche sono elencate in Limitazioni alla gestione dell'alimentazione.

Limitazioni alla ricezione di trasmissioni di attività di rete

Le app che hanno come target Android 7.0 (livello API 24) non ricevono trasmissioni CONNECTIVITY_ACTION se si registrano per riceverle nel manifest e i processi che dipendono da questa trasmissione non vengono avviati. Ciò potrebbe rappresentare un problema per le app che vogliono ascoltare le modifiche alla rete o eseguire attività di rete collettive quando il dispositivo si connette a una rete non a consumo. Nel framework Android esistono già diverse soluzioni per aggirare questa limitazione, ma la scelta di quella giusta dipende da ciò che vuoi che la tua app realizzi.

Nota:un intent BroadcastReceiver registrato con Context.registerReceiver() continua a ricevere queste trasmissioni mentre l'app è in esecuzione.

Pianificare job di rete su connessioni senza tariffa a consumo

Quando utilizzi la classe JobInfo.Builder per creare l'oggetto JobInfo, applica il metodo setRequiredNetworkType() e passa JobInfo.NETWORK_TYPE_UNMETERED come parametro del job. Il seguente esempio di codice pianifica l'esecuzione di un servizio quando il dispositivo si connette a una rete senza tariffa e si sta caricando:

Kotlin

const val MY_BACKGROUND_JOB = 0
...
fun scheduleJob(context: Context) {
    val jobScheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
    val job = JobInfo.Builder(
            MY_BACKGROUND_JOB,
            ComponentName(context, MyJobService::class.java)
    )
            .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
            .setRequiresCharging(true)
            .build()
    jobScheduler.schedule(job)
}

Java

public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
  JobScheduler js =
      (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
  JobInfo job = new JobInfo.Builder(
    MY_BACKGROUND_JOB,
    new ComponentName(context, MyJobService.class))
      .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
      .setRequiresCharging(true)
      .build();
  js.schedule(job);
}

Quando le condizioni del job vengono soddisfatte, la tua app riceve un callback per eseguire il metodo onStartJob() nell'JobService.class specificato. Per vedere altri esempi di implementazione di JobScheduler, consulta l'app di esempio JobScheduler.

Una nuova alternativa a JobScheduler è WorkManager, un'API che consente di pianificare attività in background che devono essere completate in modo garantito, indipendentemente dal fatto che il processo dell'app sia attivo o meno. WorkManager sceglie il modo appropriato per eseguire il lavoro (direttamente su un thread nel processo dell'app, nonché utilizzando JobScheduler, FirebaseJobDispatcher o AlarmManager) in base a fattori quali il livello API del dispositivo. Inoltre, WorkManager non richiede i servizi Google Play e fornisce diverse funzionalità avanzate, come il concatenamento delle attività o il controllo dello stato di un'attività. Per saperne di più, consulta WorkManager.

Monitorare la connettività di rete durante l'esecuzione dell'app

Le app in esecuzione possono comunque ascoltare CONNECTIVITY_CHANGE con un BroadcastReceiver registrato. Tuttavia, l'API ConnectivityManager fornisce un metodo più solido per richiedere un callback solo quando vengono soddisfatte le condizioni di rete specificate.

Gli oggetti NetworkRequest definiscono i parametri del callback di rete in termini di NetworkCapabilities. Puoi creare NetworkRequest oggetti con la classe NetworkRequest.Builder. registerNetworkCallback() quindi passa l'oggetto NetworkRequest al sistema. Quando le condizioni di rete sono soddisfatte, l'app riceve un callback per eseguire il metodo onAvailable() definito nella relativa classe ConnectivityManager.NetworkCallback.

L'app continua a ricevere callback finché non viene chiusa o non chiama unregisterNetworkCallback().

Limitazioni alla ricezione di trasmissioni di immagini e video

In Android 7.0 (livello API 24), le app non sono in grado di inviare o ricevere trasmissioni ACTION_NEW_PICTURE o ACTION_NEW_VIDEO. Questa limitazione contribuisce ad alleviare gli impatti sulle prestazioni e sull'esperienza utente quando diverse app devono attivarsi per elaborare una nuova immagine o un nuovo video. Android 7.0 (livello API 24) estende JobInfo e JobParameters per fornire una soluzione alternativa.

Attivare job in base alle modifiche dell'URI contenuto

Per attivare i job in caso di modifiche all'URI dei contenuti, Android 7.0 (livello API 24) estende l'API JobInfo con i seguenti metodi:

JobInfo.TriggerContentUri()
Contiene i parametri necessari per attivare un job in caso di modifiche all'URI dei contenuti.
JobInfo.Builder.addTriggerContentUri()
Passa un oggetto TriggerContentUri a JobInfo. Un ContentObserver monitora l'URI dei contenuti incapsulati. Se a un lavoro sono associati più oggetti TriggerContentUri, il sistema fornisce un callback anche se segnala una modifica in uno solo degli URI dei contenuti.
Aggiungi il flag TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS per attivare il job se uno qualsiasi dei discendenti dell'URI specificato cambia. Questo flag corrisponde al parametro notifyForDescendants passato a registerContentObserver().

Nota: TriggerContentUri() non può essere utilizzato in combinazione con setPeriodic() o setPersisted(). Per monitorare continuamente le modifiche ai contenuti, pianifica un nuovo JobInfo prima che JobService dell'app termini la gestione dell'ultimo callback.

Il seguente codice di esempio pianifica un job da attivare quando il sistema segnala una modifica all'URI dei contenuti, MEDIA_URI:

Kotlin

const val MY_BACKGROUND_JOB = 0
...
fun scheduleJob(context: Context) {
    val jobScheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
    val job = JobInfo.Builder(
            MY_BACKGROUND_JOB,
            ComponentName(context, MediaContentJob::class.java)
    )
            .addTriggerContentUri(
                    JobInfo.TriggerContentUri(
                            MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
                            JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS
                    )
            )
            .build()
    jobScheduler.schedule(job)
}

Java

public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
  JobScheduler js =
          (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
  JobInfo.Builder builder = new JobInfo.Builder(
          MY_BACKGROUND_JOB,
          new ComponentName(context, MediaContentJob.class));
  builder.addTriggerContentUri(
          new JobInfo.TriggerContentUri(MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
          JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS));
  js.schedule(builder.build());
}

Quando il sistema segnala una modifica negli URI dei contenuti specificati, la tua app riceve un callback e un oggetto JobParameters viene trasmesso al metodo onStartJob() in MediaContentJob.class.

Determinare quali autorità sui contenuti hanno attivato un job

Android 7.0 (livello API 24) estende anche JobParameters per consentire alla tua app di ricevere informazioni utili su quali autorità di contenuti e URI hanno attivato il job:

Uri[] getTriggeredContentUris()
Restituisce un array di URI che hanno attivato il job. Il valore sarà null se nessun URI ha attivato il job (ad esempio, il job è stato attivato a causa di una scadenza o per qualche altro motivo) oppure se il numero di URI modificati è maggiore di 50.
String[] getTriggeredContentAuthorities()
Restituisce un array di stringhe di autorità dei contenuti che hanno attivato il job. Se l'array restituito non è null, utilizza getTriggeredContentUris() per recuperare i dettagli degli URI modificati.

Il seguente codice di esempio esegue l'override del metodo JobService.onStartJob() e registra gli URI e le autorità dei contenuti che hanno attivato il job:

Kotlin

override fun onStartJob(params: JobParameters): Boolean {
    StringBuilder().apply {
        append("Media content has changed:\n")
        params.triggeredContentAuthorities?.also { authorities ->
            append("Authorities: ${authorities.joinToString(", ")}\n")
            append(params.triggeredContentUris?.joinToString("\n"))
        } ?: append("(No content)")
        Log.i(TAG, toString())
    }
    return true
}

Java

@Override
public boolean onStartJob(JobParameters params) {
  StringBuilder sb = new StringBuilder();
  sb.append("Media content has changed:\n");
  if (params.getTriggeredContentAuthorities() != null) {
      sb.append("Authorities: ");
      boolean first = true;
      for (String auth :
          params.getTriggeredContentAuthorities()) {
          if (first) {
              first = false;
          } else {
             sb.append(", ");
          }
           sb.append(auth);
      }
      if (params.getTriggeredContentUris() != null) {
          for (Uri uri : params.getTriggeredContentUris()) {
              sb.append("\n");
              sb.append(uri);
          }
      }
  } else {
      sb.append("(No content)");
  }
  Log.i(TAG, sb.toString());
  return true;
}

Ottimizzare ulteriormente l'app

L'ottimizzazione delle app per l'esecuzione su dispositivi con poca memoria o in condizioni di poca memoria può migliorare le prestazioni e l'esperienza utente. La rimozione delle dipendenze dai servizi in background e dai broadcast receiver impliciti registrati nel manifest può contribuire a migliorare il funzionamento dell'app su questi dispositivi. Sebbene Android 7.0 (livello API 24) adotti misure per ridurre alcuni di questi problemi, è consigliabile ottimizzare l'app in modo che venga eseguita senza l'utilizzo di questi processi in background.

I seguenti comandi di Android Debug Bridge (ADB) possono aiutarti a testare il comportamento dell'app con i processi in background disattivati:

  • Per simulare condizioni in cui le trasmissioni implicite e i servizi in background non sono disponibili, inserisci questo comando: 
  • $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore
  • Per riattivare le trasmissioni implicite e i servizi in background, inserisci il seguente comando: 
  • $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow
  • Puoi simulare l'inserimento dell'app nello stato "con limitazioni" per l'utilizzo della batteria in background. Questa impostazione impedisce all'app di essere eseguita in background. Per farlo, esegui questo comando in una finestra del terminale: 
  • $ adb shell cmd appops set <PACKAGE_NAME> RUN_ANY_IN_BACKGROUND deny