gang018 Dec 28 2015 at 12:25

Push уведомления в Android. Грабли, костыли и велосипеды

6 min

147K

Development of mobile applications*Development for Android*

From sandbox

+12

Comments 21

zo_oz Dec 28 2015 at 12:53

Результаты были в районе 20-25% расхода заряда за 8-9 часов.

Это не нормально. Как вообще можно принять после таких тестов такое решение? 3%/час при спящем телефоне? Конечно, все зависит от объема аккумулятора, но это же просто издевательство над людьми…

gang018 Dec 28 2015 at 13:06

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

kekekeks Dec 29 2015 at 11:31

Издевательство над людьми — выпускать устройства с не работающими нормально Push-уведомлениями.

jvIlya Dec 28 2015 at 13:01

Есть такой экран Settings->Battery->History details
Интересно глянуть его с вашим приложением и без него. Особенно строчку с awake.

Я думаю, если приложение все ночь будит устройство каждые 5 минут (проснуться+слазить в интернет), то батарейка должна заметно садится.

gang018 Dec 28 2015 at 13:08

Нашел этот пункт. Сегодня обязательно попробую провести тест и отписаться по результатам

forceLain Dec 28 2015 at 13:06

Необходимо в пределах 30-60 секунд оповестить пользователя о некотором действии

В конечном счете было принято решение о том, чтобы держать свое соединение с сервером в связке с GCM.

Надо было сразу с этого начинать. И убрать GCM.

Нам это уведомление не нужно, поэтому мы воспользовались следующим велосипедом… запустить одновременно с первым сервисом второй… затем убить второй сервис.

Жесть конечно. А потом все плюются от качества ПО в маркете…

bejibx Dec 29 2015 at 14:54

Согласен, жесть, но во многих ситуациях иначе никак. Знаете ли вы, например, что поддержка карт памяти появилась в Android SDK только в API 4.4 (KitKat)? Все приложения, поддерживающие более ранние версии операционки используют хаки и костыли чтобы понять по какому пути смонтирована карта памяти, ведь каждый вендор монтирует куда ему вздумается. Как у разработчика, у тебя есть выбор: либо писать хаки и костыли и потом страдать от последствий ради того, чтобы предоставить пользователю функционал, который он хочет, либо мягко послать его в пеший эротический тур, сославшись на «извините, злой Google не даёт нам так делать». Во втором случае, вам, мягко говоря, не поверят, ведь всегда найдётся кто-то, кто не постесняется накидать хаков и костылей ради функционала и тогда пользователи справедливо возразят — «Но у Васьки то работает». И после этого попробуйте втолковать людям что так делать нехорошо. Sad but true.

forceLain Dec 28 2015 at 13:16

Для того, что бы периодически опрашивать сервер не нужно городить будильники из AlarmManager. Нужен SyncAdapter. Но в вашем случае, как мне кажется, вместо постоянного периодического опроса сервера лучше подойдет сервис и long polling в нём.

BupycNet Dec 28 2015 at 16:34

Кстати. Интересно можно ли сделать соединение с сокетом, чтобы телефон спал (мало потреблял) но и мог принять через сокет данные?

bejibx Dec 29 2015 at 14:45

Только вместе с WakeLock'ом, а это автоматически означает работающий на-полную процессор. Более того, на некоторых устройствах нужно (кто бы сомневался) использовать грязнейший хак, описанный тут — Reception of UDP packets in sleep mode.

Xcam Dec 28 2015 at 15:07

И именно там нашли ответ на вопрос — начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми. Вывод — всегда читайте документацию.

в документации нашел только такие строки

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose {@code targetSdkVersion} is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

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

Alexey_Bespaly Dec 28 2015 at 15:16

начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми.

Да где же такое написано?

Документация:

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose targetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

Да они не точные, но и батарейку не сажают. Вам наверное не подойдут. Но вводить в заблуждение тоже не стоит.

h0tkey Dec 28 2015 at 18:45

Я, вероятно, что-то упустил, но для достижения latency уведомлений в 30-60 секунд вам пришлось и «будильник» с таким же периодом запускать? Если да, то подозреваю, что устройства в сон уходить почти не будут, потому что это, ЕМНИП, не мгновенный процесс, сон многоуровневый и наступает постепенно.

BupycNet Dec 28 2015 at 21:53

Странно, что автор сразу такое не нагуглил.
stackoverflow.com/questions/13534732/how-to-make-the-android-device-hold-a-tcp-connection-to-internet-without-wake-lo
Судя по всему можно таки сделать постоянное TCP соединение и усыпить девайс. Причём потом разбудить его приходом пакета.

Bo_bda Dec 29 2015 at 00:22

а вы уверены, что у вас система не вырубит инет сама тем более с введением новых систем сна в 6.0? хотя если мне не изменяет память, то она вообще сейчас может убить все если не ставить специальные флаги.

Если не прав, поправьте.

BupycNet Dec 29 2015 at 01:43

Я тут не сильно специалист. Сам не знал, что такое может вообще работать. Но технически — если у нас например есть процесс и он не убит, и есть например 3G-4G сеть, или Wifi в режиме «не выключать в режиме сна» то вполне все должно работать.
Ну в крайнем случае — можно эти флаги и использовать.

bejibx Dec 29 2015 at 15:52

Для меня данная информация выглядит сомнительно. Не указаны ни версии Android ни конкретные модели устройств на которых это заработало. В противовес могу привести несколько ссылок на stackoverflow, где утверждается обратное:

Скорее всего, как обычно, поведение очень сильно зависит от конкретного устройства и версии ОС. Для меня невозможность получить данные от сокета в режиме сна без WakeLock'а выглядит абсолютно логично — процессор в режиме сна просто прекращает обработку процесса вашего приложения, а без доступного процессорного времени как понять что на сокет что-то прилетело?

BupycNet Dec 29 2015 at 16:34

Мне что то подсказывает, что проблема может решиться api для приложений связанное с администратором устройства.
Вообще тот же gcm ведь по сути вроде как держит соединение и в wakelock может принимать пуши. Что мешает сделать тоже самое?
Вообще проблема для меня едкая — сам хочу в PushAll сделать резервный сервис. У нас уже есть веб сокет как резерв помогает тем, кто с компа заходит с закрытыми портами (сокет проксируется через nginx на обычном порту)
Вполне можно опционально подключать, если GCM отвалился.

bejibx Dec 29 2015 at 19:42

Вообще тот же gcm ведь по сути вроде как держит соединение и в wakelock может принимать пуши. Что мешает сделать тоже самое?

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

Мне что то подсказывает, что проблема может решиться api для приложений связанное с администратором устройства.

Не факт. В любом случае тут всё упирается в необходимость запросить у пользователя разрешение на администрирование устройства для вашего приложения. С большой долей вероятности пользователь просто удалит приложение за такую наглость.

BupycNet Dec 29 2015 at 20:22

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

bejibx Dec 30 2015 at 11:44

Проблема «Администратора устройства» в том, что этот режим даёт приложению кучу полномочий сразу, без возможности выборочной отмены. Получается вы выводите пользователю эту статистику и просите его разрешить админку. Он думает — «Почему бы и нет?», открывается системное окно и там написано, что приложение получит возможность «удалять данные устройства», «запрещать использование камеры»,… «увести жену», «забрать кота» и вот на этом шаге у многих может возникнуть недоверие. Я бы точно не стал давать приложению такие полномочия только ради уведомлений, разве что это приложение написано мной лично.

Show the best of all time