1

В Android battery and memory optimizations - Google I/O 2016 (в 18:46 aprox) объясняется, что несвязанные фоновые службы в будущем не будут работать.Предоставлять услуги между действиями и новыми рекомендациями по андроиду для обесценивания неограниченных backgound-сервисов

Я понимаю, что дух этого изменения позволяет сохранить пользовательскую батарею и сделать телефон отзывчивым и работоспособным.

Но у меня есть один случай, который по духу является ограниченным сервисом, но я реализую его с неограниченным.

Вариант использования - это услуга, «привязанная к нескольким действиям», и ее можно уничтожить, когда действия не находятся на переднем плане, но ее необходимо сохранить между переходами между видами деятельности. (Например, служба, которая поддерживает какое-то общее состояние и ресурсы, которые одинаковы для всех видов деятельности, и неплохо воссоздать его).

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

Есть ли у кого-нибудь идеи о том, как улучшить реализацию этого варианта использования без неограниченных услуг? Или знаете, добавятся ли в будущем дополнения к сервисам, чтобы использовать шаблон без использования неограниченного сервиса?

+1

Не можете ли вы просто 'bindService' (без предварительной' startService') и сохранить состояние и ресурсы в пользовательском 'ContentProvider'? – pskink

+0

Спасибо @pskink, это альтернатива. Но мне действительно не нравится смешивать ContentProviders здесь. Я предпочел бы временно сохранить состояние обслуживания между созданием службы в приложении. То, что мне не нравится в CP, - это реализовать его, если мне это не нужно/не нужно, а также что жизненный цикл для моего понимания - это процесс процесса. – lujop

+0

'' Я предпочту временное состояние обслуживания хранилища между созданием службы в приложении «' вы имеете в виду пользовательский класс android.app.Application? он имеет тот же жизненный цикл, что и ваш пользовательский ContentProvider: он уничтожается после того, как ваш процесс умирает – pskink

ответ

0

Пункт от @CommonsПодробнее о использовании синглета является хорошим моментом. Практически всегда просто лучше, и поскольку другие решения добавляют больше сложностей и не решают проблемы жизненного цикла как таковые, я принял идею @CommonsWare.

В конце концов, другие идеи предлагают больше сложностей, которые не нужны, потому что, поскольку у нас есть деятельность на переднем плане, нам не нужно объяснять использование службы, чтобы указать, что какая-то работа выполняется в фоновом режиме.

Решение, которое я разработал, использует одиночный одноразовый счетчик, который отслеживает, использует ли какая-либо активность услугу, и когда никто не использует «сервис» в течение некоторого времени, он уничтожается.

I created a Gist if some is interested in the code. Любые комментарии о реализации приветствуются.

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

  • Нет связанных вопросов^_^