Помимо мультиплексирования, в чём принципиальная разница между Google Mobile Services (Google Cloud Messaging) и обычными слушающими сокетами? В обоих случаях модем остаётся активным во время соединения. Я так полагаю, что GMS может реализовывать механизм pull, и тогда модем засыпает между запросами, но сообщения через Гугл доставляются достаточно шустро, поэтому если pull и используется, то частота вызовов очень большая. Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление? Допустим, это защита от случая, когда приложение реально грузит телефон в фоне, но почему бы тогда не создать прослойку, которая разрешает лишь создание сокета, а для всего остального пуская выводится уведомление? Может кто-то знаком с внутренностями и может пролить свет.
А зачем им это? Гугловый пуш это один из вариантов привязки приложения к Play Services. Думаю, тут причина в первую очередь политическая. Хотели бы — могли бы сделать стандартный протокол для пуша и позволить приложениям указывать адрес сервера, с которого они хотят получать пуши, а дальше всё ровно так же, как и с GMS. И никаких проблем, какая разница, с какого адреса пришёл этот пуш.
Здравствуйте, cppguard, Вы писали:
C>Помимо мультиплексирования, в чём принципиальная разница между Google Mobile Services (Google Cloud Messaging) и обычными слушающими сокетами? В обоих случаях модем остаётся активным во время соединения. Я так полагаю, что GMS может реализовывать механизм pull, и тогда модем засыпает между запросами, но сообщения через Гугл доставляются достаточно шустро, поэтому если pull и используется, то частота вызовов очень большая. Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление? Допустим, это защита от случая, когда приложение реально грузит телефон в фоне, но почему бы тогда не создать прослойку, которая разрешает лишь создание сокета, а для всего остального пуская выводится уведомление? Может кто-то знаком с внутренностями и может пролить свет.
Можно предположить существование отдельного и очень экономного чипа, на который вынесена логика работы с соединением GMS, нечто вроде tcp offload, но более высокоуровневое. Такая штука будет потреблять меньше батареи, чем полноценный сокет приложения, которые приложения вдобавок пишут ногами.
Здравствуйте, cppguard, Вы писали:
C>Помимо мультиплексирования, в чём принципиальная разница между Google Mobile Services (Google Cloud Messaging) и обычными слушающими сокетами? В обоих случаях модем остаётся активным во время соединения. Я так полагаю, что GMS может реализовывать механизм pull, и тогда модем засыпает между запросами, но сообщения через Гугл доставляются достаточно шустро, поэтому если pull и используется, то частота вызовов очень большая. Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление? Допустим, это защита от случая, когда приложение реально грузит телефон в фоне, но почему бы тогда не создать прослойку, которая разрешает лишь создание сокета, а для всего остального пуская выводится уведомление? Может кто-то знаком с внутренностями и может пролить свет.
На мой взгляд, как уже было сказано, привязка к гуглу. И экономия батарейки: от гугла сообщения будут поступать, например,
будучи строго привязанные к временной сетке, например, раз в 15 секунд. Итого не более 240 пробуждений в час. И в каждом
пробуждении можно сразу множество сообщений получить и обработать. А если каждый будет со своим сокетом, то там всё будет
вразнобой и будиться будут когда попало, и чаще в итоге, будет больше съедено батарейки.
Побудка касается и процессора, и GSM-модуля. Который может с открытым TCP-соединением запросто уснуть и просыпаться
только раз в несколько секунд на короткое время. Будет передача данных: пробудится и несколько секунд, наоборот, спать
не будет и будет жрать батарейку. Но в это время данные доставляются немедленно, без задержки.
Не было бы "тивоизации", лучшим способом была бы насильная привязка бэкграунд аппликаций к временной сетке, те же
"раз в 15 секунд" и разрешение использовать только UDP-сокеты для нотификаций (в TCP задержка с ответом ведёт к перепосылкам
на уровне стека).
Здравствуйте, cppguard, Вы писали:
C>Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление?
С каких пор запретили открывать сокет в фоновом режиме?
Проблема не в открытии соединения в фоновом режиме, а то что вся активность
приложения в фоновом режиме может быть приостановлена ОС Android.
И потоку читающему из сокета может просто не предоставлено CPU.
Сокет тут по-моему не важен, просто популярные мобильные ОС
для могут "заморозить", а потом убить приложения не взаимодействующие
с пользователем, а при выключенном экране это практически все приложения,
за исключением тех кто имеет виджеты на экране блокировки.
Здравствуйте, fk0, Вы писали:
fk0> Не было бы "тивоизации", лучшим способом была бы насильная привязка бэкграунд аппликаций к временной сетке, те же fk0>"раз в 15 секунд" и разрешение использовать только UDP-сокеты для нотификаций (в TCP задержка с ответом ведёт к перепосылкам fk0>на уровне стека).
Но вообще у гугла может в прошлом был, а может и сейчас есть, я не знаю, сценарий передачи нотификаций через SMS например.
Или сценарий побудки телефона через SMS (что телефон вообще отключенный от GPRS таки пробудился и принял сообщение).
Android же начал разрабатываться когда 3G только делал первые шаги и модемы могли не иметь тех режимов сбережения
энергии, что появились в более поздних стандартах. И батарейки были по 900мА*ч, а не по 4.5 А*Ч.
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, cppguard, Вы писали:
C>>Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление?
Z>С каких пор запретили открывать сокет в фоновом режиме?
Начиная то ли с 8, то ли с 7.2, для приложений с фоновой активностью выводится уведомление, которое не смахнуть.
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, cppguard, Вы писали:
C>>Если же там обычный ждущий сокет, то почему приложениям запретили создавать свои подключения в фоне, заставив выводить уведомление?
Z>С каких пор запретили открывать сокет в фоновом режиме? Z>Проблема не в открытии соединения в фоновом режиме, а то что вся активность Z>приложения в фоновом режиме может быть приостановлена ОС Android. Z>И потоку читающему из сокета может просто не предоставлено CPU.
Именно, что сеть могут зарубить: Doze restrictions
The following restrictions apply to your apps while in Doze:
Network access is suspended...
