1

Я немного смущен. Я читал, что самое большое преимущество использования начатого сервиса заключается в том, что это не зависит от приложения, поэтому, даже если андроид убивает ваше приложение, ваша служба все еще жива. Мои вопросы тогда:Сервис и жизненный цикл приложения для Android

1) Если мой сервис работает в том же процессе, что и приложение, служба тоже будет жива?

2) Я использую BroadcastReceiver для обнаружения изменений в подключении устройства, поэтому, если приложение убито, но служба не работает, я все равно получаю эти изменения в связях?

3) Если я хочу получить текущий статус подключения от службы, могу ли я сделать это с помощью getApplicationContext() или он может вернуть значение null? Во втором случае, как я могу получить текущий статус сети?

4) Подобно подключению, я отправляю событие через автобус Отто каждый раз, когда приложение меняет свой статус с переднего плана на задний план (в приложении приостановлено/возобновлено). Таким образом, моя услуга подписана на эти изменения, чтобы узнать текущий статус приложения. Если мое приложение будет убито, могу ли я доверять этим событиям? Или они не могут быть отправлены?

ответ

2

Во-первых, если вы используете передний план Service, это вряд ли будет внезапно убито. Сказав это:

Если моя служба работает в том же процессе, что и приложение, сервис также будет жив?

Ну, нет. Ваш Service является одним из компонентов вашего приложения. Если он жив, то это приложение (см. Также третий вопрос). Но, если вы вернетесь START_STICKY или START_REDELIVER_INTENT от onStartCommand(), тогда он будет воссоздан, если он будет разорван системой (если не остановить работу) как можно скорее.

Я использую BroadcastReceiver для обнаружения изменений в подключении устройства, поэтому, если приложение убито, но служба не работает, я все равно получаю эти изменения в связях?

Для статического BroadcastReceiver (зарегистрирован в Manifest): Это зависит от того, как было прекращено ваше приложение.Если пользователь принудительно остановил его, то приемник снова начнет работать снова после того, как пользователь запустит ваше приложение еще раз. Во всех других случаях: статический приемник будет неповрежден, и если ресивер был создан и зарегистрирован динамически, тогда следует отключить его при выключении Activity/Service во времени, чтобы избежать утечек памяти, поэтому такие приемники не предназначены для работайте 24/7 в любом случае.

Если я хочу получить текущий статус подключения от службы, могу ли я сделать это с помощью getApplicationContext() или он может вернуть значение null?

Это один проще: Service, так же, как Activity, расширяет ContextWrapper. Поэтому, если он запущен и работает, вы можете позвонить getApplicationContext().

Я посылаю событие через шину Отто каждый раз, когда приложение изменяет свой статус от переднего плана к фону (на применение приостановлено/возобновлено) ... Если мое заявление будет убито, я могу доверять в том, что события? Или они не могут быть отправлены?

Я думаю, что здесь вы можете смешать Application и Activity. Потому что, если необходимо сообщить об Service, то, скорее всего, вы думаете о видимой части вашего приложения и что-то вроде знаменитого входящего телефонного звонка.

В этом случае ваша деятельность может уведомить об этом Service либо по телефону onPause(), либо по адресу onStop(). Обе гарантии будут называться с Version HONEYCOMB.

Теперь я должен признаться, я не уверен, что EventBus Отто, но один вариант, который бы, конечно, работать оказывает Service с START_REDELIVER_INTENT и оповещать службу по телефону startService(myNotifyingIntent).

Как правило, ваш процесс приложения не будет немедленно убит только потому, что текущий Activity больше не находится на переднем плане. Поэтому вполне вероятно, что Service получит любое уведомление, отправленное с onPause().

+0

Большое спасибо за ваш ответ. Один вопрос, у меня есть активность, которая полностью зависит от результата службы, чтобы установить все его представления. Итак, было бы хорошей практикой просто раздуть взгляды в методе onCreate активности, а затем в методе onServiceConnected настройте все виды активности? Может ли пользователь увидеть странное поведение (или служба будет связана так быстро, что пользователь ничего не заметит?) Еще раз спасибо! – FVod

+0

@FVod - Один из таких прецедентов для меня был приложением для аудиоплеера с виджетами на главном экране с игрой/пауза и т. д. плюс информация о названии/художнике и те же сведения/элементы управления в MainActivity. Моя активность раздувает представления в onCreate(), а затем в onResume() запускает Сервис, который должен собрать всю информацию о текущем состоянии MediaPlayer и отправить его (локальное вещание) в Activity. Только после этого он может обновить содержимое «Просмотр». * * * * хорошо работает (по сравнению с другими приложениями) на Samsung Galaxy S3mini (Jellybean), но, конечно, никто не может сказать для каждого устройства . – 0X0nosugar

+0

Большое спасибо – FVod

0

1) Службы умирают по умолчанию. Но вы можете переопределить onStartCommand и вернуть START_STICKY. Есть и другие флаги. Поэтому подробнее об этом https://developer.android.com/reference/android/app/Service.html#START_STICKY

2) Да, я бы принял изменения с приемника.

3) getApplicationContext() не должен возвращать NULL.

4) Если ваше заявление было убито, onPause должен был быть вызван. Таким образом, сервис знает это приложение в фоновом режиме. Когда вы запускаете приложение, вызовы onResume, поэтому служба также будет знать это приложение на переднем плане.

Смежные вопросы