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