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