Содержание статьи
В продолжении темы прошлого номера мы узнаем, каким образом в Android можно генерировать дополнительные потоки и зачем это может понадобиться. Сегодня поговорим о таком компоненте приложения, как сервисы, и опишем их роли в мобильном мире Android. Сервисы и потоки тесно переплетены между собой, поэтому, если ты еще не читал прошлый номер «Хакера», начни с моей статьи, будет полезно!
Сервисы
Компания Google в своей статье Application Fundamentals, обращенной к будущим Android-разработчикам, выделяет четыре базовых компонента Android-приложения: Activity, Service, поставщики содержимого (Content Providers) и приемники широковещательных сообщений (BroadCast Recievers). С Activity начинается знакомство с разработкой, о последних двух компонентах «Хакер» писал раньше (и еще обязательно к ним вернется), поэтому сейчас поговорим о сервисах.
Большинство мобильных устройств обладают достаточно скромными ресурсами, а значит, ОС приходится постоянно перераспределять их между работающими приложениями. Если в системе нет свободной памяти для нового запущенного приложения, то ОС принудительно завершает Activity, которые находятся в состояниях onStop и onPause, а вместе с ними и их дополнительные потоки.
Такое положение дел существенно урезает возможности дополнительных потоков внутри UI — Activity на экране постоянно меняются, а значит, созданные ими потоки не могут жить вечно. Поэтому генерировать дополнительные потоки в Activity целесообразно только в случае, если вычисления завершатся не позже, чем пользователь переключится на другое окно, — в противном случае велик риск потерять результаты или не закончить вычисления.
И тут на помощь приходят сервисы! По сути дела, это те же самые Activity, но без графических элементов. Ввиду отсутствия UI они предназначены для длительных операций, которые могут долгое время выполняться без участия пользователя. Проигрывание музыки, запись данных для фитнес-трекера, продолжительный сетевой обмен — все это задачи для сервисов.
У сервисов в Android существует даже собственный жизненный цикл (lifecycle), который схож с жизненным циклом Activity, и, не привязанные к конкретному Activity, они работают максимально возможное время. ОС начнет убивать сервисы только в экстренных ситуациях, если пользователь параллельно с нашим приложением запустит игру, которая съест вообще все ресурсы и все равно будет тормозить.
В Android сервисы создаются с помощью класса Service или его наследника IntentService. Несмотря на схожие названия, их функциональные возможности и предназначение серьезно отличаются.
IntentService
Наиболее простой способ создать свой сервис — это воспользоваться классом IntentService. Созданный с его помощью сервис запустится в новом потоке, выполнит все необходимые действия, после чего будет остановлен системой.
В принципе, этого достаточно в большинстве случаев. Чаще всего требуется отправить в фон какую-то тяжеловесную задачу и не морочить себе голову, выполнилась она или нет, — и тут как раз подойдет IntentService.
public class SimpleIntentService extends IntentService {Полезная нагрузка размещается в методе onHandleIntent(), который будет выполнен системой сразу после старта сервиса. После завершения работы этого метода сервис будет остановлен системой, а ресурсы освобождены.
protected void onHandleIntent(Intent intent) {
try {
String url=intent.getStringExtra("link");
Thread.sleep(5000);
Log.e("IntentService", "data loaded to" + url);
} catch (InterruptedException e) {
e.printStackTrace();
}
}Передача данных, как и запуск самого сервиса, происходит через уже известный механизм намерений (Intent).
Intent intent = new Intent(getApplicationContext(), SimpleIntentService.class);
intent.putExtra("link", "url_to_load");
startService(intent);Любой сервис, как и Activity, необходимо зарегистрировать в манифест-файле, иначе ОС о нем не узнает и он просто не будет запущен.
<service android:name=".SimpleIntentService" />Все готово! После выполнения метода startService в работающем приложении появится новый поток, который выполнит необходимые действия, не загружая UI. Но простота реализации приносит и свои минусы:
- Отсутствует явная связь с главным потоком. После старта сервис начинает жить своей жизнью, и вернуть результаты вычислений обратно в Activity можно только с помощью широковещательных сообщений.
- IntentService подходит для выполнения редких, разовых операций, поскольку его конструкция не позволяет выполнять несколько задач одновременно. Если IntentService уже чем-то занят, то при повторном запуске сервиса будет организована очередь и вычисления будут выполнены последовательно.
- Операции, выполняемые в IntentService, не могут быть прерваны, а значит, сервис будет висеть в памяти до тех пор, пока не завершатся все действия, задуманные в методе
onHandleIntent.
Service
А теперь настало время познакомиться с родителями :). Я сознательно начал разговор с наследника — IntentService, поскольку он предельно прост в эксплуатации: просит мало, работает долго и уходит незаметно. С «оригинальным» же Service все сложнее, чем кажется поначалу.
В статье Services, где разработчики Google рассказывают о своем детище, он назван компонентом, который позволяет выполнять длительные операции в фоне. Прочитав вступление, испытываешь огромный соблазн сразу же накидать сервисов в приложение и выкатить релиз. Но не все так просто — к примеру, портал Stack Overflow завален вопросами вроде «почему мои сервисы постоянно выдают ANR-сообщения?».
Оказывается, изначально объект класса Service не создает для себя новый поток, а выполняется там, где его инициализировали! Поэтому, создав в MainActivity новый сервис, разработчик довольно быстро подвесит UI. Чтобы этого избежать, необходимо внутри сервиса самостоятельно генерировать потоки (AsyncTask, Loader и так далее — выбирай любой) и помещать ресурсозатратные вычисления в них.
Сервис, созданный с помощью одноименного класса, открывает нам дверь в мир настоящей многопоточности. Это инструмент, позволяющий быстро распараллеливать однотипные задачи, создавая отдельный поток под каждую из них.
Недавно «Хакер» рассказывал, что в Android достаточно легко написать зловред, который бы шифровал пользовательские данные стойким ключом. Тогда мы не акцентировали свое внимание на производительности — файлы шифровались последовательно, один за другим. Сейчас посмотрим, как с помощью сервиса можно сократить время выполнения операций шифрования.
Поскольку объекты этого класса могут самостоятельно создавать новые потоки, мы можем запустить сервис, который будет обрабатывать одновременно максимально возможное число файлов.
Количество доступных нам потоков заранее неизвестно — это во многом зависит от ресурса устройства. Но бояться ошибок переполнения не стоит, за генерацией новых потоков следит класс ThreadPoolExecutor. Он самостоятельно выставляет лимиты по операциям, и в случае необходимости новые задачи просто встанут в очередь.
Создавать новые потоки будем с помощью классов Handler и Looper, которые нам уже знакомы по первой части статьи.
public class SimpleService extends Service {
private Looper mServiceLooper;
private ServiceHandler mServiceHandler;По умолчанию сервис живет в потоке породившего его Activity. Нас это не очень устраивает, поэтому в методе OnCreate нужно породить новый поток.
public void onCreate() {
HandlerThread thread = new HandlerThread("ServiceStartArguments");
thread.start();
mServiceLooper = thread.getLooper();
mServiceHandler = new ServiceHandler(mServiceLooper);
}Теперь сервис отвязан от Activity и будет жить своей жизнью. Основная логика создаваемого сервиса содержится в методе onStartCommand, который будет выполняться каждый раз при вызове метода startService.
public int onStartCommand(Intent intent, int flags, int startId) {
Toast.makeText(this, "service starting", Toast.LENGTH_SHORT).show();Каждый сервис существует в единственном экземпляре, поэтому многократный вызов метода startService не размножает экземпляры сервиса, а только создает очередь из заданий для него. И если IntentService просто выполнит все задания последовательно, одно за другим, то благодаря классу Service у нас появляется возможность запустить все задачи одновременно в независимых потоках. Достаточно в методе onStartCommand создавать новые потоки для каждой задачи.
HandlerThread thread = new HandlerThread("New thread"+startId);
thread.start();
...
return START_STICKY;
}Остановка сервиса
Сервис, созданный с помощью одноименного класса, будет жить, пока его принудительно не остановят. Сделать это можно либо откуда-то снаружи методом stopService, с указанием интента, которым он был запущен, либо внутри самого сервиса методом stopSelf.
Как узнать, что сервис уже все сделал, особенно если мы поставили перед ним сразу несколько задач? В этом нам поможет параметр startId у метода onstartcommand — это порядковый номер каждого вызова сервиса, который увеличивается на единицу при каждом запуске.
Создав новый поток, разумно завершать его методом stopSelf, указывая startId в качестве параметра.
private final class ServiceHandler extends Handler {
...
public void handleMessage(Message msg) {
...
stopSelf(msg.arg1);
}
}С таким параметром ОС не будет сразу завершать сервис, а сравнит переданный идентификатор с тем, который был выдан при последнем запуске onStartCommand. Если они не равны, значит, в очередь была добавлена новая задача и сервис остановлен не будет.
Параметры перезапуска
Сервис — важный компонент приложения, и от стабильности его работы может зависеть стабильность всего приложения. Именно поэтому, даже если ОС и внештатно выгрузит сервис из памяти, есть возможность его запустить заново, как только появятся свободные ресурсы.
Метод onStartCommand возвращает переменную, указывающую ОС, как следует поступить с сервисом, если он был принудительно остановлен. К счастью, разработчикам не нужно запоминать сами числа, в классе Service есть их мнемонические обозначения.
Существует три варианта того, как ОС может поступить с сервисом, если он был принудительно завершен.
START_NOT_STICKY — не будет перезапущен системой, и все останется так, как есть. Подходит для случая, когда он выполняет не самые важные задачи, и приложение может позже при необходимости самостоятельно его перезапустить.
START_STICKY — будет запущен заново, но в Intent, который ОС создаст для его запуска, не будет никаких параметров. Такой вариант работает с аудиоплеерами — он должен быть активным в фоне, но не обязательно при этом автоматически начинать проигрывать песни.
START_REDELIVER_INTENT — сервис будет запущен с теми же параметрами, которые были при его последнем старте. Это удобно, когда в фоне загружается большой файл и его загрузка была прервана.
Bound Service
Иногда бывает необходимо выполнить большой объем черновой работы, а потом несколько раз использовать полученные результаты. К примеру, это может быть загрузка из сети большого XML-файла с последующим парсингом данных. Конечно, можно как-то кешировать результаты, а затем при необходимости их заново подгружать. Но есть вариант получше — создать сервис, который выполнит необходимые расчеты, раздаст данные всем желающим и завершит свою работу.
Описанный алгоритм мы можем организовать уже имеющимися средствами, но за одним исключением — непонятно, когда услуги сервиса уже больше не понадобятся и его можно остановить. Эту проблему возможно решить, создав привязанный (bound) service — это сервис, который будет работать до тех пор, пока к нему привязан хотя бы один Activity или другой сервис. В случае если «клиентов» у такого сервиса нет, он автоматически останавливается, но при необходимости может быть снова запущен.
Привязанный сервис создается с помощью того же класса Service, но теперь необходимо инициализировать метод OnBound.
public IBinder onBind(Intent intent) {
return binder;
}IBinder — это интерфейс, позволяющий организовать связь между двумя различными потоками, функционирующими внутри одного процесса. Для его использования не нужно самостоятельно реализовать этот интерфейс, достаточно создать объект класса Binder. Сейчас его основной задачей будет предоставление ссылки на работающий сервис в Activity.
private final IBinder mBinder = new MyBinder();
public class LocalBinder extends Binder {
LocalService getService() {
return LocalService.this;
}
...Чтобы Activity могли подключаться к сервису, разработчики Google создали класс ServiceConnection, основная задача которого — организовывать взаимодействие Activity и сервиса, а также следить, чтобы созданное подключение работало корректно.
public class MainActivity extends AppCompatActivity {
LocalService mService;
boolean mBound = false;Для работы этого механизма необходимо переопределить методы, отвечающие за подключение к сервису и отключение от него.
private ServiceConnection mConnection = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName className, IBinder service) {
LocalService.MyBinder binder = (LocalService.MyBinder) service;
mService = binder.getService();
mBound = true;
}При успешном подключении к сервису в потоке Activity появляется экземпляр сервиса, к которому произошло подключение. Индикатором состояния подключения к сервису будет булева переменная.
public void onServiceDisconnected(ComponentName arg0) {
mBound = false;
}Процедуры подключения к сервису и отключения от него рекомендуется выполнять в методах onStart и onStop. Это разумно, поскольку процедуры запуска/остановки сервиса и подключения к нему достаточно ресурсозатратны и не должны выполняться слишком часто.
protected void onStart() {
super.onStart();
Intent intent = new Intent(this, LocalService.class);
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
}
...
protected void onStop() {
super.onStop();
// Unbind from the service
if (mBound) {
unbindService(mConnection);
mBound = false;
}
...
}Для получения данных с сервиса достаточно обратиться к нему через его экземпляр, полученный благодаря ServiceConnection.
if (mBound) {
String data = mService.getData();
Toast.makeText(this, "number: " + num, Toast.LENGTH_SHORT).show();
}Вообще говоря, использование сервисов предполагает какие-то длительные операции. Вполне нормально, что метод getData будет выполняться длительное время и результат вычислений не вернется мгновенно.
public String getData() {
if (data==null) {
try {
Thread.sleep(5000);
data = "loaded data";
}
...
}
return data;
}В этом случае стоит вызывать методы сервиса в дополнительных потоках, например с помощью уже знакомого нам AsyncTask и слабых ссылок.
private class MyLoader extends AsyncTask<LocalService,Void,Void> {
private WeakReference<TextView>textViewW;
String data;
@Override
protected Void doInBackground(LocalService... params) {
data=params[0].getData();
return null;
}
@Override
protected void onPostExecute(Void aVoid) {
super.onPostExecute(aVoid);
textViewW=new WeakReference<TextView>(textView);
if (textViewW != null){
textViewW.get().setText(data);
}
...
}До тех пор пока сервис привязан к какому-либо Activity, его данные будут сохраняться, а значит, ими смогут воспользоваться и другие компоненты приложения. В этом и есть плюс привязанных сервисов — достаточно один раз загрузить и обработать данные, а затем готовые результаты смогут легко получить остальные участники приложения.
Foreground Service
В некоторых случаях необходимо сделать критически важный сервис, который будет выгружен из системы только вместе с выключением устройства. Именно такими сервисами являются аудиоплеер или GPS-трекер. Они будут работать всегда, даже когда создавшее их приложение будет завершено, и ни одно другое приложение не сможет вытеснить их из памяти. Если пользователь решил послушать новый альбом Taylor Swift, то песни в наушниках перестанут играть только в двух случаях — кто-то нажмет кнопку «Стоп» или в устройстве сядет аккумулятор.
Это так называемый сервис переднего плана (foreground service), и его можно создать как из класса Service, так и из класса IntentService. Но есть небольшое условие: в панели уведомлений на протяжении всей работы сервиса должна быть соответствующая информация.
Создадим сейчас свой сервис, проигрывающий музыку. В этом нам поможет стандартный Android-класс MediaPlayer, который вполне справится с тем, чтобы открыть файл и бесконечно проигрывать его по кругу. К сожалению, для более сложных задач лучше поискать другие библиотеки — реализация MediaPlayer может отличаться в зависимости от вендора устройства, поэтому приложение может работать нестабильно.
Создаем наследующий Service класс, который реализует интерфейс MediaPlayer.onPreparedListener.
public class MusicService extends Service implements MediaPlayer.OnPreparedListener {Старт сервиса, как всегда, организуем через Intent, имя проигрываемого файла можно передать через его параметры.
intent.putExtra("filename", "johny_cash-16tons.mp3");Когда песня будет готова к проигрыванию, в сервисе сработает метод onPrepared из реализуемого интерфейса.
public void onPrepared(MediaPlayer mp) {
mp.start();
player.setVolume(100,100);
}В методе OnStartCommand будет инициализирован музыкальный плеер и, самое главное, сконструирован объект, который будет демонстрироваться на панели уведомлений в течение всей работы сервиса. Это будет совершенно обычное уведомление, созданное с помощью класса Notification.
NotificationCompat.Builder mBuilder = new NotificationCompat.Builder(this)
.setSmallIcon(R.mipmap.ic_launcher)
.setContentTitle("Song in progress")
.setContentText(filename);
Скорее всего, пользовать захочет нажать на выводимое уведомление и попасть в Activity приложения, где можно будет поменять музыку. С этим справится PendingIntent, способный создать новый стек.
Intent notificationIntent = new Intent(this, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);Теперь нужно связать сформированный стек и уведомление. А вывод информации о работающем сервисе выполняется методом startForeground с указанием уникального идентификатора.
mBuilder.setContentIntent(pendingIntent);
Notification fullNotif = mBuilder.build();Что же выбрать?
Итак, за два месяца мы с тобой довольно подробно поговорили о том, где же можно обработать данные для UI. Давай теперь кратко просуммируем то, что у нас есть для создания многопоточности в Android.
Потоки, созданные в Activity, подходят для сравнительно недлительных действий, результат которых важен только в момент жизни конкретного Activity. Их можно создать с помощью AsyncTask, AsyncTaskLoader или их аналогов — все зависит от того, как тебе будет удобней.
Сервисы существуют в приложении на равных правах с Activity, но не всегда в отдельном потоке. Они могут распараллелить задачи и выполнять громоздкие вычисления долгое время, пока на экране будут меняться Activity. IntentService завершит себя сам, когда выполнит все задачи, а Service будет висеть в фоне. Применяя сервисы, нужно быть внимательным, он может случайно оказаться в потоке UI или долго и без дела висеть в памяти, забирая ресурсы.
Заключение
Надеюсь, про многопоточность было сказано достаточно, чтобы ты понял ее необходимость и полезность. Вся ли это информация? Конечно, нет, Android — очень сложная ОС, которая постоянно развивается, и нельзя в двух статьях разобрать абсолютно все нюансы такой важной темы. В конце концов, главное — как приложение работает, а не то, как оно написано. Если будут вопросы, обязательно мне пиши. Удачи!
