Подтвердить что ты не робот

Правила подключения к постоянным сокетам Android

Я тестировал специальное решение для push-уведомлений для устройств Android, использующих постоянные сокеты. Я хотел бы поделиться своими выводами и подтвердить результаты.

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

Тест 1:

Pinging is done using a timer at 10 second intervals.
Server sends notification every minute.
Applications acquires wifi and wake locks.
Duration : 8 hours
Battery loss : ~14%

Тест 2:

Pinging is done using AlarmManager at 10 second intervals.
Server sends notification every minute.
Application acquires only a wifilock
Duration : 8 hours
Battery loss : ~7%

Предположения: Входящий сетевой пакет автоматически просыпает процессор, поэтому нет необходимости в блокировке слежения. Использование AlarmManager для ping (вместо таймеров) означает, что нам не нужен wakelock.

Удаление этого вакелока действительно помогло батарее. Удивительно, но агрессивное пинги на любом решении не повлияло на срок службы батареи настолько, насколько я ожидал. (У нас было много других тестов, в том числе тот, в котором приложение просто держало wifilock и ничего не делало, что вызвало от 4% до 5% потери батареи за тот же период)

Поскольку приложение удалось успешно отправить все запросы ping и получить все входящие сообщения, я считаю, что мои предположения верны. Но я хотел бы получить подтверждение от любых экспертов.

Еще один вопрос: Если приложение должно было вместо этого слушать входящие подключения. В этом случае мне нужно будет держать вакелон, правильно? Входящее соединение не пробуждает CPU? Мы не спускаемся по этому маршруту, а просто хотим подтвердить.

Кроме того, пожалуйста, не рекомендуем GCM, это было исключено политикой компании.

Спасибо.

4b9b3361

Ответ 1

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

Дополнительные примечания:

  • В методе OnReceive BroadcastReceiver для сигнала тревоги pinging, если вы не вызываете напрямую сокет (создавая новый поток или намерение), вам нужно будет удерживать блокировку до тех пор, пока запрос ping не будет завершен, Android удерживает блокировку только после того, как OnReceive вернется, после чего возможно (но редко), что CPU может спать до завершения пинга.

  • Используйте Высокопроизводительный Wifi Lock, если уведомления чувствительны.

  • В решении было затронуто еще одна проблема, связанная с конкретным устройством, она покрыта здесь.

Обновление

Подключитесь к следующей проблеме с Android 5.1: Проблема Android

Обновление 2

Нужно кодировать режим Doze для Android 6.0: Doze Mode