IntentService
Класс IntentService является подклассом класса Service. Он используется, если надо выполнять какие-то тяжёлые задачи с намерениями, которые могут выполняться асинхронно. Принцип работы этого вида сервиса прост. Он создаёт новый поток для своей работы, затем мониторит все входящие намерения и отправляет их на обработку в этот поток. Далее в коде вы определяете, как обработать Intent. Вам не нужно запускать AsyncTask и управлять тяжёлыми задачами, сервис сам справится. Вы можете отправить данные обратно в приложение через широковещательное сообщение и принять сообщение через широковещательный приёмник.
Иными словами, приложение посылает в сервис данные через метод startService(), в которых передаёт намерения. IntentService принимает эти вызовы, берёт намерения последовательно и отправляет их в очередь на обработку. И далее они поочерёдно обрабатываются в отдельном потоке методом onHandleIntent() по одному за раз. Когда последний Intent из очереди будет обработан, сервис сам завершит свою работу.
Во многих случаях использование IntentService проще, чем AsyncTask или Thread.
Напишем код для основной активности, в которой осуществим три вызова сервиса через метод startService(). Переменная time – это время паузы, которую будем делать в сервисе, а task – просто метка, чтобы отличать вызовы. Для этого создаётся намерение с указанием нужной службы, а в дополнительных параметрах передаются данные.
В коде встречается вызов класса MyIntentService. Создадим его.
В классе необходимо создать конструктор, в котором вызываем конструктор суперкласса и указываем какое-нибудь имя, которое будет использовано для наименования потока.
В методе onHandleIntent() обрабатываем намерения. Достаём из них значения переменных time и task, запускаем паузу на time секунд и выводим в лог значения label в начале и в конце.
Не забываем прописать сервис в манифесте в секции application:
В итоге, при запуске в логах видим следующее:
Сервис создался, вызовы выполнились по очереди и сервис завершил работу.
Усложним задачу. Сейчас мы просто вывели результаты в журнал, а сама активность не получила уведомления. Создадим отдельное намерение и отправим его через метод sendBroadcast().
Теперь в основной активности необходимо зарегистрировать свой BroadcastReceiver и принять сообщение от сервиса:
В данном примере мы возвращаем результат после выполнения всех задач и выводим в одной текстовой метке. В методе onHandleIntent() вы можете выполнять тяжёлые задачи. Так как они выполняются в другом потоке, то ваша основная активность остаётся отзывчивой на действия пользователей. Как только сервис завершит обработку данных, то сработает отправка широковещательного сообщения обратно приложению через метод sendBroadcast(). И вам его надо только принять и обработать.
Не забывайте снимать регистрацию приёмника через метод unregisterReceiver() (рекомендуется в методах onPause() или onDestroy() в нашем примере).
Промежуточные результаты
Дополним программу и будем посылать в активность промежуточные результаты, которые будут обновлять состояние индикатора прогресса. Добавим индикатор на экран.
Добавим в класс службы дополнительный код.
В активности следует зарегистрировать ещё один широковещательный приёмник. Сервис в цикле создаёт промежуточные данные и отсылает его активности. Активность принимает данные через приёмник и обновляет состояние индикатора.
Запустив пример, вы увидите сначала работу индикатора прогресса, а потом выведется текст. Также промежуточные данные можно отсылать в уведомления. Добавим код в существующий код:
Если вы запустите код, то увидите, что будет обновляться не только индикатор на главном экране приложения, но и данные в уведомлениях.
Запуск и остановка службы
В примерах служба запускалась одновременно с запуском приложения. Перенесём код в кнопку. А также добавим вторую кнопку для остановки службы. При этом будем отслеживать количество запущенных служб.
Код для активности.
Вызываем Toast
Вызвать Toast в методе onHandleIntent() напрямую не получится, сообщение не появляется. Следует создать отдельный поток. Чтобы выполнение проходило в основном потоке, объект Handler должен быть создан в методе, выполняемом в основном потоке. Метод onHandleIntent() не подходит, так как он выполняется в фоновом потоке. Вместо этого воспользуемся методом onStartCommand(), который вызывается каждый раз при запуске службы через намерение. Метод onStartCommand() выполняется в основном потоке и отрабатывает до метода onHandleIntent(). Если создать объект Handler в методе onStartCommand(), то его можно будет использовать для передачи кода в основной поток в методе onHandleIntent():
Источник
Полный список
— изучаем IntentService
— включаем режим Foreground для сервиса
— помещаем сервис в автозагрузку
Строили мы, строили, и, наконец, построили. Урок номер 100, с чем всех нас и поздравляю )
В этом уроке рассмотрим еще несколько полезных вещей про сервисы. Выносить каждую из них в отдельный урок я не стал, вполне можно в одном все рассмотреть. Проекты здесь тоже создавать не будем, чтобы урок не получился слишком громоздким. Я просто приведу некоторые куски кода и скрины для наглядности своих рассуждений. А если у вас будет желание, вы по этим наработкам сами можете создать проекты-примеры.
IntentService
Это подкласс обычного Service. Он используется, если вам в сервисе надо выполнять какие-то тяжелые задачи, и вы не хотите сами возиться с асинхронностью. Принцип работы этого вида сервиса прост. Он создает новый поток для своей работы. Затем берет все Intent пришедшие ему в onStartCommand и отправляет их на обработку в этот поток. Как именно обрабатываются Intent – зависит от нас, т.к. мы сами кодим это в методе onHandleIntent.
Т.е. приложение сыпет в сервис вызовами startService, в которых передает Intent-ы. IntentService принимает эти вызовы в onStartCommand, берет Intent-ы и отправляет их в очередь на обработку. И далее они поочередно обрабатываются в отдельном потоке методом onHandleIntent. Когда последний Intent из очереди обработан, сервис сам завершает свою работу.
В приложении делаем три вызова:
Где time – это время паузы, которую будем делать в сервисе, а label – просто метка, чтобы отличать вызовы.
Здесь необходим конструктор, в котором вызываем конструктор супер-класса и указываем какое-нить имя. Оно будет использовано для наименования потока.
В методе onHandleIntent кодим обработку Intent-ов. Достаем из них time и label, запускаем паузу на time секунд и выводим в лог label в начале и в конце.
В итоге, при запуске в логах видим:
11:07:37.880: D/myLogs(4137): onCreate
11:07:37.880: D/myLogs(4137): onHandleIntent start Call 1
11:07:40.880: D/myLogs(4137): onHandleIntent end Call 1
11:07:40.880: D/myLogs(4137): onHandleIntent start Call 2
11:07:41.880: D/myLogs(4137): onHandleIntent end Call 2
11:07:41.880: D/myLogs(4137): onHandleIntent start Call 3
11:07:45.890: D/myLogs(4137): onHandleIntent end Call 3
11:07:45.890: D/myLogs(4137): onDestroy
Сервис создался, вызовы выполнились по очереди и сервис завершил работу. От нас понадобилось только накодить обработку.
Foreground
Вы можете сказать системе, что ваш сервис очень важен для пользователя и его нельзя грохать при нехватке памяти. Это актуально, например, для музыкального плеера. В статус-бар при этом будет помещено уведомление.
На вход он принимает те же параметры, что и NotificationManager.notify – ID и Notification.
Т.е. вы создаете уведомление, назначаете ему ID и передаете это в startForeground. Сервис переходит в режим IDDQD :), а в статус-баре появилось уведомление.
Оно появилось в разделе для постоянных уведомлений (Ongoing).
Метод stopForeground (boolean removeNotification) — возвращает сервису способность быть убитым системой в случае острой нехватки памяти. А на вход он принимает boolean-значение – удалять уведомление из статус-бара или нет.
Уведомление также пропадет, когда сервис будет остановлен.
Эти методы работают, начиная с Android 2.0. Пример реализации для более ранних версий есть в хелпе.
Напомню, что уведомления мы научились создавать на прошлом уроке.
Автозагрузка
Сервисы для получения погоды или почты имеет смысл помещать в автозагрузку. Для этого нам надо создать BroadcastReceiver, настроить его IntentFilter на Action = android.intent.action.BOOT_COMPLETED, и добавить права android.permission.RECEIVE_BOOT_COMPLETED. Этот BroadcastReceiver будет вызван системой при старте системы и в нем мы кодим запуск сервиса.
Допустим, есть проект с сервисом MyService.
Создаем в проекте класс MyBroadReceiv
В манифесте добавляем его как Receiver и настраиваем фильтр
Добавляем права на получение сообщения о загрузке
Инсталлим проект на AVD. Закрываем AVD. Запускаем через меню в Eclipse: Window > AVD Manager. Находим там наш эмулятор и запускаем вручную.
Когда он запустился, смотрим логи
onReceive android.intent.action.BOOT_COMPLETED
MyService onCreate
MyService onStartCommand
Сработал BroadcastReceiver и запустил сервис.
Если после запуска AVD логи не отображаются, то откройте DDMS и во вкладке Devices явно выберите ваш AVD.
P.S. Я уже писал об этом, но напишу еще раз. Последующие уроки будут выходить по более свободному графику. Следите за обновлениями.
На следующем уроке:
— создаем свой ContentProvider
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Под капотом JobIntentService
В данной статье, речь пойдет об одной проблеме с JobIntentService’ом, о которой существует множество вопросов на соответсвующих ресурсах и репортов в баг трэкере гугла. А так же о причине по которой, судя повсему, гугл не считает ее багом и закрывет данные репорты.
Введение
JobIntentService’ы были созданы для фоновой работы. Широкое применение они получили в Android 8 и выше, когда исчезла возможность использования сервисов в фоновом режиме.
По сути они заменяют сервисы в фоновом режиме, а так же находятся под управлением планировщика задач(JobScheduler).
Таким образом система имеет возможность контролировать ход выполнения задач в фоновом режиме а так же сама управляет wakelock’ами, что позволило оптимизировать расход батареи устройства и избежать не корректного использования wakelock’ов разработчиками. Данные шаги позволили минимизировать ситуации когда устройство не может погрузится в режим сна(Doze Mode), что опять же влияет на экономию заряда батареи.
Коротко о JobIntentService
По сути JobIntentService это тот же IntentService под управлением планировщика задач(JobScheduler).
Выполняется в фоновом потоке AsyncTask’а.
В версиях Андроида 4.4 и ниже используется обычный IntentService.
Жизненный цикл и подводные камни
Оба типа задач имеют одинаковый жизненный цикл. Задачи контролируются Handler’ом и имеют состояния.
Хотя эти состояния не доступны извне, но при определенных обстоятельствах система выбрасывает исключения, при которых приложение “падает”. Данные поведения являются проблемой и головной болью для многих разработчиков и к сожалению не имеют простого решения. Для начала изучим состояния и жизненный цикл задач, а потом рассмотрим возможные решения.
Последовательность состояний задач
BINDING — состояние создания задачи(байндинг сервиса) тайм-аут 18 секунд.
STARTING — состояние запуска задачи, тайм-аут 8 секунд.
EXECUTING — состояние выполнения задачи, тайм-аут 10 минут.
STOPPING — состояние остановки задачи(например после вызова cancel()), тайм-аут 8 секунд.
FINISHED — финальное состояние завершенной задачи, последнее состояние в жизненном цикле задачи.
Упрощенная схема жизненного цикла задач
У каждого состояния задачи есть свой тайм-аут. По истечении тайм-аута выполнение задачи прерывается вне зависимости от ее состояния. Собственно это механизм тайм-аутов и является подводным камнем т.к. по истечении тайм-аута система выбрасывает исключение типа java.lang.SecurityException и приложение “падает” со следующим сообщением Caller no longer running, last stopped +1s600ms because: timed out while starting где +1s600ms это время которое прошло с момента тайм-аута до момента выброса исключения, а “причина” ( because: timed out while starting ) — указывает в каком состоянии была задача, когда тайм-аут истек.
Выводы
Как показывает опыт, данные исключения встречаются в довольно таки загруженных приложениях.
В подтверждение данной проблемы можно наблюдать как и на слабых, так и на топовых устройствах. На данную проблему так же указывает и выбрасываемые исключения с сообщениями о тайм-аутах. Соответственно, само собой напрашивается решение о разгрузке приложения и оптимизации использования JobIntentService’ов, например, избегать ситуаций когда паралельно запускаются несколько JobIntentService’ов. Второе решение, в некоторых случаях более тривиальное, а иногда и сложнее первого варианта — это использовать JobService.
Так же если погуглить данную проблему то можно наткнуться и на другие «сомнительные» варианты решения данной проблемы, например можно посмотреть следующие ссылки:
На данный момент гугл готовит хорошую замену JobService’ам и JobIntentService’ам — это Worker и WorkManger из пакета androidx.work.
К сожалению данные инструменты еще не готовы к продакшену и имеют ряд багов, но уже сейчас как показали тесты, решают проблему описаную выше.
Источник
