Руководство по фоновой работе в Android. Часть 1
О фоновой работе приложений в Android есть много статей, но мне не удалось найти подробного руководства по реализации работы в фоне – думаю, из-за того, что появляется все больше новых инструментов для такой работы. Поэтому я решил написать серию статей о принципах, инструментах и методах асинхронной работы в приложениях под Android.
Будет несколько частей:
- Основной поток, осуществление фоновой работы с помощью AsyncTask, публикация результатов в основном потоке.
- Затруднения при использовании AsyncTask. Loaders как один из способов их избежать.
- Работа в фоне с помощью ThreadPools и EventBus.
- RxJava 2 как метод асинхронной работы.
- Корутины в Kotlin как метод асинхронной работы.
Начнем с первой части.
Основы UI
Первое, что следует понять, – почему мы вообще беспокоимся о работе в фоне в мобильных приложениях.
Во всех приложениях для Android есть хотя бы один поток, на котором происходит прорисовка UI и обработка пользовательского ввода. Поэтому он и называется потоком UI или главным потоком.
Каждый метод жизненного цикла каждого компонента вашего приложения, включая Activity, Service и BroadcastReceiver, исполняется на UI-потоке.
Человеческий глаз преобразовывает сменяющиеся изображения в плавное видео, если частота смены достигает 60 кадров в секунду (да, это магическое число берется отсюда), давая основному потоку только 16 мc для прорисовки всего экрана.
Продолжительность сетевого вызова может быть в тысячи раз больше.
Когда мы хотим загрузить что-либо из Интернета (прогноз погоды, пробки, сколько стоит ваша часть биткоина в данный момент), мы не должны делать это из главного потока. Более того, Android не позволит нам, выбросив NetworkOnMainThreadException.
Семь лет назад, когда я разрабатывал свои первые приложения на Android, подход от Google был ограничен использованием AsyncTasks. Давайте посмотрим, как мы писали код для общения с сервером (псевдокод преимущественно):
Метод doInBackground() гарантированно будет вызван не на основном потоке. Но на каком? Зависит от реализации. Вот как Android выбирает поток (это часть исходного кода класса AsyncTask):
Здесь можно увидеть, что выполнение зависит от параметра Executor. Посмотрим, откуда он берется:
Как здесь указано, по умолчанию executor ссылается на пул потоков размера 1. Это означает, что все AsyncTasks в вашем приложении запускаются последовательно. Это не всегда было верно, так как для версий ОС от DONUT до HONEYCOMB использовался пул размером от 2 до 4(в зависимости от количества ядер процессора). После HONEYCOMB AsyncTasks снова выполняются последовательно по умолчанию.
Итак, работа выполнена, байты закончили свое длинное путешествие с другого полушария. Нужно превратить их во что-то понятное и разместить на экране. К счастью, наша Activity тут как тут. Давайте поместим результат в одно из наших View.
О, черт! Опять исключение!
android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
Но мы не делали никаких сетевых обращений на основном потоке! Правильно, но мы попытались нарушить другой закон UI. Пользовательский интерфейс можно менять только из UI-потока. Это верно не только для Android, но и практически для любой системы, с которой вы столкнетесь. Причину этого хорошо объяснили в Java Concurrency In Practice. Вкратце – архитекторы хотели избежать сложной блокировки при изменениях из нескольких источников (пользовательский ввод, биндинг и другие изменения). Использование единственного потока решает эту проблему.
Да, но UI все равно нужно обновлять. У AsyncTask есть еще метод onPostExecute, который вызывается на UI-потоке:
Как эта магия работает? Посмотрим в исходном коде AsyncTask:
AsyncTask использует Handler для вызова onPostExecute в UI, ровно как и метод postOnUiThread в компонентах Android.
Handler прячет всю внутреннюю кухню. Какую именно? Идея состоит в том, чтобы иметь бесконечный цикл проверки сообщений, приходящих на UI-поток, и обрабатывать их соответствующе. Велосипедов тут никто не изобретает, хотя без кручения педалей не обошлось.
Для Android это реализовано классом Looper, который передается в InternalHandler в приведенном выше коде. Суть класса Looper находится в методе loop:
Он просто опрашивает очередь входящих сообщений в бесконечном цикле и обрабатывает эти сообщения. Это означает, что на UI-потоке должен быть инициализированный экземпляр Looper. Можно получить доступ к нему с помощью статического метода:
Кстати, вы только что узнали, как проверить, вызывается ли ваш код в UI-потоке:
Если вы попытаетесь создать экземпляр Handler в методе doInBackground, то получите другое исключение. Оно сообщит о необходимости наличия Looper для потока. Теперь вы знаете, что это значит.
Надо заметить, что AsyncTask может быть создан только в UI-потоке по указанным выше причинам.
Вы можете подумать, что AsyncTask – это удобный способ выполнения фоновой работы, так как он скрывает сложность и требует немного усилий при использовании, но есть несколько проблем, которые приходится решать по пути:
- Каждый раз нужно писать достаточно много кода для решения относительно простой задачи
- AsyncTasks ничего не знают о жизненном цикле. При неправильном обращении лучшее, что вы получите — утечка памяти, в худшем – сбой
- AsyncTask не поддерживает сохранение состояния прогресса и повторное использование результатов загрузки.
В следующей части я подробно разберу эти проблемы и покажу, как Loaders могут помочь их решить.
Источник
Найден секретный способ освободить до 20 Гб памяти в телефоне
Существует несколько способов очистить систему Android от мусора и освободить таким образом память устройства. Это могут быть как встроенные сервисы, так и некоторые сторонние приложения для очистки. Но что делать, если ни один способ вам не помог и телефон все равно сигнализирует о нехватке памяти? В этом случае можно прибегнуть к ручной очистке и освободить таким образом до 20 Гб памяти смартфона.
Удаление папки Telegram
В 2021 году этот кроссплатформенный мессенджер по праву стал самым популярным приложением в мире, обогнав по числу скачиваний даже такого гиганта как Tik-Tok.
Но у Telegram есть одна небольшая проблема – вся просмотренная вами информация сохраняется во внутренней памяти телефона, тем самым засоряя систему.
Если вы являетесь активным пользователем Telegram, рекомендуем периодически очищать содержимое папки с приложением. Для этого достаточно перейти в любой файловый менеджер и полностью удалить папку Telegram. Не стоит переживать, с приложением после удаления ничего не случится. Система при следующем входе автоматически создаст папку Telegram заново.
Многим пользователям, которые делают такую процедуру впервые после установки Telegram, удается очистить таким образом от 1 до 10 Гб памяти. Проверьте и убедитесь сами.
Удаление папки.Thumbnails
Следующий способ – удаление папки, которая содержится в корневом разделе DCIM (или Pictures) системы Android и содержит в себе все мини копии картинок и фотографий, которые встречаются вам при серфинге в интернете и в приложениях. Этот раздел также может занимать очень большой объем данных, если ранее вы еще не проводили подобную очистку.
Папка.Thumbnails довольно хитрая и скрыта от глаз пользователя в каталогах системы. Чтобы ее найти и удалить, необходимо сначала включить отображение скрытых папок в настройках файлового менеджера.
В некоторых случаях системный файловый менеджер также не дает увидеть эту папку. В этом случае можно попробовать установить стороннее приложение, например ES-проводник, а затем перейти в каталог DCIM (Pictures), включить отображение скрытых папок и удалить папку.Thumbnails.
Если вы больше не хотите, чтобы миниатюры засоряли вам память устройства, можно немного перехитрить систему, создав в папке DCIM новый файл с другим расширением, но с тем же названием.Thumbnails.
Система Android устроена таким образом, что никогда не позволит создать два файла с одинаковым названием, поэтому папка.Thumbnails больше не сможет там появиться. Сделать это также можно с помощью ES-проводника.
Нажимаем на три точки в верхнем правом углу приложения → «+Создать» → Файл. Называем файл.Thumbnails (обязательно ставим точку вначале).
Готово! Теперь наш созданный файл не позволит системе Android создать папку.Thumbnails, а значит система больше не будет засоряться лишними миниатюрами.
Удаление папки Data
Еще одна папка, занимающая большое количество памяти в телефоне – папка Data, которая находится внутри каталога Android. Эта папка содержит кэш, а также некоторые настройки и служебную информацию о приложениях. Но каких-либо серьезных системных данных, влияющих на работу системы в целом, она не содержит. Поэтому ее также можно удалить, освободив до 10 Гб памяти.
Удалять ее нужно только в обход корзины, так как сама корзина является вложенной в папку Data, о чем система предупреждает при попытке удалить ее стандартным путем. Поэтому нам потребуется снова воспользоваться сторонним файловым менеджером, который позволит удалить папку Data напрямую, без промежуточных инстанций.
Открываем ES проводник и переходим во внутренний каталог системы. Затем переходим в папку Android→Выделяем папку Data→ Нажимаем Удалить. Убираем галочку с пункта «Перенести в корзину» и нажимаем ОК. Нам удалось очистить таким образом почти 3 Гб внутренней памяти.
Заключение
В далеком 1981 году на пути становления IBM, Билл Гейтс произнес, ставшую сегодня забавным мемом, фразу: «В будущем 640 Кб будет достаточно для каждого». Из-за особенностей первых процессоров, никто не мог и представить, что когда-нибудь в компьютерах, а тем более в мобильных устройствах удастся разместить большее количество памяти, а главное, что кому-то может понадобиться такой объем информации.
Несмотря на то, что сегодня любой смартфон обладает памятью в десятки тысяч раз, превышающий этот объем, нехватка памяти до сих пор остается актуальной проблемой, особенно для бюджетных моделей смартфонов. Мы надеемся, что с помощью нашей инструкции вам удастся очистить ваше устройство и наконец решить данную проблему.
Источник
Tasks и Back Stack в Android
Итак. Каждое Android приложение, как минимум, состоит из фундаментальных объектов системы — Activity. Activity — это отдельный экран который имеет свою отдельную логику и UI. Количество Activity в приложении бывает разное, от одного до много. При переходах между различными Activity пользователь всегда может вернуться на предыдущую, закрытую Activity при нажатии кнопки back на устройстве. Подобная логика реализована с помощью стека (Activity Stack). Его организация «last in, first out» — т.е. последний вошел, первый вышел. При открытии новой Activity она становится вершиной, а предыдущая уходит в режим stop. Стек не может перемешиваться, он имеет возможность добавления на вершину новой Activity и удаление верхней текущей. Одна и та же Activity может находиться в стеке, сколько угодно раз.
Task — это набор Activity. Каждый таск содержит свой стек. В стандартной ситуации, каждое приложение имеет свой таск и свой стек. При сворачивании приложения, таск уходит в background, но не умирает. Он хранит весь свой стек и при очередном открытии приложения через менеджер или через launcher, существующий таск восстановится и продолжит свою работу.
Ниже покажу картинку, как работает стек.
Если продолжать нажимать кнопку back, то стек будет удалять Activity до того, пока не останется главная корневая. Если же на ней пользователь нажмет back, приложение закроется и таск умрет. Кстати, я говорил о том, что когда мы сворачиваем наше приложение и запускам например новое, то наш таск просто уходит в background и будет ждать момента, пока мы его вызовем. На самом деле есть одно «но». Если мы будем иметь много задач в background или же просто сильно нагружать свое устройство, не мала вероятность того, что таск умрет из за нехватки системных ресурсов. Это не война конечно, но то что мы потеряем все наши текущие данные и наш стек очистится — это точно. Кстати для избежания потери данных в таком случаи, вам стоит почитать про SavingActivityState.
Маленький итог
Управление тасками
Существует два пути для изменения стандартной организации тасков. Мы можем устанавливать специальные атрибуты в манифесте для каждой Activity. Также мы можем устанавливать специальные флаги для Intent, который запускает новую Activity с помощью startActivity(). Заметьте, что иногда атрибуты в манифесте и флаги в Intent могут противоречить друг другу. В этом случаи флаги Intent будут более приоритетны.
Атрибут launchMode
Для каждой Activity в манифесте можно указать атрибут launchMode. Он имеет несколько значений:
- standard — (по умолчанию) при запуске Activity создается новый экземпляр в стеке. Activity может размещаться в стеке несколько раз
- singleTop — Activity может распологаться в стеке несколько раз. Новая запись в стеке создается только в том случаи, если данная Activity не расположена в вершине стека. Если она на данный момент является вершиной, то у нее сработает onNewIntent() метод, но она не будет пересоздана
- singleTask — создает новый таск и устанавливает Activity корнeвой для него, но только в случаи, если экземпляра данной Activity нет ни в одном другом таске. Если Activity уже расположена в каком либо таске, то откроется именно тот экземпляр и вызовется метод onNewIntent(). Она в свое время становится главной, и все верхние экземпляры удаляются, если они есть. Только один экземпляр такой Activity может существовать
- singleInstance — тоже что и singleTask, но для данной Activity всегда будет создаваться отдельный таск и она будет в ней корневой. Данный флаг указывает, что Activity будет одним и единственным членом своего таска
На самом деле не важно, в каком таске открыта новая Activity. При нажатии кнопки back мы все равно вернемся на предыдущий таск и предыдущие Activity. Единственный момент, который нужно учитывать — это параметр singleTask. Если при открытии такой Activity мы достанем ее из другого background таска, то мы полностью переключаемся на него и на его стек. на картинке ниже это продемонстрировано.
Флаги
Как и говорил, мы можем устанавливать специальный флаги для Intent, который запускает новую Activity. Флаги более приоритетны, чем launchMode. Существует несколько флагов:
- FLAG_ACTIVITY_NEW_TASK — запускает Activity в новом таске. Если уже существует таск с экземпляром данной Activity, то этот таск становится активным, и срабатываем метод onNewIntent().
Флаг аналогичен параметру singleTop описанному выше - FLAG_ACTIVITY_SINGLE_TOP — если Activity запускает сама себя, т.е. она находится в вершине стека, то вместо создания нового экземпляра в стеке вызывается метод onNewIntent().
Флаг аналогичен параметру singleTop описанному выше - FLAG_ACTIVITY_CLEAR_TOP — если экземпляр данной Activity уже существует в стеке данного таска, то все Activity, находящиеся поверх нее разрушаются и этот экземпляр становится вершиной стека. Также вызовется onNewIntent()
Affinity
Стандартно все Activity нашего приложения работают в одном таске. По желанию мы можем изменять такое поведение и указывать, чтобы в одном приложении Activity работали в разных тасках, или Activity разных приложений работали в одном. Для этого мы можем в манифесте для каждой Activity указывать название таска параметром taskAffinity. Это строковое значение, которое не должно совпадать с названием package, т.к. стандартный таск приложения называется именно как наш пакет. В общем случаи данный параметр указывает, что Activity будет гарантированно открываться в своём отдельном таске. Данный параметр актуален, если мы указываем флаг FLAG_ACTIVITY_NEW_TASK или устанавливаем для Activity атрибут allowTaskReparenting=«true». Этот атрибут указывает, что Activity может перемещаться между тасками, который её запустил и таском, который указан в taskAffinity, если один из них становится активным.
Чистка стека
Если таск долгое время находится в background, то система сама чистит его стек, оставляя только корневую Activity. Данное поведение обусловлено тем, что пользователь может забыть, что он делал в приложении до этого и скорее всего зашел в него снова уже с другой целью. Данная логика также может быть изменена с помощью нескольких атрибутов в манифесте.
- alwaysRetainTaskState — если флаг установлен в true для корневой Activity, то стек не будет чиститься и полностью восстановится даже после длительного времени
- clearTaskOnLaunch — если установить флаг в true для корневой Activity, то стек будет чиститься моментально, как только пользователь покинет таск. Полная противоположность alwaysRetainTaskState
- finishOnTaskLaunch — работает аналогично clearTaskOnLaunch, но может устанавливаться на любую Activity и удалять из стека именно её
Это всё для данного топика. Статья не импровизированная, а по сути является вольным переводом официальной документации. Рекомендую собрать легкий пример и поэксперементировать с флагами и атрибутами. Некоторые моменты, лично для меня были, неожиданно интересными. любые ошибки и недоработки учту в лс. Спасибо.
Источник
