Использование беспроводной связи для передачи данных потенциально является одним из наиболее значительных источников разряда батареи вашего приложения. Чтобы свести к минимуму расход заряда батареи, связанный с сетевой активностью, очень важно понимать, как ваша модель подключения повлияет на базовое радиооборудование.
В этом разделе описывается конечный автомат беспроводной радиосвязи и объясняется, как с ним взаимодействует модель подключения вашего приложения. Затем он предлагает несколько методов, соблюдение которых поможет минимизировать влияние потребления данных вашим приложением на батарею.
Государственная машина радио
Беспроводная радиосвязь на устройстве вашего пользователя имеет встроенные функции энергосбережения, которые помогают свести к минимуму количество потребляемой энергии аккумулятора. В полностью активном режиме беспроводная радиосвязь потребляет значительную мощность, но в неактивном или ждущем режиме радиостанция потребляет очень мало энергии.
Следует помнить один важный фактор: радиостанция не может мгновенно перейти из режима ожидания в полностью активный режим. Существует период задержки, связанный с «включением» радиостанции. Таким образом, батарея медленно переходит из состояний с более высокой энергией в состояния с более низкой энергией, чтобы сохранить мощность, когда она не используется, и одновременно попытаться минимизировать задержку, связанную с «включением» радиостанции.
Конечный автомат типичной сетевой радиосвязи 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 для эффективного управления этими взаимодействиями.