На Stackoverflow часто встречаются вопросы по выполнению на Android фоновых задач, в т.ч. и повторяющихся с заданным промежутком времени. Как правило, первое, что используется, это Service.

Такой подход в некоторых случаях может привести к тормозам и низкой скорости ответа пользовательского интерфейса. Расскажу когда так бывает и как с этим бороться…

Бывает так, что нужно походить по страницам сайта, который внезапно лёг или вовсе закрылся, и испокон веков нас здесь выручает Google с его поисковым кэшем. Одна беда — «походить» в этом случае превращается в сплошное мучение: посмотреть страницу, скопировать адрес ссылки, по которой хочется пройти, вставить в поисковую строку и добавить префикс «cache:». Многовато действий ради одного перехода по ссылке. Вот ссылка на решение этой проблемы для нетерпеливых: GCB 2.0.

Архитектура большинства Java(и не только) приложений сегодня предусматривает возможность расширения функционала посредством различного рода магических воздействий на код. В последнее время это также стало возможно, если использовать какой-нибудь модный фреймворк или IoC-контейнер. Но что делать, если приложение долгоживущее и слишком сложное для того, чтобы переводить его на использование какого либо фреймворка?

В последнем приложении, с которым я работал, был реализован на тот момент неизвестный мне велосипед SPI механизм, который искал в джарках текстовые файлы вида META-INF/services/<qualified interface name> и брал оттуда название нужного класса, реализующего этот интерфейс, далее этот класс использовался как расширение. Поискав в интернете, узнал, что Service Provider Interface(SPI) представляет собой программный механизм для поддержки сменных компонентов и что этот механизм уже довольно давно используется в Java Runtime Environment(JRE), например в Java Database Connectivity(JDBC):

ps = Service.providers(java.sql.Driver.class);
try {
  while (ps.hasNext()) {
    ps.next();
  }
} catch (Throwable t) {
  // Do nothing
}

Благодаря этому коду приложения больше не нуждаются в конструкции Class.forName(<driver class>) (хотя и с ней будут работать), JDBC драйверы будут подгружены автоматически при первом обращении к методам класса DriverManager.

SPI механизм также используется в Java Cryptography Extension(JCE), Java Naming and Directory Service(JNDI), Java API for XML Processing(JAXP), Java Business Integration(JBI), Java Sound, Java Image I/O.

Как это работает?

Весь смысл в разделении логики на сервис(Service) и провайдеры(Service Providers). Ссылки на провайдеры сохраняются в джарках расширений в текстовом файле(UTF-8) META-INF/services/<qualified service class>, в каждой строке полное имя класса провайдера. Пустые строки и комментарии(начинающиеся с символа #) игнорируются. Ограничения на провайдеры: они должны реализовывать интерфейс либо наследоваться от класса сервиса и иметь конструктор по умолчанию(zero-argument public constructor).

Сегодня мы напишем сервис для Android'а, который будет работать в фоне, срабатывать через определенный интервал времени и автоматически перезапускаться после перезагрузки телефона. Казалось бы ничего сложного в этом нет, но очень много людей сталкиваются с проблемами, когда пытаются разобраться с этими самыми пресловутыми Services.

На днях мне довелось испытать на себе качество работы сервиса Asus в Чехии. Ноутбук M50vc, который я купил полтора года назад, оказался очень быстрый и выносливый. На нем без проблем идут современные ресурсоемкие программы и даже игры, хотя прошло уже много времени по компьютерным меркам. Основная проблема оказалась в корпусе, точнее в экране, который легко царапался и кнопках мыши связанных между собой какой-то палочкой, которая постоянно ломалась.
Это конечно раздражало, но не было достаточной причиной для отказа от ноутбука на некоторое время. Дело в том, что сервис Asus в Чехии находится в городе Острава (400 км от Праги) и схема с отправкой ноута меня несколько смущала. Но после поездки в Германию батарея полностью разрядилась и заблокировалась, а за неделю до этого стала коротить зарядка. Пришлось воспользоваться услугами сервис центра.

По рабочей необходимости приходится иногда писать системные сервисы для Microsoft Windows.

На Хабре уже есть статья Создание своего Windows Service , но по моему мнению — статья не более чем краткий обзор, который можно найти в MSDN. В ней не рассмотрены, например, возможные варианты поведения сервиса в случае ошибки, или запись в журналы сообщений.
Постараюсь, используя опыт написания такого рода приложений, изложить максимально возможный объем информации.