Czy AsyncTask jest naprawdę wadliwy koncepcyjnie, czy po prostu czegoś mi brakuje?

Powód jest oczywisty: co jeśli aktywność zostaje zniszczona, co uruchomił zadanie?

Ręcznie odłącz Aktywność od AsyncTask W onDestroy(). Ręcznie ponownie powiązać nową aktywność z AsyncTask w onCreate(). Wymaga to statycznej klasy wewnętrznej lub standardowej klasy Java, plus może 10 linii kodu.

Wygląda na to, że AsyncTask jest nieco bardziej niż tylko koncepcyjnie wadliwe. Jest również bezużyteczny ze względu na problemy ze zgodnością. Android Docs czyta:

gdy po raz pierwszy wprowadzono, asynchroniczne zadania były wykonywane seryjnie na jednym wątku tła. począwszy od pączka, została ona zmieniona na pulę wątków pozwalającą na równoległe działanie wielu zadań. rozpoczynając pracę, zadania są z powrotem wykonywane na jednym wątku, aby uniknąć wspólnej aplikacji błędy spowodowane wykonaniem równoległym. Jeśli naprawdę chcesz równoległego wykonania, możesz użyć executeOnExecutor(Executor, Params...) wersja tej metody z THREAD_POOL_EXECUTOR; jednakże, patrz komentarz tam Ostrzeżenia dotyczące jego stosowania.

Zarówno executeOnExecutor() i THREAD_POOL_EXECUTOR są dodane w API poziom 11 (Android 3.0.x, plaster miodu).

Oznacza to, że jeśli utworzysz dwa AsyncTask s, aby pobrać dwa pliki, drugie pobieranie rozpocznie się dopiero po zakończeniu pierwszego. Jeśli czatujesz przez dwa serwery, a pierwszy serwer jest wyłączony, nie połączysz się z drugim przed połączeniem z pierwszym. (O ile oczywiście nie użyjesz nowych funkcji API11, ale to sprawi, że Twój kod będzie niezgodny z 2.x).

I jeśli chcesz celować w oba 2.x i 3.0+, rzeczy stają się naprawdę trudne.

Dodatkowo, docs mówią:

Uwaga: Innym problemem, który możesz napotkać podczas korzystania z wątku roboczego, jest nieoczekiwane ponowne uruchomienie aktywności z powodu zmiana konfiguracji runtime (np. gdy użytkownik zmieni orientację ekranu), która może zniszczyć Twój wątek roboczy . Aby zobaczyć, jak można utrzymać zadanie podczas jednego z tych restartów i jak prawidłowo anulować zadanie, gdy działanie zostanie zniszczone, zobacz kod źródłowy aplikacji Shelves sample.

Prawdopodobnie wszyscy, w tym Google, nadużywamy AsyncTask z punktu widzenia MVC.

Aktywność jest kontrolerem i kontroler nie powinien uruchamiać operacji, które mogą przetrwać widok . Oznacza to, że asynchroniczne zadania powinny być używane z modelu , z klasy, która nie jest związana z cyklem życia aktywności - pamiętaj, że działania są niszczone podczas rotacji. (Co do widoku , zazwyczaj nie programuje się klas pochodzących z np. android.widget.Button, ale możesz. Zazwyczaj jedyną rzeczą jaką robisz w widoku jest xml.)

Nie jestem pewien, czy to prawda, że ryzykujesz wyciek pamięci z odniesieniem do kontekstu z Asynktasku.

Zwyczajowym sposobem ich implementacji jest utworzenie nowej instancji AsyncTask w ramach jednej z metod działania. Więc jeśli aktywność zostanie zniszczona, to po zakończeniu AsyncTask nie będzie nieosiągalna, a następnie kwalifikuje się do zbierania śmieci? Więc odniesienie do aktywności nie będzie miało znaczenia, ponieważ sama AsyncTask nie będzie się kręcić.

Byłoby bardziej wytrzymałe, aby utrzymać tydzień na swojej aktywności:

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]);
            }
        }
    }

}

Dlaczego po prostu nie nadpisać metody onPause() w aktywności właściciela i anulować AsyncTask stamtąd?

Masz absolutną rację - dlatego nabierają rozpędu odejście od używania zadań/ładowarek asynchronicznych w ćwiczeniach do pobierania danych. Jednym z nowych sposobów jest użycie frameworka Volley, który zasadniczo zapewnia wywołanie zwrotne po przygotowaniu danych - znacznie bardziej zgodne z modelem MVC. Volley został spopularyzowany w Google I/O 2013. Nie wiem, dlaczego więcej ludzi nie jest tego świadomych.

Osobiście po prostu przedłużam wątek i używam interfejsu zwrotnego do aktualizacji interfejsu użytkownika. Nigdy nie mogłem uzyskać AsyncTask do pracy prawo bez problemów FC. Używam również kolejki Nie blokującej do zarządzania pulą realizacji.

Myślałem, że cancel działa, ale nie działa.

Tutaj o tym mówią:

"" jeśli zadanie już się rozpoczęło, to może parametr określa, czy wątek wykonujący to zadanie powinien być przerwany w próbie zatrzymania zadania."

Nie oznacza to jednak, że wątek jest przerywany. To jest Java thing, not an AsyncTask rzecz."

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

Lepiej byłoby myśleć o AsyncTask jako o czymś, co jest ściślej powiązane z aktywnością, kontekstem, Contextwrapperem itp. Jest to bardziej wygodne, gdy jego zakres jest w pełni zrozumiały.

Upewnij się, że masz Zasady Anulowania w swoim cyklu życia, aby ostatecznie były zbierane śmieci i nie przechowują odniesienia do Twojej aktywności, a także mogą być zbierane śmieci.

Bez anulowania Asynctasku podczas przechodzenia od kontekstu napotkasz wycieki pamięci i NullPointerExceptions, jeśli po prostu potrzebujesz przekazać opinię jak Toast proste okno dialogowe, a następnie singleton kontekstu aplikacji pomoże uniknąć problemu z NPE.

AsyncTask nie jest zły, ale na pewno dzieje się wiele magii, która może prowadzić do nieprzewidzianych pułapek.

Co do "doświadczenia pracy z nim": jest możliwe Aby Zabij proces wraz ze wszystkimi zadaniami asynchronicznymi Android odtworzy stos aktywności, aby użytkownik o niczym nie wspominał.