Как выявлять SDK, вызывающие ANR или другие проблемы?

Question

Чтобы выявить проблемный SDK, нужно опираться на данные из продакшена: отчёты ANR, крашей и логи. Обычно сравнивают версии приложения и смотрят, что изменилось. Затем делают тестовые билды, отключая SDK по одному. Дополнительно используют профилирование и трассировку главного потока. Цель — получить воспроизводимый сценарий и доказательство, что проблема связана именно с этим SDK.

YeaHub · Accepted Answer

На практике ANR из-за SDK — это почти всегда комбинация факторов: слабые устройства, холодный старт, нестабильная сеть, инициализация в main thread и неудачные тайминги. Поэтому лучший подход — идти от фактов (прод-метрики) к гипотезам (какой SDK виноват) и затем к экспериментам (изолировать влияние).ОпределениеПроблемный SDK — это сторонняя библиотека, которая заметно ухудшает стабильность или производительность приложения (например, вызывает ANR, краши, утечки памяти, рост времени старта или фризы).1) Сбор сигналов из продакшенаСначала нужно понять, что именно происходит и насколько массово:ANR-отчётыПосмотри, в каких версиях приложения ANR вырос.Определи топ-девайсы и версии Android, где проблема встречается чаще.Crash-отчётыИногда SDK “не успевает” и падает, а иногда “подвисает” и даёт ANR.Важно смотреть частоту, а не единичные случаи.Метрики стартаЕсли ANR чаще на cold start, это сильный намёк на тяжёлую инициализацию SDK.Что важно фиксировать в заметках по инциденту:Версия приложения, где рост началсяПроцент сессий с ANRУстройства/ОС, где пикВремя и сценарий (старт, вход в бой, открытие магазина)2) Чтение стека ANR и поиск “подписей” SDKДальше полезно научиться распознавать следы SDK в стеке:Смотри main thread stack traceИщи вызовы с пакетами сторонних библиотек.Часто это будет com.*, io.*, net.* (Android/Java части SDK), а не C#.Типичные паттерны, которые ведут к ANRСинхронный I/O (диск/сеть) в main threadДолгая инициализация при старте (инициализация рекламы/аналитики)Блокировка на lock / ожидание результата (wait/join)Если в стеке видно “чужие” пакеты, это уже хорошая зацепка. Если не видно — проблема всё равно может быть в SDK, который нагружает main thread косвенно (например, частыми callbacks).3) Корреляция с изменениями: “что поменялось”После сигналов нужно найти, какие изменения могли привезти регрессию:Changelog SDKОбновили версию SDK?Добавили новый модуль (например, новые форматы рекламы)?Порядок инициализацииПереместили вызов в Awake() вместо поздней инициализации?Начали инициализировать всё сразу на старте?КонфигурацияИзменили remote-config/feature flag?Включили более тяжёлый режим (например, сбор расширенной телеметрии)?Цель: построить гипотезу вида “после обновления SDK X инициализация стала занимать 2–5 секунд на слабых девайсах, из-за чего main thread не отвечает”.4) Эксперименты: изоляция влияния SDKСамый надёжный способ доказать виновника — экспериментально:4.1) Быстрый метод: отключение по флагуЕсли SDK позволяет “выключить” функциональность:Выключи его через конфигурациюВыпусти hotfix/канареечный релиз на небольшой процентСравни ANR rate и время стартаВажно: выключать нужно именно код, который запускается, а не только “отправку событий”.4.2) Метод “бинарного поиска” по сборкамКогда SDK много и неясно кто виноват:Сделай тестовый билд, где отключена половина SDKЕсли проблема исчезла — виновник в отключенной половинеПовторяй, пока не останется 1–2 кандидатаЭто экономит время по сравнению с “отключать по одному”, если библиотек много.4.3) A/B билды с точечной заменойДля финального доказательства:Билд A: текущий SDK (подозреваемый включён)Билд B: SDK отключён или заменён на заглушкуОдин и тот же сценарий, одни и те же девайсы5) Профилирование: как поймать зависаниеANR трудно отлаживать “в моменте”, поэтому важно создавать условия:5.1) Нагрузка + слабое устройствоИспользуй слабый девайс или лимит CPU (если есть возможность)Включи плохую сеть (эмуляция/режим разработчика, где возможно)Тестируй cold start, переходы между сценами, открытие тяжёлых окон5.2) Тайминги и трассировка “длинных операций”Полезно добавлять “маркерные” логи вокруг инициализаций SDK:var sw = System.Diagnostics.Stopwatch.StartNew();
Debug.Log("[SDK_INIT] Start AdsSDK");

AdsSdk.Init();

Debug.Log($"[SDK_INIT] End AdsSDK {sw.ElapsedMilliseconds}ms");
Рекомендации:Логи должны быть короткими и с уникальным префиксом, чтобы легко фильтроватьНа проде лучше отправлять такие тайминги как метрики, а не спамить логами6) Частые причины, почему “SDK виноват”, даже если его нет в стекеИногда в стеке ANR нет прямого упоминания SDK, но оно всё равно причина:SDK провоцирует частые GC/аллокацииSDK подписывается на callbacks и делает тяжёлую работу в обработчикахSDK создаёт фоновые потоки, которые потом блокируют main thread через ожидание результатаSDK конфликтует с другим SDK (например, оба лезут в один и тот же ресурс)В таких случаях помогает только сравнение билдов и измерение метрик.7) Что считать “доказательством” виновности SDKЧтобы решение было уверенным, обычно достаточно 2–3 независимых подтверждений:ANR/фризы коррелируют с обновлением или включением SDKВремя старта или main thread time ухудшилось после измененияОтключение/замена SDK в тестовом билде снижает ANRКраткий выводВыявление “виновного” SDK строится на трёх шагах: прод-данные → гипотеза по изменениям → экспериментальная изоляция (отключение/AB/бинарный поиск). Чем быстрее ты получаешь воспроизводимость и сравнение билдов, тем быстрее находишь реальную причину ANR.