Оптимизируйте доступ к сети

Использование беспроводного радиомодуля для передачи данных — потенциально один из самых существенных источников расхода заряда батареи вашего приложения. Чтобы минимизировать расход заряда батареи, связанный с сетевой активностью, крайне важно понимать, как ваша модель подключения повлияет на базовое радиооборудование.

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

Государственная машина радио

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

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

Государственная машина для типичного сетевого радио 3G состоит из трех энергетических состояний:

  • Полная мощность : используется при активном соединении, позволяя устройству передавать данные с максимально возможной скоростью.
  • Низкое энергопотребление : промежуточное состояние, при котором потребление энергии аккумулятора сокращается примерно на 50%.
  • Режим ожидания : состояние минимального энергопотребления, в течение которого сетевое соединение неактивно.

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

Чтобы минимизировать задержку, штат Машина использует задержку, чтобы отложить переход на более низкие энергетические состояния. На рисунке 1 используется время AT & T для типичного 3G -радио.


Рисунок 1. Типичная машина состояний беспроводной радиосвязи 3G.

Конечный автомат радиосвязи на каждом устройстве, в частности связанная с ним задержка перехода («время окончания») и задержка запуска, будут различаться в зависимости от используемой технологии беспроводной радиосвязи (3G, LTE, 5G и т. д.) и определяются и настраиваются сетью оператора, в которой работает устройство.

На этой странице описывается типичная схема состояния типичной беспроводной радиосети 3G, основанная на данных, предоставленных AT&T. Однако общие принципы и соответствующие рекомендации применимы ко всем реализациям беспроводной радиосвязи.

Этот подход особенно эффективен для типичного мобильного веб-сёрфинга, поскольку предотвращает нежелательные задержки во время просмотра веб-страниц. Относительно короткое время задержки также гарантирует, что после завершения сеанса сёрфинга радиомодуль сможет перейти в состояние с более низким энергопотреблением.

К сожалению, такой подход может привести к неэффективности приложений на современных операционных системах смартфонов, таких как Android, где приложения работают как на переднем плане (где важна задержка), так и в фоновом режиме (где приоритетом должно быть время работы от аккумулятора).

Как приложения влияют на состояние радиоаппаратуры

При каждом создании нового сетевого подключения радиомодуль переходит в состояние полной мощности. В случае типичного конечного автомата 3G-радио, описанного ранее, он будет работать на полной мощности в течение всего времени передачи данных, плюс дополнительные 5 секунд задержки, после чего 12 секунд будет находиться в состоянии низкого энергопотребления. Таким образом, для типичного 3G-устройства каждый сеанс передачи данных будет потреблять энергию не менее 18 секунд.

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


Рисунок 2. Относительное потребление энергии беспроводной радиосвязи при передаче данных длительностью в одну секунду, выполняемой три раза в минуту. В график не входит задержка включения между запусками.

Для сравнения, если бы то же приложение объединяло передачу данных, выполняя одну трёхсекундную передачу каждую минуту, это поддерживало бы радиостанцию в режиме высокой мощности всего 20 секунд в минуту. Это позволило бы радиостанции находиться в режиме ожидания 40 секунд в минуту, что значительно снизило бы расход заряда батареи.


Рисунок 3. Относительное потребление мощности беспроводной радиосвязи для трехсекундных передач, выполняемых раз в минуту.

Методы оптимизации

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

Пакетная передача данных

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

Конечно, это не всегда возможно, если вашему приложению необходимо немедленно получать или отправлять данные в ответ на действие пользователя. Вы можете снизить эту нагрузку, предвосхищая и выполняя предварительную загрузку данных . Другие сценарии, такие как отправка журналов или аналитики на сервер и другие несрочные передачи данных, инициированные приложением, отлично подходят для пакетной обработки и объединения. Советы по планированию фоновой сетевой передачи данных см. в разделе «Оптимизация задач, инициированных приложением» .

Предварительная выборка данных

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

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

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

Вот практический пример.

Читатель новостей

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

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

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

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

Дополнительные соображения

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

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

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

Следуя этому принципу, большие загрузки, такие как видеофайлы, следует осуществлять порциями с регулярными интервалами (каждые 2–5 минут), фактически предварительно загружая только те видеоданные, которые, скорее всего, будут просмотрены в течение следующих нескольких минут.

Одно из решений — запланировать полную загрузку только при подключении к Wi-Fi и, возможно, только во время зарядки устройства. API WorkManager поддерживает именно этот вариант использования, позволяя ограничить фоновую работу до тех пор, пока устройство не будет соответствовать критериям, указанным разработчиком, таким как зарядка и подключение к Wi-Fi.

Проверьте наличие подключения перед отправкой запросов

Поиск сигнала сотовой связи — одна из самых энергозатратных операций на мобильном устройстве. Рекомендуется сначала проверить наличие соединения с помощью ConnectivityManager , как показано в разделе «Мониторинг состояния подключения и измерение подключения» . При отсутствии сети приложение может экономить заряд батареи, не заставляя мобильное устройство выполнять поиск. Запрос можно запланировать и выполнить в пакете с другими запросами при установлении соединения.

Подключения к бассейну

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

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

HttpURLConnection и большинство HTTP-клиентов, таких как OkHttp , по умолчанию включают пул соединений и повторное использование одного и того же соединения для нескольких запросов.

Подведение итогов и взгляд в будущее

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

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