Android AsyncTask для тривалих операцій

Цитуючи документацію для AsyncTask, знайдену тут , там сказано:

AsyncTasks в ідеалі слід використовувати для коротких операцій (не більше декількох секунд.) Якщо вам потрібно тримати потоки запущеними протягом тривалого періоду часу, настійно рекомендується використовувати різні API, надані пакетом java.util.concurrent, таким як Виконавець, ThreadPoolExecutor та FutureTask.

Тепер виникає моє запитання: чому? У doInBackground()функції збігає в потоці призначеного для користувача інтерфейсу так , що шкода є, маючи довго запущену операцію тут?

Це дуже гарне питання, для програмування Android потрібен час, щоб повністю зрозуміти проблему. Справді, AsyncTask має дві основні проблеми, пов'язані між собою:

• Вони погано прив’язані до життєвого циклу діяльності
• Вони дуже легко створюють витоки пам'яті.

Всередині програми RoboSpice Motivations ( доступна в Google Play ) ми детально відповідаємо на це запитання. Це дасть глибокий огляд AsyncTasks, Loaders, їх особливостей та недоліків, а також познайомить вас з альтернативним рішенням для мережевих запитів: RoboSpice. Мережеві запити є загальною вимогою для Android і за своєю природою тривають операції. Ось уривок із програми:

Життєвий цикл AsyncTask та Activity

AsyncTasks не відповідають життєвому циклу екземплярів Activity. Якщо ви запустите AsyncTask всередині Activity і обернете пристрій, Activity буде знищено, і буде створено новий екземпляр. Але AsyncTask не помре. Він буде продовжувати жити, поки не завершиться.

І коли він завершиться, AsyncTask не буде оновлювати інтерфейс нової активності. Дійсно, він оновлює попередній екземпляр діяльності, який більше не відображається. Це може призвести до винятку типу java.lang.IllegalArgumentException: подання, не приєднане до диспетчера вікон, якщо ви використовуєте, наприклад, findViewById для отримання подання всередині Activity.

Проблема витоку пам'яті

Дуже зручно створювати AsyncTasks як внутрішні класи вашої діяльності. Оскільки AsyncTask потрібно буде маніпулювати поданнями Activity, коли завдання завершено або виконується, використання внутрішнього класу Activity здається зручним: внутрішні класи можуть отримувати безпосередній доступ до будь-якого поля зовнішнього класу.

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

У довгостроковій перспективі це спричиняє витік пам’яті: якщо AsyncTask триває довго, він зберігає активність «живою», тоді як Android хотів би позбутися від неї, оскільки вона більше не відображається. Діяльність не може бути зібрана сміттям, і це центральний механізм для Android для збереження ресурсів на пристрої.

Насправді дуже погана ідея використовувати AsyncTasks для тривалих операцій. Тим не менше, вони чудово підходять для короткоживучих, таких як оновлення подання через 1 або 2 секунди.

Я закликаю вас завантажити додаток RoboSpice Motivations , він справді пояснює це поглиблено, а також надає зразки та демонстрації різних способів виконання деяких фонових операцій.

чому?

Оскільки AsyncTaskза замовчуванням використовує пул потоків, який ви не створили . Ніколи не зв’язуйте ресурси з пулу, який ви не створили, оскільки ви не знаєте, які вимоги до цього пулу. І ніколи не зв’язуйте ресурси з пулу, який ви не створили, якщо документація для цього пулу говорить вам не робити, як у цьому випадку.

Зокрема, починаючи з Android 3.2, у пулі потоків, який використовується за AsyncTaskзамовчуванням (для програм, android:targetSdkVersionвстановлених на 13 або вище), є лише один потік - якщо ви зв'яжете цей потік на невизначений час, жодне з ваших інших завдань не буде запущено.

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

Для більш тривалих завдань, які не потребують оновлення інтерфейсу, замість них ви можете використовувати служби, оскільки вони можуть жити навіть без інтерфейсу.

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

для отримання додаткової інформації див. теми:

AsyncTask довше, ніж кілька секунд?

і

AsyncTask не зупиняється, навіть коли діяльність знищена

Проблема AsyncTask полягає в тому, що якщо він визначений як нестатичний внутрішній клас діяльності, він матиме посилання на Activity. У сценарії, коли діяльність контейнер асинхронного завдання закінчується, але фонова робота в AsyncTask продовжується, об’єкт активності не буде зібраним сміттям, оскільки на нього є посилання, це спричиняє витік пам'яті.

Рішенням для виправлення цього є визначення асинхронного завдання як статичного внутрішнього класу активності та використання слабкого посилання на контекст.

Але все ж корисно використовувати його для простих і швидких фонових завдань. Для розробки програми з чистим кодом краще використовувати RxJava для запуску складних фонових завдань та оновлення інтерфейсу користувача з результатами від нього.