Comments 19
Стоит упомянуть, что в последей версии «пушей» от гугла есть несколько важных нововведений.
Например, поддержка так называемого «upstream messaging», то есть обмен сообщениями не в одну сторону ( Your Server => GCM Cloud => Device, как это есть сейчас), но еще и в обратную ( Device <=> GCM Cloud <=> Your Server ).
Называется оно CCS ( developer.android.com/google/gcm/ccs.html ), и поскольку использует XMPP как транспорт (кстати говоря, Device => GCM Cloud использует тот же XMPP), то можно реализовать перманентное (условно перманентное, потому что имеют место разрывы сети итд) соединение не только между Device и GCM Cloud (как сейчас), но и между GCM Service и Your Server, что позволяет сократить время обмена сообщениями между девайсом и Вашим сервисом за счет времени коннекта и хендшейка.
Например, поддержка так называемого «upstream messaging», то есть обмен сообщениями не в одну сторону ( Your Server => GCM Cloud => Device, как это есть сейчас), но еще и в обратную ( Device <=> GCM Cloud <=> Your Server ).
Называется оно CCS ( developer.android.com/google/gcm/ccs.html ), и поскольку использует XMPP как транспорт (кстати говоря, Device => GCM Cloud использует тот же XMPP), то можно реализовать перманентное (условно перманентное, потому что имеют место разрывы сети итд) соединение не только между Device и GCM Cloud (как сейчас), но и между GCM Service и Your Server, что позволяет сократить время обмена сообщениями между девайсом и Вашим сервисом за счет времени коннекта и хендшейка.
Интересно читать эту статью здесь (особенно когда рядом реклама: «Агент Mail.Ru cо звонками»). Запустил я как то раз этот агент у себя на телефоне, так он как начал жрать мою батарею. И продолжал жрать пока я его процесс не убил.
Иногда мне приходится использовать программы, которые жрут батарею. И удалять — не выход.
Немного помогает Greenify (только для тех, кто уже получил root)
Немного помогает Greenify (только для тех, кто уже получил root)
UFO just landed and posted this here
Спасибо за замечание. Еще не успел посмотреть на Volley Library в действии, т.к. всего месяц назад ее презентовали на Google IO 2013, обязательно скоро попробую и может быть добавлю в статью.
Мое личное ИМХО относительно абстрактных моделей Android Framework — скоро Gingerbread уйдет в небытие — и соответственно использование HttpClient от Apache уже медленно, но верно теряет смысл, HttpURLConnection выйдет на первый план. Кстати, вот ссылочки на неплохие обертки, работают как на Java так и на Android (здесь и здесь)
Меня больше интересует другой момент, как Вы производите отладку http-трафика? При использовании HttpClient спасал их Logger, а вот как Вы справляетесь при использовании HttpURLConnection? Я к сожалению не смог найти чего-либо более вменяемого, чем отладка трафика с эмулятора через Wireshark.
Меня больше интересует другой момент, как Вы производите отладку http-трафика? При использовании HttpClient спасал их Logger, а вот как Вы справляетесь при использовании HttpURLConnection? Я к сожалению не смог найти чего-либо более вменяемого, чем отладка трафика с эмулятора через Wireshark.
скоро Gingerbread уйдет в небытие — и соответственно использование HttpClient от Apache уже медленно, но верно теряет смысл,
что уйдет в небытие — согласен, насчет как скоро сказать не решусь, т.к. плафтормы <= 2.3 все еще занимают порядка 25% из всех Android OS.
Меня больше интересует другой момент, как Вы производите отладку http-трафика?
Для отладки используем тоже Wireshark, также Network Traffic Tool. Еще рекомендую посмотреть в сторону новой библиотеки для работы с сетью Volley, наверняка, там есть фичи, связанные с отладкой трафика.
Ссылочка потерялась
Поправил. Библиотек Volley.
Наш безопасник использует Charles для отладки HTTP- и HTTPS-трафика. Можно ставить брейкпоинты на определённые запросы, дропать их.
Да, штучка интересная — говорят хорошая альтернатива для wireshark, возьму на заметку, спасибо!
Да, ещё я сам использовал ZAP code.google.com/p/zaproxy/, но он тормозной местами, а безопасник использует Charles, т.к. ему нужно редактировать запросы и ответы.
Wireshark — штука хорошая, но для высокоуровневых протоколов вроде HTTP не очень удобная. Вот ручную работу с сокетами через него отлаживать — самое то.
Wireshark — штука хорошая, но для высокоуровневых протоколов вроде HTTP не очень удобная. Вот ручную работу с сокетами через него отлаживать — самое то.
А о чем, в первую очередь, думаете вы?
Я в первую очередь думаю, что речь в статье о доставке обновлений с сервера на клиент, а не об общем случае сетевого взаимодействия в вакууме — это исходя из описания. Во вторую очередь я думаю о том, что для этого кейза есть сто раз описанная и обговоренная связка типа:
1) если размер обновлений невелик, то сервер пересылает все данные обновлений в самой пуш-нотификации
2) если размер обновлений велик, то сервер пересылает в пуш-нотификации только сигнал о наличии и количестве обновлений
3) клиент либо сразу обновляет контент в случае 1) либо делает запрос на сервер и получает пачку апдейтов в случае 2)
Все, других формул нет. Единственный возможный вариант — это свой long-polling для каких-либо нужд. Но не используют его не потому что
Реализация этого подхода достаточно сложна на мобильном клиенте в первую очередь из-за нестабильности мобильного соединения
а потому что «у нас сервер такого количества одновременно висящих соединений не выдержит» или «наши программисты не смогут такое сделать быстро, а клиент нужен вчера». Да и в общем случае встроенного механизма более чем хватает.
В третью очередь, глядя на эту статью, я думаю о том, что каждый раз, когда вставал вопрос о Keep-Alive в соединении (который, черт побери, опять же создает серьезную нагрузку на сервер) — всегда это происходило в одном и том же случае:
— Ребята, а где у нас запрос на получение контента Вьюшки Номер Один?
— Чувак, глянь спеку API, десяток разных запросов — и будет тебе счастье.
— Сколько?!!!
— Ну, десять, что ли… А потом еще по три запроса на каждый из десяти
И тут, что характерно, есть два решения. Первое — это оптимизировать в поте лица, но это паршивое решение. Это означает, что ты а) борешься со следствием, а не с причиной б) огребаешь последствия в виде усложения структуры приложения в) поощряешь рост профнепригодности парней на серверной стороне, или по крайней мере того гения, который такой API разработал. Хорошее решение — это сделать один (я настаиваю, один, не два, не три, а ровно один) аггрегирующий запрос для мобильного приложения, либо дать возможность каким-либо образом создавать произвольные аггрегирующие запросы.
Второй неприятный (может быть, только для меня) момент при работе с HttpUrlConnection заключается в том, что параметр keep alive duration не поддается настройке (я легального способа не нашел, если кто подскажет — буду признателен).
Правильно не поддается. Потому что время жизни keep-alive соединения настраивается на сервере, там же настраивается и пресловутый keep-alive duration, который на самом деле keep-alive timeout. Если оно настроено, то сервер в респонсе вернет что-то вроде
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Соответственно, при использовании HttpUrlConnection необходимо будет самому трекать timeout, определяя, какой коннекшн еще можно использовать, а какой нет, а при использовании HttpClient пробросить этот параметр как значение getKeepAliveDuration (пример тут)
Спасибо за комментарий.
Речь в статье, в первую очередь, какие аспекты при работе с http клиентами (urlconnection и httpclient) влияют потребление трафика, безопасность и расход батареи.
согласен, много описано об этом: Google I/O 2010 — Building push applications for Android, Google I/O 2012 — Google Cloud Messaging for Android и Google I/O 2013 — Google Cloud Messaging. Поэтому в этой статье об этом ничего и не рассказывается, а просто упоминается в начале о механизме пуш-уведомлений.
не соглашусь. Обычный polling — это тоже способ доставки обновлений на клиент. Далеко не все приложения используют GCM или пишут свою реализацию long-polling'a.
вы не внимательно прочитали статью, о том как настроить keep alive duration в HttpClient в ней рассказывается.
Я в первую очередь думаю, что речь в статье о доставке обновлений с сервера на клиент
Речь в статье, в первую очередь, какие аспекты при работе с http клиентами (urlconnection и httpclient) влияют потребление трафика, безопасность и расход батареи.
Во вторую очередь я думаю о том, что для этого кейза есть сто раз описанная и обговоренная связка типа:
1) если размер обновлений невелик, то сервер пересылает все данные обновлений в самой пуш-нотификации
2) если размер обновлений велик, то сервер пересылает в пуш-нотификации только сигнал о наличии и количестве обновлений
3) клиент либо сразу обновляет контент в случае 1) либо делает запрос на сервер и получает пачку апдейтов в случае 2)
согласен, много описано об этом: Google I/O 2010 — Building push applications for Android, Google I/O 2012 — Google Cloud Messaging for Android и Google I/O 2013 — Google Cloud Messaging. Поэтому в этой статье об этом ничего и не рассказывается, а просто упоминается в начале о механизме пуш-уведомлений.
Все, других формул нет. Единственный возможный вариант — это свой long-polling для каких-либо нужд.
не соглашусь. Обычный polling — это тоже способ доставки обновлений на клиент. Далеко не все приложения используют GCM или пишут свою реализацию long-polling'a.
а при использовании HttpClient пробросить этот параметр как значение getKeepAliveDuration
вы не внимательно прочитали статью, о том как настроить keep alive duration в HttpClient в ней рассказывается.
не соглашусь. Обычный polling — это тоже способ доставки обновлений на клиент. Далеко не все приложения используют GCM или пишут свою реализацию long-polling'a.
Способ — да, хороший в плане баланса «реалтайм-нагрузка на сервер» — нет.
вы не внимательно прочитали статью, о том как настроить keep alive duration в HttpClient в ней рассказывается.
Статью я прочитал внимательно. Ссылку на пример я скинул потому, что там верно сделана обработка keep alive timeout. В случае изменения времени жизни коннекта на сервере ваш код вызовет снижение скорости работы с сетью у всех юзеров. Код по ссылке — только у тех, у кого очередной злобный проксятник отрежет хедер Keep-Alive.
Sign up to leave a comment.
Работа с сетью в Android: трафик, безопасность и батарейка