Мы часто сталкиваемся с ситуацией: приложение отлично работает на тестовом Wi-Fi, но пользователи массово жалуются на тормоза. Причина — неоптимальное сетевое взаимодействие, которое выявляется только при профилировании сети мобильного приложения. В одном из наших проектов при открытии ленты отправлялось 47 запросов, из которых 12 дублировались, а 8 загружали данные, уже лежащие в локальном кэше. Каждая лишняя секунда ожидания снижает конверсию на 20%, и без профилирования вы рискуете потерять до 30% аудитории. Анализ HTTP-запросов и оптимизация API помогут избежать этих потерь.
Наша команда имеет 6+ лет опыта в оптимизации мобильных приложений и провела профилирование сети для 40+ проектов. Мы используем современные инструменты и методики, чтобы гарантировать быстрый и стабильный пользовательский опыт. Оптимизация сети не только улучшает UX, но и сокращает расходы на серверный трафик до 40% — в денежном эквиваленте это экономия от 100 000 до 300 000 рублей в год для среднестатистического приложения. Снижение трафика на 30% может сэкономить до 200 000 рублей на серверных счетах за год. Закажите профилирование и получите детальный отчёт с рекомендациями.
Какие инструменты используем?
Charles Proxy / Proxyman
Перехватывают весь HTTP/HTTPS-трафик устройства. Charles Proxy — кросс-платформенный стандарт (Charles Proxy на Wikipedia), Proxyman — нативный macOS-инструмент с лучшим UX для iOS-разработчиков. Настройка: установить корневой сертификат на устройство, выставить прокси в настройках Wi-Fi.
Отметим: что ищем в Charles:
- Дублирующиеся запросы — один и тот же URL несколько раз за короткий период
- Размер ответов — эндпоинты, отдающие явно лишние данные (10 KB там, где нужно 500 байт)
- Время ответа — медленные серверные ответы vs клиентская задержка
- Ошибки и ретраи — сколько запросов завершается ошибкой и как обрабатывается retry
Throttling в Charles (Proxy → Throttle Settings) — симуляция 3G, Edge, медленного Wi-Fi. Charles Proxy предлагает 4 профиля throttling (3G, EDGE, DSL, WiFi) против 2 в Proxyman — это в 2 раза больше вариантов для тестирования. Обязательный шаг: проверить приложение на 400 Kbps перед релизом. Поведение на плохом соединении часто не тестируется и содержит серьёзные баги.
Для корректного перехвата HTTPS-трафика необходимо установить корневой сертификат Charles на устройство и доверять ему. На iOS это делается через Настройки → Основные → Профили. На Android — через Безопасность → Установить сертификат.
Android Network Profiler
Встроен в Android Studio. Показывает запросы в хронологии, тело запроса/ответа, время DNS resolution, SSL handshake, waiting, downloading. Особенно полезен Connection View — видно, сколько параллельных соединений открыто и есть ли очередь ожидания.
Для OkHttp добавляем EventListener для точных метрик:
val client = OkHttpClient.Builder() .eventListener(object : EventListener() { override fun connectStart(call: Call, inetSocketAddress: InetSocketAddress, proxy: Proxy) { Log.d("NET", "connectStart: ${call.request().url}") } override fun responseBodyEnd(call: Call, byteCount: Long) { Log.d("NET", "responseBodyEnd: $byteCount bytes") } }) .build() Xcode Network Instruments + URLSessionTaskMetrics
URLSessionTaskMetrics — встроенный механизм iOS для сбора метрик каждого запроса:
func urlSession(_ session: URLSession, task: URLSessionTask, didFinishCollecting metrics: URLSessionTaskMetrics) { for transaction in metrics.transactionMetrics { print("DNS: \(transaction.domainLookupEndDate! - transaction.domainLookupStartDate!)") print("TLS: \(transaction.secureConnectionEndDate! - transaction.secureConnectionStartDate!)") print("TTFB: \(transaction.responseStartDate! - transaction.requestStartDate!)") } } Это даёт breakdown: DNS lookup, TCP connect, TLS handshake, TTFB (Time to First Byte), transfer time. Если TLS handshake занимает 300 мс на каждом запросе — нет HTTP persistent connections или неправильно настроен Certificate Pinning без session reuse. Подробнее: URLSessionTaskMetrics.
Сравнение инструментов
| Инструмент | Платформа | Особенности | Когда использовать |
|---|---|---|---|
| Charles Proxy | macOS/Windows | HTTP/HTTPS, throttling, rewrite | Универсальное решение |
| Proxyman | macOS | Нативный UI, быстрая настройка | iOS-разработка |
| Android Studio Profiler | Android | Хронология запросов, Connection View | Android-приложения |
| Xcode Instruments | iOS | URLSessionTaskMetrics, Network | iOS-приложения |
Как мы оптимизируем сетевой слой?
Анализ и выявление проблем
Мы проверяем HTTP/2 multiplexing — используется ли протокол или приложение работает на HTTP/1.1 с 6 параллельными соединениями. URLSession и OkHttp поддерживают HTTP/2 автоматически если сервер его поддерживает. Видно в Charles: Protocol: h2 vs http/1.1.
Compression: сервер должен возвращать Content-Encoding: gzip или br (Brotli) для JSON. Если нет — JSON-ответы идут в сыром виде. Разница для типичных API-ответов: 3–5x по размеру.
Connection reuse: TLS handshake — дорогая операция (50–200 мс). Persistent connections переиспользуют установленное соединение. Если каждый запрос начинается с нового handshake — проблема в конфигурации URLSession (несколько инстансов вместо shared) или в серверном keepalive timeout.
Как проводится профилирование: пошагово
- Устанавливаем сниффер (Charles/Proxyman) и корневой сертификат на устройство.
- Настраиваем throttling для симуляции медленного соединения (3G или 400 Kbps).
- Запускаем приложение и воспроизводим типичные сценарии пользователя.
- Записываем весь трафик и анализируем каждый запрос в Charles: ищем дубликаты, крупные ответы, высокое время DNS/TLS.
- Составляем отчёт с найденными проблемами и рекомендациями.
Типичные проблемы и решения
| Проблема | Признак | Решение |
|---|---|---|
| Дублирующиеся запросы | Один URL загружается несколько раз | Кэширование, объединение запросов |
| Отсутствие сжатия | JSON без gzip | Настроить Content-Encoding на сервере |
| Медленный TLS Handshake | Задержка >100 мс каждый раз | Persistent connections, HTTP/2 |
| Некэшируемый DNS | Задержка при каждом запросе | DNS prefetch, единый URLSession |
Практический кейс
Из нашей практики: у клиента каждый запрос к API занимал 800 мс. Профилирование через Charles показало, что каждый запрос имел DNS lookup 120–180 мс. Причина — DNS не кэшировался из-за короткого TTL (60 секунд) и URLSession не переиспользовал DNS resolution между сессиями. Решение: URLSessionConfiguration.urlCache с кастомным DNS prefetch + переход на единый URLSession.shared вместо создания нового инстанса в каждом сервисном классе. После оптимизации время запроса снизилось до 200 мс — ускорение в 4 раза. Свяжитесь с нами для консультации — оценим ваш проект за 1 день.
Что входит в профилирование?
Профилирование включает полный цикл: анализ текущего сетевого взаимодействия приложения, выявление дублирующихся запросов, избыточных данных, медленных эндпоинтов. Мы проверяем DNS-кэширование, сжатие, HTTP/2, persistent connections. Готовим подробный отчёт с найденными проблемами и рекомендациями, помогаем с их исправлением (кэширование, объединение запросов, настройка сессии). После внедрения проводим итоговое повторное профилирование для подтверждения улучшений.
Сроки
Профилирование сети и подготовка отчёта — 1–2 дня. Исправление выявленных проблем — 2–5 дней. Стоимость рассчитывается индивидуально в зависимости от сложности проекта. Получите консультацию — мы расскажем, сколько времени займёт оптимизация именно вашего приложения.
Проверьте настройки HTTP/2, сжатие ответов и DNS-кэширование — эти простые шаги могут ускорить приложение в разы. Закажите профилирование сети и убедитесь, что ваше приложение работает максимально быстро. Гарантируем результат: после оптимизации время загрузки данных сократится минимум на 30%.