что такое anr на андроид
Все о функциях разработчика в вашем телефоне
Константин Иванов
Настройки, которые используются для отладки и для разработки приложений, спрятаны в вашем телефоне – спрятаны в прямом смысле слова. Многие из нас идут в соответствующий раздел меню, чтобы запустить отладку USB или переключиться к рабочему модулю ART, но кроме этого, здесь имеется целый список настроек. Большая часть никогда вам не понадобится, но разве не интересно узнать, что скрывается в недрах вашего устройства?
«Разблокируем» функции разработчика в телефоне
Как говорилось выше, эти функции изначально скрыты. Это имеет смысл, поскольку найти их просто, а большинству людей они попросту не нужны. Для того, чтобы добраться до них, идем в раздел «Об устройстве» и ищем там пункт «Номер сборки». После пяти быстрых тапов появляется диалоговое окно – теперь устройство считает вас разработчиком. Только попробуйте ничего не испортить, ладно? Ну, или делайте что хотите – тоже вариант. Так или иначе, возможность заставить ваш телефон перестать работать всегда имеется.
А теперь посмотрим на предложенные функции повнимательнее.
Настройки
Понятно, что большинству пользователей все эти настройки ни на что не сдались. Кроме того, лезть туда и нажимать на пункты меню ради самого процесса — не лучшая идея. Но всегда стоит знать, что вообще можно сделать, хотя бы и просто для того, чтобы не делать этого никогда.
Надеемся, что наш рассказ просветил вас немного по вопросу этих настроек и опций, записанных непонятными словами. Кстати, в зависимости от выбранного языка системы, производителя и версии ОС Android, набор пунктов может несколько отличаться разделами и их названиями.
Приложение отвечает: как мы уменьшили количество ANR-ошибок в шесть раз. Часть 1, про сбор данных
Пожалуй, одна из худших проблем, которая может случиться с вашим приложением, — ошибка ANR (Application Not Responding), когда приложение не отвечает. Если таких ошибок много, они могут негативно влиять не только на пользовательский опыт, но и на позицию в выдаче Google Play и фичеринг.
В начале прошлого года количество ANRs в приложении Badoo превышало порог “Bad Behaviour” в Google Play. Поэтому мы собрали команду для решения этой проблемы и потратили несколько месяцев, экспериментируя с разными подходами. В результате мы смогли уменьшить количество таких ошибок более чем в шесть раз.
В этой серии из двух статей я расскажу о том, как нам это удалось, что дало наибольший эффект и как вы можете использовать эти подходы в своём приложении.
В первой части мы поговорим об основах: что представляет собой ошибка ANR и как её лучше отслеживать. Если вы уже знакомы с этой темой, предлагаю перейти ко второй части, в которой я расскажу о наших способах решения этой проблемы.
Что такое ошибка ANR?
Обычно любое приложение с графическим интерфейсом выполняет все связанные с ним операции и отрисовку в отдельном UI-потоке исполнения. Android не исключение: здесь в главном потоке приложения выполняется цикл, отвечающий за все действия с интерфейсом:
При использовании этого цикла крайне важно не выполнять длительные операции, потому что это напрямую повлияет на отзывчивость приложения. Если в главном потоке выполнять слишком много действий, это может привести к снижению частоты кадров или даже к зависаниям интерфейса:
Чтобы как-то идентифицировать такие ситуации, в Android ввели понятие ANR, с помощью которого система сообщает, что приложение зависло. Вот что об этом говорится в официальной документации:
Когда UI-поток Android-приложения блокируется слишком долго, выдаётся ошибка Application Not Responding (ANR).
ANR выдаётся, когда приложение находится в одном из этих состояний:
— на переднем плане находится Activity, приложение в течение пяти секунд не отвечает на входящие события или BroadcastReceiver, например нажатия на кнопки или касания экрана;
— на переднем плане нет Activity, ваш BroadcastReceiver не закончил исполнение в течение длительного времени.
Если ANR случается, когда на переднем плане находится Activity вашего приложения, Android показывает диалоговое окно с предложением закрыть приложение или подождать.
Довольно легко принудительно вызвать ANR, написав Thread.sleep() в любом обработчике интерфейса, например обработчик нажатия кнопки. После нажатия на кнопку вы увидите примерно следующее:
Наличие ошибок ANR в вашем приложении не только влияет на опыт его использования, но и, согласно документации Google, может повлиять на позицию в поисковой выдаче и продвижение в Google Play.
Чтобы снизить вероятность возникновения ANR, нужно всего лишь избегать выполнения длительных операций в главном потоке. Звучит вроде бы просто, но иногда не так легко определить корневую проблему, которая приводит к таким ошибкам. Поэтому довольно важно иметь хорошую систему мониторинга и репортинга ANR-ошибок.
Давайте посмотрим, какие существуют способы отладки ANR-ошибок и какие инструменты могут быть в этом полезны.
Отслеживание ANR
Локальный анализ
Самый простой случай — если у вас есть возможность стабильно воспроизводить ANR-проблему локально. Существует довольно много инструментов, которые могут помочь вам быстро найти источник проблемы.
Первое, что можно сделать, — это проверить дамп стек-трейсов для всех потоков (thread dump). Когда приложение перестает отвечать, Android создаёт дамп всех текущих потоков, который может помочь в анализе проблемы. Обычно он находится в директории /data/anr/, точный путь можно найти в Logcat сразу после сообщения об ошибке ANR.
Дамп потоков содержит стек-трейсы: вы увидите, в каком состоянии был каждый поток (например, какая строка выполнялась в конкретный момент времени). По сути, это состояние приложения на момент создания дампа.
Чаще всего причина возникновения ANR обнаруживается в стек-трейсе главного потока скорее всего, код в этом месте выполняется слишком долго. Если информации из этого стек-трейса будет недостаточно, можно попробовать обратиться к довольно неплохой документации от Google, где описываются основные причины, способы диагностирования и решения проблемы ANR.
Отслеживание с помощью Google Play
Google Play автоматически отправляет отчёты об ошибках ANR, если у пользователя включена такая опция. В консоли Google Play есть несколько метрик и инструментов для анализа ANR.
Во-первых, можно увидеть агрегированные графики с общим количеством ANR-ошибок за день. Также есть такая метрика, как ANR rate — отношение количества сессий за день, в которых возникала хотя бы одна ANR-ошибка, к общему количеству сессий за сутки. Для этой метрики задан порог в 0,47%, превышение которого считается «неудовлетворительным поведением» (“Bad Behaviour”) и может плохо повлиять на позицию приложения в Google Play.
Во-вторых, можно открывать отдельные отчёты об ANR-ошибках, сгруппированные по схожести на основе стек-трейса. Основные группы находятся в разделе Android Vitals. И это, вероятно, наиболее полезный раздел для выявления самых частых причин возникновения ANR-ошибок в вашем приложении.
Если вы активно используете консоль Google Play, вы могли заметить некоторые её недостатки. Например, к отчётам нельзя прикрепить дополнительную информацию, такую как логи для отладки. Также невозможно настроить логику группировки отчётов. Иногда система помещает в одну группу ошибки, возникшие по разным причинам, а иногда раскидывает по разным группам ошибки, у которых причина одна.
Всё это иногда затрудняет определение основных ошибок и поиск изначальных проблем. Что же можно сделать для улучшения ситуации?
Скачивание данных из Google Play
Для решения проблемы с логикой группировки можно попробовать скачать сырые отчёты об ANR-ошибках из Google Play для последующего ручного анализа. Раньше была возможность выгрузить эти данные из Google Cloud Storage, но несколько лет назад Google перестала поддерживать этот функционал:
Однако всё ещё можно просматривать отдельные отчёты в консоли. Но как нам экспортировать тысячи отчётов, не потратив при этом кучу времени на рутинную работу?
Существует много способов автоматизировать сбор информации с сайтов. Самый правильный и простой — получение данных через API, но, к сожалению, Google не предоставляет публичный API для получения отчётов. Одно из решений — эмулировать пользовательское поведение, автоматически кликая на ссылки и кнопки в браузере и сохраняя отображающийся текст.
Веб-скрапер можно реализовать с помощью популярного инструмента Selenium, который предоставляет простой интерфейс для взаимодействия с веб-страницами. Изначально он предназначался для создания автоматизированных тестов для веб-приложений и доступен на разных языках, включая Java и Kotlin.
Мы реализовали скрапер на Selenium и получили сырые отчёты об ANR-ошибках для одного из релизов. Благодаря этому нам удалось проанализировать их так, как не получилось бы сделать с помощью встроенных в консоль Google Play инструментов. Например, просто поискав в отчётах по ключевым словам “Application.onCreate”, мы обнаружили, что около 60% ошибок произошло во время выполнения метода Application.onCreate. При этом в консоли Google Play нет возможности получить такую информацию, так как отчёты разбиты по группам.
Внутренняя аналитика
Другой способ сбора дополнительных данных и проведения расширенного анализа заключается в настройке собственного репортинга ANR-ошибок. В прошлом мы уже экспериментировали с решением похожих проблем, настраивая репортинг крашей. Для того чтобы проводить анализ падений приложения, мы создали внутренний инструмент Gelato.
Его функциональность схожа с возможностями других инструментов для краш-репортинга, таких как Firebase Crashlytics и App Center, но ещё и позволяет нам полностью контролировать сохраняемые данные, менять логику группировки и применять сложную фильтрацию:
Это не реальные данные приложения Bumble, иллюстрация сделана просто для примера
Мы решили отслеживать в Gelato ещё и ANR-ошибки в надежде, что это поможет нам в поиске их причин. Для этого нам нужно было знать, когда приложение перестаёт отвечать. В Android 11 появился новый API, предоставляющий информацию о недавних причинах завершения процесса, но у большинства наших пользователей установлены более ранние версии ОС, поэтому нам требовалось найти другое решение.
И мы нашли простой способ, который часто используется для отслеживания зависаний главного потока исполнения: запустить watchdog-поток, который периодически будет пытаться выполнить задачу в главном потоке. Если задача не выполняется за определённый промежуток времени, то можно сохранить дамп текущего состояния потоков и отправить его в наш инструмент для анализа отчётов о падениях:
Такую логику реализует, например, библиотека, которой мы воспользовались для реализации репортинга в Gelato. Это позволило нам проводить более глубокий анализ данных и лучше интегрировать этот инструмент в нашу инфраструктуру. Например, теперь мы можем сравнивать зависания главного потока в разных вариантах в ходе A/B-тестирования.
Вот пример отчёта в нашей системе:
Это не реальные данные приложения Bumble, иллюстрация сделана просто для примера
Полезный совет: собирайте и отправляйте вместе с отчётом лог событий аналитики. Иногда это даёт возможность буквально пошагово воспроизвести проблему.
Если у вас нет своего решения для сбора отчётов о падениях приложения, вы можете настроить репортинг и в сторонние инструменты. Например, можно отправлять ANR-ошибки в App Center или Firebase Crashlytics, так как они предоставляют API для отправки кастомных крашей.
Но помните, что все эти отчёты нельзя считать полной альтернативой ANR-отчётам в Google Play (как мы говорили выше, в Android немного другие правила определения таких ошибок). Но в любом случае это может помочь получить общее представление об основных проблемах. Вполне вероятно, что если генерируется много отчётов о зависании главного потока исполнения в какой-то части вашего приложения, то в ней происходят и ANR-ошибки.
В завершение
Мы обсудили, что представляют собой ANR-ошибки и как их можно отслеживать. Во второй части статьи я расскажу о наших подходах к снижению ANR rate и о том, что из этого получилось.
Android-как я могу исследовать ANR?
есть ли способ узнать, где мое приложение бросило ANR (приложение не отвечает). Я взглянул на следы.txt-файл в /data, и я вижу трассировку для своего приложения. Это то, что я вижу в трассировке.
10 ответов:
ANR происходит, когда какая-то длительная операция происходит в «главном» потоке. Это поток цикла событий, и если он занят, Android не может обрабатывать дальнейшие события GUI в приложении и, таким образом, вызывает диалог ANR.
теперь, в трассировке вы опубликовали, основной поток, кажется, все в порядке, нет никаких проблем. Это простаивания в очереди, ждет еще одно сообщение сюда. В вашем случае ANR, скорее всего, была более длительной операцией, а не чем-то, что заблокировал поток навсегда, поэтому поток событий восстановился после завершения операции, и ваша трассировка прошла после ANR.
обнаружение, где происходят ANRs, легко, если это постоянный блок (например, тупик, приобретающий некоторые блокировки), но сложнее, если это просто временная задержка. Во-первых, просмотрите свой код и найдите vunerable пятна и длительные операции. Примеры могут включать использование сокетов, блокировок, спящих потоков и других операций блокировки из события нитка. Вы должны убедиться, что все это происходит в отдельных потоках. Если ничего не кажется проблемой, используйте DDMS и включите представление потока. Это показывает все потоки в вашем приложении, похожие на трассировку, которую вы имеете. Воспроизвести ANR, и обновить основной поток в то же время. Это должно показать вам точно, что происходит во время ANR
Вы можете включить StrictMode в API уровня 9 и выше.
StrictMode чаще всего используется для захвата случайного диска или сети доступ к основному потоку приложения, где выполняются операции пользовательского интерфейса полученные и анимации имеют место. Сохраняя основной поток вашего приложения отзывчивый, ты тоже запретить диалоги ANR от показа пользователям.
используя penaltyLog() вы можете посмотреть вывод АБР logcat в то время как вы используйте приложение, чтобы увидеть нарушения, как они происходят.
вам интересно, какая задача содержит поток пользовательского интерфейса. Файл трассировки дает вам подсказку, чтобы найти задачу. вам нужно исследовать состояние каждого потока
состояние потока
фокус на приостановлено, состояние монитора. Состояние монитора указывает, какой поток исследуется, и приостановленное состояние потока, вероятно, является основной причиной взаимоблокировки.
основные шаги исследования
трассировка не всегда содержит «ожидание блокировки». в в этом случае трудно найти главную причину.
Я изучал android в течение последних нескольких месяцев, поэтому я далек от эксперта, но я был очень разочарован документацией по ANRs.
большинство советов, похоже, направлены на то, чтобы избежать их или исправить их, слепо просматривая ваш код, что здорово, но я ничего не мог найти при анализе трассировки.
есть три вещи, которые вам действительно нужно искать с журналами ANR.
1) взаимоблокировки: когда поток находится в ожидании государство, вы можете посмотреть через детали, чтобы найти, кто это «heldby=». Большую часть времени он будет удерживаться сам по себе, но если он удерживается другой нитью, это, вероятно, будет знаком опасности. Иди посмотри на эту нить и посмотри, за что она держится. Вы можете найти петлю, которая является явным признаком, что что-то пошло не так. Это довольно редко, но это первый момент, потому что, когда это происходит, это кошмар
2) ожидание основного потока: Если ваш основной поток находится в состоянии ожидания, проверьте, удерживается ли он по другой нитке. Этого не должно произойти, потому что ваш поток пользовательского интерфейса не должен удерживаться фоновым потоком.
оба этих сценария означают, что вам нужно значительно переработать свой код.
3) тяжелые операции на основной поток: это наиболее распространенная причина ANRs, но иногда один из труднее найти и исправить. Посмотрите на основные детали потока. Прокрутите вниз трассировку стека и пока не увидите классы, которые вы узнаете (из вашего приложения). Посмотрите на методы в трассировке и выяснить, если вы делаете звонков внутри сети, БД и т. д. в таких местах.
наконец, и я прошу прощения за бесстыдно подключив свой собственный код, вы можете использовать анализатор журнала python, который я написал в https://github.com/HarshEvilGeek/Android-Log-Analyzer это будет проходить через ваши файлы журналов, открывать файлы ANR, находить взаимоблокировки, находить ожидающие основные потоки, находить неперехваченные исключения в журналах агентов и печатать все это на экране относительно легко читать. Читать ReadMe файл (который я собираюсь добавить), чтобы узнать, как его использовать. Это помогло мне тонну на прошлой неделе!
всякий раз, когда вы анализируете вопросы синхронизации, отладка часто не помогает, так как замораживание приложения в точке останова сделает проблему уйти.
лучше всего, чтобы вставить много протоколирования вызовов (Log.XXX ()) в различные потоки и обратные вызовы приложения и посмотреть, где задержка находится. Если вам нужен stacktrace, создайте новое исключение (просто создайте экземпляр) и запишите его.
что вызывает ANR?
как правило, система отображает ANR, если приложение не может ответить на ввод пользователя.
в любой ситуации, когда ваше приложение выполняет потенциально длительную операцию, вы не должны выполнять работу в потоке пользовательского интерфейса, а вместо этого создать рабочий поток и выполнять большую часть работы там. Это сохраняет поток пользовательского интерфейса (который управляет циклом событий пользовательского интерфейса) и предотвращает вывод системы о том, что ваш код заморожен.
Как избежать ANRs
приложений Android обычно полностью работают на один поток по умолчанию «поток пользовательского интерфейса» или «основной поток»). Это означает, что все, что ваше приложение делает в потоке пользовательского интерфейса, которое занимает много времени, может вызвать диалоговое окно ANR, потому что ваше приложение не дает себе возможности обрабатывать входные события или передачи намерений.
поэтому любой метод, который выполняется в потоке пользовательского интерфейса, должен выполнять как можно меньше работы этот поток. В частности, мероприятия должны делать как можно меньше для настройки в ключевых методах жизненного цикла, таких как onCreate() и onResume(). Потенциально длительные операции, такие как операции с сетью или базой данных, или вычислительно дорогостоящие вычисления, такие как изменение размера растровых изображений, должны выполняться в рабочем потоке (или в случае операций с базами данных с помощью асинхронного запроса).
код: рабочий поток с классом AsyncTask
Код: Выполнить Рабочий поток
чтобы выполнить этот рабочий поток, просто создайте экземпляр и вызовите execute ():
Русские Блоги
Подробный ANR оптимизации приложений для Android
Чтобы облегчить чтение, меня пригласили перенести серию статей по оптимизации производительности Android-приложений в исходные Nuggets.
Новую функцию «Сборник» в Nuggets можно использовать для создания серии эссе.
Давайте поговорим сегодня об ANR.
1, сталкивались ли вы с ANR
Во время использования Приложения вы могли столкнуться с такой ситуацией:
Поздравляем, это легендарный ANR.
1.1 Что такое ANR
1.2 Почему генерируется ANR
В Android за быстродействием приложения следят системные службы Activity Manager и Window Manager. Как правило, диалоговое окно ANR появляется в следующих двух ситуациях:
1.3 Как избежать ANR
Зная причину ANR, очень просто избежать ANR, всего одно правило:
Не выполняйте тяжелых операций в основном потоке (потоке пользовательского интерфейса).
На самом деле это связано с двумя проблемами:
2, анализ ANR
2.1 Получите файл трассировки, созданный ANR
При генерации ANR система сгенерирует файл traces.txt и поместит его в / data / anr /. Вы можете передатьadbКоманда для локального экспорта:
2.2 Анализ traces.txt
2.2.1 ANR, вызванный обычной блокировкой
Полученный файл tracs.txt обычно выглядит следующим образом:
Следующим образомGithubAppВ качестве примера возьмем код: ANR, созданный потоком принудительного сна.
Получите трассировочную информацию, все легко сказать.
Как в приведенной выше информации о трассировкеДобавлен комментарий на китайском языкеОн в основном объяснил, как анализировать файл трассировки:
Вышеупомянутая трассировка ANR относительно проста, и возможно, что вы не выполнили слишком трудоемких операций в основном потоке, но это все еще ANR. Это могут быть следующие две ситуации:
2.2.2 Полная загрузка процессора
Информация трассировки, которую вы видите сейчас, может содержать такую информацию:
Последнее предложение указывает:
Анализируя стек вызовов метода в это время, обычно обнаруживается, что метод имеет частые операции чтения и записи файла или чтения и записи базы данных в основном потоке.
2.2.3 Причина памяти
Фактически, память может вызвать ANR. Например, если в Приложении осталось мало памяти из-за утечки памяти, мы нажимаем кнопку, чтобы запустить большое изображение в качестве фонового действия, и ANR может быть сгенерирован. В это время информация трассировки может быть такой:
Как видите, свободной памяти осталось не так много.
2.2 Обработка ANR
Для трех различных ситуаций общая обработка выглядит следующим образом
Основной поток заблокирован
Создайте отдельный подпоток для обработки длительных блокирующих транзакций.
ЦП полностью загружен, ввод-вывод заблокирован
Блокировка ввода-вывода обычно означает, что чтение и запись файла или операции с базой данных выполняются в основном потоке, а также могут выполняться асинхронно, открывая дочерние потоки.
Недостаточно памяти
Увеличьте память виртуальной машины, используйте атрибут largeHeap, проверьте наличие утечек памяти (это обсуждается в главе об оптимизации памяти) и т. Д.
3, иди глубже
Никто не хочет решать проблему после того, как она возникла.
Разница между мастером и новичком заключается в том, что мастер знает, как избежать проблемы с самого начала. Итак, для проблемы ANR, какой уровень работы нам нужно сделать, чтобы ее избежать?
3.1 Какие места выполняются в основном потоке
3.2 Как можно использовать дочерние потоки
3.2.1 Запуск режима резьбы
Именно так Java реализует многопоточность.Существует два метода реализации, наследующие Thread или реализующие интерфейс Runnable:
Наследовать тему
Реализуйте интерфейс Runnable
3.2.2 Использование AsyncTask
Это уникальный способ для Android. AsyncTask, как следует из названия, означает асинхронную задачу.
3.2.3 HandlerThread
Способ объединения обработчика и потока в Android. Перед ним облако. По умолчанию handleMessage обработчика выполняется в основном потоке, но если я передаю цикл дочернего потока этому обработчику, handleMessage будет выполняться в этом дочернем потоке. В HandlerThread есть как раз такая комбинация:
3.2.4 IntentService
Служба работает в основном потоке, но IntentService работает в дочернем потоке.
Фактически, IntentService реализует модель HandlerThread + ServiceHandler.
Пример кода вышеупомянутого HandlerThread также взят изИсходный код IntentService.
3.2.5 Loader
Загрузчик данных, представленный в Android 3.0, может использоваться в Activity / Fragment. Он поддерживает асинхронную загрузку данных и может отслеживать источник данных для получения новых результатов при изменении данных. CursorLoader обычно используется для загрузки данных из базы данных.
3.2.6 Особое внимание
При использовании Thread и HandlerThread, чтобы эффект был лучше, рекомендуется установить приоритет Thread немного ниже:
Потому что, если вы не устанавливаете какой-либо приоритет, вы знаете, что создаваемый поток по умолчанию имеет тот же приоритет, что и поток пользовательского интерфейса. Поток с таким же приоритетом, планирование ЦП может по-прежнему блокировать ваш поток пользовательского интерфейса, Причина ANR.