Android AsyncTask per operazioni di lunga durata

Citando la documentazione per AsyncTask trovata qui , dice:

Gli AsyncTasks dovrebbero idealmente essere usati per operazioni brevi (pochi secondi al massimo). Se hai bisogno di mantenere i thread in esecuzione per lunghi periodi di tempo, ti consigliamo vivamente di usare le varie API fornite dal pacakge java.util.concurrent come Executor, ThreadPoolExecutor e FutureTask.

Ora sorge la mia domanda: perché? La doInBackground()funzione viene eseguita dal thread dell'interfaccia utente, quindi che male c'è dall'avere un'operazione di lunga durata qui?

È un'ottima domanda, ci vuole tempo come programmatore Android per comprendere appieno il problema. Infatti AsyncTask ha due problemi principali correlati:

• Sono scarsamente legati al ciclo di vita dell'attività
• Creano perdite di memoria molto facilmente.

All'interno dell'app RoboSpice Motivations ( disponibile su Google Play ) rispondiamo in dettaglio a questa domanda. Fornirà una visione approfondita di AsyncTask, Loader, le loro caratteristiche e svantaggi e ti introdurrà anche a una soluzione alternativa per le richieste di rete: RoboSpice. Le richieste di rete sono un requisito comune in Android e sono per natura operazioni di lunga durata. Ecco un estratto dall'app:

Il ciclo di vita AsyncTask e Activity

Gli AsyncTask non seguono il ciclo di vita delle istanze di Activity. Se avvii un AsyncTask all'interno di un'attività e ruoti il ​​dispositivo, l'attività verrà distrutta e verrà creata una nuova istanza. Ma AsyncTask non morirà. Continuerà a vivere finché non sarà completo.

E al termine, AsyncTask non aggiornerà l'interfaccia utente della nuova attività. Infatti aggiorna l'istanza precedente dell'attività che non viene più visualizzata. Ciò può portare a un'eccezione del tipo java.lang.IllegalArgumentException: vista non allegata al gestore delle finestre se si utilizza, ad esempio, findViewById per recuperare una vista all'interno dell'attività.

Problema di perdita di memoria

È molto comodo creare AsyncTask come classi interne delle tue attività. Poiché AsyncTask dovrà manipolare le visualizzazioni dell'attività quando l'attività è completa o in corso, l'uso di una classe interna dell'attività sembra conveniente: le classi interne possono accedere direttamente a qualsiasi campo della classe esterna.

Tuttavia, significa che la classe interna manterrà un riferimento invisibile sulla sua istanza di classe esterna: l'attività.

A lungo andare, questo produce una perdita di memoria: se l'AsyncTask dura a lungo, mantiene "viva" l'attività mentre Android vorrebbe sbarazzarsene in quanto non può più essere visualizzato. L'attività non può essere raccolta dai rifiuti e questo è un meccanismo centrale per Android per preservare le risorse sul dispositivo.

È davvero una pessima idea usare AsyncTasks per operazioni di lunga durata. Tuttavia, vanno bene per quelli di breve durata come l'aggiornamento di una vista dopo 1 o 2 secondi.

Ti incoraggio a scaricare l' app RoboSpice Motivations , lo spiega davvero in modo approfondito e fornisce esempi e dimostrazioni dei diversi modi per eseguire alcune operazioni in background.

perché ?

Perché AsyncTask, per impostazione predefinita, utilizza un pool di thread che non hai creato . Non legare mai risorse da un pool che non hai creato, poiché non sai quali sono i requisiti di quel pool. E non legare mai risorse da un pool che non hai creato se la documentazione di quel pool ti dice di non farlo, come nel caso qui.

In particolare, a partire da Android 3.2, il pool di thread utilizzato per AsyncTaskimpostazione predefinita (per le app con android:targetSdkVersionimpostato su 13 o superiore) contiene un solo thread: se leghi questo thread a tempo indeterminato, nessuna delle altre attività verrà eseguita.

Le attività Aysnc sono thread specializzati che sono ancora pensati per essere utilizzati con la GUI delle app ma pur mantenendo le attività pesanti in termini di risorse del thread dell'interfaccia utente. Quindi, quando cose come l'aggiornamento degli elenchi, la modifica delle visualizzazioni ecc. Richiedono di eseguire alcune operazioni di recupero o di aggiornamento, è necessario utilizzare attività asincrone in modo da poter mantenere queste operazioni fuori dal thread dell'interfaccia utente, ma si noti che queste operazioni sono ancora connesse all'interfaccia utente in qualche modo .

Per le attività a esecuzione più lunga, che non richiedono l'aggiornamento dell'interfaccia utente, è possibile utilizzare i servizi invece perché possono vivere anche senza un'interfaccia utente.

Quindi, per attività brevi, usa attività asincrone perché possono essere uccise dal sistema operativo dopo che la tua attività di spawn muore (di solito non morirà a metà operazione ma completerà il suo compito). E per attività lunghe e ripetitive, utilizza invece i servizi.

per maggiori informazioni, vedi discussioni:

AsyncTask per più di pochi secondi?

e

AsyncTask non si interromperà nemmeno quando l'attività è stata distrutta

Il problema con AsyncTask è che se è definita come classe interna non statica dell'attività, avrà un riferimento all'attività. Nello scenario in cui l'attività del contenitore dell'attività asincrona termina, ma il lavoro in background in AsyncTask continua, l'oggetto attività non verrà sottoposto a garbage collection in quanto vi è un riferimento, ciò causa la perdita di memoria.

La soluzione per risolvere questo problema è definire un'attività asincrona come classe interna statica di attività e utilizzare un riferimento debole al contesto.

Tuttavia, è una buona idea utilizzarlo per attività in background semplici e veloci. Per sviluppare un'app con codice pulito, è meglio utilizzare RxJava per eseguire complesse attività in background e aggiornare l'interfaccia utente con i risultati.