Все о функциях разработчика в вашем телефоне
Константин Иванов
Настройки, которые используются для отладки и для разработки приложений, спрятаны в вашем телефоне – спрятаны в прямом смысле слова. Многие из нас идут в соответствующий раздел меню, чтобы запустить отладку USB или переключиться к рабочему модулю ART, но кроме этого, здесь имеется целый список настроек. Большая часть никогда вам не понадобится, но разве не интересно узнать, что скрывается в недрах вашего устройства?
«Разблокируем» функции разработчика в телефоне
Как говорилось выше, эти функции изначально скрыты. Это имеет смысл, поскольку найти их просто, а большинству людей они попросту не нужны. Для того, чтобы добраться до них, идем в раздел «Об устройстве» и ищем там пункт «Номер сборки». После пяти быстрых тапов появляется диалоговое окно – теперь устройство считает вас разработчиком. Только попробуйте ничего не испортить, ладно? Ну, или делайте что хотите – тоже вариант. Так или иначе, возможность заставить ваш телефон перестать работать всегда имеется.
А теперь посмотрим на предложенные функции повнимательнее.
Настройки
- Создать отчет об ошибках. Тапаете здесь, чтобы отправить соответствующее сообщение туда, куда вы хотите. Устройство готовит нужные файлы для отправки, что занимает пару минут, после чего вы видите уведомление. Если смахнуть его, процесс остановится, а если тапнуть, сообщение отправится.
- Пароль резервного копирования. Позволяет использовать ADB для создания бэкапа и восстановления приложений и связанных с ними данных на вашем компьютере. Резервное копирование данных требует введения пароля, и без него данные не могут быть восстановлены.
- Активный режим. Выбор этого пункта позволяет вам держать экран работающим постоянно при подключении телефона кабелем к зарядному устройству или к компьютеру по USB. Не стоит использовать этот пункт без надобности, поскольку это верный способ выжечь экран.
- Выбор рабочего модуля. Именно здесь вы можете выбрать между Dalvik и ART. Последний по-прежнему находится в тестовом режиме – это явно не то, что мы увидим в Android L. С некоторыми телефонами у него настоящий антагонизм, поэтому стоит уточнить на соответствующем форуме насчет вашей модели устройства.
- Включить журнал трансляции операций HCI Bluetooth. Иногда разработчику или специалисту по безопасности требуется перехватить и проанализировать пакеты Bluetooth HCI. Включение этого пункта помещает их в файл, который находится во встроенной памяти устройства (/sdcard/btsnoop_hci.log) для восстановления. После этого их можно проанализировать программой типа Wireshark.
- Статистика процессов. Все, что вам может понадобиться узнать о запущенных на вашем устройстве процессах. Тапаете здесь, а потом на одном из пунктов. Для обычного пользователя это просто набор цифр, но для разработчика может быть весьма полезным.
- Отладка USB. То, что позволяет вашему телефону связываться с компьютером, используя Android Debug Bridge (ADB). Это требуется для использования DDMS или команд ADB.
- Отозвать авторизацию отладки USB. Когда отладка при помощи компьютера происходит в первый раз, вам нужно авторизовать его и установить пару ключей. Эта настройка отменяет данное действие и предлагает повторить его снова.
- Отчеты об ошибках. Включает опцию, которая становится видимой, когда вы зажимаете кнопку питания для сбора и отправки отчета об ошибках. Очень удобно, если вы что-то тестируете.
- Фиктивные местоположения. Эта настройка позволяет вам вручную задавать информацию о местоположении, заставляя ваш телефон думать, что он там, где его в действительности нет. Кроме читов для Forsquare, это полезно для приложений, которые используют информацию о местоположении.
- Приложение для отладки. Эта настройка позволяет вам выбрать приложение для отладки. Вам не требуется действительно подключаться к отладчику, но если вы включите его, то не будете получать сообщений об ошибках, когда останавливаетесь на точке останова. Если вы не понимаете, что это значит, тогда эта настройка вам никогда не требовалась и не понадобится. Она создана для работы со средствами разработчика, позволяющими убедиться в том, что приложение работает корректно.
- Подождите, пока отладчик. Этот пункт остается неактивным, пока вы не выберет приложение для отладки. Когда оно установлено и выбрано, то настройка просто не позволяет выбранному приложению запуститься до тех пор, пока не включится отладчик. Еще один пункт, который нужен разработчикам, но бесполезен для большинства пользователей.
- Проверять для USB. Позволяет Google сканировать приложения, которые вы поставили через ADB, на предмет вредоносного поведения. Хорошая вещь.
- Показывать касания. Выбирая этот пункт, вы будете видеть визуальный эффект, подтверждающий регистрацию касания экрана.
- Местоположение указателя. Эта настройка размещает в верхней части экрана строку, в которой выводятся координаты точки экрана, которой коснулись последней.
- Показать обновления экрана. Заставляет край «окна» вспыхивать, когда происходит обновление контекста. Раздражает безумно.
- Показывать границы макета. Отмечает края элементов в окне диалога для того, чтобы вы знали, куда нужно нажать, чтобы активировать его. Попробуйте – и немедленно выключайте.
- Написание справа налево. Изменяет ориентацию экрана для поддержки языков с правосторонним написанием
- Анимация окна: масштаб. Устанавливает скорость воспроизведения анимации окна. Чем меньше число, тем быстрее.
- Анимация перехода: масштаб. Устанавливает скорость воспроизведения анимации при переходе. Опять же, чем меньше, тем быстрее.
- Эмуляция дополнительных дисплеев. Эта настройка позволяет разработчикам имитировать различные размеры экрана. Не самая надежная вещь.
- Рендеринг принудительно. Заставляет приложения использовать аппаратный двухмерный рендеринг, если они были написаны так, чтобы не использовать его по умолчанию. Иногда творит чудеса. Иногда отправляет все к чертям. Будьте бдительны.
- Показать обновления окна. С этой настройкой любая отрисовка, производимая графической подсистемой, получает красную подсветку.
- Показывать аппаратные обновления. Выделяет аппаратные уровни зеленым при обновлении. Зачем это нужно — можете почитать здесь http://www.curious-creature.org/2013/09/13/optimizing-hardware-layers/ (на английском).
- Отладка наложения. Наложение происходит каждый раз, когда приложение запрашивает систему на отрисовку чего-либо поверх чего-то иного. Эта настройка позволяет вам видеть, когда и где это происходит, чтобы видеть, в чем проблема.
- Включить 4х MSAA. Эта настройка принудительно включает множественную выборку сглаживания (MSAA). Как и с любым другим графическим ускорителем, чем больше сглаживания, тем лучше все смотрится. Но скорость работы при этом падает.
- Строгий режим. Эта настройка заставляет экран мигать, когда приложение использует главный поток для выполнения длительной и интенсивной операции.
- Выводить использование ЦП. Размещает в правом верхнем углу небольшое окно с информацией о центральном процессоре и его использовании. Забавная игрушка.
- Профиль обработки GPU. Эта настройка может либо рисовать график на экране, либо писать его в файл. График — визуальное отображение загрузки работы графического адаптера. Еще одна вещь, на которую интересно посмотреть.
- Включить трассеровку OpenGL. Настройка, позволяющая следить за ошибками OpenGL и помещающая их в специальный файл лога по вашему выбору. Ничего такого, что стоило бы трогать большинству пользователей.
- Не сохранять операции. Эта настройка уничтожает любое приложение, как только вы закрываете его окно. Ничего хорошего из этого не выйдет, что бы там на форумах ни писали.
- Фоновые процессы. Позволяет задавать в настройках количество процессов, которые могут одновременно работать в фоне. Еще одна вещь, которую большинству из нас не стоит трогать слишком часто. Если вообще стоит.
- Показать все ANR. Эта настройка заставляет все процессы показать сообщение «Приложение не отвечает», если приложение зависло, включает фоновые процессы, которые не запускаются пользователем. Полезно, если одно приложение мешает нормально работать другому.
Понятно, что большинству пользователей все эти настройки ни на что не сдались. Кроме того, лезть туда и нажимать на пункты меню ради самого процесса — не лучшая идея. Но всегда стоит знать, что вообще можно сделать, хотя бы и просто для того, чтобы не делать этого никогда.
Надеемся, что наш рассказ просветил вас немного по вопросу этих настроек и опций, записанных непонятными словами. Кстати, в зависимости от выбранного языка системы, производителя и версии ОС Android, набор пунктов может несколько отличаться разделами и их названиями.
Источник
Уровни журнала Android
Android поддерживает различные уровни журналов, Verbose, Debug, Info, Warn и Error. Я понимаю, как работают уровни ведения журнала; Меня больше интересует типичный результат, ожидаемый для заданного уровня.
Например, при разработке приложения мне может быть любопытно, когда какой-то метод что-то делает (это часто бывает для целей отладки). Я просмотрю журналы, чтобы убедиться, что методы вызываются в ожидаемом порядке, если сетевой ответ – это то, что, как я думаю, должно быть, если парсеры найдут нужную информацию и т. Д.
Почему кто-то использует Verbose vs Debug vs Info?
С точки зрения разработчика, для первого, второго или стороннего приложения не все журналы для целей отладки? (Предполагая, что разработчики не смотрят журналы для удовольствия … Я не такой садистский)
С точки зрения потребителя, когда s *** попадает в вентилятор, и им необходимо обратиться в службу поддержки клиентов, потому что их супер важное / деловое приложение не работает, разработчик использует журнал для целей отладки.
Единственная причина, по которой я мог видеть использование подробностей или информации, – это, вероятно, операции сбора данных / хранилища данных. Если да, зачем использовать verbose vs info.
Не уверен. Если я злоупотребляю этим или если инфраструктура андроида …
Я в основном следую тому, что должен сказать Томаш Нуркевич при рассмотрении уровня ведения журнала:
ОШИБКА – случилось что-то ужасное, что нужно немедленно расследовать. Никакая система не может переносить элементы, зарегистрированные на этом уровне. Пример: NPE, недоступная база данных, критически важный случай использования не может быть продолжен.
WARN – процесс может быть продолжен, но проявляйте особую осторожность. Пример: «Приложение, запущенное в режиме разработки» или «Консоль администрирования не защищена паролем». Приложение может переносить предупреждающие сообщения, но они всегда должны быть оправданы и проверены.
INFO – Важный бизнес-процесс завершен. В идеальном мире администратор или продвинутый пользователь должен понимать сообщения INFO и быстро узнать, что делает приложение. Например, если заявка касается бронирования авиабилетов, в каждом билете должно быть только одно заявление INFO, в котором говорится: «[Кто] забронировал билет с [Где] до [Где]». Другое определение сообщения INFO: каждое действие значительно изменяет состояние приложения (обновление базы данных, внешний системный запрос).
VERBOSE – очень подробная информация, предназначенная только для разработки. Вы можете сохранять сообщения трассировки в течение короткого периода времени после развертывания в рабочей среде, но относить эти операторы журнала как временные, которые должны или могут быть отключены в конечном итоге. Различие между DEBUG и VERBOSE является наиболее сложным, но если вы поместите инструкцию регистрации и удалите ее после того, как функция была разработана и протестирована, она, вероятно, должна быть на уровне VERBOSE.
Мой самый любимый уровень – WTF (2.2+), который, как предполагается, будет означать «Какая ужасная неудача», для ситуаций, которые никогда не должны происходить.
Обычно я использую «информацию» для простых сообщений.
Источник
Ускоряем телефон в пару кликов
У вас зависает телефон при запуске приложений или сильно нагружается система?
Сегодня я расскажу, как без сторонних приложений ускорить свой смартфон. Для этого нужно включить всего пару настроек, которые находятся в режиме разработчика. Как туда попасть?
1. Заходим в главные «Настройки» — «О телефоне». Здесь несколько раз быстро нажимаете на версию MIUI, пока не появится сообщение, что вы стали разработчиком.
Для других телефонов нужно найти пункт «Номер сборки». Нажимаете несколько раз, пока не появится сообщение, что вы стали разработчиком.
2. Теперь переходим в «Расширенные настройки» на телефоне. Заходим в пункт «Для разработчиков».
3. Нажимаем «Буфер журнала» и видим, что по умолчанию стоит 256 Кб. Необходимо выставить 16 Мб.
4. Теперь ищем блок настроек «Трассировка системы» . Заходим в него и первым делом отключаем «Записывать действия приложений, доступных для отладки» . После этого открываем блок «Категории» . Здесь ищем пункт «power:Power Management» и ставим галочку — Ок.
Эти простые настройки должны ускорить ваш телефон.
А теперь предлагаю зайти в интересный блок настроек «Настройки Game Driver» Что же это за настройка?
Бывает так, что когда нагружаете свой смартфон «тяжелыми» приложениями, то он виснет?
Если у вас такое происходит зайдите в блок «Настройки Game Driver» и выставьте для «тяжелого» приложения «Game Driver» по умолчанию. После этого вы заметите, что все притормаживания и лаги исчезнут.
Этот Game Driver реально работает. Он повышает производительность телефона, когда вы используете «тяжелые» приложения или игры. Просто выберите приложение и установите по умолчанию использовать Game Driver.
Пробуйте и пишите в комментариях о полученном результате.
Источник
Русские Блоги
Журнал Android
За годы разработки Android я часто сталкиваюсь с таким явлением: в одном приложении часто используется несколько методов обработки журналов с разными стилями, что иногда сбивает с толку разработчиков. В то же время у автора часто возникают неоднозначные вопросы: существует несколько уровней журнала, какой уровень журнала используется при каких обстоятельствах? При каких обстоятельствах можно использовать журнал, как использовать журнал и почему? В Android так много журналов, как эффективно просматривать журналы? Помня об этих вопросах, автор произвел определенный вид использования журналов, основываясь на обычном опыте разработки, документах спецификации журналов компании и соответствующей информации в сети. Что касается самого основного использования и введения журнала, эта статья не будет вдаваться в подробности, я надеюсь, что эта статья может помочь некоторым людям, и я надеюсь, что большие коровы дадут лучшие мнения и предложения, которые помогут мне расти!
Основное содержание этой статьи таково:
1. Классификация журналов
1. Общий уровень журнала
Система Android предоставляет разработчикам хороший инструмент для ведения журнала android.util.Log. Существует 5 наиболее часто используемых методов, как показано ниже, а уровень вывода журнала также назначается 5 уровням по очереди:
(1) Log.v: здесь v означает многословное значение Verbose, а соответствующий уровень журнала — VERVOSE. С этим уровнем журнала будет выводиться любое сообщение.
(2) Log.d: здесь d означает Debug, а соответствующий уровень журнала — DEBUG. С этим уровнем журнала, помимо журнала уровня VERBOSE, будут выводиться оставшиеся 4 уровня журнала.
(3) Log.i: где i обозначает информацию, которая является общим информационным сообщением, а соответствующий уровень журнала — INFO. При этом уровне журнала информация VERBOSE и DEBUG не выводится, будут выводиться только оставшиеся 3 уровня информации.
(4) Log.w: w обозначает предупреждающую информацию, обычно используемую в сценариях, когда система предлагает разработчикам оптимизировать код Android, а соответствующий уровень — WARN. Этот уровень журнала будет выводить только информацию WARN и ERROR.
(5) Log.e: e обозначает информацию об ошибке и обычно используется для вывода исключений и сообщений об ошибках. Журнал этого уровня будет выводить информацию только этого уровня. Как правило, система Android будет использовать этот уровень журнала при выводе фатальной информации, такой как грубость.
2. Связанный исходный код (на основе android-26, то же ниже)
Исходный код android.util.Log.java дает четкое описание уровня журнала, а также, в свою очередь, дает метод использования. Соответствующие фрагменты исходного кода следующие:
Tip: Don’t forget that when you make a call like 21 * 22 * that when you’re building the string to pass into Log.d, the compiler uses a 23 * StringBuilder and at least three allocations occur: the StringBuilder 24 * itself, the buffer, and the String object. Realistically, there is also 25 * another buffer allocation and copy, and even more pressure on the gc. 26 * That means that if your log message is filtered out, you might be doing 27 * significant work and incurring significant overhead. 28 */ 29 public final class Log < 30 31 /** 32 * Priority constant for the println method; use Log.v. 33 */ 34 public static final int VERBOSE = 2 ; 35 36 /** 37 * Priority constant for the println method; use Log.d. 38 */ 39 public static final int DEBUG = 3 ; 40 41 /** 42 * Priority constant for the println method; use Log.i. 43 */ 44 public static final int INFO = 4 ; 45 46 /** 47 * Priority constant for the println method; use Log.w. 48 */ 49 public static final int WARN = 5 ; 50 51 /** 52 * Priority constant for the println method; use Log.e. 53 */ 54 public static final int ERROR = 6 ; 55 56 /** 57 * Priority constant for the println method. 58 */ 59 public static final int ASSERT = 7 ; 60 61 . 62 }
3. Интерпретация исходного кода
Помимо четких пояснений в примечаниях, мы также можем обратить внимание на дополнительную информацию
(1) Класс Log.java модифицируется с помощью final и не может быть унаследован. Он не имеет подклассов. В то же время он не наследует другие классы и не имеет родительского класса. Логическая взаимосвязь этого типа относительно проста и легко читается. Читатели имеют возможность прочитать исходный код и определенно получат более глубокое понимание.
(2) Видно, что уровень вывода журнала также включает ASSERT, а функция, используемая для вывода, также включает Log.wtf (. ) и т. Д. В исходном коде также упоминается, что обычно используются только пять вышеупомянутых уровней журнала. Для ASSERT Я не буду много говорить о Log.wtf () и т. Д., Просто разберитесь с ним, и нет необходимости использовать его при нормальной разработке.
(3) Уровни журнала находятся в порядке от 2 до 7. Странным явлением является то, что нет 0 и 1, и он не оценивается от 0 или 1. Что касается причин, читатели могут изучать, если им интересно.
(4) В комментарии перед именем класса также упоминается, что строка, переданная в журнал, будет потреблять системные издержки. Таким образом, мы не можем бесконтрольно использовать журнал, мы должны обращать внимание на навыки и характеристики использования.
Читатели могут узнать больше!
2. Спецификация использования журнала
У разных компаний разные требования и спецификации для использования Log.Далее я буду использовать спецификации, встреченные в ходе работы, чтобы проиллюстрировать спецификации использования Log (конечно, из комментариев к исходному коду в предыдущем разделе вы также можете увидеть некоторые подсказки. ):
1. В приложении журналы уровня VERBOSE, как правило, не допускаются. Для журналов уровня INFO и WARN разрешено печатать очень небольшой объем важной информации. Это требование в действии. На самом деле, эти три уровня часто используются в исходном коде системы. Например, Когда система печатает общую информацию об исключениях, используется журнал уровня WARN.
2. Уровень ERROR разрешается использовать только при очень серьезной ошибке.Если общая информация заключается в использовании уровня DEBUG (преимущества использования уровня DEBUG будут обсуждены позже, когда будет упомянуто Log.isLoggable ()). Когда система сообщает о критическом исключении, используется журнал уровня ОШИБКИ.
3. Запрещается распечатывать личную информацию пользователя, такую как IMEI, номер мобильного телефона, пароль, номер банковской карты и т. Д. В зарубежных странах некоторые законы также содержат строгие требования к содержанию журнала.
4. Не печатайте в журнале слишком много конкретных деталей реализации, поскольку это приведет к угадыванию дизайна архитектуры и реализации кода через журнал.
5. Детали основного алгоритма или механизма не могут быть отображены в журнале, например информация, связанная с основным алгоритмом, поток вызовов функций между приложениями и фреймворками и т. Д.
6. Запрещено печатать журнал в цикле. В условиях цикла, частых операциях, часто вызываемых интерфейсах, событиях ACTION_MOVE, повторной печати и т. Д. Использование журнала должно контролироваться. В единицу времени приложения разной природы предъявляют определенные требования к количеству журналов, и существуют определенные ограничения на размер каждого журнала. Из-за большого или частого журнала это оказывает определенное влияние на производительность приложения. Даже если есть переключатель журнала для управления выводом журнала, объединение строк потребует некоторой производительности и ресурсов.
7. Вы должны быть осторожны при печати захваченного стека исключений. Если вам не нужно распечатывать стек для определения проблемы, постарайтесь не печатать стек. Если стек действительно нужен, попробуйте контролировать частоту печати в том же стеке.
8. Старайтесь не изменять журнал, который идет с исходным кодом Android. В журнале событий категорически запрещено изменять журнал, поставляемый с исходным кодом.
9. Тег в журнале обычно называется в честь разделенного функционального модуля, и лучше использовать имя класса и имя метода в качестве префикса для информации журнала. Это сделано для облегчения позиционирования при просмотре журнала, что очень полезно для анализа проблем.
Вышеупомянутое не только включает спецификации использования, но также некоторые советы по использованию журнала. Некоторые из этих спецификаций различаются в зависимости от компании и разной степени строгости, а некоторые требуют единообразного соответствия их спецификациям. Читатели могут рассмотреть их в зависимости от конкретной ситуации.
В-третьих, просмотреть журнал в Android Studio
Android Studio предоставляет разработчикам хороший инструмент для просмотра журналов.Разработчики могут открыть представление журнала следующими способами: View> Tool Windows> Logcat или использовать комбинацию клавиш по умолчанию Alt + 6, чтобы открыть / скрыть представление Logcat. Вот краткое введение в использование этого инструмента.
1. Выберите условия фильтрации в Logcat.
На скриншоте ниже отмечены общие функции использования представления Logcat в Android Studio.Разработчики могут выбирать условия фильтрации в соответствии с реальной ситуацией.
2. Настройка цвета информации журнала.
При просмотре журналов есть небольшая хитрость: для просмотра журналов разных уровней Android Studio устанавливает разные цвета для информации журнала разных уровней. Разработчики также могут установить цвет или другие атрибуты в соответствии со своими предпочтениями, чтобы при просмотре журнала было легко различать уровень журнала, и при просмотре было ощущение иерархии. Путь настройки: Файл> Настройки> Редактор> Цвета и шрифты> Android Logcat. Как показано на скриншоте ниже:
После завершения настройки используйте следующий код для проверки
Информация журнала, напечатанная в представлении logcat, выглядит следующим образом:
Хотя разработчики могут устанавливать цвет журнала и другие атрибуты в соответствии со своими предпочтениями, автор по-прежнему рекомендует читателям стараться следовать соглашениям об общих именах, например, Журналы с уровнем ERROR часто имеют красный цвет 。
3. Описание информации журнала в Logcat
Следующий снимок экрана — это журнал, напечатанный автором, с объяснением различных полей в нем.
В-четвертых, напишите простой в использовании вспомогательный класс Log.
Базовые навыки использования журнала легко освоить, но есть еще много навыков, которые необходимо освоить, если их можно гибко использовать в проектах.
1. Сценарии, с которыми часто сталкиваются разработчики
При конкретной разработке разработчики часто сталкиваются со следующими ситуациями:
(1) При отладке часто печатается большое количество журналов, чтобы помочь в анализе проблем, но эти журналы должны быть закрыты, когда версия должна быть выпущена для пользователей.
(2) Разработчики часто устанавливают переменную в коде, например логическое isDebug и т. Д., Для управления печатью / закрытием журнала. Но каждый раз, когда вы выпускаете версию, вам нужно вручную изменять это значение, что неудобно в использовании и легко забыть.
(3) Для пользовательской версии, выпущенной для пользователей, журнал закрывается. Когда необходимо проанализировать ошибку, в журнале содержится слишком мало информации, из-за чего разработчики часто думают, что «умелые женщины не могут готовить без риса», что не способствует анализу проблемы.
(4) После получения информации журнала часто бывает непросто выяснить, к какой функции относится эта информация, к какому типу и каким методом она распечатывает.
(5) Некоторые журналы необходимо закрыть в пользовательской версии, но некоторые журналы необходимо хранить все время, и эти два типа журналов нужно обрабатывать по-разному.
Подобные обстоятельства, по-видимому, постоянно испытывают разработчики.
2. Код вспомогательного инструмента
Опытные разработчики обычно пишут вспомогательный класс Log, чтобы максимально избежать этих проблем.Автор также суммировал набор кодов во время разработки, как показано в следующем коде:
Примечание. Этот набор кода реализован в соответствии со спецификациями использования журналов компании. В настоящее время автор занимается разработкой системных приложений для мобильных телефонов. Вышеупомянутые методы обработки относительно предвзято относятся к системным приложениям, но они также практичны для чисто сторонних разработчиков приложений. .
3. Использование и описание вспомогательных классов.
(1) Распечатать основной журнал
Согласно комментариям в коде, должно быть легко понять использование и значение этих методов. Кратко продемонстрируем пример использования
Вызовите Logger.d (className, methodName, msg) в том месте, где журнал должен быть напечатан; вот и все, ниже показан выходной журнал
Вот небольшой трюк: для получения className вы можете использовать следующие методы (TAG — это имя класса во входящем Logger.d (. )):
Результатом, возвращаемым именем класса .class.getSimpleName (), будет «HandleDemoActivity». Самым большим преимуществом этого является то, что если имя класса изменится, значение также изменится. Если вы используете жестко запрограммированную эту переменную, гибкость будет больше разница.
(2) Стек вызовов функции печати printStackTraceInfo
На следующем снимке экрана показан стек вызовов функции, который очень полезен для анализа трассировки вызываемого метода. Вторая строка метода printStackTraceInfo () — это место, где стек вызовов окончательно захватывается, и трассировка вызова может быть четко видна.
(3) Распечатать информацию об исключении printExceptionInfo (Exception pEx)
Этот метод в основном используется для печати собранной информации об исключении. На снимке экрана ниже четко показана причина исключения, место его возникновения и стек вызовов. SDK также поставляется с методом e.printStackTrace (), который печатается самой системой (снимок экрана 2). Однако информация для печати делится на несколько частей информации для печати. При поиске по тегу можно искать только информацию, содержащую тег, и информация не может быть отображена в целом. Пользовательский метод преодолевает этот момент и удобен для всех. Посмотреть. Конечно, читатели могут выбирать, использовать ли функции, входящие в SDK, в соответствии со своими предпочтениями.
Снимок экрана 1: Индивидуальные распечатки отклонений от нормы
Снимок экрана 2: Аномальная печать, связанная с sdk
(4) Используйте Log.isLoggable (tagName, level)
В пункте 1 (3) данного обзора упоминается, что журнал отладочной версии закрыт в пользовательской версии, что значительно затрудняет анализ ошибки. Следовательно, в условии isTagLoggable (. ) для определения того, разрешить ли печать журнала, добавляется условие «или», Log.isLoggable (тег, уровень), которое решает проблему невозможности распечатать часть журнала в пользовательской версии.
1) Основное использование
После добавления этого условия в системе пользовательских версий просто выполните следующую команду в командном поле:
TagName в команде — это значение TAG во вспомогательном классе, то есть FunctionName. Уровень относится к нижнему пределу уровня журнала, который вы хотите вывести. Например, если уровень равен D, будут выведены все журналы с более высокими уровнями, кроме VERBOSE; если уровень E, то Будет выведен только журнал уровня ERROR. Конкретные команды для этого вспомогательного класса:
После ввода этой команды будут выведены все журналы с именем «FunctionName» в качестве имени тега и уровнем DEBUG и выше. Чтобы вернуться в состояние, не предназначенное для печати, просто перезагрузите телефон.
2) Связанный исходный код
3) Интерпретация исходного кода
Основываясь на приведенном выше исходном коде и комментариях, автор извлек некоторую информацию:
- Это собственный метод, реализованный снизу через jni.
- Когда уровень тега для запуска печати не установлен, уровень по умолчанию — INFO, то есть, если уровень в isLoggable (тег, уровень) — VERBOSE или DEBUG, isLoggable () вернет false, а другие уровни вернут true.
- Здесь можно установить другие уровни. После 5 уровней, упомянутых выше, есть ASSERT и SUPPRESS. Установите значение SUPPRESS, чтобы отключить все журналы.
- Длина строки TAG не должна быть слишком длинной. После 23 следующие строки будут обрезаны.
- Комментарий также предоставляет метод изменения системного файла, чтобы установить уровень журнала, разрешенный для печати.
Ниже приводится тестовая функция.
5) Результаты тестирования
А) Никакая команда не выполняется, результат теста:
Это доказывает, что уровень тега по умолчанию — INFO, но Log.v () — Log.e () может распечатать журнал.
Я не знаю, заметил ли читатель, что, хотя уровень по умолчанию — INFO, значение, установленное здесь командой, также является INFO, но в настоящее время сообщения Log.v () и Log.d () не выводятся.
В) Выполнение заказа
Здесь мы также видим, что значение Log.isLoggable (TAG, Log.DEBUG) по умолчанию ложно. Как мы упоминали во втором пункте, когда мы говорили о спецификации использования журнала во втором разделе, общая информация печатается с журналом уровня DEBUG в сочетании с приведенным выше вспомогательным классом журнала, вы, конечно же, можете почувствовать некоторые преимущества здесь, читатели Вы также можете использовать эти условия для разработки собственных удобных методов в соответствии с вашим собственным пониманием.
Из приведенных выше результатов теста мы также можем сделать вывод: adb shell setprop log.tag.tagName level не только изменит возвращаемое значение Log.isLoggable (tag, level), но и повлияет на Log.v () — Log.e ( ) Следует ли печатать. Читатели должны обратить внимание на эти нюансы, когда я только начинал, я их игнорировал, и они тоже были обведены -_-!
6) Рекомендуемая литература
Пять, получение журнала
После разработки стратегии ввода журнала вы можете получить журнал. В основном есть следующие способы получить журнал, с которым контактировал автор
1. Получено из средств разработки.
Например, представление Logcat, которое поставляется с упомянутой выше Android Studio, также доступно в eclipse, что проще в использовании. Этот метод в основном используется разработчиками, а тестировщики обычно не используют аналогичные инструменты в среде IDE.
2. adb поставляется с инструментом logcat
Командная функция также относительно мощна, ее очень удобно использовать, не требуется дополнительных IDE, adb настроен на компьютере, подключен к мобильному телефону, и вы можете ввести команду в поле команд. Этот инструмент также имеет множество команд и мощных функций.К сожалению, я не часто использую эту функцию. В основном я использую собственные инструменты IDE и мобильный журнал мобильного телефона.
3. Мобильный телефон имеет собственную функцию записи журнала.
Как правило, мобильные телефоны также поставляются с инструментами для записи журналов. Различные марки и модели имеют разные способы захвата системных журналов и форматов журналов. Ниже приведен пример определенной модели Biya.
(1) Введите пароль на клавиатуре набора номера (вы можете выполнять поиск в Интернете, разные бренды имеют разные пароли, и типы журналов, регистрируемых на одном мобильном телефоне, также различны), и вы войдете в интерфейс инструмента журнала, как показано ниже:
Как видите, существует множество типов журналов, которые можно сканировать, и мы открываем только MobileLog здесь. Разработчики могут выбрать открытие необходимого журнала в зависимости от реальной ситуации. До сих пор я использовал только MoboleLog, -_-
(2) Перед использованием нажмите кнопку «Очистить», чтобы очистить предыдущие файлы журналов, чтобы не создавать слишком много ненужных журналов и не влиять на просмотр полезной информации.
(3) Нажмите кнопку «Пуск», и система начнет сбор журналов.
(4) Начните управлять мобильным телефоном, воспроизводите ошибки и т. Д. Журналы, созданные в этот период, будут сохранены.
(5) После завершения операции нажмите кнопку «Закрыть», и система сгенерирует файл журнала.Внизу вы можете увидеть путь хранения журнала, просто найдите его по этому пути.
Шесть, просмотр и анализ журнала
После того, как вы получите файл журнала, вы можете проанализировать его. В средстве просмотра IDE Logcat и журнале, полученном в adb logcat, в основном доступно основное представление, поэтому я не буду здесь об этом говорить. Здесь мы в основном говорим об анализе журнала в MobileLog.
1. Структура документа
После входа в папку журнала вы увидите следующий список папок
Если MobileLog включен, перезагружая телефон или перезагружая его после паузы, будет создана новая папка журнала. Разработчики начинают анализ с самого последнего журнала повторения ошибок. После выбора папки журнала в течение определенного периода времени нажмите, и вы увидите следующий интерфейс
Как правило, мы обращаем внимание только на содержимое папки moblie (пока автор использовал только файлы в этом каталоге). После нажатия для входа отобразится список файлов журнала, как показано ниже:
2. Анализируйте файлы журналов
(1) Сводка файла журнала
Имя файла содержит модель, информацию о версии и тип журнала в файле. Как правило, нам нужно обращать внимание только на файлы сбоя и основные файлы, а иногда и на файлы системного журнала.
- Журнал сбоев собирается в файле сбоев. Сначала проанализируйте этот файл, чтобы узнать, есть ли в нем информация о сбоях, относящаяся к вашему проекту.
- Главный файл, журналы, которые мы добавили в предыдущей статье, и те, которые разрешено печатать, будут собраны в этом файле.
- Системный файл собирает системный журнал. В этом файле будет отражен журнал, поставляемый с системной структурой, и он иногда может понадобиться.
- Остальные файлы используются нечасто, и автор не встречал сцены использования оставшихся файлов.
(2) Проанализировать журнал сбоев.
В файле сбоя вы можете четко увидеть время, когда произошел сбой, процесс, вызвавший сбой, и имя пакета. Обратите внимание на время сбоя: если разница во времени между сценой и сценой, которую вы воспроизводите, велика (например, более 10 минут), это может не иметь большой корреляции с проблемой, которую вы хотите анализировать.
(3) Проанализировать основной файл журнала
Основной файл часто содержит много информации журнала. Представление logcat или журнал, записанный adb logcat, упомянутый ранее, а также различные типы журналов в разных моделях мобильных телефонов имеют в основном одинаковую базовую структуру. Одно сообщение также содержит такую информацию, как дата, время, номер процесса, номер потока, уровень журнала, ТЕГ, сообщение и т. Д. Как показано ниже:
Анализируя эти журналы, автор упоминает здесь несколько часто используемых советов:
- Выберите хороший текстовый редактор. Автор и мои коллеги в основном используют Notepad ++, который очень полезен для поиска информации.Читатели могут искать в Интернете навыки использования этого инструмента.
- В сочетании с дизайном при добавлении журнала вы можете быстро отфильтровать важную информацию на основе ключевой информации, такой как функциональные модули, имена классов и имена методов.
- Каждому приложению обычно соответствует номер процесса. Если номер процесса изменяется на полпути, это означает, что приложение аварийно завершило работу на полпути. Вы можете найти причину ошибки рядом с точкой изменения номера процесса.
- Наиболее важным моментом является просмотр большого количества журналов этого типа. Иногда вы можете не найти проблему после повторного чтения, поэтому вам придется читать ее снова и снова, искать по различным ключевым словам и, если необходимо, даже просматривать ее построчно. Так же, как для улучшения навыков письма, сначала нужно много писать, это единственный способ.
Автор также изучает и изучает навыки анализа MobileLog. Здесь мы будем медленно накапливать опыт, обобщать и медленно обновлять.
3. Анализ исходного кода
В исходном коде есть следующие коды
Исходный код также дает ровно 5 значений LOG_ID, LOG_ID_MAIN
LOG_ID_CRASH.За исключением журнала событий, остальные также находятся во взаимно однозначном соответствии. Реализация методов Log.v ()
Log.e () вызывает метод println_native (), и первым переданным значением параметра bufID также является LOG_ID_MAIN. Бывает, что журналы, выводимые этими методами, сохраняются в основном файле. . Автор не нашел четкой информации, подтверждающей связь, но автор считает, что это не должно быть совпадением, и заинтересованные читатели могут провести дальнейшие исследования самостоятельно. Кроме того, мы также можем обнаружить, что println_native () также является собственным методом, реализованным локально через jni.
Семь сторонних инструментов
В настоящее время существует множество отличных сторонних инструментов для управления журналами. Я использовал два: log4j и Tencent’s bugly, оба из которых относительно просты в использовании.
- log4j использовать данные:https://blog.csdn.net/zjclugger/article/details/51576156
- информация об использовании с ошибками:https://bugly.qq.com/docs/ Он в основном используется для записи журналов, таких как сбой / отказ в сети.
Личный совет: при использовании сторонних инструментов вы должны импортировать сторонние пакеты jar, SDK и т. Д., Что, несомненно, увеличит нагрузку на приложение. Вообще говоря, если дополнительный класс журнала, написанный вами, может легко удовлетворить желаемые требования, не используйте его. Конечно, исходя из личного опыта, нелегко реализовать такие функции, как bugly самостоятельно -_-
8. Заключение
Использование журнала — это относительно базовый навык при разработке anroid, а также очень практический навык, который постоянно используется во время разработки. Большая часть содержания этой статьи относительно проста, конечно, она также содержит некоторые моменты, которые обычно упускаются из виду, и в основном нет места для разговоров о принципах. Автор имеет относительно небольшой опыт во многих аспектах, таких как анализ MobileLog, а также постоянно учится, исследует и подводит итоги. Надеюсь, читатели дадут мне больше советов, большое спасибо!
Источник