Android — Лаги в android приложении


Содержание

Android — Лаги в android приложении

А если телефон вдруг ребутнул, я разумеется ничего не успел нажать (в смысле Save) и при новой загрузке catlog уже не активен. Можно ли ещё сохранить логи? Целы ли они в самом «катлоге».

Сорри, он кажись и так уже записывает на карту. а то раньше в каталоге катлога ничего не было.

Сообщение отредактировал Arth67 — 26.01.12, 14:21

Список изменений:
версия: 1.3.2
‪ — CatLog can be launched from external Intents. Details: сайт разработчика.
‪версия: 1.3.1
‪ — New «Default Log Level» setting.

Отладка приложения, Logcat

Для отладки приложений могут быть использованы всплывающие сообщения Toast. Однако это не эффективно. Android SDK включает средство просмотра отладочных сообщений Logcat. Оно не представляет сложности в освоении, поэтому широко используется программистами. Logcat позволяет просматривать отладочные сообщения не только разрабатываемого приложения, но и протоколируемые системой сообщения. Так, например, Garbage Collection периодически протоколирует свои сообщения о выполнении определенных действий («сборке мусора»), которые можно просматривать с помощью Logcat.

Для протоколирования сообщений необходимо использовать класс android.util.Log, позволяющий объединять сообщения по категориям. В следующем списке приведены методы класса Log, отсортированные по приоритету (важности) от высшего к низшему :

  • Log.e(String, String) — ошибка (error)
  • Log.w(String, String) — предупреждение (warning)
  • Log.i(String, String) — информация (info)
  • Log.d(String, String) — отладка (debug)
  • Log.v(String, String) — подробно (verbose)

Пример протоколирования

В качестве первого параметра методов Log используется текстовый тег (в примере переменная TAG). Если имеется необходимость в качестве тега сообщения определить наименование класса, то можно использовать следующее определение :

Панель Logcat в Studio

Logcat в среде разработки Android Studio располагается на отдельной вкладке, интерфейс которой представлен на следующем скриншоте. Слева вертикально располагаются кнопки управления сообщениями : очистка, перемещение по списку и т.д. Интерес представляет расположенный сверху справа компонент с выпадающим списком/меню. Если выбрать представленный на скриншоте пункт «Edit Filter Configuration», то можно определить фильтр сообщений, окно которого изображено на следующем скриншоте.

Фильтр сообщений

Logcat позволяет создать набор из нескольких фильтров. Достаточно только для каждого фильтра определить его наименование «Filter Name» и тег сообщений «Log Tag». Значение тега сообщения регистрируется классом android.util.Log.

Создадим простой пример протоколирования сообщений. В примере переопределим методы активности; в каждом методе будем протоколировать соответствующее сообщение.

Листинг активности

После старта приложения переходим на вкладку Locat и просматриваем список регистрируемых сообщений. Чтобы исключить сообщений системы установим фильтр State (справа, сверху). После этого можно менять ориентацию устройства (portrait => landscape => portrait) и контролировать список сообщений.

Протоколируемые сообщения можно просматривать не только с помощью Logcat. Они также попадают и на вкладку Run (см. следующий скриншот), но только с ме́ньшей функциональностью (отсутствует время регистрации, нельзя фильтровать и т.д.).

Формат сообщения

Logcat представляет сообщения в определенном формате : «date time PID-TID/package priority/tag: message». Поле даты (date) имеет формат MM-DD (месяц–день). Формат времени (time) HH24:MI:SS.SSS (часы:минуты:секунды.мс) включает милисекунды. Значения идентификаторов процесса PID и потока TID могут совпадать, если существует только один поток. Пример сообщения : 02-08 08:43:51.557 11608-43308/com.android.test.p08activity D/ACTIVITY_STATE: onStop.

Английский вариант полного описания Logcat.

Контроль протоколирования, BuildConfig

На этапе разработки приложения вывод отладочных сообщений, конечно же, полезен и необходим. Но что делать с этими сообщеними в готовом релизе? Если проект включает несколько модулей с различными тегами отладочных сообщений, то подготовка очередного релиза потребует определенных усилий с ручным удалением отладочных сообщений и комментариев. Иногда программисты используют условные выражения для вывода сообщений/комментариев. Например :

В этом примере сообщения будут протоколироваться в отдельной процедуре WriteLog только если IS_RELEASE=false. Одним движением (IS_RELEASE=true) можно блокировать протоколирование сообщений перед созданием готового apk-файла.

Начиная с 17-ой версии Android Build Tools в приложении автоматически формируется класс BuildConfig, содержащий статическое поле DEBUG с признаком отладочной сборки. При использовании данного класса перед протоколированием необходимо выполнить следующую проверку :

Объект BuildConfig можно расширить и включить в него свой «тег». Для этого необходимо внести соответствующие изменения в секцию buildType сборочного build.gradle файла проекта. Вот как может выглядеть секция buildType для тега ACTIVITY_STATE :

Конфигурация releaseWithLog будет релизной сборкой с протоколированием. Соответственно в коде приложения необходимо будет выполнять следующую проверку :

Полный список

В этом уроке мы:

— рассмотрим логи приложения и всплывающие сообщения

Project name: P0121_LogAndMess
Build Target: Android 2.3.3
Application name: LogAndMess
Package name: ru.startandroid.develop.logandmess
Create Activity: MainActivity

Создадим в main.xml экран, знакомый нам по прошлым урокам про обработчики:

Алгоритм приложения будет тот же. По нажатию кнопок меняется текст. Обработчик — Activity.

Сохраним, запустим. Убедимся, что все работает.

Логи приложения

Когда вы тестируете работу приложения, вы можете видеть логи работы. Они отображаются в окне LogCat. Чтобы отобразить окно откройте меню Window > Show View > Other … В появившемся окне выберите Android > LogCat

Должна появится вкладка LogCat

Рассмотрим эту вкладку подробней. Логи имеют разные уровни важности: ERROR, WARN, INFO, DEBUG, VERBOSE (по убыванию). Кнопки V D I W E (в кружках) – это фильтры и соответствуют типам логов. Опробуйте их и обратите внимание, что фильтр показывает логи не только своего уровня, но и уровней более высокой важности. Также вы можете создавать, редактировать и удалять свои фильтры – это мы рассмотрим чуть дальше.


Давайте смотреть, как самим писать логи. Делается это совсем несложно с помощью класса Log и его методов Log.v() Log.d() Log.i() Log.w() and Log.e(). Названия методов соответствуют уровню логов, которые они запишут.

Изменим код MainActivity.java. Возьмем все каменты из кода и добавим в DEBUG-логи с помощью метода Log.d. Метод требует на вход тэг и текст сообщения. Тэг – это что-то типа метки, чтобы легче было потом в куче системных логов найти именно наше сообщение. Добавим описание тега (TAG) и запишем все тексты каментов в лог.

Eclipse ругнется, что не знает класс Log. Обновите импорт (CTRL+SHIFT+O) и, если спросит, выберите android.util.Log. Запустим приложение, понажимаем кнопки и посмотрим логи

Видно, что все отлично записалось. Чтобы сделать просмотр удобней, создадим свой фильтр. Жмем значок +

Имя фильтра произвольное, например, «My logs». Log Tag – это как раз значение константы TAG, которая описана в нашем коде и использовалась в методе Log.d, т.е. — «myLogs«. Pid оставляем пустым, это id процесса. Уровень поставим Debug

и жмем OK. Появилась новая вкладка My logs, на которой отображаются логи, соответствующие только что созданному фильтру.

Мы помещали в лог текст, но разумеется, вы можете писать, например, значения интересующих вас переменных (приведенные к типу String).

Иногда бывает, что логи не отображаются во вкладке LogCat, хотя AVD запущен, приложение работает без проблем. В таком случае должно помочь следующее: в Eclipse идем в меню Window > Open Perspective > Other > DDMS. Откроется немного другой набор окон чем обычно. Там найдите вкладку Devices и в ней должно быть видно ваше AVD-устройство, кликните на него и логи должны появиться. Чтобы вернуться в разработку: Window > Open Perspective > Java.

Всплывающие сообщения

Приложение может показывать всплывающие сообщения с помощью класса Toast. Давайте подредактируем метод onClick. Сделаем так, чтобы всплывало сообщение о том, какая кнопка была нажата.

Разберем синтаксис вызова. Статический метод makeText создает View-элемент Toast. Параметры метода:

context – пока не будем вдаваться в подробности, что это такое и используем текущую Activity, т.е. this.
text – текст, который надо показать
duration – продолжительность показа ( Toast.LENGTH_LONG — длинная, Toast.LENGTH_SHORT — короткая )

Toast создан и чтобы он отобразился на экране, вызывается метод show(). Сохраняем, запускаем, проверяем.

Если у вас есть Андроид-смартфон, я думаю вы уже видели подобные сообщения. Теперь вы знаете, как это делается )

На следующем уроке:

— создаем пункты меню

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Android: логгирование и отправка результатов на почту

Хочу начать небольшой разговор о том, как можно получать данные о работе приложения и некоторых его компонентов от пользователей.

Одно дело — разработка, LogCat в Android Studio (если вы из любителей пожестче — можно распечатку в консоли смотреть с помощью adb), и совсем другое — ломать голову над вопросом почему у вас все работает на всем парке тестовых устройств, а пользователь жалуется на абсолютно обратную ситуацию. Коммуникация между разработчиком и конечным пользователем — это хорошо, но совсем другое — видеть своими глазами картинку происходящего (помните, как в матрице — для кого-то это зеленые иероглифы, а для кого-то — женщина в красном?)

Предлагаю разбить задачу на несколько частей, а именно — сбор и хранение логов, способ их передачи из одного приложения в другие с помощью FileProvider, ну и небольшой helper класс для создания писем с аттачами. Итак, поехали.

Сбор и хранение логов.

Кто-то использует System.out.println, кто-то — статические методы класса Log. Я с некоторых пор пришел к написанию своего класса для распечатки логов. Давайте вкратце расскажу почему.

Во-первых, это проще. Как правило, для отслеживания изменений в процессе выполнения приложения я использую одну и ту же метку. И вот однажды я подумал — зачем ты пишешь постоянно Log.i(MY_TAG, «info») если можно сократить немного и убрать из этой формулы одну постоянную?

Цукерберг рекомендует:  Ошибка python - Где тут ошибки python

Во-вторых, расширение логгирования. Это конкретно упирается в нашу задачу — хранение логов в файлах. Можно написать отдельный класс, в который будем передавать какие-то данные, как то: данные и имя файла, но данные мы уже передаем в метод Log.i / Log.e / проч., создавать лишний раз переменную что ли для этого? Некрасиво все это как-то.

Ладно, довольно лирики, давайте лучше взглянем на класс Diagnostics.

Для того, чтобы вывести информацию в LogCat с дефолтной меткой, достаточно написать следующее:

Иногда мне хочется видеть какие методы вызываются и в каких объектах. И с какими параметрами или значениями переменных. В общем, тут важно для меня — где именно производится вызов. Тогда я использую следующую конструкцию

Diagnostics.i(this, “onCreate w/param1 = “ + param1);

где this — это экземпляр класса Caller. Например, для MainActivity вы увидите следующее:

И все сразу становится понятно — кто вызывает и где вызывает.

А теперь о хранении этой информации.

Как вы уже могли видеть, в классе Diagnostics есть методы для работы с файлами — createLog и appendLog. Объяснять, я думаю, не стоит — первый создает файл, второй — добавляет в него строку. Для новичков или тех, кто ленится читать код, уточню — appendLog создает файл, если его не существует, а createLog всегда создает новый. Чтобы лишней информации там не хранилось.

Файлы хранятся в cache директории, которая, к слову, недоступна для других приложений (ну, если у вас телефон не рутован, конечно).

В общем, теперь процедура распечатки лога и хранения его в файле выглядит следующим образом.

Надеюсь, это выглядит просто в использовании.


Передача файлов в другие приложения

Как я уже говорил выше, наши файлы для лога хранятся в некоторой защищенной от чужих глаз папке. Она настолько защищена, что если вы попробуете передать файлы в другое приложение с использованием относительного пути File.getAbsolutePath(), то вы потерпите неудачу.

На помощь к нам мчится FileProvider, друзья!

Вообще, в документации есть отличная статья (она же — пошаговая инструкция) на эту тему — Setting Up File Sharing, но для тех, кто предпочитает читать StackOverFlow и isidroid.com, я приведу выжимку из статьи с кодом реализации.

2. Указываем директории, доступные для шаринга. Для этого создаем файл res/xml/cache_file_paths и для нашего конкретного примера заполняем его.
Конец.

Нет, правда, это все.

На самом деле это довольно мощный инструмент для работы с файлами в вашем приложении, но в рамках поставленной задачи это все, что нам нужно сделать. Подробности — в официальной документации.

Отправка писем с логами.

Мы с вами почти добрались до конца, осталось дело за малым. Вообще, создание намерения (intent) для отправки писем — это довольно тривиальная задача, чтобы под нее писать отдельный хелпер. Но с другой стороны, если можно причесать код в вашей Activity / Fragment, то почему бы и нет, верно?

Гораздо симпатичнее будет выглядеть какой-нибудь строитель (builder) в коде нежели условия, проверки и лишние циклы. Я за то, чтоб это выносить в отдельный класс (кстати, не только я ратую за разделение представления от бизнес-логики).

Давайте перейдем сразу к сути. Сначала я покажу класс (который вы можете скопировать и использовать не глядя, конечно), а потом пример его использования. Поехали!

Где this — это Activity.

Вы можете самостоятельно указать «рыбу» для текста письма, но я рекомендую использовать те данные, которые указаны в методе buildContent, расширяя их при необходимости. Можно конечно извернуться и применить паттерн «декоратор» для расширения этих данных без модификации класса FeedbackHelper, но лично для меня необходимости в этом не было… Что до вас, то дерзайте!

[Ищу] Снятие логов andro > Автор slavakuharenkov , 14 мар 2020 09:17

#1 slavakuharenkov

Здравствуйте. Ищу инструкцию как вытянуть логи конкретного приложения на андроиде. Есть установленный ADB, через него вижу логи, только не знаю как отобрать логи для определенного приложения. И есть программа CatLog, но незнаю как в ней сохранить файл с логами. Помогите кто знает. Спасибо)

#2 Garm

Я монитором пользовался (в platform-tools sdk лежит, если память не изменяет), всё же через GUI работать удобнее несколько.

#3 slavakuharenkov

Я монитором пользовался (в platform-tools sdk лежит, если память не изменяет), всё же через GUI работать удобнее несколько.

Ну да, через файл monitor.bat только как искать логи конкретного приложения?

А вообще интересует вопрос: какие логи нужно отправлять при нахождении ошибки, все или только логи приложения тестируемого?

может разработчику нужно видеть сторонние процессы или нет?

#4 Garm

Приложения можно фильтровать по их по activity name, если не знаешь его, можно через adb использовать dumpsys activity (там есть running activities). Плюс можно фильтровать по уровню логов (по умолчанию verbose, вроде).

Касательно второго вопроса, это зависит, как мне кажется. Лично я не так часто логи в репорты вставлял, но они мне помогали найти причину ошибки. Если повезёт, то у вас могут быть assert’ы какие-нибудь выводиться, например.

#5 slavakuharenkov

Приложения можно фильтровать по их по activity name, если не знаешь его, можно через adb использовать dumpsys activity (там есть running activities). Плюс можно фильтровать по уровню логов (по умолчанию verbose, вроде).

Касательно второго вопроса, это зависит, как мне кажется. Лично я не так часто логи в репорты вставлял, но они мне помогали найти причину ошибки. Если повезёт, то у вас могут быть assert’ы какие-нибудь выводиться, например.

Можно подробней об этом » dumpsys activity (там есть running activities). » Что открывать Android studio или monitor.bat ? или где это смотреть?

По поводу второго: не понял вообще ответа

#6 Garm

dumpsys — команда adb, к слову, судя по http://developer.and. help/shell.html, оно и в ddms должно быть.

По поводу второго: не понял вообще ответа

Я имел в виду, что это зависит от конкретной ситуации. В моём случае, как правило, отправки логов не требовалось, но сами логи позволяли мне лучше понимать процессы. Из тех что отправлял, обычно это были stack trace’ы и assert’ы, хотя были случаи когда отсылал также и системные логи.

Топливо для Андроида. Избавляем свое приложение от лагов, тормозов и долгих экранов загрузки

Содержание статьи

Как появляются лаги

Перед тем как перейти к обсуждению инструментов и техник повышения производительности, уделим немного времени тому, как вообще появляются лаги и почему приложение может быть медленным. Основные проблемы современных приложений:

  • слишком долгая загрузка приложения и отдельных экранов;
  • фризы, когда приложение просто зависает, а через некоторое время появляется сообщение с предложением его убить;
  • проседания FPS, когда вместо плавной прокрутки и анимации пользователь видит слайд-шоу.


Причины всех этих проблем просты: слишком долгое выполнение каких-либо операций, вычислительных или операций ввода-вывода, а вот способы оптимизации разные.

Холодный старт

Запуск приложения состоит из нескольких стадий: это инициализация нового процесса, подготовка окна для вывода интерфейса приложения, показ окна на экране и передача управления коду приложения. Далее приложение должно сформировать интерфейс на основе описания в XML-файле, подгрузить с «диска» или из интернета необходимые для корректного отображения интерфейса элементы (битмапы, данные для списков, графиков и прочее), инициализировать дополнительные элементы интерфейса, такие как выдвижное меню (Drawer), повесить на элементы интерфейса колбэки.

Очевидно, что это огромный объем работы и следует приложить все усилия для того, чтобы выполнить ее как можно быстрее. Два главных инструмента в этом деле:

  • отложенная инициализация;
  • параллельный запуск задач.

Отложенная инициализация означает, что все, что можно выполнить позже, надо выполнить позже. Не стоит создавать и инициализировать все данные и объекты, которые только могут понадобиться приложению, в самом начале. Сначала инициализируем только то, что нужно для корректного отображения главного экрана, затем переходим ко всему остальному.

Обработку сложных и дорогостоящих операций, которые невозможно оптимизировать, а также блокируемых операций типа чтения с диска или получения данных с сервера, следует отправлять в отдельный поток и обновлять интерфейс асинхронно по завершении его работы.

Пример: у тебя есть приложение, которое должно показывать на главном экране сводку данных, полученных из интернета. Самый очевидный способ сделать это — получить данные с сервера и после этого отобразить интерфейс. И хотя Android по умолчанию не позволяет выполнять сетевые запросы в основном потоке приложения, вынуждая создавать отдельный поток для получения данных с сервера, большинство разработчиков все равно постараются сделать код последовательным.

Проблема такого подхода в том, что он вносит задержки, которые просто не нужны. Большую часть времени сетевой поток будет простаивать в ожидании данных, и это время лучше использовать для отображения интерфейса. Другими словами: сразу после запуска приложения следует создать поток, который будет получать данные с сервера, но не ожидать получения этих данных, а создавать интерфейс, используя временные заглушки вместо пока еще не принятых данных.

В качестве заглушек можно использовать пустые картинки, пустые строки, пустые списки (например, RecyclerView можно инициализировать сразу, а при получении данных просто вызвать notifyDataSetChanged() ). После получения данных с сервера их следует кешировать. При следующем запуске их можно будет использовать вместо заглушек.

Такой подход эффективно работает в отношении не только сетевых коммуникаций, но и любых задач, требующих долгих вычислений и/или ожидания данных. Например, лаунчеру необходимо немало времени, чтобы запросить у системы список установленных приложений, отсортировать его, загрузить в память иконки и другие данные. Поэтому современные лаунчеры делают это асинхронно: отображают интерфейс и с помощью фонового потока заполняют его иконками приложений.

Еще одно узкое место: формирование интерфейса из описания лайотов в XML-файле. Когда ты вызываешь метод setContentView() или inflate() объекта LayoutInflater (в коде фрагмента), Android находит нужный лайот в бинарном XML-файле (для эффективности Android Studio упаковывает XML в бинарный формат), читает его, проводит парсинг и на основе полученных данных формирует интерфейс, измеряя и подгоняя элементы интерфейса друг к другу.

Это действительно сложная и дорогая операция. Поэтому необходимо уделить особое внимание оптимизации лайотов: избегать излишней вложенности лайотов друг в друга (например, использовать RelativeLayout вместо вложенных друг в друга LinearLayout), а также разбить сложные описания интерфейса на множество более мелких и загружать их только тогда, когда в этом возникнет необходимость.

Другой вариант — перейти на язык Kotlin и использовать библиотеку Anko. Она позволяет описывать интерфейс прямо в коде, благодаря чему скорость отображения интерфейса возрастает в четыре раза, а ты получаешь большую гибкость в управлении логикой формирования интерфейса.

Фризы и проседания FPS

В Android только главный поток приложения имеет право обновлять экран и обрабатывать нажатия на экран. Это значит, что, когда твое приложение занимается сложной работой в главном потоке, оно не имеет возможности реагировать на нажатия. Для пользователя приложение будет выглядеть зависшим. В данном случае опять же поможет вынос сложных операций в отдельные потоки.

Цукерберг рекомендует:  Вакансии Game Dude

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Как снять и отправить логи при падении приложения на andro > Задать вопрос

У меня есть приложение на android которое я тестирую везде где можно и на некоторых устройствах приложение падает, но этих устройств у меня нету под рукой, и мне соответственно нужно что-бы мне на почту приходили логи ошибки. Я уже задавал два вопроса Определить причину падения приложения на телефоне android // Непонятная проблема программы android y xiaomi. И вот у меня возник закономерный вопрос, что нужно дописать своему приложению что-бы во время падения оно предлагало пользователю отправить логи мне на почту? Как сделать, что-бы эти методы отслеживания логов активировались только в момент падения приложения а не при любом удобном для них (методов) случае. Я буду очень благодарен за любую помощь, советы и само-собой критику от всех кто увидит мой вопрос. Заранее спасибо за помощь.

Снятие логов с телефона

Для того чтобы снять логи с Вашего телефона, пожалуйста, выполните следующие действия:

2. Затем откройте папку под названием “android-sdk” и запустите файл SDK Manager:

3. Установите все необходимые паки:

4. Зайдите в «Настройки» и перейдите вкладку «Все настройки».

4а. Спуститесь в самый низ и выберите пункт «О телефоне/О планшете».

4б. Теперь семь раз нажмите на «Номер сборки» своего аппарата. В процессе нажатий (после 4) у вас будет обновляться информация о том, сколько нажатий еще осталось сделать для открытия меню, которое нам нужно.

Если вы все сделали правильно и достаточное количество раз «накликали» по «Номеру сборки» должно появиться сообщение «Вы стали разработчиком!». Опять откройте вкладку «Все настройки» и теперь над пунктом «О телефоне» будет раздел «Для разработчиков»

5. Подключите свое андроид устройство к компьютеру через USB кабель и разрешите отладку (в появившемся поп-апе на устройстве):

6. Откройте папку под названием “tools” и запустите файл ddms:

7. В появившемся окне выберете свое устройство:

8. Нажмите кнопку очищения логов:

9. Запустите TD:Reborn на устройстве.

10. Выделите все пришедшие логи и нажмите кнопку копировать:

11. Полученный файл пришлите в техподдержку TD: Reborn.

Где у андроида логи?


Телефон LG P500. Иногда наглухо виснет, лечится только выдергиванием батареи. Как понять, что происходит — то ли ядро в кору выпало, то ли оболочка фризится — непонятно. Поделитесь тайным знанием, куда смотреть. Или мануалом, где про это написано.

Android Log Collector

эмулятор терминала, команда adb logcat

короче прог для просмотра логов в маркете полно. а adb это из SDK

че ты с ним делал? какая версия? у меня тоже П500, правда я почти им не пользуюсь. только звоню, и изредка в инторнеты хожу. до сих пор даже до 2.3 не обновил. да, я лентяй.

2.3.3 Проблема возникла практически с самого начала, с заводским дефолтом. Сейчас отрутовал, кучу хлама предустановленного снес, теперь виснет гораздо реже.

я вот тоже хочу 2.3, а потом рут-права, да только запуск на телефоне каких-то бинарей, сделанных кем-то меня немого напрягает.

afaik все «джейлбрейки» (или как их лучше называть?) предполагают запуск прекомпилированных блобов? я бы хотел какой-нть опен-сурцный вариант — самому собрать и проверить на наличие бэкдоров. паранойя, ага.

в /data/logger/*.log
только надо в hidden menu включить запись логов.
последовательность для входа в скрытое меню нагуглишь сам — у меня нет для этой трубы.

самому собрать и проверить на наличие бэкдоров. паранойя, ага

После перепрошивки и хардресета — не пофиг ли на бэкдоры в руте? :)

юзай adb shell, даже top -n 1 работает

adb logcat + временной лог

отладку usb — возможно можно будет подключиться через adb во время зависания по usb кабелю.

Еще смотри по времени когда виснет и жрет баттарею в BattaryGraph.

У меня тоже такое было но хитрое перепрошивание хитрой китайской прошивки вроде пока помогло, но про adb узнал уже после.

таки сначала перепрошивка, потом получение рута

Таки, наоборот. Как ты поставишь кастомную прошивку, не имея рута? И зачем тебе рут, когда в кастомных прошивках он обычно стоит изначально? :)

я хотел обновить дефолт 2.2 на дефол 2.3, получить рут, удалить говно с телефона, как сделал ТС

кто сказал что в кастомной прошивке не может быть бэкдоров?

кочнено, я исхожу из предположения, что в дефолтной прошивке нет бэкдоров :)

Droid Log Viewer

О как — у меня сегодня опять завис.

Почитал буржуйский форум попробую форматированную флешку от нокии и вставить ее, там правда про factory reset писали.

Кстати LogCat всетаки после перезагрузки ведет лог заново или я что то не так понимаю?

И adb shell во время зависания не работает. На kernelpanic кстати не похоже — на ютрубе кернел паник на этом телефоне уже видел и телефон мигает во время сего.

Хотя может это и kernel panic.

У меня тоже, где то в 16 часов. Грешил на включенную юсб отладку, но можеь оно тупо от даты зависит?

И кстати, похоже грохается именно ядро, при вставке шнура на большом брате ничего не происходит

Поставить sdk и запустить ddms, подключить по usb, там будут видны все логи.

Оке завтра на работе посмотрю. И отпишусь сюда если чо найду.

Write and View Logs with Logcat

The Logcat window in Andro >Log class. It displays messages in real time and keeps a history so you can view older messages.

To display just the information of interest, you can create filters, modify how much information is displayed in messages, set priority levels, display messages produced by app code only, and search the log. By default, logcat shows the log output related to the most recently run app only.

When an app throws an exception, logcat shows a message followed by the associated stack trace containing links to the line of code.

As of Android Studio 2.2, the Run window also displays log messages for the current running app. Note that you can configure the logcat output display, but not the Run window.

View your app logs

To display the log messages for an app:

  1. Build and run your app on a device.
  2. Click View > Tool Windows > Logcat (or click Logcat in the tool window bar).


The Logcat window shows the log messages for the selected app, as selected from the dropdown lists at the top of the window, as shown in figure 1.

Figure 1. Logcat window

By default, logcat displays just the log messages for your app running on the device. To change this default, see how to filter logcat messages.

The Logcat toolbar provides the following buttons:

  1. Clear logcat : Click to clear the visible log.
  2. Scroll to the end : Click to jump to the bottom of the log and see the latest log messages. If you then click a line in the log, the view pauses scrolling at that point.
  3. Up the stack trace and Down the stack trace : Click to navigate up and down the stack traces in the log, selecting the subsequent filenames (and viewing the correspnding line numbers in the editor) that appear in the printed exceptions. This is the same behavior as when you click on a filename in the log.
  4. Use soft wraps : Click to enable line wrapping and prevent horizontal scrolling (though any unbreakable strings will still require horizontal scrolling).
  5. Print : Click to print the logcat messages. After selecting your print preferences in the dialog that appears, you can also choose to save to a PDF.
  6. Restart : Click to clear the log and restart logcat. Unlike the Clear logcat button, this recovers and displays previous log messages, so is most useful if Logcat becomes unresponsive and you don’t want to lose your log messages.
  7. Logcat header : Click to open the Configure Logcat Header dialog, where you can customize the appearance of each logcat message, such as whether to show the date and time.
  8. Screen capture : Click to capture a screenshot.
  9. Screen record : Click to record a video of the device (for a maximum of 3 minutes).

Write log messages

The Log class allows you to create log messages that appear in logcat. Generally, you should use the following log methods, listed in order from the highest to lowest priority (or, least to most verbose):

See the Log class description for a more complete list of options.

You should never compile verbose logs into your app, except during development. Debug logs are compiled in but stripped at runtime, while error, warning, and info logs are always kept.

For each log method, the first parameter should be a unique tag and the second parameter is the message. The tag of a system log message is a short string indicating the system component from which the message originates (for example, ActivityManager ). Your tag can be any string that you find helpful, such as the name of the current class.

A good convention is to declare a TAG constant in your class to use in the first parameter. For example, you might create an information log message as follows:

Kotlin

Note: Tag names greater than 23 characters are truncated in the logcat output.

Logcat message format

Every Andro >ActivityManager ). A user-defined tag can be any string that you find helpful, such as the name of the current >Log method call, for example:

Kotlin

The priority is one of the following values:

  • V: Verbose (lowest priority)
  • D: Debug
  • I: Info
  • W: Warning
  • E: Error
  • A: Assert

The log message format is:

For example, the following log message has a priority of V and a tag of AuthZen :

PID stands for process identifier and TID is thread identifier; they can be the same if there’s only one thread.

Set the log level

You can control how many messages appear in logcat by setting the log level. You can display all messages, or just the messages indicating the most severe conditions.

Цукерберг рекомендует:  Test - помогите с тестом c++

Remember that logcat continues to collect all messages regardless of the log level setting. The setting just determines what logcat displays.

In the Log level menu, select one of the following values:

    Verbose: Show all log messages (the default).

Debug: Show debug log messages that are useful during development only, as well as the message levels lower in this list.

Info: Show expected log messages for regular usage, as well as the message levels lower in this list.

Warn: Show possible issues that are not yet errors, as well as the message levels lower in this list.

Error: Show issues that have caused errors, as well as the message level lower in this list.

  • Assert: Show issues that the developer expects should never happen.

  • Search logcat messages

    To search the messages currently displayed in logcat:

    1. Optionally select Regex if you want to use a regular expression search pattern.
    2. Type a character sequence in the search field .

    The logcat output display changes accordingly.

  • Press Enter to store the search string in the menu during this session.
  • To repeat a search, choose it from the search menu. Select or deselect Regex as needed (the setting isn’t remembered).
  • Filter logcat messages

    One way to reduce the log output to a manageable level is to restrict it by using a filter.

    Note: The filter applies to your full logcat history, not just those messages currently displayed in logcat. Make sure your other display options are set appropriately so you can see the filter output you want to examine.

    To define and apply a filter:

    1. In the filter menu, select a filter option:
      • Show only selected application: Display the messages produced by the app code only (the default). Logcat filters the log messages using the PID of the active app.
      • No Filters: Apply no filters. Logcat displays all log messages from the device, regardless of which process you selected.
      • Edit Filter Configuration: Create or modify a custom filter. For example, you could create a filter to view log messages from two apps at the same time.

    After you define filters, you can also select them in the menu. To remove them from the menu, delete them.

  • If you selected Edit Filter Configuration, create or modify a filter:
    1. Specify the filter parameters in the Create New Logcat Filter dialog:
      • Filter Name: Type the name of a filter you want to define, or select it in the left pane to modify an existing filter. The name can contain lowercase characters, underscores, and digits only.
      • Log Tag: Optionally specify a tag. For more information, see logcat Message Format.
      • Log Message: Optionally specify log message text. For more information, see logcat Message Format.
      • Package Name: Optionally specify a package name. For more information, see logcat Message Format.
      • PID: Optionally specify a process ID. For more information, see logcat Message Format.
      • Log Level: Optionally select a log level. For more information, see Set the Log Level.
      • Regex: Select this option to use regular expression syntax for that parameter.
    2. Click + to add the filter definition to the left pane.

    To remove a filter, select it in the left pane and click .

  • When you’re finished, click OK.
  • If you don’t think you see the log messages you want, try selecting No filters and searching for particular log messages.

    Read garbage collection messages

    Sometimes when a garbage collection event occurs, they’re printed to logcat.

    For more detail about your app’s memory, use the Memory Profiler.

    Dalvik log messages

    In Dalvik (but not ART), every GC prints the following information to logcat:

    GC Reason What triggered the GC and what kind of collection it is. Reasons that might appear include: GC_CONCURRENT A concurrent GC that frees up memory as your heap begins to fill up. GC_FOR_MALLOC A GC was caused because your app attempted to allocate memory when your heap was already full, so the system had to stop your app and reclaim memory. GC_HPROF_DUMP_HEAP A GC that occurs when you request to create an HPROF file to analyze your heap. GC_EXPLICIT An explicit GC, such as when you call gc() (which you should avoid calling and instead trust the GC to run when needed). GC_EXTERNAL_ALLOC This happens only on API level 10 and lower (newer versions allocate everything in the Dalvik heap). A GC for externally allocated memory (such as the pixel data stored in native memory or NIO byte buffers). Amount freed The amount of memory reclaimed from this GC. Heap stats Percentage free of the heap and (number of live objects)/(total heap size). External memory stats Externally allocated memory on API level 10 and lower (amount of allocated memory) / (limit at which collection will occur). Pause time Larger heaps will have larger pause times. Concurrent pause times show two pauses: one at the beginning of the collection and another near the end.

    While these log messages accumulate, look out for increases in the heap stats (the 3571K/9991K value in the above example). If this value continues to increase, you might have a memory leak.

    ART log messages

    Unlike Dalvik, ART doesn’t log messages for GCs that were not explicitly requested. GCs are only printed when they are deemed slow. More precisely, if the GC pause exceeds 5ms or the GC duration exceeds 100ms. If the app is not in a pause perceptible state (such as when the app is in the background, where the user cannot preceive a GC pause), then none of its GCs are deemed slow. Explicit GCs are always logged.

    ART includes the following information in its garbage collection log messages:

    GC Reason What triggered the GC and what kind of collection it is. Reasons that might appear include: Concurrent A concurrent GC that does not suspend app threads. This GC runs in a background thread and does not prevent allocations. Alloc The GC was initiated because your app attempted to allocate memory when your heap was already full. In this case, the garbage collection occurred in the allocating thread. Explicit The garbage collection was explicitly requested by an app, for example, by calling gc() or gc() . Like Dalvik, in ART the best practice is that you trust the GC and avoid requesting explicit GCs, if possible. Explicit GCs are discouraged because they block the allocating thread and unnecessarily waste CPU cycles. Explicit GCs could also cause jank (stuttering, juddering, or halting in the app) if they cause other threads to get preempted. NativeAlloc The collection was caused by native memory pressure from native allocations such as Bitmaps or RenderScript allocation objects. CollectorTransition The collection was caused by a heap transition; this is caused by changing the GC strategy at run time (such as when the app changes between pause perceptible states). Collector transitions consist of copying all the objects from a free-list backed space to a bump pointer space (or visa versa).

    This occurs only on low RAM device prior to Android 8.0 when an app changes process states from a pause perceptible state (such as when the app is in the foreground, where the user can preceive a GC pause) to a non pause perceptible state (or visa versa).

    HomogeneousSpaceCompact Homogeneous space compaction is free-list space to free-list space compaction which usually occurs when an app is moved to a pause imperceptible process state. The main reasons for doing this are reducing RAM usage and defragmenting the heap. DisableMovingGc This is not a real GC reason, but a note that collection was blocked due to use of GetPrimitiveArrayCritical. while concurrent heap compaction is occurring. In general, the use of GetPrimitiveArrayCritical is strongly discouraged due to its restrictions on moving collectors. HeapTrim This is not a GC reason, but a note that collection was blocked until a heap trim finished. GC Name ART has various different GCs which can get run. Concurrent mark sweep (CMS) A whole heap collector which frees collects all spaces other than the image space. Concurrent partial mark sweep A mostly whole heap collector which collects all spaces other than the image and zygote spaces. Concurrent sticky mark sweep A generational collector which can only free objects allocated since the last GC. This garbage collection is run more often than a full or partial mark sweep since it is faster and has lower pauses. Marksweep + semispace A non concurrent, copying GC used for heap transitions as well as homogeneous space compaction (to defragement the heap). Objects freed The number of objects which were reclaimed from this GC from the non large object space. Size freed The number of bytes which were reclaimed from this GC from the non large object space. Large objects freed The number of object in the large object space which were reclaimed from this garbage collection. Large object size freed The number of bytes in the large object space which were reclaimed from this garbage collection. Heap stats Percentage free and (number of live objects)/(total heap size). Pause times In general pause times are proportional to the number of object references which were modified while the GC was running. Currently, the ART CMS GCs only has one pause, near the end of the GC. The moving GCs have a long pause which lasts for the majority of the GC duration.

    If you are seeing a large amount of GCs in logcat, look for increases in the heap stats (the 25MB/38MB value in the above example). If this value continues to increase and doesn’t ever seem to get smaller, you could have a memory leak. Alternatively, if you are seeing GC which are for the reason «Alloc», then you are already operating near your heap capacity and can expect OOM exceptions in the near future.

    Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

    Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих