Тестування сумісності мобільного додатку на різних пристроях
Дизайнер намалював макет під iPhone 14 Pro з екраном 6.1" і Dynamic Island. Розробник перевіряв на тому ж пристрої. Реліз вийшов — і з'ясувалося: на Samsung Galaxy A03 з екраном 720×1600 кнопка «Підтвердити» виходить за межі, тому що верстка зав'язана на safe area, якої на старих Samsung немає. На iPad Mini нижня навігація займає третину екрана — планшет ніхто не тестував. У нашій практиці такі історії — норма. Ми допомагаємо виявити проблеми до релізу: складаємо матрицю пристроїв, тестуємо на емуляторах, хмарних фермах та фізичних зразках, формуємо звіт з рекомендаціями. Зв'яжіться з нами для попередньої оцінки вашого проекту.
Пристрої надто різні. Єдиного рішення немає — є методичне тестування. Ми проводимо його, використовуючи комбінацію емуляторів, хмарних ферм (BrowserStack, Firebase Test Lab) та фізичних пристроїв. Це дозволяє заощадити час і гроші, запобігши дорогим багам в продакшні.
Чому пристрої відрізняються і як це впливає на додаток?
Чим відрізняються пристрої — не лише розміром екрана. Ось що реально впливає на поведінку додатка.
Роздільна здатність і щільність пікселів
ldpi (120 dpi), mdpi (160), hdpi (240), xhdpi (320), xxhdpi (480), xxxhdpi (640). Іконки без адаптованих варіантів під щільність виглядають розмитими або величезними. На Redmi з 720p і Samsung з 1080p при однаковій фізичній діагоналі — різна щільність, різні dp→px перерахунки.
Співвідношення сторін
Стандарт 16:9 (720×1280) застарів. Актуальні: 20:9 (Samsung S-серія), 19.5:9 (iPhone), 21:9 (Sony Xperia), складні пристрої зі змінним співвідношенням. Верстка, яка хардкодить висоту елементів, ламається на нестандартних пропорціях.
Safe Area і вирізи
Dynamic Island (iPhone 14 Pro+), notch-hole (Samsung), punch-hole camera (більшість сучасних Android). На Android — WindowInsets і displayCutout. Без обробки вирізів контент ховається під камеру. Apple рекомендує дотримуватися safe area insets Apple Human Interface Guidelines.
Продуктивність заліза
Qualcomm Snapdragon 8 Gen 3 у флагмані vs MediaTek Helio G85 у бюджетнику — різні рівні. Анімації на 120 fps, плавні на флагмані, смикаються на mid-range. Складні Compose-лейаути з множинними recompositions це відчують.
Апаратні можливості
Немає NFC, барометра, LiDAR, Face ID. Без перевірки PackageManager.hasSystemFeature() спроба використати відсутнє залізо — крэш або silent fail.
Як ми проводимо тестування сумісності?
Ми починаємо з аналізу цільової аудиторії та статистики пристроїв, потім складаємо матрицю тестування. Після цього запускаємо перевірки на емуляторах, хмарних фермах та фізичних зразках. У результаті ви отримуєте звіт з матрицею несумісностей, скріншотами та рекомендаціями. Замовте тестування сьогодні — ми підготуємо детальний план перевірок.
Матриця пристроїв
Складаємо на основі аналітики (Firebase, Mixpanel по device_model), загальної статистики ринку та бізнес-вимог:
| Категорія | Приклади | Чому включаємо |
|---|---|---|
| Флагман iOS | iPhone 15 Pro, iPhone 14 | Цільова аудиторія, Dynamic Island |
| Компактний iOS | iPhone SE 3rd gen | Маленький екран, немає notch |
| Планшет iOS | iPad (10th gen), iPad Pro | Широкий екран, Split View |
| Флагман Android | Google Pixel 8, Samsung S24 | Актуальний Android, OLED |
| Mid-range Android | Samsung A54, Xiaomi Redmi Note 12 | Найбільша частка ринку |
| Бюджетний Android | Samsung A03, Redmi 10 | Низька продуктивність, 720p |
| Планшет Android | Samsung Galaxy Tab S9 | Адаптивний layout |
| Складний | Samsung Z Fold 5 | Якщо підтримується форм-фактор |
Мінімальна матриця для більшості проектів: 5–7 пристроїв. Більше — через BrowserStack або Firebase Test Lab (реальні пристрої без покупки). Тестування на хмарній фермі в 5 разів швидше, ніж покупка та обслуговування власного парку.
Порівняння середовищ тестування
| Середовище | Переваги | Недоліки |
|---|---|---|
| Емулятори (Android Emulator, iOS Simulator) | Швидкий запуск, безліч конфігурацій | Не емулюють апаратні функції (NFC, датчики), неточно відображають продуктивність |
| Хмарні ферми (BrowserStack, Firebase Test Lab) | Реальні пристрої без покупки, паралельні прогони | Обмежена робота з нестандартними жестами, затримки мережі |
| Фізичні пристрої | Точне відтворення, всі залізні функції | Дорого, довго обслуговувати парк |
Що входить в роботу?
- Аналіз цільової аудиторії та статистики пристроїв
- Складання матриці пристроїв (5–7+ моделей)
- Тестування на емуляторах (Android Emulator, iOS Simulator)
- Тестування на хмарній фермі (BrowserStack, Firebase Test Lab)
- Ручне тестування на фізичних пристроях (за потреби)
- Звіт з матрицею несумісностей, скріншотами та рекомендаціями
- Консультація з виправлення знайдених проблем
Як тестувати адаптивний layout?
На Android — WindowSizeClass з Jetpack Compose:
val windowSizeClass = calculateWindowSizeClass(this) when (windowSizeClass.widthSizeClass) { WindowWidthSizeClass.Compact -> PhoneLayout() // < 600dp WindowWidthSizeClass.Medium -> TabletLayout() // 600–840dp WindowWidthSizeClass.Expanded -> DesktopLayout() // > 840dp } Тестуємо всі три класи: Compact (телефон portrait), Medium (планшет portrait або телефон landscape), Expanded (планшет landscape).
На iOS — horizontalSizeClass у SwiftUI:
@Environment(\.horizontalSizeClass) var sizeClass var body: some View { if sizeClass == .compact { VStack { ... } } else { HStack { ... } // iPad, landscape iPhone Plus } } Специфіка складних пристроїв
Samsung Galaxy Z Fold — два режими: складений (compact, 22:9) і розкритий (великий екран, ~4:3). Додаток має коректно переходити між режимами без втрати стану. onConfigurationChanged викликається при розкритті/складанні. Якщо Activity перестворюється — всі незбережені дані у формі губляться. Перевіряємо: фокус у TextField зберігається, скрол-позиція відновлюється, модальні вікна не «стрибають».
Перевірка апаратних можливостей
// Android: перевіряємо перед використанням val hasBluetooth = packageManager.hasSystemFeature(PackageManager.FEATURE_BLUETOOTH) val hasNfc = packageManager.hasSystemFeature(PackageManager.FEATURE_NFC) val hasCamera = packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA_ANY) Якщо функція недоступна — приховуємо UI-елемент або показуємо пояснення. Не крэшимося, не показуємо недоступну кнопку.
Досвід і гарантії
Наша команда — сертифіковані інженери з досвідом мобільної розробки 7+ років. Ми протестували понад 50 проєктів різної складності — від стартапів до enterprise-рішень. Гарантуємо якість тестування: ви отримаєте вичерпний звіт з реальними проблемами та конкретними шляхами їх виправлення.
Терміни
2–3 дні — складання матриці пристроїв за аналітикою, тестування на пріоритетних пристроях (емулятори + хмарна ферма), звіт з матрицею несумісностей та скріншотами. Для проєктів з розширеним покриттям (складні, планшети, специфічні регіони) термін збільшується до 5–7 днів. Вартість розраховується індивідуально — отримайте консультацію для оцінки вашого проєкту.