Матрица начинается с аудитории
Первый вопрос — не какие телефоны есть у QA, а на каких устройствах действительно будут играть пользователи.
Если проект ориентирован на массовую мобильную аудиторию, проверка только на современных флагманах даст слишком оптимистичную картину. Нижняя граница поддерживаемых устройств обычно намного важнее: именно там раньше проявляются проблемы с памятью, GPU и временем загрузки.
Поэтому при разработке игр для Android полезно заранее определить минимальную конфигурацию и несколько уровней устройств выше неё.
Не выбирайте телефоны только по бренду
Два смартфона с похожей ценой могут сильно отличаться по chipset, GPU, объёму RAM и версии Android.
Поэтому device matrix лучше строить вокруг комбинаций характеристик: слабое и среднее железо, разные GPU, несколько актуальных версий ОС и популярные разрешения экрана.
Отдельно стоит учитывать производителей, если аудитория проекта сильно зависит от конкретных рынков. Разные оболочки Android могут влиять на permissions, background processes, уведомления и системные сценарии.
Слабое устройство показывает проблемы раньше
Флагман способен скрыть неэффективный rendering, тяжёлый UI и слишком большой расход памяти.
На минимальном устройстве те же решения быстро превращаются в stutters или crash.
Поэтому бюджет производительности мобильной игры нужно проверять не на самом удобном телефоне разработчика, а на заранее выбранной нижней границе.
То же относится к памяти. Если приложение приближается к пределу RAM уже на средних устройствах, после добавления нового контента проблема только усилится. Здесь полезно отдельно контролировать memory budget мобильной игры.
Не нужно проходить всю игру на каждом телефоне
Device matrix не означает, что полный regression нужно вручную повторять на двадцати устройствах.
Основные функциональные сценарии можно проверять на ограниченном наборе, а остальные устройства использовать для зон риска: производительности, запуска, UI, загрузок, background/foreground, permissions и системных интеграций.
Так QA игры остаётся управляемым, а команда всё равно получает достаточно широкое покрытие Android-экосистемы.
Матрица должна меняться вместе с продуктом
Набор устройств, который был правильным в начале разработки, через год может устареть.
Меняется аудитория, появляются новые версии Android, а после оптимизации команда может решить снизить минимальные требования или, наоборот, отказаться от слишком слабых моделей.
Поэтому device matrix лучше регулярно пересматривать по реальной аналитике пользователей и crash reports.
Главная цель здесь не в максимальном количестве телефонов. Хорошая матрица должна покрывать разные типы рисков, а не просто длинный список моделей.
Если Android-версия уже выходит на широкий рынок, но непонятно, какие устройства действительно нужны для QA — соберите данные по минимальным требованиям, целевым регионам и текущей аудитории. На их основе можно сформировать компактную device matrix, которая даст намного больше пользы, чем случайный набор смартфонов.