Как смоделировать медленный интернет на Android: 5 способов (2026)

Почему Фора Софт написала этот плейбук

Мы в Фора Софт разрабатываем Android-приложения с 2005 года, и основной темой более чем 625 выпущенных продуктов остаётся медиа: видео в реальном времени, голос, потоки с камер видеонаблюдения, телемедицинские консультации, виртуальные судебные заседания. Все они первыми страдают при плохом интернете. Поэтому эмуляция медленного соединения — не просто пункт в нашем QA-процессе, а обязательный профиль по умолчанию. Наши Android-сборки должны пройти его, прежде чем попасть в основную ветку.

Этот гайд — краткая версия инструкции, которую мы даём каждому новому Android-инженеру. В основе — проекты вроде Valt (платформа удалённых допросов для правоохранительных органов США), CirrusMED (телемедицина с видеоконсультациями) и BrainCert (живые e-learning классы для студентов с нестабильной мобильной связью). На этих проектах плохая сеть — не редкое исключение, а повседневная реальность.

Если ваше Android-приложение делает что-то сложнее, чем загрузка JSON — например, видео, чат в реальном времени, загрузку файлов, платежи или фоновую синхронизацию — пять методов ниже должны быть встроены как в ваш цикл разработки, так и в CI. Дальше — о том, как это делаем мы.

Что на самом деле означает «медленный» Android в 2026 году

«Медленный» — это три параметра, а не один: пропускная способность (кбит/с в обе стороны), задержка (RTT в мс плюс джиттер) и потери пакетов (%). Любой инструмент, который позволяет менять только пропускную способность, скрывает от вас самые интересные проблемы. В таблице ниже — краткий список профилей, на которых мы тестируем каждую сборку под Android. Они соответствуют данным Ookla за 2026 год из Global Mobile Speed Index для «хвостовых» рынков и тому, что мы наблюдаем на реальных устройствах в сельской местности.

Два неочевидных профиля — это «EDGE дно» и «Wi-Fi с потерями». EDGE по-прежнему остаётся актуальным для пользователей на развивающихся рынках и в подземном транспорте. Wi-Fi с потерями — это ситуации вроде переговорной комнаты или кофейни: высокая пропускная способность, но сильный джиттер и обрывистые потери пакетов. Именно такой сценарий чаще всего становится причиной жалоб: «у меня за столом всё работает, а в переговорке видеозвонок отваливается».

Пять методов, которые реально сдвигают стрелку

За годы мы перепробовали десятки подходов. Выжили пять. Каждый работает на своём уровне стека — поэтому в итоге приходится использовать как минимум два параллельно.

Метод 1 — Android-эмулятор: netspeed и netdelay

Это самый быстрый способ посмотреть, как приложение работает на сетях 2G или 3G. При этом это и самый недопонятый инструмент в списке — названия предустановок часто обещают больше, чем реально дают.

Командная строка

Запустите эмулятор с предустановленной системой и задержкой:

emulator -avd Pixel_8_API_34 -netspeed edge -netdelay umts
# netspeed options: gsm hscsd gprs edge umts hsdpa lte evdo full
# netdelay options: gprs edge umts none (or a number in ms)

Менять профиль на лету

Подключитесь к консоли AVD и меняйте профиль на ходу — именно так мы тестируем переходы между радиосетями в видеоприложениях:

adb emu network speed edge
adb emu network delay 500
adb emu network speed full   # back to line rate

Шпаргалка по предустановкам (приблизительные значения up / down)

gsm 14,4 кбит/с симметрично. hscsd 14,4 / 57,6 кбит/с. gprs 28,8 / 57,6 кбит/с. edge 473 кбит/с симметрично. umts 384 кбит/с симметрично. hsdpa 5,76 / 13,98 Мбит/с. lte 58 / 173 Мбит/с. full без ограничений.

Чего он не делает

Throttling эмулятора — без потерь и без джиттера. Он не покажет шторм повторных отправок в WebRTC, потоп TCP-ретрансмитов или баги retry-бюджета. Он также с удовольствием пропустит приложение, которое «прошло» на профиле edge, но падает на реальной EDGE с потерями 3%. Относитесь к нему как к инструменту разработчика, а не как к QA-шлюзу.

Метод 2 — tc и netem: настоящая сетевая лаборатория

Если вы хотите нагрузить реальное Android-устройство, подключите его через Linux-машину (или Raspberry Pi в режиме Wi-Fi-точки) и ограничьте исходящий трафик с помощью tc. NetEm позволяет задавать задержку, джиттер, лимит пропускной способности, потери пакетов (равномерные или импульсные), дублирование, искажение и переупорядочивание — полный набор инструментов для имитации сетевых проблем.

Профиль «плохой 3G»

# on the router / hotspot, shape wlan0
sudo tc qdisc add dev wlan0 root handle 1: htb default 10
sudo tc class add dev wlan0 parent 1: classid 1:10 htb rate 780kbit ceil 780kbit
sudo tc qdisc add dev wlan0 parent 1:10 handle 10: \
  netem delay 300ms 100ms distribution normal loss 2% 25%

Профиль «хороший LTE»

sudo tc qdisc replace dev wlan0 root netem delay 50ms 10ms rate 25mbit

Профиль «Wi-Fi с потерями» (всплесковый)

sudo tc qdisc replace dev wlan0 root netem \
  delay 40ms 120ms distribution paretonormal loss 8% 30% reorder 25% 50%
# clean up
sudo tc qdisc del dev wlan0 root

Как превратить это в стадию CI

Заверните каждый tc-профиль в shell-скрипт, запустите набор тестов Espresso или Appium, а затем проанализируйте конфигурацию. В большинстве Android-репозиториев у нас есть папка network-profiles/ с файлами edge.sh, poor-3g.sh, lossy-wifi.sh и reset.sh. GitHub Actions с привилегированными контейнерами обрабатывают это аккуратно; собственный раннер на Hetzner AX становится выгоднее GitHub примерно после 100 минут работы в день.

Метод 3 — Charles Proxy и Proxyman: ограничение скорости на уровне HTTP

Для REST, GraphQL и любого HTTPS-трафика перехватывающий прокси позволяет ограничивать скорость по хосту, изменять запросы и управлять задержками — без прав суперпользователя. Укажите в настройках Wi-Fi на Android адрес прокси-сервера на ноутбуке, установите корневой сертификат Charles или Proxyman через исключение в Network Security Config — и вы сможете перехватывать трафик.

Встроенные предустановки throttle

56k Modem 56 кбит/с. ISDN/DSL 512 кбит/с. ADSL 2 Мбит/с. ADSL2+ 16 Мбит/с. Fibre 32–100 Мбит/с. 3G HSPA 1,6 Мбит/с вниз / 768 кбит/с вверх, задержка 150 мс, потери 2%. 4G настраивается. Эти значения — по умолчанию в Charles 5.x 2026 года и в Proxyman Network Conditioner.

Выборочный throttling по хосту

Ограничьте только api.yourcompany.com, оставив аналитику и отчёты о сбоях работать на полной скорости. Так вы поймёте, какой именно экран тормозит из-за медленного API.

Метод 4 — удалённые Chrome DevTools для WebView и PWA

Если ваше Android-приложение использует WebView, Trusted Web Activity, PWA или Chrome Custom Tabs, chrome://inspect в десктопной версии Chrome даёт полную панель Network в DevTools для контента на устройстве. Предустановленные профили: Slow 3G — около 500 кбит/с вниз, 500 кбит/с вверх, задержка 2000 мс. Fast 3G — 1,5 Мбит/с вниз, 750 кбит/с вверх, задержка 562 мс. Slow 4G и Fast 4G появились в Chrome 115+. Кастомные профили позволяют задать точные значения скорости и задержки.

DevTools throttling работает на стороне клиента, внутри рендерера. Он не влияет на нативный трафик OkHttp или Retrofit. Для гибридных приложений сочетайте его с Методом 3 (Charles на нативной стороне), чтобы увидеть полную картину.

Метод 5 — фермы устройств с сетевыми профилями

Ничего из того, что вы запускаете на ноутбуке, не поймает баги, возникающие в реальных радиомодулях на двухстах разных телефонах. Это делают фермы устройств. Три из них, на которые стоит обратить внимание для Android в 2026 году:

Три бонусных инструмента «про запас»

1. Toxiproxy. TCP-прокси от Shopify, который принимает «токсики»: задержку, ограничение полосы пропускания, таймауты, slow_close, slicer. Запускается в контейнере рядом с вашим API в CI. Если бэкенд у вас, Toxiproxy позволяет искусственно создавать сбои выше по стеку, а не изменять клиентскую сеть.

2. Clumsy (Windows). Альтернатива tc/netem, когда лабораторные машины работают под Windows. Под капотом использует WinDivert. Поддерживает задержки, потерю пакетов, ограничение скорости, перестановку и искажение пакетов.

3. Network Link Conditioner (macOS). Системный шейпер от Apple (входит в Xcode Additional Tools). Полезен, если ваш Mac используется как Wi-Fi-мост для Android-устройства: установите в NLC режим «3G» или «Edge» — и Android в этой сети автоматически получит такие же сетевые условия.

Набор ADB: скриптование режима «в самолёте» и Wi-Fi

Сам ADB не поддерживает throttling, но это правильный инструмент для второго класса багов, связанных со скоростью сети — переходов между состояниями связности.

# toggle airplane mode (requires Android < 13 or system app on 13+)
adb shell settings put global airplane_mode_on 1
adb shell cmd connectivity airplane-mode enable   # API 30+

# only cellular in airplane mode, keep Wi-Fi and Bluetooth
adb shell settings put global airplane_mode_radios cell

# toggle Wi-Fi
adb shell svc wifi disable
adb shell svc wifi enable

# drop cellular data
adb shell svc data disable

Заверните это в @Rule в Espresso, чтобы проверять поведение при переходах. WorkManager-задача с повтором, которая молча теряет работу, когда Wi-Fi пропадает посреди загрузки, — самый частый баг, когда «у разработчика на столе всё работает, а в проде падает», который мы исправляем.

WebRTC, HLS и видео в «больной» сети

Большинство интересных багов, которые мы исправляем в Фора Софт, возникают в медийных пайплайнах. Три эмпирических правила, которые экономят недели отладки:

1. Тестируйте WebRTC на 300, 150 и 80 кбит/с. По умолчанию в libwebrtc начальная оценка битрейта — 300 кбит/с; пробинг поднимает её до 900 и 1800. На 150 кбит/с система переходит в режим выживания — отбрасываются слои simulcast, VP9 переключается на более низкое пространственное разрешение. На 80 кбит/с остаётся только аудио. Убедитесь, что интерфейс корректно отображает эти изменения, а не показывает застывшее видео.

2. Лестницы HLS должны начинаться с 480p / 800 кбит/с. Если первая ступенька будет выше — пользователи с EDGE будут ждать 10+ секунд, пока плеер не перейдёт на более низкое качество. Делайте сегменты по 2–6 секунд, поддерживайте буфер 30–60 секунд в стабильном режиме и быстро переключайтесь на более низкое качество, если буфер упадёт ниже 4 секунд.

3. Эмулируйте потери пакетов, а не только полосу. Видеокодеки хорошо справляются с низкой пропускной способностью, но плохо переносят потери пакетов. Даже 5% случайных потерь могут серьёзно повлиять на качество. Если ваше приложение работает с живым видео, используйте Метод 2 (tc/netem). Наш гид по оптимизации Android-стриминга подробно разбирает паттерны устойчивости к потерям, применяемые в продакшене.

Сначала offline-first, потом throttle-тесты

Эмуляция медленных сетей лишь показывает, где приложение ломается. Исправлять нужно структурно. Три паттерна, которые мы используем в каждом Android-проекте, где сеть ненадёжна:

1. Room + StateFlow как источник истины. UI читает данные из Room, а синхронизирующий слой пишет в Room. Сеть может пропадать и появляться — UI остаётся стабильным. Room 3.0 (2026) перешёл на androidx.sqlite и стал ориентирован на корутины, что позволило избавиться от большей части лишнего кода, который раньше приходилось писать вручную.

2. WorkManager с экспоненциальным откатом и ограничениями. Используйте BackoffPolicy.EXPONENTIAL (30 с → 60 с → 120 с), привязывайте задачу к NetworkType.CONNECTED и учитывайте заголовки Retry-After — возвращайте Result.retry() только после паузы, указанной сервером.

3. Кэш OkHttp + Cache-Control как запасной вариант. Дисковый кэш объёмом 10 МБ с only-if-cached при повторной попытке в офлайне превращает режим «в самолёте» из «пустого экрана» в «последнее известное состояние». Одно это изменение обычно выводит приложение из категории «не работает без интернета» в отзывах пользователей.

Мини-кейс — снижение числа сбоев на 40% в Android-приложении телемедицины

Ситуация. Американская телемедицинская платформа (по объёму близкая к нашему проекту CirrusMED) запускала видеоконсультации на Android с использованием WebRTC. Пациенты в сельской местности, подключённые по 3G, жаловались на чёрный экран во время звонков и зависания приложения. Crashlytics фиксировал ANR на уровне 1,2% и показывал показатель crash-free sessions — 97,1%, что было заметно ниже порога Play Vitals.

План на 12 недель. Мы запустили CI-стадию tc/netem с тремя профилями (EDGE «дно», плохой 3G, Wi-Fi с потерями), которая прогоняет регрессионный набор тестов Appium. Отдельные тесты мы провели, ограничив пропускную способность сигнального хоста WebRTC через Charles — так мы воспроизвели баг с чёрным экраном прямо за рабочим столом. В список исправлений вошли: отключение simulcast при скорости ниже 200 кбит/с, добавление предварительного измерения пропускной способности перед звонком, загрузка сплэша WebView из кэша OkHttp и более агрессивный экспоненциальный откат в WorkManager (15/30/60 с) для очереди консультаций.

Итог. Доля сессий без сбоев выросла с 97,1% до 99,6%. Количество зависаний (ANR) снизилось с 1,2% до 0,18% — теперь приложение соответствует требованиям Play Vitals. Время загрузки первого кадра в звонках уменьшилось с 6,4 до 2,1 секунды на слабом 3G-соединении. Хотите такую же оценку для своего приложения? Мы можем провести аудит за один спринт — подойдёт для большинства Android-приложений.

Модель затрат: сколько на самом деле стоит настройка тестов на медленной сети

Ниже — порядковые цифры, которые мы видим на проектах с двумя–четырьмя Android-инженерами и средним CI. Мы выстраиваем процессы через Agent Engineering — наши пайплайны проще, чем в среднем по отрасли, поэтому цифры находятся на нижней границе.

Фреймворк принятия решения — выберите стек за пять вопросов

1. Стримит ли ваше приложение аудио или видео? Если да, Метод 2 (tc/netem) — обязателен. Тестирование только полосы пропускания пропустит баги, связанные с потерями пакетов.

2. Целите ли вы в развивающиеся рынки или сельские регионы? Если да, профили «EDGE дно» и «плохой 3G» должны проверяться в CI при каждом PR, а не только перед релизом.

3. Какое у вас приложение — нативное, гибридное или PWA? Нативное — используем Метод 3 (Charles). Гибридное — комбинируем Метод 3 и Метод 4 (DevTools). PWA — применяем Метод 4 и Lighthouse.

4. Сколько OEM показывает ваша аналитика? До 10: эмулятор + одно реальное устройство — хватит. От 10 до 30: используйте Firebase Test Lab ночью. От 30 и выше: выбирайте BrowserStack или HeadSpin.

5. Какой тренд у вас в Play vitals? Если ANR выше 0,47% DAU или холодный старт длится дольше 5 секунд на устройствах p50 — у вас проблема с дистрибуцией, а не с отделкой. Сейчас важнее тестировать работу приложения на медленной сети, чем внедрять новые функции.

Пять ловушек, которые мы видим на каждом аудите

1. Тестирование только на Wi-Fi. У Wi-Fi высокая пропускная способность, но и джиттер у него тоже высокий. Это не альтернатива 4G, а уж тем более не замена EDGE. Каждый релиз должен пройти хотя бы один тестовый профиль, настроенный под сотовую сеть.

2. Throttling только на скачивание. На реальной мобильной сети загрузка обычно в 3–10 раз медленнее скачивания. Если приложение загружает фото, видео или большие пакеты данных, тестируйте асимметрию.

3. Игнорирование переходов «офлайн → онлайн». Большинство сбоев на Android в условиях плохой сети происходят не во время медленного соединения, а в момент, когда связь восстанавливается и приложение отправляет на сервер накопившуюся очередь запросов.

4. Фиксированная задержка без джиттера. В реальных сетях задержки колеблются. Фиксированная задержка в 300 мс скрывает ошибки в настройке таймаутов, которые при нормальной задержке 300 мс ± 100 мс проявляются уже с первого запуска.

5. Измерение средних, а не процентилей. Пользователь, который жалуется на приложение, живёт в p95, а не в среднем. Снимайте p50, p95 и p99 времени загрузки в throttle-тестах и ставьте релизные шлюзы по p95.

KPI: что измерять в throttle-прогоне

KPI качества. Время до первого кадра — менее 2,5 с на «плохом 3G» для видеоэкранов. Холодный старт — менее 5 с на «EDGE днём». Время от взаимодействия до ответа — менее 200 мс после отправки запроса.

Бизнес-метрики. Сессии без сбоев — не менее 99,5% по всем профилям. ANR — менее 0,47% DAU (порог Play Vitals). Доля успешно завершённых критических сценариев (регистрация, оплата, вход в звонок) — не менее 95% при слабом 3G.

KPI надёжности. Доля успешных повторов при временных ошибках — более 90%. Время обработки очереди WorkManager после возврата в сеть — менее 60 секунд. Потеря данных в циклах «в самолёте» (round-trip-тест Room) отсутствует.

Когда не стоит переинвестировать в тесты на медленной сети

Если ваше приложение — внутренний B2B-инструмент, которым пользуются только в офисной Wi-Fi-сети, или планшетный киоск с проводным подключением, тратить инженеро-недели на EDGE-оптимизацию — не тот приоритет. То же самое, если аналитика показывает менее 0,5% сессий со скоростью ниже 2 Мбит/с на скачивание, а Play Vitals у вас в порядке.

Планка не в том, чтобы «эмулировать всё подряд». Планка — покрыть профили, на которых реально используют ваше приложение пользователи, плюс один уровень ниже для запаса. Для потребительского Android-приложения в 2026 году это почти всегда «EDGE дно» + «плохой 3G» + «хороший LTE» — как минимум.

FAQ

Что почитать дальше

Готовы выпустить Android-приложение, которое стабильно работает в реальных сетях?

Берите два метода, а не один. Throttling в эмуляторе — для цикла разработки, tc/netem плюс ферма устройств — для CI и релизных шлюзов. Покрывайте «EDGE дно», «плохой 3G», «типичный мобильный» и «Wi-Fi с потерями». Измеряйте p95, а не среднее. Ограничивайте полосу и на загрузку тоже, добавляйте джиттер, добавляйте потери пакетов.

Затем интегрируйте фикс-лист в Room, WorkManager и OkHttp, чтобы приложение по умолчанию работало в оффлайне. Эта последовательность — эмулировать, измерить, исправить, повторить — и есть ключевое отличие между приложением, которое проходит проверку Play Vitals на устройствах P50, и тем, которое сохраняет четыре звезды на развивающихся и сельских рынках.