Вопрос по boot, android, alarmmanager – Дизайн Android: фоновый длительный сервис или AlarmManager?

6

Я создаю приложение, которое будет следить за состоянием батареи, Wi-Fi-соединением и данными о местоположении через равные промежутки времени и записывать результаты в файл (а затем отправлять их на сервер). При установке приложения мониторинг должен быть отключен - но пользователь, включающий его, должен пережить перезагрузку. После долгих чтений я понял, что у меня есть 2 варианта:

ПодклассService и уволить его от моей деятельности. Установите его на передний план, прилипайте, а что нет, и надейтесь, что он не будет убит андроидом, и позаботьтесь, если андроид его воссоздает (на самом деле должно быть 3 сервиса, поэтому синхронизация между ними может быть грязной). Запустите тему в сервисе (я полагаю, нет необходимости в исполнителях) и получите ееThread.sleep(REGULAR_INTERVAL), Проснись, собери данные запиши их в файл. Передайте собранную информацию и отобразите ее в моей активности, если она будет запущена (для которой будет зарегистрирован Broadcast Receiver). Промыть и повторитьwhile(true), Есть способ прервать этоПусть моя активность зарегистрирует PendingIntent с AlarmManager, который будет запускаться каждый REGULAR_INTERVAL. У меня нетЯ так много изучал технические детали этого подхода, но я надеюсь, что смогу заставить PendingIntent создать и запустить IntentService (похоже, так и есть - иметь бесплатное ПО Thread, а также отключаться самостоятельно). ). Некоторый скелетный код для этого подхода приветствуется.

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

Итак, прежде чем я начну это строить, какой подход предпочтительнее?

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

Я не'не понизить ваш вопрос, но кто-то еще немне понравилось. Дон»не слишком беспокоиться об этом. Luksprog
Почему отрицательный голос? Mr_and_Mrs_D
@ Luksprog: да нет проблем - я неНе думаю, что это ты: D - Я ненавижу отрицательные голоса без причины - и в любом случае этоне плохой вопрос или что-нибудь - дух Mr_and_Mrs_D
Ваши пользователи, вероятно, убьют вас, если вы сохранитеService живы непрерывно истощая свой телефонs аккумулятор только для сбора данных купола в определенные промежутки времени. Используйте второй подход, сIntentService с дополнительными WakeLocks при необходимости (посмотрите на CommonsWare'sWakefullIntentService). Luksprog
@Luksprog: спасибо - нужны ли мне замки? в приемнике вещания, который получит сигнал тревоги (все еще изучая, как именно это должно быть реализовано)? Mr_and_Mrs_D

Ваш Ответ

3   ответа
0

В зависимости от продолжительности повторяющейся задачи вы можете выбрать один из нескольких подходов. Этот вопрос обсуждает их -Планирование повторяющейся задачи в Android

Использование AlarmManager удобно, когда время ожидания задачи составляет 15 минут или более. Картина хорошо известна.

@CommonsWare: у меня похожая ситуация для выполнения некоторого задания (GPS Positioning) с интервалом в 1 минуту. Я использую Handler для этого в своей основной деятельности, как это повлияет на мое приложение Tushar
6

в то время как в случае 2 зарегистрируйте приемник для события тревоги и настройте диспетчер тревоги

Ваш получатель уже будет зарегистрирован через манифест.

какой будет предпочтительным подходом?

AlarmManagerпредполагаяREGULAR_INTERVAL обычно прилично длинный (например, более нескольких минут). В идеале этот интервал настраивается пользователем.

Если вы намерены сделать это, даже если устройство в противном случае спит, ваш вариант № 1 просто не будет работать, если вы не сохранитеWakeLock на все время, что заставит ваших пользователей хотеть выстрелить вам в лицо из дробовика.

Некоторый скелетный код для этого подхода приветствуется.

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

Вот пример приложения демонстрируя использованиеAlarmManager за_WAKEUP тревоги, используямойWakefulIntentServiceWakefulIntentService (или что-то подобное) необходимо, потому чтоAlarmManager не дает устройству долго спать (достаточно дляonReceive() изBroadcastReceiver), и поэтому вам нужно предпринять дополнительные шаги, чтобы держать устройство в активном состоянии достаточно долго, чтобы вы могли выполнять свою работу.Теоретически, ваша работа может быть достаточно быстрой, чтобы сделать только вonReceive() изBroadcastReceiver, избегая необходимости возиться сWakefulIntentService, Однако вы будете выполнять дисковый ввод-вывод каждый раз, что в идеале не должно выполняться в основном потоке приложений, гдеonReceive() называется. И, когда вы идете, чтобы загрузить свои данные, вам вполне может понадобитьсяWakefulIntentService тогда, во всяком случае, если вы хотите сделать это в фоновом режиме.

Спасибо - зачем регистрировать BroadcastReceiver в манифесте (а не загрузочном - он должен быть там)? Wouldn»Значит ли это, что он будет зарегистрирован все время, что приведет к некоторым накладным расходам? Пока BootReceiver -> is monitoring enabled ? (register a receiver for the alarm; set up the alarm) : return кажется более экономичным. Также AlarmReceiver будет работать в моем основном потоке пользовательского интерфейса? Это было бы в том случае, когда моя активность (которая просто отображает собранные данные и позволяет включать / отключать мониторинг) активна - нет? В противном случае не было бы потока пользовательского интерфейса (или это не будет иметь значения) - я не прав? Mr_and_Mrs_D
@CommonsWare. Любая идея, как приложение, как WhatsApp, FB работает так гладко - почти в режиме реального времени и с небольшим расходом батареи. Можете ли вы порекомендовать какой-либо пример приложения для этого. Мне нравятся ваши книги и блоги, и было бы здорово, если бы вы могли написать пост в блоге. Я обнаружил, что многие были сбиты с толку (включая меня) и увидели все ваши ответы о переполнении стека. user2223032
@Mr_and_Mrs_D: "В противном случае не было бы потока пользовательского интерфейса " - всегда естьПользовательский интерфейс ", точнее, называется "основная ветка приложения ", Если вы тратите слишком много времени на основной поток приложения, даже изonReceive()Android прекратит работу. CommonsWare
Хорошо, я должен прочитать о BR - я подумал, что если я зарегистрирую приемник в загрузочном приемнике - или в моем приложении, когда пользователь включит мониторинг, я буду в порядке. Посмотрите на опубликованный код и вернитесь для получения дополнительной информации - поскольку от меня ускользает множество мелких деталей :) Mr_and_Mrs_D
@Mr_and_Mrs_D: "зачем регистрировать BroadcastReceiver в манифесте? - в противном случае вам необходимо постоянно поддерживать компонент (например, Сервис), что является точкой перехода кAlarmManager, Ты сделаешьне хочу постоянно занимать память. "Wouldn»Значит ли это, что он будет все время регистрироваться - что приведет к некоторым накладным расходам? " - он будет использоваться только вашим. "AlarmManagerТакже AlarmReceiver будет работать в моем основном потоке пользовательского интерфейса? " -onReceive() изBroadcastReceiver вызывается в главном потоке приложений. CommonsWare
1

использовать второй вариант, и следует использовать intentService + AlarmManager, см. этот примерhttp://www.dotkam.com/2011/01/10/android-prefer-alarms-and-intent-receivers-to-services/

Похожие вопросы