Android не останавливаются процессы

Процессы и потоки в Android: пишем AsyncTask правильно

Продолжаю свои повествования об Android. И в этот раз хочу поделиться ценной информацией о процессах и потоках, которая должна быть хорошо усвоена и всегда оставаться под рукой во избежании ошибок и недопонимания при написании приложений. В конце статьи приведу пример реализации AsyncTask, который загружает в ImageView картинку по нажатию на кнопку.

Прежде всего отмечу, что подробнее о данной теме можно прочесть в данном руководстве — developer.android.com/guide/topics/fundamentals/processes-and-threads.html

На заметку о процессах и потоках в Android

Когда запускается компонент приложения и приложение не имеет других запущенных компонентов, Android создает новый процесс для приложения с одним потоком исполнения. По умолчанию все компоненты одного приложения запускаются в одном процессе, в потоке называемом «главный». Если компонент приложения запускается и уже существует процесс для данного приложения(какой-то компонент из приложения существует), тогда компонент запущен в этом процессе и использует его поток выполнения. Вы можете изменить данное поведение, задав разные процессы для разных компонентов вашего приложения. Кроме того вы можете добавить потоки в любой процесс.

Задать отдельный процесс для компонента можно с помощью файла манифеста. Каждый тег компонента(activity, service, receiver и provider) поддерживает атрибут android:process. Данный атрибут позволяет задать процесс, в котором будет выполняться компонент. Также вы можете задать процесс в котором будут выполняться компоненты разных приложений. Также данный атрибут поддерживается тегом application, что позволяет задать определенный процесс для всех компонентов приложения.

Android пытается поддерживать процесс приложения как можно дольше, но когда потребуются ресурсы старые процессы будут вытеснены по иерархии важности.

Существует 5 уровней иерархии важности: (процессы первого уровня из списка будут удалены последними)

1.Процесс с которым взаимодействует пользователь(Foreground process)
К таким процессам относится например: активити с которым взаимодействует пользовать; сервис(экземпляр Service), с которым взаимодействует пользователь; сервис запущенный методом startForeground(); сервис, который выполняет один из методов своего жизненного цикла; BroadcastReceiver который выполняет метод onReceive().

2.Видимый процесс
Процесс, в котором не выполнены условия из пункта №1, но который влияет на то, что пользователь видит на экране. К примеру, вызван метод onPause() активити.

3.Сервисный процесс
Служба запущенная методом startService()

4.Фоновый процесс
Процесс выполняемый в фоновом режиме, который невиден пользователю.

Отмечу, что в компонентах приложения существует метод onLowMemory(), но полагаться на то, что данный метод будет вызван нельзя, также как нельзя на 100% полагаться на метод onDestroy(), поэтому логику сохранения данных или каких-либо настроек можно осуществить в методе onStop(), который(как уверяют) точно вызывается.

Когда запускается приложение, система создает «главный» поток выполнения для данного приложения, который также называется UI-потоком. Этот поток очень важен, так как именно в нем происходит отрисовка виджетов(кнопочек, списков), обработка событий вашего приложения. Система не создает отдельный поток для каждого экземпляра компонента. Все компоненты, которые запущенны в одном процессе будут созданы в потоке UI. Библиотека пользовательского интерфейса Android не является потоково-безопасной, поэтому необходимо соблюдать два важных правила:

1) Не блокировать поток UI
2) Не обращаться к компонентам пользовательского интерфейса не из UI-потока

Теперь, предположим, что у нас возникла задача — загрузить картину в ImageView из сети и тут же ее отобразить. Как мы поступим? По логике: мы создадим отдельный поток, который и сделает всю нашу работу, примерно так:

Выглядит правдоподобно, так как мы вынесли операцию загрузки картинки в отдельный поток. Проблема в том, что мы нарушили правило №2. Исправить эту проблему можно с помощью следующих методов:

Activity.runOnUiThread(Runnable)
View.post(Runnable)
View.postDelayed(Runnable, long)

К примеру, воспользуемся первым из них:

Теперь реализация потоково-безопасная: сетевая операция выполняется в отдельном потоке, а к ImageView обращаемся из потока UI.
К счастью, данные операции можно объединить с помощью наследования класса Handler и реализации нужной логики, но лучшее решение — наследовать класс AsyncTask.

AsyncTask позволяет выполнить асинхронную работу и делать обновления пользовательского интерфейса.
Для обновления реализуйте метод onPostExecute(), а всю фоновую работу заключите в метод doInBackground(). После того, как вы реализуете свою собственную задачу, необходимо ее запустить методом execute().

Привожу обещанный пример AsyncTask, в котором реализована задача загрузки и отображения картинки(вариант с аннотациями и отклонением от применения стандартного протокола диалогов):

А теперь рассмотрим самый правильный вариант с точки зрения работы с диалогами:

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

Не забудьте добавить в свою разметку кнопочки атрибут с указанным значением: android:onClick=«runButtonHandler»

И добавлю: в оффициальном документе(Тыц ) также, как и в моем случае, не используется preExecute(), но если вам понадобится выполнить какие-то действия с вашим пользовательским интерфейсом до начала выполнения задачи, то смело используйте данный метод.

Параметры передаваемые в AsyncTask:
1. Параметры(в нашем случае адрес URL).
2. Прогресс (единицы задающие ход изменения задачи). В нашем случае не используется.
3. Результат выполнения задачи(в нашем случае объект Bitmap)

Код довольно прост: всю фоновую работу мы выполняем в методе doInBackGround(), вызывая метод publishProgress(), чтобы во время загрузки картинки крутился наш ProgressDialog при вызове метода onProgressUpdate(). После выполнения фоновой работы вызывается метод onPostExecute() в который передается результат работы метода doInBackGround(), в нашем случае это объект Bitmap и тут же мы его загружаем в ImageView.
Отмечу пару важных моментов, которые нужно учитывать:

1) Метод doInBackGround() выполняется в фоновом потоке, потому доступа к потоку UI внутри данного метода нет.
2) Методы onPostExecute() и onProgressUpdate() выполняются в потоке UI, потому мы можем смело обращаться к нашим компонентам UI.

Да, я снова применил библиотеку android-annotations, так что не пугайтесь аннотациям.

Хочу отметить важность понимания модели работы процессов в Android, чтобы не допустить ошибок при разработке приложений.

Данная статья это переработка доступной информации + личный опыт при реализации указанной задачи и работе с потоками.

Как всегда пожелания и замечания по поводу материала статьи в личку. Если вам есть что-то добавить или дополнить — смело пишите в комментарии.

UPD Статья обновленна добавлением более правильной версии в плане работы с диалогами.

Источник

7 способов закрыть все фоновые приложения на Android

Несмотря на то, что рынок переполнен множеством устройств с поражающей производительностью и сроком жизни батареи, не все используют новейшие модели смартфонов с последней версией операционной системы. Так как большинство пользователей предпочитают дешевые устаревшие модели, становится очевидным, что от них не добиться желаемой производительности или срока службы батареи.

Если ты когда-либо задумывался о возможности их улучшения, стоит задуматься над использованием диспетчера задач. Сейчас мы расскажем про семь способов быстро закрыть приложения, которые работаю в фоновом режиме ОС Android. В процессе их тестирования, мы заметили, что лучшие результаты достигаются на старых и дешевых моделях, которые замедляются с течением времени и не могут обеспечить батареи нужную мощность.

Greenify

Greenify оценивается как лучший помощник, сохраняющий заряд батареи, и как один из лучших убийц приложений для операционной системы Android. Greenify отыскивает другие программы, которые тратят много зарядки, и затем ограничивает время их работы в фоновом режиме, переводя в состояние наподобие гибернации, что приводит к продлению времени работы смартфона и небольшому улучшению производительности.

Для пользователей более новых версий Android (Marshmallow и выше) предлагается режим агрессивной спячки, который для большей эффективности усиливает режим спячки, встроенный в ОС Android. Отключение фоновых программ также предохраняет их от подвисания, что действительно полезно для дешевых устройств.

При наличии root-прав вы можете расширить эту функцию и получить специальные возможности. Greenify — хороший выбор еще и потому, что позволяет составить черный список тех утилит, которые нежелательны для запуска.

Clean Master

Следующая программа — это Clean Master, один из самых популярных убийц приложений в Play Store, который предлагает тонну функций. Приложение включает в себя очистку мусора, бесплатный антивирус, облачное хранилище для фотографий, расширение для браузера, ускоритель телефона за счет чистки оперативной памяти, увеличение времени работы батареи и утилиту, которая удаляет ненужные файлы из WhatsApp. Одним словом, это достаточно большой функционал для одного приложения, что делает Clean Master очень полезным.

Специальный помощник в приложении выдает список программ, которые тратят много заряда аккумулятора, и предлагает отключить их. Clean Master также ведет статистику, демонстрирующую влияние отключения приложения на работу батареи, отображая часы службы батареи, которые вы получите, отключив те или иные приложения.

ES Task Manager

Если вы являетесь владельцем телефона на Android, то уже возможно слышал о ES Task Manager — убийце приложений от того же разработчика, что и ES File Explorer. В нем есть диспетчер задач, очистка кэша, менеджер загрузки устройства, оптимизатор работы батареи, анализ карты памяти и многое другое.

В этом помощнике доступна функция отключения всех программ одним нажатием. Впрочем, данная опция может раздражать тех, кто не собирался отключать все инструменты сразу. Менеджер запуска — полезное дополнение, позволяющее исключить ненужные приложения из списка тех, которые запускаются вместе с включением смартфона. ES Task Manager незаменим для тех, кто хотел бы одним нажатием ускорить работу телефона.

Advanced Task Manager

В отличие от ES Task Manager, Advanced Task Manager показывает список программ, которые запущены на устройстве, и дает возможность выбрать ненужные и отключить их для ускорения работы устройства и продления заряда батареи. Вы можете воспользоваться также списком для игнорирования, чтобы сохранить важные приложения от внезапного отключения и потери данных.

Внутри имеется сканер вирусов, чтобы защитить телефон от вредоносных файлов, которые вы можете случайно скачать. Не лишней будет и специальная функция, благодаря которой вы можете относительно просто удалять ненужные приложения. И самое важное: Advanced Task Manager позволяет автоматизировать процесс отключения приложений, которые какое-то время находятся в режиме ожидания.

ShutApp

ShutApp позволит немедленно отключать приложения, использующие заряд батареи, одним нажатием. Инструмент прост в использовании и разделен на три части. Поэтому можно отключить отдельные приложения, ввести процессор в гибернацию в режиме ожидания или настроить функции вроде WiFi, Bluetooth и синхронизацию на автоматическое отключение, когда они не используются.

Решение «гибернация в одно нажатие» выполняется, чтобы помочь значительно сохранить заряд батареи. Единственная причина, по которой это приложение в конце списка, — это раздражающие полноэкранные рекламные объявления, которые всплывают довольно часто. В программе есть возможность отключить рекламу и раскрыть все функции. Так что, если реклама будет раздражать, просто купите платную версию приложения.

Naptime

Приложение Naptime от известного программиста Франсиско Франко, отлично находит и отключает приложения, заставляя правильно работать в режиме ожидания. Режим агрессивной спячки перестает работать после включения экрана. Это означает, что ни один из процессов не сможет быть скрыт во время использования устройства.

Приложению требуются root-права для работы, но имеется обходной путь. Для этого необходимо получить разрешения Naptime DUMP через ADB посредством удаления тех команд, которые будут всплывать после того, как запустится программа в первый раз. Очевидно, Naptime не рассчитано на начинающих и должно использоваться только теми, кто обладает хотя бы базовыми знаниями в использовании ADB.

Функции для разработчиков

В случае если вы не хочется использовать сторонние инструменты для отключения приложений, то можете использовать встроенные инструменты для получения того же эффекта. Они помогут ограничить количество фоновых процессов, которые могут быть запущены на устройстве. Чтобы получить доступ к этим настройкам, достаточно сделать несколько простых шагов.

Войти в режим разработчика, много раз нажимая на номер прошивки в меню «О телефоне» в настройках. В меню «Для разработчиков» пролистать до меню «Приложения» и нажать на кнопку «Лимит фоновых процессов» и выбрать количество процессов, которое для вас допустимо, — вот и все!

Вы также можете предотвратить запуск приложений в фоновом режиме, нажав на вариант «Без фоновых процессов» в том же меню. Это завершит любой процесс при переключении на другой. К сожалению, это не всегда положительно влияет на общую производительность, так как сначала придется запускать программы каждый раз при переключении на них, что будет занимать некоторое время.

Источник

Наша Service и опасна и трудна или некоторые аспекты выживания служб в Android

Вместо введения

Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.

Итак, каркас простейшего приложения для отработки приемов борьбы.

Здесь все элементарно. SomeActivity при создании запускает службу KamikadzeService, которая, в свою очередь, стартует, как липкая или sticky. Для агентов враждебных платформ поясню, что служба при старте дает указание операционной системе в случае непредвиденного завершения сервиса перезапустить его при первой возможности. Делает она это, возвращая START_STICKY из метода onStartCommand. Если служба не липкая, то после удаления пользователем задачи шансов на возрождение после смерти у нее не будет.

Метод onTaskRemoved вызывается системой как раз при удалении пользователем задачи. Здесь совершенно необходимо упомянуть об атрибуте службы android:stopWithTask, который можно выставить в манифесте. Как можно догадаться по его названию (либо просто почитав документацию), если android:stopWithTask = ”true”, то волевое движение пальца пользователя по нужному квадратику в Recent Tasks List наряду с удалением задачи будет и останавливать службу. Поскольку в этом случае сервис будет считаться согласным на остановку, то и перезапускать автоматически никто ничего не будет — умерла, так умерла.

В самом начале моей борьбы за относительную устойчивость сервисов, обнаружив наличие этого флага, я имел наивность предположить, что проблема решится установкой android:stopWithTask = ”false” и сервис больше не будет умирать вместе с задачей. Увы, действительность и мечтания имели ряд существенных отличий. Действительно, в этом случае система не будет останавливать службу. Она ее просто прибьет без соответствующего предупреждения. Кстати, по умолчанию этот атрибут равен ”false”, из чего уже можно было догадаться, что явная его установка ни к чему не приведет

Для столь же простодушных разработчиков подытожу: значение атрибута службы android:stopWithTask никак не влияет на ее шансы остаться в живых после удаления задачи пользователем, служба в любом случае обречена. Этот атрибут всего лишь определяет, какой метод сервис будет вызван перед уничтожением. Если он равен ”true”, то у службы будет вызван метод onDestroy (не во всех, мягко говоря, случаях, но об этом чуть позже). А если атрибут равен ”false”, то последним вздохом сервиса, заметным разработчику, будет запуск метода onTaskRemoved.

Изучив все это и всласть поэкспериментировав с приведенной программкой, можно сделать следующий вывод: у нас не получится избежать гибели background service при удалении задачи. Ну не получится и не получится, в конце концов легкой жизни никто не обещал. Раз уж система может перезапускать нашу липкую службу, пусть делает это. А мы просто будем время от времени сохранять ее состояние, восстанавливая его при возрождении службы из пепла. Увы, не все так просто.

KitKat. No rest for the wicked

Еще в СССР в конце 80-х в рамках цикла передач “Сколько-то там вечеров с Thames Television” показывали рекламу шоколада KitKat. Ни про какой KitKat никто в то время не слыхивал, но реклама была в новинку и просматривали ее с интересом. И я отлично запомнил слоган, который сейчас и воткнул в название раздела. Ибо отражает.

В качестве предисловия. Выше упоминалось, что при android:stopWithTask=”true” сервис именно останавливается, то есть перед смертью получает свой успокоительный onDestroy. Так было до появления Android KitKat, с приходом которого все неуловимо изменилось. При удалении пользователем задачи в этой и более поздних версиях Android служба перейдет в иной мир … бесследно. В подавляющем большинстве случаев. Если конечно, не считать возможный вызов onDestroy у Activity, попавшему пользователю под палец. Очевидно, что все это делает android:stopWithTask совершенно бесполезным для наших целей.

Но выпуск Android KitKat хорошо запомнился разработчикам фоновых служб совсем не поэтому. Дело в том, что в первоначальных вариантах этой версии крылась одна занимательная деталь, которая в свое время лично меня вогнала в состояние глубокой депрессии. KitKat никогда не перезапускал sticky-сервисы.

А дальше были крики душ программистов на stackoverflow, ворох тикетов в Google, исправления, обновления и т.д. Сколько таких прошивок до сих пор живы на устройствах, никто не знает. Но то, что они еще попадаются, это точно. Решение в лоб с попыткой перезапустить службу

не дает ничего, поскольку Android сначала отработает старт, а лишь потом со спокойной совестью уничтожит службу. Здесь придется добавить костыль в виде AlarmManager:

То есть планируем перезапуск службы вручную через три секунды после удаления задачи. Время взято с потолка.

Передний край нащупала разведка

Тот, кто читал эту статью сначала, помнит мое утверждение о неотвратимости смерти background service при удалении задачи. Признаюсь, я здесь немного манипулировал терминами. На самом деле у службы существует способ остаться целой и невредимой, но уже в виде foreground service. Например, так:

При создании служба создает уведомление, в нашем случае это всего лишь иконка приложения. Созданное уведомление передается в метод startForeground и — вуаля — служба становится почти бессмертной. Удаление задачи на нее никак не повлияет, да и при нехватке памяти она будет останавливаться только в самом крайнем случае. Практически единственный способ ее остановить — нажимание соответствующих кнопок в Settings/Apps, что, в общем-то и требовалось. Так зачем же я городил огород до этого? А дело в этом самом уведомлении, которое Google с давних пор требует для перевода службы на передний план. Оно заметно для пользователя, заметно даже если его создать с прозрачной иконкой. А для ряда приложений это не всегда хорошо. Я сейчас говорю не о троянах и прочих вредоносных программах, их создатели вряд ли озабочены описываемой проблемой вообще, поскольку по определению не должны показывать пользователю что-то, за что он может потянуть. Просто показ уведомлений, не обусловленных реальной необходимостью, выглядит, на мой взгляд, глуповато. Пользователь это также чувствует и зачастую это его даже раздражает, как видно из комментариев к некоторым приложениям в Google Play.

Но и против уведомлений у нас нашлись методы, правда это уже не костыль, а скорее, хак. Добавим еще одну службу в проект:

А onCreate в KamikadzeService перепишем так:

Суть подхода в том, что служба HideNotificationService, выйдя не передний план с тем же идентификатором 777, уходит опять на задний с удалением своего уведомления. Заодно уничтожается и уведомление KamikadzeService, но последняя остается на переднем плане, причем уже «на первый взгляд, как будто, не видна». После этого служба HideNotificationService прекращает работу. Следует уточнить, что порядок запуска служб, как и их выхода на передний план здесь не имеет значения, главное обеспечить, чтобы stopForeground второй (HideNotificationService) был вызван позже, чем startForeground первой (KamikadzeService). И обязательно равенство идентификаторов, передаваемых в startForeground.

И здесь опять возникает резонный вопрос — если все это прекрасно работает, зачем я ранее долго и нудно разжевывал про повадки ”чисто” фоновых служб? Да потому что описанный прием — хак и хак достаточно грязный, чтобы им еще долго можно было пользоваться. Хотя в эмуляторе с прилетевшим на днях Android 6.0 это пока работает. Надеяться или не надеяться — решать читателю.

Источник