AsyncTask è concettualmente difettoso o mi sto perdendo qualcosa?

Ho studiato questo problema da mesi ormai, ho trovato diverse soluzioni ad esso, di cui non sono contento poiché sono tutti hack enormi. Non riesco ancora a credere che una classe imperfetta nel design sia entrata nel framework e nessuno ne parli, quindi immagino che mi debba mancare qualcosa.

Il problema è con AsyncTask. Secondo la documentazione esso

"consente di eseguire operazioni in background e pubblicare risultati sul thread dell'interfaccia utente senza dover manipolare thread e / o gestori."

L'esempio continua quindi a mostrare come showDialog()viene chiamato un metodo esemplare onPostExecute(). Questo, tuttavia, mi sembra del tutto inventato , perché mostrare una finestra di dialogo ha sempre bisogno di un riferimento a un valido Contexte un AsyncTask non deve mai contenere un forte riferimento a un oggetto di contesto .

Il motivo è ovvio: cosa succede se l'attività viene distrutta e ciò ha innescato l'attività? Questo può succedere sempre, ad esempio perché hai capovolto lo schermo. Se l'attività conterrà un riferimento al contesto che lo ha creato, non stai solo trattenendo un oggetto di contesto inutile (la finestra sarà stata distrutta e qualsiasi interazione dell'interfaccia utente non riuscirà con un'eccezione!), Rischi anche di creare un perdita di memoria.

A meno che la mia logica non sia difettosa qui, questo si traduce in: onPostExecute()è del tutto inutile, perché a che serve questo metodo eseguire sul thread dell'interfaccia utente se non si ha accesso a nessun contesto? Non puoi fare nulla di significativo qui.

Una soluzione alternativa sarebbe quella di non passare istanze di contesto a un AsyncTask, ma a Handlerun'istanza. Funziona così: dal momento che un gestore si lega vagamente al contesto e all'attività, è possibile scambiare messaggi tra di loro senza rischiare una perdita (giusto?). Ciò significherebbe che la premessa di AsyncTask, vale a dire che non è necessario preoccuparsi dei gestori, è sbagliata. Sembra anche abusare di Handler, poiché stai inviando e ricevendo messaggi sullo stesso thread (lo crei sul thread dell'interfaccia utente e lo invii in onPostExecute () che viene eseguito anche sul thread dell'interfaccia utente).

Per finire, anche con quella soluzione alternativa, hai ancora il problema che quando il contesto viene distrutto, non hai alcuna registrazione delle attività che ha generato. Ciò significa che è necessario riavviare qualsiasi attività quando si ricrea il contesto, ad esempio dopo una modifica dell'orientamento dello schermo. Questo è lento e dispendioso.

La mia soluzione a questo (come implementato nella libreria Droid-Fu ) è quella di mantenere una mappatura di WeakReferences dai nomi dei componenti alle loro istanze correnti sull'oggetto applicazione univoco. Ogni volta che viene avviato un AsyncTask, registra il contesto di chiamata in quella mappa e su ogni richiamata, recupera l'istanza di contesto corrente da quella mappatura. Ciò garantisce che non si farà mai riferimento a un'istanza di contesto obsoleta e che si abbia sempre accesso a un contesto valido nei callback in modo da poter svolgere un lavoro di interfaccia utente significativo lì. Inoltre non perde, perché i riferimenti sono deboli e vengono cancellati quando non esiste più alcuna istanza di un determinato componente.

Tuttavia, è una soluzione complessa e richiede di sottoclassare alcune delle classi di librerie Droid-Fu, rendendolo un approccio piuttosto invadente.

Ora voglio semplicemente sapere: mi sto perdendo qualcosa in modo massiccio o AsyncTask è davvero completamente imperfetto? In che modo le tue esperienze ci lavorano? Come hai risolto questi problemi?

Grazie per il tuo contributo.

Che ne dici di qualcosa del genere:

class MyActivity extends Activity {
    Worker mWorker;

    static class Worker extends AsyncTask<URL, Integer, Long> {
        MyActivity mActivity;

        Worker(MyActivity activity) {
            mActivity = activity;
        }

        @Override
        protected Long doInBackground(URL... urls) {
            int count = urls.length;
            long totalSize = 0;
            for (int i = 0; i < count; i++) {
                totalSize += Downloader.downloadFile(urls[i]);
                publishProgress((int) ((i / (float) count) * 100));
            }
            return totalSize;
        }

        @Override
        protected void onProgressUpdate(Integer... progress) {
            if (mActivity != null) {
                mActivity.setProgressPercent(progress[0]);
            }
        }

        @Override
        protected void onPostExecute(Long result) {
            if (mActivity != null) {
                mActivity.showDialog("Downloaded " + result + " bytes");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mWorker = (Worker)getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = this;
        }

        ...
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new Worker(this);
        mWorker.execute(...);
    }
}

Il motivo è ovvio: cosa succede se l'attività viene distrutta e ciò ha innescato l'attività?

Dissociare manualmente l'attività dal AsyncTaskin onDestroy(). Riassociare manualmente la nuova attività a AsyncTaskin onCreate(). Ciò richiede una classe interna statica o una classe Java standard, più forse 10 righe di codice.

Sembra che AsyncTasksia un po ' più di un semplice difetto concettuale . È inoltre inutilizzabile per problemi di compatibilità. I documenti Android leggono:

Alla prima introduzione, gli AsyncTask erano eseguiti in serie su un singolo thread in background. A partire da DONUT, questo è stato modificato in un pool di thread che consente a più attività di operare in parallelo. A partire da HONEYCOMB, le attività tornano ad essere eseguite su un singolo thread per evitare errori di applicazione comuni causati dall'esecuzione parallela. Se si desidera veramente l'esecuzione parallela, è possibile utilizzare la executeOnExecutor(Executor, Params...) versione di questo metodo con THREAD_POOL_EXECUTOR ; tuttavia, vedere i commenti lì per avvertenze sul suo utilizzo.

Entrambi executeOnExecutor()e THREAD_POOL_EXECUTORsono aggiunti nel livello API 11 (Android 3.0.x, HONEYCOMB).

Ciò significa che se si creano due AsyncTasksecondi per scaricare due file, il secondo download non inizierà fino al termine del primo. Se chatti tramite due server e il primo server è inattivo, non ti collegherai al secondo prima del timeout della connessione al primo. (A meno che tu non usi le nuove funzionalità API11, ovviamente, ma questo renderà il tuo codice incompatibile con 2.x).

E se vuoi scegliere come target sia 2.x sia 3.0+, le cose diventano davvero difficili.

Inoltre, i documenti dicono:

Attenzione: un altro problema che potresti riscontrare quando si utilizza un thread di lavoro è il riavvio imprevisto dell'attività a causa di una modifica della configurazione di runtime (ad esempio quando l'utente modifica l'orientamento dello schermo), che potrebbe distruggere il thread di lavoro . Per vedere come è possibile persistere l'attività durante uno di questi riavvii e come annullare correttamente l'attività quando l'attività viene distrutta, vedere il codice sorgente per l'applicazione di esempio Shelves.

Probabilmente tutti, incluso Google, utilizziamo in modo improprio AsyncTaskdal punto di vista MVC .

Un'attività è un controller e il controller non deve avviare operazioni che potrebbero sopravvivere alla vista . Cioè, AsyncTasks dovrebbe essere usato dal Modello , da una classe che non è legata al ciclo di vita dell'Attività - ricorda che le Attività vengono distrutte durante la rotazione. (Per quanto riguarda la vista , di solito non programmate classi derivate da es. Android.widget.Button, ma potete farlo. Di solito, l'unica cosa che fate sulla vista è l'xml.)

In altre parole, è errato collocare i derivati ​​AsyncTask nei metodi delle attività. OTOH, se non dobbiamo usare AsyncTasks nelle attività, AsyncTask perde la sua attrattiva: era pubblicizzato come una soluzione rapida e semplice.

Non sono sicuro che sia vero che rischi una perdita di memoria con un riferimento a un contesto da un AsyncTask.

Il modo normale di implementarli è creare una nuova istanza di AsyncTask nell'ambito di uno dei metodi dell'attività. Quindi, se l'attività viene distrutta, una volta completato AsyncTask non sarà irraggiungibile e quindi idoneo alla raccolta dei rifiuti? Quindi il riferimento all'attività non avrà importanza perché l'AsyncTask stesso non rimarrà in sospeso.

Sarebbe più efficace mantenere un riferimento settimanale sulla tua attività:

public class WeakReferenceAsyncTaskTestActivity extends Activity {
    private static final int MAX_COUNT = 100;

    private ProgressBar progressBar;

    private AsyncTaskCounter mWorker;

    @SuppressWarnings("deprecation")
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_async_task_test);

        mWorker = (AsyncTaskCounter) getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(this);
        }

        progressBar = (ProgressBar) findViewById(R.id.progressBar1);
        progressBar.setMax(MAX_COUNT);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.activity_async_task_test, menu);
        return true;
    }

    public void onStartButtonClick(View v) {
        startWork();
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new AsyncTaskCounter(this);
        mWorker.execute();
    }

    static class AsyncTaskCounter extends AsyncTask<Void, Integer, Void> {
        WeakReference<WeakReferenceAsyncTaskTestActivity> mActivity;

        AsyncTaskCounter(WeakReferenceAsyncTaskTestActivity activity) {
            mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(activity);
        }

        private static final int SLEEP_TIME = 200;

        @Override
        protected Void doInBackground(Void... params) {
            for (int i = 0; i < MAX_COUNT; i++) {
                try {
                    Thread.sleep(SLEEP_TIME);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                Log.d(getClass().getSimpleName(), "Progress value is " + i);
                Log.d(getClass().getSimpleName(), "getActivity is " + mActivity);
                Log.d(getClass().getSimpleName(), "this is " + this);

                publishProgress(i);
            }
            return null;
        }

        @Override
        protected void onProgressUpdate(Integer... values) {
            super.onProgressUpdate(values);
            if (mActivity != null) {
                mActivity.get().progressBar.setProgress(values[0]);
            }
        }
    }

}

Perché non sovrascrivere il onPause()metodo nell'Attività proprietaria e annullare il AsyncTaskda lì?

Hai assolutamente ragione - ecco perché un movimento lontano dall'uso di compiti / caricatori asincroni nelle attività per recuperare i dati sta guadagnando slancio. Uno dei nuovi modi è utilizzare un framework Volley che essenzialmente fornisce un callback una volta che i dati sono pronti, molto più coerenti con il modello MVC. Volley è stata popolata in Google I / O 2013. Non so perché più persone non ne siano a conoscenza.

Personalmente, estendo Thread e utilizzo un'interfaccia di callback per aggiornare l'interfaccia utente. Non potrei mai far funzionare AsyncTask senza problemi FC. Uso anche una coda non bloccante per gestire il pool di esecuzione.

Ho pensato che annullare funzioni ma non lo fa.

qui hanno RTFMing a riguardo:

"" Se l'attività è già stata avviata, il parametro mayInterruptIfRunning determina se il thread che esegue questa attività deve essere interrotto nel tentativo di interrompere l'attività. "

Ciò non implica, tuttavia, che il thread sia interrompibile. Questa è una cosa Java, non una cosa AsyncTask. "

http://groups.google.com/group/android-developers/browse_thread/thread/dcadb1bc7705f1bb/add136eb4949359d?show_docid=add136eb4949359d

Faresti meglio a pensare ad AsyncTask come qualcosa che è più strettamente associato a un'attività, un contesto, un contesto, ecc. È più conveniente quando il suo ambito è pienamente compreso.

Assicurati di avere una politica di cancellazione nel tuo ciclo di vita in modo che alla fine venga raccolta spazzatura e non conservi più un riferimento alla tua attività e anche possa essere raccolta spazzatura.

Senza cancellare il tuo AsyncTask mentre ti allontani dal tuo Contesto, ti imbatterai in perdite di memoria e NullPointerExceptions, se hai semplicemente bisogno di fornire un feedback come un Toast in una semplice finestra di dialogo, allora un singleton del tuo Contesto dell'applicazione contribuirebbe ad evitare il problema NPE.

AsyncTask non è affatto male, ma c'è sicuramente molta magia in corso che può portare a insidie ​​impreviste.

Per quanto riguarda "esperienze di lavoro con essa": è possibile per uccidere il processo insieme a tutti AsyncTasks, Android sarà ricreare lo stack di attività in modo che l'utente non parlare di nulla.