Тест на реальных девайсах: как собрать матрицу устройств и почему твой телефон врёт

У меня был проект, где всё летало на моём Pixel и на паре топовых айфонов — а в отзывах сыпалось «вылетает на старте», «чёрный экран», «тормозит». Разгадка простая: я тестировал на трёх флагманах, а игру ставили на трёхлетний бюджетник с 3 ГБ памяти и Android 10. Реальные баги живут не на твоём девайсе.

Мобильное тестирование ломается не на логике, а на ЖЕЛЕЗЕ и его разнообразии. Разберём, какую матрицу устройств брать и почему.

Почему один-два девайса врут

Android — это тысячи моделей, десяток версий ОС, разные чипы, объёмы памяти, плотности экрана, вырезы, оболочки поверх (Samsung One UI, Xiaomi MIUI/HyperOS и т.д.), свои политики энергосбережения. iOS однороднее, но и там разрыв между новым Pro и стареньким SE по памяти и теплу — это разные миры. Твой рабочий телефон — почти всегда лучше медианного устройства аудитории, поэтому на нём не воспроизводится то, на чём падает у людей.

Как собрать матрицу устройств

Не «побольше девайсов», а осознанный срез по осям риска. Бери реальную аналитику своей аудитории (Google Play Console → Statistics, App Store Connect, Firebase) и покрывай:

ОС-версии — самая старая, что вы поддерживаете (minSdk / min iOS), + самая свежая (там ломают новые ограничения приватности/фона), + одна-две популярные из середины.
Класс железа — обязательно low-end (мало RAM, слабый GPU — тут вылезают OOM, лаги, долгий старт), середняк и флагман.
Вендоры/оболочки — Samsung и Xiaomi почти всегда отдельно (агрессивный киллинг фоновых процессов, свои разрешения, нотификации); плюс «чистый» Android (Pixel).
Экраны — узкий/широкий аспект, вырез/дырка/динамический остров, складные, планшет; проверь, что UI и safe-area не разъезжаются.
Локаль/регион — другой язык (длина строк), RTL, региональные форматы, часовой пояс.

Практичное правило: ~5–8 реальных устройств, закрывающих крайние точки этих осей, дают больше, чем 20 похожих флагманов. Обязательно держи в наборе минимум один честный low-end — он ловит больше всего.

Реальные девайсы vs эмуляторы vs облако

Эмулятор/симулятор — быстро для разработки и UI-проверок, но врёт про производительность, тепло, батарею, камеру, сенсоры, GPU-специфику и реальную сеть. Смоук и функционалку — можно; финальную приёмку — нет.

Реальное железо у тебя на столе — эталон для ключевых устройств и для того, что эмулятор не покажет (термалка, жесты оболочки, реальные прерывания). Минус — не купишь весь зоопарк.

Облачные фермы (Firebase Test Lab, BrowserStack, AWS Device Farm) — доступ к сотням реальных моделей без закупки; удобно гонять автотесты и матрицу перед релизом. Минус — латентность, нет «пощупать», лимиты по времени. Рабочая связка: ключевые девайсы вживую + облако для широты матрицы в CI.

Что тестировать именно на разном железе (а не на одном)

Холодный старт и OOM на low-end — время загрузки, вылеты по памяти, чёрный экран.
Производительность — FPS/фризы, троттлинг при нагреве на слабом чипе.
Оболочки вендоров — фоновый киллинг (Xiaomi/Samsung убивают процесс → теряется сессия/пуш), свои диалоги разрешений.
Экран — вырезы, safe-area, складные, изменение размера окна, поворот.
Прерывания и сеть — звонок, сворачивание, плохая/переключающаяся сеть — по-разному на разных ОС.
Апдейт поверх старой версии (не чистая установка) — миграция сейвов на реальном устройстве пользователя.

Коротко — что забрать с собой

Твой телефон — не аудитория. Реальные баги на медианном и слабом устройстве.
Матрица = осознанный срез по осям (ОС, класс железа, вендор/оболочка, экран, локаль) из СВОЕЙ аналитики, а не «побольше».
5–8 крайних точек > 20 похожих флагманов. Хотя бы один честный low-end обязателен.
Эмулятор — для скорости, реальное железо — для приёмки, облако — для широты в CI.
Термалку, батарею, вендор-киллинг, safe-area и апдейт-поверх на эмуляторе не поймать — только вживую/в облаке.

Почитать: Firebase Test Lab (облачная ферма устройств) · Android — Gradle Managed Devices · Android — оптимизация игр