Чи AsyncTask насправді концептуально помилковий чи мені просто щось не вистачає?

Я досліджував цю проблему вже місяцями, придумав різні її рішення, якими я не задоволений, оскільки всі вони масові хаки. Я досі не можу повірити, що клас, який зіпсувався в дизайні, ввійшов у рамки, і ніхто про це не говорить, тому, мабуть, мені просто щось не вистачає.

Проблема в с AsyncTask. Згідно з документацією, це

"дозволяє виконувати фонові операції та публікувати результати в потоці інтерфейсу користувача, не маніпулюючи потоками та / або обробниками."

Потім приклад продовжує показувати, як showDialog()викликається деякий зразковий метод onPostExecute(). Це, однак, здається мені цілком надуманим , тому що для показу діалогового вікна завжди потрібна посилання на дійсну Context, а AsyncTask ніколи не має чіткого посилання на контекстний об'єкт .

Причина очевидна: що робити, якщо діяльність знищується, що ініціювало завдання? Це може траплятися постійно, наприклад, тому що ви перевернули екран. Якщо завдання міститиме посилання на контекст, який його створив, ви не тільки тримаєтесь за непотрібним контекстним об'єктом (вікно буде зруйновано і будь-яка взаємодія з інтерфейсом вийде з ладу за винятком!), Ви навіть ризикуєте створити витік пам'яті.

Якщо моя логіка тут хибна, це означає: onPostExecute()цілком марний, адже яке добре для цього методу запускати на потоці інтерфейсу, якщо у вас немає доступу до жодного контексту? Тут не можна зробити нічого значимого.

Одним із завдань було б передати екземпляри контексту AsyncTask, але Handlerекземпляр. Це працює: оскільки обробник невміло зв’язує контекст і завдання, ви можете обмінюватися повідомленнями між ними, не ризикуючи протікати (правда?). Але це означатиме, що передумова AsyncTask, а саме, що вам не потрібно турбуватися з обробниками, є неправильним. Це також здається зловживанням Handler, оскільки ви надсилаєте та отримуєте повідомлення в одному потоці (ви створюєте його в потоці інтерфейсу користувача та надсилаєте через нього в onPostExecute (), який також виконується в потоці інтерфейсу).

На додаток до цього, навіть із цим вирішенням, у вас все ще виникає проблема, що коли контекст руйнується, у вас немає запису про виконання завдань, які він виконував. Це означає, що вам потрібно перезапустити будь-які завдання під час створення контексту, наприклад, після зміни орієнтації екрана. Це повільно і марно.

Моє рішення цього (як реалізовано в бібліотеці Droid-Fu ) полягає в підтримці відображення WeakReferences від імен компонентів до їх поточних примірників на унікальному об’єкті програми. Кожного разу, коли запускається AsyncTask, він записує контекст виклику на цій карті, і при кожному зворотному виклику він отримує поточний екземпляр контексту з цього відображення. Це гарантує, що ви ніколи не будете посилатися на нескладний контекстний екземпляр, і ви завжди матимете доступ до дійсного контексту в зворотному звороті, щоб ви могли робити значну роботу інтерфейсу там. Він також не протікає, оскільки посилання слабкі та очищаються, коли жодного примірника певного компонента більше не існує.

Але це складний спосіб вирішення і вимагає підкласи деяких класів бібліотек Droid-Fu, що робить це досить нав'язливим підходом.

Тепер я просто хочу знати: я просто масово щось пропускаю, чи AsyncTask справді повністю помилковий? Як ви працюєте з цим своїм досвідом? Як ви вирішили ці проблеми?

Дякуємо за ваш внесок

Як щодо щось подібне:

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(...);
    }
}

Причина очевидна: що робити, якщо діяльність знищується, що ініціювало завдання?

Відмежуйте діяльність вручну від AsyncTaskв onDestroy(). Вручну відновіть нову діяльність до входу AsyncTaskв onCreate(). Для цього потрібен або статичний внутрішній клас, або стандартний клас Java, плюс, можливо, 10 рядків коду.

Схоже AsyncTask, це дещо більше, ніж просто концептуально недолік . Він також непридатний для проблем сумісності. Документи Android читали:

При першому введенні AsyncTasks виконувались послідовно на одному фоновому потоці. Починаючи з DONUT, це було змінено на пул потоків, що дозволяють паралельно працювати безлічі завдань. Починаючи HONEYCOMB, завдання повертаються до виконання в одному потоці, щоб уникнути поширених помилок програми, викликаних паралельним виконанням. Якщо ви справді хочете паралельного виконання, ви можете використовувати executeOnExecutor(Executor, Params...) версію цього методу з THREAD_POOL_EXECUTOR ; однак, дивіться коментар щодо попереджень щодо його використання.

Обидва executeOnExecutor()і THREAD_POOL_EXECUTORє Додано в рівні API 11 (Android 3.0.x, Honeycomb).

Це означає, що якщо ви створите два AsyncTasks для завантаження двох файлів, друге завантаження не розпочнеться, поки перший не закінчиться. Якщо ви спілкуєтесь через два сервери, а перший сервер не працює, ви не підключитесь до другого перед тим, як вимкнено з'єднання з першим. (Якщо, звичайно, ви не використовуєте нові функції API11, але це зробить ваш код несумісним з 2.x).

І якщо ви хочете націлити на 2.x і 3.0+, матеріал стає справді складним.

Крім того, документи говорять:

Увага: Ще одна проблема, з якою ви можете зіткнутися під час використання робочої нитки, - це несподівані перезавантаження вашої діяльності через зміну конфігурації часу виконання (наприклад, коли користувач змінює орієнтацію екрана), що може зруйнувати вашу робочу нитку . Щоб побачити, як ви можете зберегти своє завдання під час одного з цих перезавантажень та як правильно скасувати завдання, коли діяльність знищена, див. Вихідний код для прикладу програми "Шельви".

Напевно, ми всі, включаючи Google, зловживаємо AsyncTaskз точки зору MVC .

Діяльність - це контролер , і контролер не повинен починати операції, які можуть переживати погляд . Тобто AsyncTasks слід використовувати з Model , з класу, який не пов'язаний з життєвим циклом діяльності - пам’ятайте, що Діяльність знищується при обертанні. (Щодо перегляду , ви зазвичай не програмуєте класи, похідні, наприклад, від android.widget.Button, але ви можете. Зазвичай, єдине, що ви робите щодо перегляду - це xml.)

Іншими словами, неправильно розміщувати похідні AsyncTask у методах діяльності. ОТОХ, якщо ми не мусимо використовувати AsyncTasks в діяльності, AsyncTask втрачає свою привабливість: його раніше рекламували як швидке та просте виправлення.

Я не впевнений, що це правда, що ви ризикуєте витік пам'яті з посиланням на контекст AsyncTask.

Звичайний спосіб їх реалізації - створити новий екземпляр AsyncTask в межах одного з методів діяльності. Отже, якщо активність буде знищена, то після завершення роботи AsyncTask це буде недоступно, а потім придатне для збору сміття? Тому посилання на активність не матиме значення, оскільки сам AsyncTask не буде зависати.

Було б надійніше зберегти тижневу референцію про свою діяльність:

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

}

Чому б просто не змінити onPause()метод у власній діяльності та скасувати AsyncTaskзвідти?

Ви абсолютно праві - ось чому відхилення від використання асинхронних завдань / завантажувачів у заходах для отримання даних набирає обертів. Одним із нових способів є використання фреймворку Volley, який по суті забезпечує зворотний виклик, коли дані будуть готові - набагато більше відповідає моделі MVC. Воллі популяризувався в Google I / O 2013. Не впевнений, чому більше людей не знають про це.

Особисто я просто розширюю Thread і використовую інтерфейс зворотного дзвінка для оновлення інтерфейсу користувача. Я ніколи не міг змусити AsyncTask працювати правильно без проблем з FC. Я також використовую неблокуючу чергу для управління пулом виконання.

Я думав, що скасувати працює, але це не так.

ось вони RTFMing про це:

"" Якщо завдання вже запущено, параметр mayInterruptIfRunning визначає, чи слід переривати потік, що виконує це завдання, намагаючись зупинити завдання. "

Однак це не означає, що нитка є переривною. Це справа Java, а не річ AsyncTask. "

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

Вам буде краще думати про AsyncTask як про щось, що тісніше поєднується з Activity, Context, ContextWrapper і т. Д. Це більше зручності, коли його сфера повністю зрозуміла.

Переконайтеся, що у вашому життєвому циклі є політика щодо скасування, щоб вона врешті-решт збиралася сміттям і більше не зберігала посилання на вашу діяльність, а також могла збиратися сміття.

Не скасовуючи AsyncTask під час відходу від вашого контексту, ви зіткнетесь із витоками пам'яті та NullPointerExceptions, якщо вам просто потрібно надати зворотний зв'язок, як простий діалог Toast, тоді однократне повідомлення вашого контексту додатків допоможе уникнути проблеми NPE.

AsyncTask - це не все погано, але, безумовно, відбувається багато магії, яка може призвести до деяких непередбачених підводних каменів.

Що стосується «досвіду роботи з ним»: це можливо , щоб вбити процес разом з усіма AsyncTasks, Android буде заново створити стек активності , так що користувач не буде нічого згадувати.