Инструменты тестирования Android приложений. Часть 5
Содержание:
- Часть 1. Android приложение: что это и как с этим работать
- Часть 2: ADB
- Часть 3: Logcat
- Часть 4: ReTrace
- (Вы здесь) Часть 5: Побеждаем ANR с помощью ANRWatchdog
Побеждаем ANR с помощью ANRWatchdog
Если вы работаете на Windows и запустите несколько приложений, то их все можно увидеть в Диспетчере задач: под каждое приложение создается свой процесс, который можно завершить в любой момент.
Android работает по схожему принципу: каждое приложение в системе Android живет на своем процессе, у процесса есть своя выделенная память под нужды приложения и несколько потоков выполнения (Threads).
Потоки приложения нужны, чтобы делать несколько вещей одновременно, например, загружать электронную книгу и показывать анимированный статус загрузки.
Потоки приобрели свою популярность при создании многоядерных процессоров. Если в работе участвует только одно ядро, то приложение может иметь несколько потоков, но это будет псевдопараллелизм — потоки будут конкурировать за активное состояние и перебивать друг друга (на предыдущем примере: анимация будет зависать, пока она висит, загружается книга). На всех же современных телефонах все выполняется параллельно.
Важно знать, что у Android (и у многих других платформ) есть специальный поток, который занимается только отрисовкой UI и анимациями, он называется “Main Thread”.
Очень часто бывает, что разработчик забывает перевести тяжеловесную операцию на другой поток, и она начинает выполнятся на Main потоке. И из-за этого приложение визуально начинает подвисать.
Если такая ситуация случается и операция занимает очень много времени (например, работает сложный алгоритм, который ищет все словосочетания в файле размером в несколько гигабайт), то приложение завершится с ANR (Application not responding). Вы точно встречались с подобной ситуацией — появляется диалоговое окно с текстом “Приложение <название> не отвечает”.
Теперь вы знаете почему так происходит. :)
Понимание данного нюанса поможет быстрее найти первопричину этих зависаний и составить подробный багрепорт, который будет более информативным, чем простое: “Экран Х завис, когда пользователь открыл его”.
ANR штука противная: из-за зависания потока не идет логгирования и не понятно, что именно забило поток выполнения, а сама Android система не пишет это напрямую.
Бывает, если прийти с ANR к разработчику, он может просто отмахнуться или попытаться воспроизвести и, в случае неудачи — забить (зависит это напрямую от степени неравнодушности команды разработки). QA специалист может прийти ANR к разработке примерно понимая откуда растут корни и потребовать мониторинга ситуации. И тут есть много средств, как эту ситуацию контролировать, самая простая из них и легкая в реализации — использовать стороннюю библиотеку ANRWatchdog.
ANRWatchdog работает по следующему принципу: запускается отдельный поток, который через фиксированные периоды времени проверяет доступен ли Main поток. Если нет, то Watchdog кидает ошибку, в которой собирает информацию по всем активым потокам. Затем крашит приложение и выводит в логи информацию о том, что именно блокирует Main поток (вплоть до строчки в коде).
Прелесть этой библиотеки в том, что она хорошо конфигурируется — период проверки может меняться, библиотека может не крашить приложение, а отправлять логи на внешние трекеры, на которые потом можно ссылаться в отчетах об ошибке. С точки зрения разработки, ее внедрение займет два часа в худшем случае. Так что, если вы не еще ее не используете, то обсудите возможность ее внедрения с командой. Это та вещь, которая поможет улучшить производительность вашего приложения.
Еще бывают случаи, что подвисание UI может присутствовать, но не достигает критичных значений (Watchdog не отправляет ошибку, но UI заметно подвисает), в этом случае можно использовать встроенные в инструменты разработчика опцию Profile GPU rendering.
Она позволяет выводить на экран статистику по скорости отрисовки и обновления UI.
Каждый вертикальный прямоугольник — это один кадр отрисовки. На Android девайсах 60fps (кадров в секунду) считается эталонным для человеческого восприятия. Если поделить секунду на 60 то получится, что один кадр должен выполняться максимум за 16.6 мс. Этот временной предел показывает горизонтальная зеленая линия.
Если вертикальный прямоугольник поднимается выше зеленой линии, значит время отрисовки кадра длилось дольше эталонного. То есть, если при загрузке экрана каждый кадр отрисовывается за 160 мс, то вместо 60 кадров в секунду мы получаем 50, а это уже будет заметно для глаз пользователя. Можно описать диагностику проще: “чем больше прямоугольники, тем хуже пользовательский опыт”.
Если такая ситуация встречается часто и у бизнесса есть фокус на улучшении перфоманса, то можно сконфигурировать Watchdog так, чтобы он отправлял отчеты при малых значениях и точечно устранять проблемы. Но эти пункты остаются на усмотрение команды и бизнеса: иногда можно акцентировать внимание на проблеме, но не трубить тревогу.
