История одного фриза Был в практике интересный баг. В некоторых регионах игроки жаловались на сильные тормоза. Иногда игра зависала намертво. При этом на тестах баг поймать не удавалось - вообще никак. На оптимизацию в проекте тратилось много времени. И работа с ресурсами и проверка настроек контента. И отключение анимации и внутренностей объектов, если их никто не видит. Через время баг поймали PM и UI-художница. Это сделало ситуацию страннее. Если включить VPN или играть с условно стабильным интернетом, проблема у игроков пропадала. В дев билдах баг не воспроизводился, а вот в магазином билде у того же пользователя всё было плохо. А на другой день без переустановки всё хорошо.🫠 Раз есть явная зависимость от интернета - логично смотреть сетевые запросы. После небольшого расследования нашёлся виновник. Это оказался сервис Microsoft для мультиплеерных игр - PlayFab. Что странно, дев и прод билды он не отличает. Почему всё было ок в тестовых билдах до сих пор загадка. При этом чтобы поймать баг, надо было снижать стабильность сети и увеличить потерю пакетов. Снизив качество интернета до условного "3G", баг не ловился. Дальше начали разбираться, почему запрос к нему фризит игру так, что с ней вообще нельзя взаимодействовать. Оказалось, что запрос выполнялся в том же потоке, что и UI. Пока запрос не отрабатывал, интерфейс «замирал». Это уже оказался архитектурный косяк. Фризы и тормоза - это далеко не всегда про нехватку оперативки или слабое железо на устройстве. Часто проблема кроется в процессах, которые происходят «за кадром» и напрямую игроку не видны: сетевые запросы, инициализация сервисов, блокировки потоков. Многопоточность в целом частая проблема на мобильных устройствах. Если что-то идёт не в том потоке, или один поток блокирует другой, можно встретить много проблем. Эффект для игрока будет выглядеть как фриз. Поэтому при расследовании подобных багов важно смотреть не только на железо и ресурсы, но и на то, что и где выполняется в момент зависания.🦄