Android — использование фоновой службы

У меня есть служба IDL смешанного регистра, которую я использую двумя способами:

  1. Служба создаст поток и сделает сетевой вызов, чтобы получить некоторый XML-контент от имени Activity. Содержимое возвращается обратно в Activity через клиентский IDL, который определяет методы обратного вызова.
  2. Если пользователь выбирает вариант уведомления, служба создает таймер, который выполняется повторно, и создает уведомление на панели инструментов. Он также кэшировал содержимое, поэтому, когда Activity запрашивает обновление, оно обслуживается из кеша, а не из другого сетевого вызова.

Итак, мои вопросы

  1. Для сценария № 1, какова цена (если есть), которую я плачу за использование службы для сетевых вызовов вместо создания фонового потока непосредственно в действии?
  2. Для № 2 - мне лучше изменить реализацию на AlarmManager? Я заметил, что когда я убиваю процессы с помощью TasKiller, моя служба умирает и никогда не перезапускается, будет ли у задания на базе AlarmManager больше шансов на восстановление?

android background-process service
person Bostone    schedule 27.10.2009    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Для сценария № 1, какова цена (если есть), которую я плачу за использование службы для сетевых вызовов вместо создания фонового потока непосредственно в действии?

Я предполагаю, что, поскольку вы сказали, что это «служба IDL», это то, что я называю удаленной службой — вы используете AIDL для определения интерфейса, который используется через границы процесса.

В этом случае затраты составляют несколько МБ ОЗУ для второго процесса плюс немного процессорного времени для накладных расходов IPC. Насколько этот «бит процессорного времени» зависит от того, как часто он вызывается.

Для № 2 - мне лучше изменить реализацию на AlarmManager?

Как правило, да. В идеале сервисы должны находиться в памяти как можно меньше.

Я заметил, что когда я убиваю процессы с помощью TasKiller, моя служба умирает и никогда не перезапускается, будет ли у задания на базе AlarmManager больше шансов на восстановление?

Нет, потому что приложения-«убийцы задач», как правило, злоупотребляют API (по словам Дайанны Хакборн), который убивает все, включая запланированные будильники. Насколько мне известно, в настоящее время не существует надежной и эффективной защиты от «убийц задач».

person CommonsWare    schedule 27.10.2009
comment
Да для АЙДЛ. Я понимаю расходы во время фактического вызова, у меня действительно нет выбора для выполнения в отдельном потоке, поскольку это сетевой вызов, выполнение которого может занять много времени. Но что делать между вызовами? Есть ли какое-либо наказание за простое бездействие такой службы в течение длительного периода времени? Скажем, у меня нет уведомлений и мне вообще не нужно определять таймер, но я все равно использую службу для обслуживания удаленных вызовов. Это законно? - person Bostone; 27.10.2009
comment
Конечно, особенно если вы используете BIND_AUTO_CREATE на стороне клиента. Затем Android закроет удаленную службу через некоторое время после того, как не будет привязанных клиентов. В идеале, опять же, вы хотите избежать того, чтобы служба постоянно зависала в памяти, только с точки зрения потребления памяти. - person CommonsWare; 28.10.2009
comment
Я рискну утомить вас этим еще немного: должен ли я реорганизовать свой код, в котором я использую сервис, предоставляемый AIDL, двумя способами: 1. Получить XML из сети от имени клиента по запросу 2. Периодически проверять наличие обновлений, уведомить и кэшировать результат. Он работает довольно быстро на моем MyTouch, но я хотел бы оптимизировать его, если смогу - person Bostone; 28.10.2009
comment
Эта оптимизация, если я правильно понимаю, что вы хотите сделать, не обязательно улучшит производительность вашего отдельного приложения, но сделает его более приятным игроком на устройстве в целом. Мертвый сервис, так сказать, не использует батарею. Итак, если ваш рефакторинг означает, что вашей службе не хватает памяти, за исключением тех случаев, когда она выполняет значимую работу, и ваш период опроса является разумным (например, 10 минут), рефакторинг, вероятно, является хорошей идеей. - person CommonsWare; 28.10.2009
comment
Я просто не могу купить что-то, в названии которого есть Alert, для моих регулярных запланированных операций. По сути, если я вас правильно понимаю, службы плохо реализованы, и их следует избегать даже за счет взлома вашего кода. Просто использование AlertManager для cron op кажется мне взломом. Я ошибся? Существует ли законный (рекомендуемый) сценарий для службы AIDL? - person Bostone; 29.10.2009
comment
Это AlarmManager, а не AlertManager, поэтому ваше первое беспокойство кажется необоснованным. Услуги реализованы неплохо, но люди, кажется, забывают, что это телефоны, а не четырехъядерные настольные компьютеры с 4 ГБ памяти, подключенные к постоянному питанию от сети переменного тока. Например, мне, возможно, придется отказаться от Pandora, потому что ее сервис жрет безумное количество батареи без видимой веской причины. В первую очередь AIDL предназначен для взаимодействия, предоставляя API-интерфейсы сторонним приложениям. Я не могу придумать, как использовать его только в одном приложении. - person CommonsWare; 30.10.2009
comment
Мое плохое — это AlarmManager, который, как мне кажется, звучит еще более хакерски, чем Alert, что означает, что каждый раз, когда мне нужно обновление, я поднимаю тревогу. Я согласен с злоупотреблением услугами - я вынужден использовать TasKiller, даже если мне не нравится идея самостоятельного управления ресурсами моего телефона. Тем не менее, я вижу смысл - я думаю, что меня привлекает менталитет рабочего стола, где вы можете пожертвовать небольшим количеством производительности ради абстракции. К - вернуться к работе - person Bostone; 30.10.2009