Panoramica del lavoro in background

Spesso le app devono svolgere più di una operazione alla volta. Le API Android offrono molti modi diversi per farlo. Scegliere l'opzione giusta è molto importante; un'opzione potrebbe essere giusta per una situazione ma molto sbagliata per un'altra. La scelta di API errate può compromettere le prestazioni o l'efficienza delle risorse della tua app, con un conseguente consumo della batteria e un peggioramento delle prestazioni del dispositivo dell'utente nel suo complesso. In alcuni casi, la scelta dell'approccio sbagliato potrebbe impedire la visualizzazione dell'app nel Play Store.

Questo documento illustra le diverse opzioni a tua disposizione e ti aiuta a scegliere quella più adatta alla tua situazione.

Terminologia

Alcuni termini importanti relativi al lavoro in background potrebbero essere utilizzati in più modi contraddittori. Per questo motivo, è importante definire i nostri termini.

Se un'app viene eseguita in background, il sistema pone una serie di limitazioni. Ad esempio, nella maggior parte dei casi un'app in background non può avviare servizi in primo piano.

Ai fini del presente documento, utilizzeremo il termine "attività" per indicare un'operazione svolta da un'app al di fuori del suo flusso di lavoro principale. Per garantire un allineamento delle informazioni, abbiamo suddiviso questi elementi in tre categorie principali di tipi di attività: lavoro asincrono, lavoro in background e servizi in primo piano.

Scegli l'opzione giusta

Nella maggior parte degli scenari, puoi capire quali sono le API giuste da utilizzare per la tua attività individuando la categoria (lavoro asincrono, operazioni in background o servizi in primo piano) in cui rientra l'attività.

Se hai ancora dubbi, puoi utilizzare i diagrammi di flusso forniti da noi che aggiungono ulteriori sfumature alla decisione. Ognuna di queste opzioni è descritta più dettagliatamente più avanti nel documento.

Esistono due scenari principali da considerare per il lavoro in background:

Questi due scenari hanno i propri alberi decisionali.

Lavoro asincrono

In molti casi, un'app deve semplicemente eseguire operazioni simultanee mentre è in esecuzione in primo piano. Ad esempio, un'app potrebbe dover eseguire un calcolo che richiede molto tempo. Se eseguisse il calcolo sul thread dell'interfaccia utente, l'utente non sarebbe in grado di interagire con l'app fino al termine del calcolo; questo potrebbe causare un errore ANR. In questi casi, l'app deve utilizzare un'opzione di lavoro asincrono.

Le opzioni comuni di lavoro asincrone includono coroutine Kotlin e thread Java. Puoi trovare ulteriori informazioni nella documentazione relativa al lavoro asincrono. È importante notare che, a differenza del lavoro in background, il completamento del lavoro asincrono non è garantito se l'app smette di essere in una fase del ciclo di vita valida (ad esempio, se l'app lascia il primo piano).

Lavoro in background

Il lavoro in background è un'opzione più flessibile quando devi svolgere un lavoro che dovrebbe continuare anche se l'utente abbandona l'app. Nella maggior parte dei casi, l'opzione migliore per il lavoro in background è utilizzare WorkManager, anche se in alcuni casi potrebbe essere appropriato usare l'API della piattaforma JobScheduler.

WorkManager è una libreria efficace che consente di impostare lavori semplici o complessi in base alle tue esigenze. Puoi utilizzare WorkManager per pianificare l'esecuzione delle attività in orari specifici o per specificare le condizioni in cui deve essere eseguita l'attività. Puoi anche configurare catene di attività, in modo che ogni attività venga eseguita a turno e passi i risultati a quella successiva. Per comprendere tutte le opzioni disponibili, leggi l'elenco delle funzionalità di WorkManager.

Ecco alcuni degli scenari più comuni per il lavoro in background:

  • Recupero periodico dei dati dal server
  • Recupero dei dati del sensore (ad esempio dati del contatore di passi)
  • Ricevere dati periodici sulla posizione (devi disporre dell'autorizzazione ACCESS_BACKGROUND_LOCATION su Android 10 o versioni successive)
  • Caricare contenuti basati su un attivatore di contenuti, ad esempio foto create dalla fotocamera

Servizi in primo piano

I servizi in primo piano offrono un modo potente per eseguire immediatamente attività che non devono essere interrotte. Tuttavia, i servizi in primo piano possono sovraccaricare maggiormente il dispositivo e, a volte, possono avere implicazioni per privacy e sicurezza. Per questi motivi, il sistema pone molte limitazioni su come e quando le app possono utilizzare i servizi in primo piano. Ad esempio, un servizio in primo piano deve essere visibile all'utente e nella maggior parte dei casi le app non possono avviare servizi in primo piano quando sono in background. Per ulteriori informazioni, consulta la documentazione sui servizi in primo piano.

Esistono due metodi per creare un servizio in primo piano. Puoi dichiarare la tua proprietà Service e specificare che il servizio è in primo piano chiamando Service.startForeground(). In alternativa, puoi utilizzare WorkManager per creare un servizio in primo piano, come descritto nella sezione relativa al supporto per i worker di lunga durata. Tuttavia, è importante sapere che un servizio in primo piano creato da WorkManager deve rispettare le stesse restrizioni di qualsiasi altro servizio in primo piano. WorkManager fornisce solo alcune API utili per semplificare la creazione di un servizio in primo piano.

API alternative

Il sistema offre API alternative progettate per offrire prestazioni migliori per casi d'uso più specifici. Se esiste un'API alternativa per il tuo caso d'uso, ti consigliamo di utilizzarla anziché un servizio in primo piano, in quanto dovrebbe migliorare le prestazioni dell'app. La documentazione relativa ai tipi di servizi in primo piano indica quando è disponibile un'API alternativa valida da utilizzare al posto di un particolare tipo di servizio in primo piano.

Ecco alcuni degli scenari più comuni per l'utilizzo di API alternative:

  • Utilizzare trasferimenti di dati avviati dall'utente per eseguire download o caricamenti di grandi dimensioni, anziché creare un servizio di sincronizzazione dei dati in primo piano
  • Utilizzare Gestione dispositivi associati per l'accoppiamento Bluetooth e il trasferimento di dati, anziché utilizzare un servizio in primo piano per un dispositivo connesso
  • Usare la modalità Picture in picture per riprodurre il video, anziché creare un servizio in primo piano per la riproduzione di contenuti multimediali

Attività avviate dall'utente

Diagramma di flusso che mostra come scegliere l'API appropriata. Questo grafico riassume il materiale della sezione "Attività avviate dall'utente".
Figura 1: come scegliere l'API giusta per eseguire un'attività in background avviata dall'utente.

Se un'app deve eseguire operazioni in background e l'operazione viene avviata dall'utente mentre l'app è visibile, rispondi a queste domande per trovare l'approccio giusto.

L'attività deve continuare a essere eseguita mentre l'app è in background?

Se non è necessario che l'attività continui a funzionare mentre l'app è in background, devi utilizzare il lavoro asincrono. Esistono varie opzioni per svolgere il lavoro asincrono. È importante capire che queste opzioni smettono di funzionare se l'app va in background. (vengono interrotti anche quando l'app viene chiusa). Ad esempio, un'app di social media potrebbe voler aggiornare il feed di contenuti, ma non dovrebbe terminare l'operazione se l'utente ha abbandonato la schermata.

Ci sarà un'esperienza utente negativa se l'attività viene differita o interrotta?

È importante valutare se l'esperienza utente non verrà compromessa se un'attività viene posticipata o annullata. Ad esempio, se un'app deve aggiornare i propri asset, l'utente potrebbe non notare se l'operazione viene eseguita subito o nel cuore della notte durante la ricarica del dispositivo. In questi casi, devi utilizzare le opzioni relative al lavoro in background.

È un'attività breve e critica?

Se l'attività non può essere ritardata e verrà completata rapidamente, puoi utilizzare un servizio in primo piano con il tipo shortService. Questi servizi sono più facili da creare rispetto ad altri servizi in primo piano e non richiedono tante autorizzazioni. Tuttavia, i servizi brevi devono essere completati entro tre minuti.

Esiste un'API alternativa solo per questo scopo?

Se l'attività non è invisibile all'utente, la soluzione corretta potrebbe essere utilizzare un servizio in primo piano. Questi servizi vengono eseguiti continuamente una volta avviati, quindi sono un'ottima scelta quando interrompere l'attività avrebbe un'esperienza utente negativa. Ad esempio, un'app di monitoraggio dell'allenamento potrebbe usare sensori di posizione per consentire agli utenti di registrare il percorso di jogging su una mappa. Ti consigliamo di non eseguire questa operazione con un'opzione di lavoro in background, perché se l'attività viene messa in pausa, il monitoraggio viene interrotto immediatamente. In una situazione come questa, un servizio in primo piano è più logico.

Tuttavia, poiché i servizi in primo piano possono utilizzare molte risorse del dispositivo, il sistema pone molte limitazioni su quando e come possono essere utilizzati. In molti casi, invece di utilizzare un servizio in primo piano, puoi usare un'API alternativa che gestisce il job al posto tuo con meno problemi. Ad esempio, se l'app deve compiere un'azione quando l'utente arriva in una determinata posizione, la soluzione migliore è utilizzare l'API geofence anziché monitorare la posizione dell'utente con un servizio in primo piano.

Attività in risposta a un evento

Diagramma di flusso che mostra come scegliere l'API appropriata. Questo grafico riassume il materiale della sezione "Attività in risposta a un evento".
Figura 2: come scegliere l'API giusta per eseguire un'attività in background attivata da eventi.

A volte un'app deve svolgere operazioni in background in risposta a un attivatore, ad esempio:

Potrebbe essere un trigger esterno (come un messaggio FCM) o essere in risposta a un allarme impostato dall'app stessa. Ad esempio, un gioco potrebbe ricevere un messaggio FCM che richiede di aggiornare alcuni asset.

Se hai la certezza che l'attività venga completata in pochi secondi, utilizza il lavoro asincrono per eseguirla. Il sistema concede alla tua app alcuni secondi per eseguire queste attività, anche se l'app era in background.

Se l'attività richiederà più di qualche secondo, potrebbe essere opportuno avviare un servizio in primo piano per gestire l'attività. Infatti, anche se la tua app è attualmente in background, potrebbe essere autorizzata ad avviare un servizio in primo piano se l'attività è stata attivata dall'utente e rientra in una delle esenzioni dalle limitazioni relative all'avvio in background approvate. Ad esempio, se un'app riceve un messaggio FCM con priorità elevata, può avviare un servizio in primo piano anche se è in background.

Se l'attività richiederà più di qualche secondo, utilizza il lavoro in background.