Тестування продуктивності: де мобільний застосунок втрачає користувачів
Застосунок стабільно проходить демо на тестовому стенді, але в користувача на середньому пристрої та в мобільній мережі екран відгукується із затримкою, стрічка підвисає під час прокручування, а на слабкому сигналі сесія відвалюється.
Це не «дрібні баги» — це вузькі місця мобільного застосунку, які проявляються лише під реальним навантаженням.
Тестування продуктивності як окрема дисципліна потрібне саме тому, що лабораторні умови не відтворюють ні різноманіття пристроїв, ні поведінку мережі, ні конкуренцію за ресурси з іншими застосунками на телефоні.
Ціна такої сліпої зони вимірювана: користувач іде, якщо інтерфейс не реагує довше за пару секунд, а частка відмов зростає разом із глибиною сценарію.
Падіння продуктивності застосунку рідко буває однією причиною — зазвичай складаються важкі запити на старті, зайві перемальовування екрана, витоки пам'яті при довгій сесії та відсутність кешу на повторних переходах.
Точкове виправлення одного місця зсуває проблему, але не прибирає її: вузьке місце переїжджає в сусідній сценарій.
Затримки відгуку інтерфейсу та зростання навантаження на мобільний застосунок проявляються каскадом. Поки користувач чекає на відповідь, він повторює дію — і застосунок отримує подвоєний потік запитів, який добиває й без того навантажену ділянку.
На слабкому каналі це перетворюється на таймаути та повторні надсилання, а на сервері — на піки, які не видно у спокійному профілі.
Саме тому тестування продуктивності мобільного застосунку починають не з правок коду, а з вимірювань: де саме втрачається час, за якого профілю пристрою та мережі, як поводиться пам'ять на довгій сесії.
Далі розбираємо, як це закривається — від профілювання реальних сценаріїв до порогів, за якими реліз проходить або не проходить.
Що дає тестування продуктивності та які режими перевірки бувають
Профілювання: де саме втрачається час
Профілювання мобільного застосунку розбирає кадр відмалювання по шарах: скільки часу йде на підготовку даних, введення-виведення, очікування мережі, роботу зі сховищем.
Інженер бачить не «застосунок гальмує», а конкретну ділянку — наприклад, синхронне читання з локальної бази в головному потоці під час побудови списку. Виправлення одного такого місця знімає просідання кадрів під час прокручування в рази, а не на відсотки.
Навантажувальне тестування: поведінка під піком
Навантажувальне тестування мобільних застосунків відтворює профіль реального трафіку: холодний старт, вхід, масові запити до одного екрана, обрив зв'язку на середині операції. Перевіряємо, що відбувається з чергою запитів і кешем, коли одночасно працюють тисячі пристроїв.
Результат — відома межа: за якої кількості одночасних сесій час відповіді залишається в нормі, а де починаються відмови.
Моніторинг у проді: метрики відгуку на живих пристроях
Моніторинг продуктивності в проді збирає метрики відгуку застосунку з реальних пристроїв: час до першого кадру, тривалість ключових операцій, частку зависань і аварійних завершень.
Лабораторний стенд не відтворює різноманіття моделей, версій системи та якості мережі — прод показує, у якої частки користувачів операція виходить за допустимий час. Це замикає цикл: знахідка з прода повертається в профілювання.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Разова перевірка | Перед великим релізом, при скаргах на швидкість | Не ловить регрес між релізами |
| Профілювання за запитом | Локалізація відомого просідання | Потребує відтворюваного сценарію |
| Навантажувальне тестування | Перед зростанням аудиторії, розпродажем, кампанією | Потрібен реалістичний профіль трафіку |
| Безперервний моніторинг | Постійна робота застосунку в проді | Потребує розмітки метрик у коді |
Android Profiler та аналогічні інструменти дають покадрову картину, але цінність з'являється, коли заміри регулярні та порівнювані між релізами. Тоді просідання відгуку видно до того, як його помітять користувачі, а не після сплеску відмов.
Як ми проводимо тестування продуктивності: етапи інженерної роботи
Тестування продуктивності починається не із запуску профілювальника, а з аудиту продуктивності застосунку: збираємо метрики запуску, відгуку інтерфейсу та споживання ресурсів на реальних пристроях і в емуляторах, фіксуємо базову лінію.
Без неї будь-який подальший замір — це цифри без точки порівняння, і суперечка «стало краще чи гірше» перетворюється на смаківщину.
Далі будуємо схему навантажувального тестування під профіль реальних користувачів: які сценарії домінують, де пікові сплески, як поводиться мережа за слабкого сигналу та перемикання між Wi-Fi і мобільним інтернетом.
- Аудит поточного стану. Проганяємо ключові користувацькі шляхи, знімаємо метрики холодного й теплого старту, відгуку списків, плавності прокручування, споживання пам'яті та заряду. Результат — карта проблемних місць із відтворюваними замірами.
- Побудова схеми навантаження. Визначаємо сценарії, інтенсивність і тривалість прогонів, набір пристроїв і версій системи. Схема має повторювати реальні умови, а не синтетичний максимум — інакше оптимізуємо те, чого користувач не робить.
- Налаштування профілювання. Розгортаємо збір метрик на стенді та на пристроях інженерів, налаштовуємо автоматичний прогін сценаріїв і зберігання замірів між збірками. Це дає порівняння версій, а не разовий знімок.
- Перевірка вузьких місць. Локалізуємо причину: блокуючі операції в головному потоці, зайві перемальовування, витоки пам'яті, важкі запити до мережі чи бази. Гіпотезу підтверджуємо заміром до і після правки, а не оцінкою на око.
- Повторні прогони та регресія. Після виправлень ганяємо той самий набір сценаріїв і звіряємо з базовою лінією. Так фіксуємо, що покращення реальне і не зламало сусідні шляхи.
- Передача результатів тестування. Віддаємо команді замовника звіт із метриками до/після, відтворюваними сценаріями та списком залишкових ризиків, щоб перевірки можна було повторювати власними силами.
Опишіть задачу — повернемося з оцінкою та планом під ваш профіль навантаження і стек.
Чим відрізняється перевірка на реальних пристроях від емуляторів?
Емулятор відтворює логіку застосунку, але не фізику пристрою. Він виконує код на процесорі робочої станції, підмінює графіку програмним рендерингом і не має справжнього модема, гіроскопа, камери та акумулятора.
Тому тестування продуктивності на емуляторі відповідає на питання «чи працює логіка», але не на питання «чи вкладемося ми в бюджет кадру та пам'яті на живому пристрої».
Розрив проявляється там, де поведінку задає залізо: тротлінг під навантаженням, поведінка при заповненій пам'яті, реальна швидкість запису в сховище.
Відмінності в продуктивності починаються з процесора та пам'яті. Настільний чип тримає стабільну частоту, а мобільний іде в тепловий тротлінг через кілька хвилин навантаження — застосунок, рівний на емуляторі, на телефоні просідає за кадрами саме на довгих сценаріях.
Емулятор виділяє застосунку пам'ять хоста і не показує, як система витісняє фонові процеси: на пристрої з малим обсягом пам'яті збирач сміття спрацьовує частіше, а система може зняти застосунок при перемиканні задач.
Мережеві умови в тестах — друге джерело розбіжностей. Емулятор дає рівний канал через хост-машину, тоді як реальна мережа змінює тип підключення, втрачає пакети та перемикається між поколіннями зв'язку на ходу.
Сценарії «слабкий сигнал», «перехід між мережами», «повернення з фону з довантаженням даних» відтворюються тільки на фізичному пристрої, бо залежать від модема та політик енергозбереження.
Апаратні обмеження додають те, що не емулюється в принципі: реальний екран із високою щільністю пікселів, датчики, камера, біометрія, різні виробники чипів і прошивок.
Звідси практика: емулятори закривають швидкі регресії та перевірку логіки на багатьох конфігураціях, а тестування на реальних пристроях — фінальний замір перед релізом на матриці з кількох моделей різного класу.
Без фізичних пристроїв не обійтися там, де важливі кадри під навантаженням, витрата батареї, поведінка при слабкій мережі та стабільність на слабкому залізі.
Кейс: як ми скоротили час відгуку та прибрали відвали в застосунку
До нас звернувся сервіс доставки: застосунок працював, але на екрані списку замовлень під час прокручування з'являлися «білі» картки, а при поверненні з фону сесія відвалювалася і користувач заново проходив вхід.
Вимірювання на реальних пристроях показали: холодний старт розтягувався, а на слабких моделях застосунок падав під час підвантаження зображень у стрічці.
Проблема була не в одному багу, а у відсутності системи — продуктивність ніхто не вимірював регулярно, тому регресії накопичувалися від релізу до релізу.
Що показали вимірювання до змін
Зібрали профіль на середньому та слабкому пристрої, прогнали сценарії: запуск, вхід, прокручування стрічки, оформлення замовлення, повернення з фону.
З'ясувалося, що вузьке місце — синхронне завантаження та декодування картинок в основному потоці: інтерфейс блокувався, кадри провалювалися, а нестача пам'яті на слабких моделях призводила до примусового закриття.
Окремо випливла утеча: екрани не звільняли слухачі, і після десяти переходів споживання пам'яті зростало лінійно.
Що змінили
- Винесли завантаження та декодування зображень у фонові задачі з обмеженням паралелізму та кешем за розміром екрана.
- Переписали життєвий цикл екранів: слухачі знімаються при виході, стан відновлюється після повернення з фону.
- Ввели бюджет продуктивності у збірку: перевірка часу запуску, плавності прокручування та пам'яті на кожній зміні.
- Налаштували автоматичний прогін сценаріїв на реальних пристроях перед релізом.
Метрики до та після
| Метрика | До | Після |
|---|---|---|
| Холодний старт | 4,1 с | 1,6 с |
| Провали кадрів при прокручуванні | 18% | 2% |
| Відвали на слабких пристроях | 6,4% сесій | 0,3% сесій |
| Зростання пам'яті за 10 переходів | +140 МБ | +8 МБ |
Клас відмов «падіння при підвантаженні контенту» пішов повністю, «зависання інтерфейсу» скоротився до поодиноких випадків. Регресії тепер ловляться до релізу, а не у відгуках.
Методологію вимірювань та пороги бюджету продуктивності ми будували на підході Firebase Performance Monitoring — він дає зріз за реальними пристроями користувачів, а не лише за тестовими стендами.
Сумніви та що ви отримаєте на руки після тестування продуктивності
Перед стартом замовники зазвичай ставлять одні й ті самі питання: чи не доведеться переписувати релізний контур, що з відкатом, якщо зміни просадять метрики, і які доступи потрібні з вашого боку.
Відповідаємо по суті: тестування продуктивності — це вимірювання та профіль навантаження, а не переписування продукту. Ми працюємо на копії стенда або на виділеному профілі, релізна гілка залишається недоторканою, а будь-яка зміна спочатку перевіряється на ізольованій збірці.
Що якщо тестовий контур не збігається з бойовим? Тоді цифри будуть брехати, тому першим кроком звіряємо конфігурацію: версії залежностей, схеми даних, ліміти мережі та поведінку бекенду під навантаженням.
Розбіжності фіксуємо у звіті — ви бачите, які метрики переносяться на прод, а які потребують переперевірки.
Що якщо знайдені вузькі місця потребуватимуть правок у коді? Ми віддаємо пріоритезований список з оцінкою впливу на час відгуку та запасом за навантаженням, а не «переробіть усе». Правки вносяться окремими змінами, кожну можна відкотити незалежно — без відкату всього релізу.
Які доступи потрібні для тестування?
Достатньо тестового стенда, облікового запису з обмеженими правами та доступу до систем збору метрик. Продові дані та повні адміністративні права не потрібні — працюємо на знеособлених наборах.
На руки ви отримуєте:
- профіль навантаження з описом сценаріїв і цільових значень;
- звіт щодо вузьких місць з пріоритетами та оцінкою впливу;
- конфігурації та скрипти прогонів для повторного запуску;
- схему метрик: що і де знімається, як читати графіки;
- документацію з продуктивності з порогами та правилами регресії;
- план відкату для кожної запропонованої зміни;
- регламент повторних прогонів перед релізом.
Опишіть вашу задачу та поточний стек — повернемося з оцінкою та планом робіт.
Терміни етапів тестування продуктивності мобільного застосунку
Терміни залежать від того, наскільки застосунок уже готовий до навантажувальних перевірок: чи є стабільний реліз, розмічені сценарії, доступ до збірок із профілюванням. Нижче — орієнтир за етапами впровадження, без прив'язки до календарних дат. Це графік робіт для типового проєкту; на дзвінку уточнюємо обсяг і коригуємо.
Тривалість аудиту та час на налаштування стенда — найбільш передбачувані частини: вони майже не залежать від коду. Основна варіативність в етапі оптимізації: якщо вузьких місць багато, цикл «правка — замір» повторюється, і термін зростає. Тому графік робіт ми будуємо ітераціями — після кожного прогону видно, скільки залишилося.
Android Studio Profiler та аналогічні інструменти дають знімати профілі прямо на пристрої, тому заміри йдуть на реальній поведінці, а не на синтетиці.
