Сетевой трафик, генерируемый приложением, может существенно влиять на время работы аккумулятора устройства. Чтобы оптимизировать этот трафик, необходимо его измерять и определять его источник. Сетевые запросы могут поступать непосредственно от действий пользователя, из кода вашего приложения или от сервера, взаимодействующего с вашим приложением.
В этом разделе показано, как отслеживать и классифицировать сетевой трафик, а также даны рекомендации по выявлению и решению проблем.
Используйте Network Profiler для мониторинга запросов
Используйте Network Profiler для отслеживания сетевых запросов вашего приложения. Вы можете отслеживать, как и когда ваше приложение передает данные, и оптимизировать базовый код соответствующим образом.
Рисунок 1. Отслеживание сетевого трафика. Модель сетевого трафика показывает, что эффективность можно значительно повысить, используя предварительную загрузку запросов или группирование загрузок.
Отслеживая частоту передачи данных и объём данных, передаваемых за каждое соединение, вы можете определить области приложения, которые можно сделать более экономичными. Как правило, вы будете искать короткие пики нагрузки, которые можно отложить.
Для более точного определения причины пиков передачи данных API Traffic Stats позволяет маркировать передачи данных, происходящие через сокет в заданном потоке, с помощью TrafficStats.setThreadStatsTag()
. Вызов этой функции не приводит к автоматической маркировке всего трафика для конкретного потока; теги должны быть применены к сокетам.
После установки тега потока вы можете вручную помечать и снимать теги с отдельных сокетов с помощью TrafficStats.tagSocket()
и TrafficStats.untagSocket()
. Тег также применяется, если в потоке открыт сокет или если сокет сервера принимает соединение.
Одновременный доступ нескольких потоков к одному и тому же сокету будет использовать тот тег, который был у сокета в момент отправки или получения сетевых пакетов (который может отличаться от того момента, когда пользователь записал или прочитал данные, из-за буферизации и повторных передач).
Например, вы можете определить константы для представления различных типов сетевого трафика, как показано в следующем примере кода:
Котлин
const val USER_INITIATED = 0x1000 const val APP_INITIATED = 0x2000 const val SERVER_INITIATED = 0x3000
Ява
public static final int USER_INITIATED = 0x1000; public static final int APP_INITIATED = 0x2000; public static final int SERVER_INITIATED = 0x3000;
Затем вы можете соответствующим образом пометить свои сетевые запросы:
Котлин
TrafficStats.setThreadStatsTag(USER_INITIATED) TrafficStats.tagSocket(outputSocket) // Transfer data using socket TrafficStats.untagSocket(outputSocket)
Ява
TrafficStats.setThreadStatsTag(USER_INITIATED); TrafficStats.tagSocket(outputSocket); // Transfer data using socket TrafficStats.untagSocket(outputSocket);
Библиотека HttpURLConnection
автоматически помечает сокеты на основе текущего значения TrafficStats.getThreadStatsTag()
. Библиотека также помечает и снимает пометки с сокетов при их повторном использовании через пулы keep-alive, как показано в следующем примере кода:
Котлин
class IdentifyTransferSpikeTask { @WorkerThread fun request(url: String) { TrafficStats.setThreadStatsTag(APP_INITIATED) // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag() } }
Ява
public class IdentifyTransferSpikeTask { @WorkerThread public void request(String url) { TrafficStats.setThreadStatsTag(APP_INITIATED); // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag(); } }
Анализ типов сетевого трафика
При анализе сетевого трафика, генерируемого вашим приложением, необходимо понимать его источник, чтобы оптимизировать его соответствующим образом. Частая сетевая активность, генерируемая вашим приложением, может быть вполне приемлемой, если оно реагирует на действия пользователя, но совершенно неприемлемой, если приложение не находится на переднем плане или устройство находится в кармане или сумке.
Анализируйте трафик, инициированный пользователем
Сетевой трафик, инициированный пользователем, может эффективно группироваться, пока пользователь выполняет определённую задачу в вашем приложении, или распределяться неравномерно, когда пользователь запрашивает дополнительную информацию, необходимую вашему приложению. Цель анализа сетевого трафика, инициированного пользователем, — выявить закономерности частого использования сети с течением времени и попытаться снизить их частоту путём группировки запросов.
Непредсказуемость пользовательских запросов затрудняет оптимизацию такого типа использования сети в вашем приложении. Кроме того, пользователи ожидают быстрого ответа при активном использовании приложения, поэтому отсрочка запросов ради повышения эффективности может привести к ухудшению пользовательского опыта. В целом, при непосредственном взаимодействии пользователя с вашим приложением следует отдавать приоритет быстрому ответу, а не эффективному использованию сети.
Рекомендации по оптимизации трафика, инициируемого пользователями, см. в разделе Оптимизация запросов, инициированных пользователями .
Анализируйте трафик, инициированный приложением
Сетевой трафик, инициируемый приложением, обычно является областью, в которой вы можете существенно повлиять на эффективность использования пропускной способности сети. Анализируя сетевую активность вашего приложения, обращайте внимание на периоды бездействия и определите, можно ли их увеличить. Если вы видите закономерности постоянного доступа к сети из вашего приложения, попробуйте группировать этот трафик, чтобы радиомодуль устройства мог переключаться в режим пониженного энергопотребления между периодами активности.
Рекомендации по оптимизации трафика, инициируемого приложением, см. в разделе Оптимизация запросов, инициированных приложением .
Анализ трафика, инициированного сервером
Сетевая активность, инициируемая серверами, взаимодействующими с вашим приложением, также обычно является областью, где вы можете существенно повлиять на эффективность использования пропускной способности сети. Firebase Cloud Messaging (FCM) — это простой механизм передачи данных с сервера на конкретный экземпляр приложения. Используя FCM, ваш сервер может уведомлять приложение, работающее на определённом устройстве, о наличии новых доступных данных.
Рекомендации по оптимизации трафика, инициируемого сервером, см. в разделе Оптимизация запросов, инициированных сервером .
Используйте Battery Historian для визуализации влияния сетевого трафика
Battery Historian — это инструмент, визуализирующий расход заряда батареи устройства за определённый период времени. Вы можете использовать этот инструмент для анализа влияния сетевой активности на расход заряда батареи. Например, Battery Historian может показать, использует ли ваше приложение сотовую связь чаще, чем вы ожидаете. Подробнее об использовании Battery Historian см. в разделе «Профилирование расхода заряда батареи с помощью Batterystats и Battery Historian» .