Android studio перейти к ошибке

Уже год как я начал пытаться программировать под Android, и весь год меня в этом поддерживал добрый друг Android Studio. Безусловно, я продвигался бы намного быстрее, знай зеленый я о хоткеях больше, но в свое время я не нашел цельного и понятного справочника важных горячих клавиш IDE, а посему написал его сам. В нем далеко не все комбинации, лишь те, что показались полезными в работе, за исключением Ctrl+C, Ctrl+V, Ctrl+X и Ctrl+Z. Выставляю его на суд общественности и для всеобщего пользования здесь:

• Быстрое исправление ошибок/Quick bug fix Alt+Enter

  Отображает окно с вариантами способов отображния ошибок, если таковых более одного.

• Завернуть в…/Surround with… Ctrl+Alt+T

  Список из более чем десяти опций. Тут тебе и try-catchб и if/else, и synchronized, и Runnable… Так сказать, обертка на любой вкус.

• Информация о текущем классе/Context info Alt+Q

  Название, видимость, абстрактность, родители — полное досье.

• Изменить сигнатуру/Change signature Ctrl+F6

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

  Скриншот для наглядности

  

• Недавние изменения в проекте/Recent changes Alt+Shift+C

  Не очень детально, но вспомнить поможет.

• Отобразить иерархию типов/Type hierarchy Ctrl+H

  Выводит дерево типов вплоть до самого верхнего, т.е. до того, на котором стоит указатель.

  Пример вместо тысячи слов

  

• Перейти к источнику/Jump to source F4 (Win)/CMD + down-arrow (Mac)Комментарии излишни
• Перейти к объявлению/Go to Declaration CTRL+B(Win)/CMD+B(Mac)
• Перейти к родителю/Go to Super CTRL+U(Win)/CMD+Y(Mac)
• Поиск по названию элемента/Search by symbol name CTRL + ALT + SHIFT + N (Win)/OPTION + CMD + O (Mac)

  Иногда излишне долгий, а иногда просто необходимый

• Показать документацию к API/Show docs for selected API CTRL + Q (Win)/F1 (Mac)

  Пример

  

• Показать параметры метода/Show parameters for selected method Ctrl+P

  Пример

  

• Просмотр определения элемента/Quick definition Ctrl+Shift+I

  Пример

  

• Реформаттинг кода/Reformat CTRL + ALT + L (Win)/OPTION + CMD + L (Mac)

  Позволяет оптимизировать импорты (optimise imports) и реорганизовать фрагменты кода (rearrangement entries) на уровне файла, директории или только выбранного текста. Реформаттинг кода включает в себя группировку overriden методов по классу/интерфейсу, группировку геттеров и сеттеров, а также упорядочение методов по глубине вхождения (например, если метод foo() в своем теле вызывет метод bar(), то метод bar() будет перенесен сразу под метод foo(), если это не нарушит структуру кода) и полезную мелочь типа пробела в начало склеиваемой в конец подстроки. Реорганизация достаточно гибко настраивается через File | Settings | Code Styles, выбрать Java в выпадающем списке и перейти на вкладку Rearrangement.

• Сгененрировать метод/Generate method ALT + Insert (Win)/CMD + N (Mac)

  На выбор для генерации предлагаютсяконструкторы, геттеры/сеттеры, equals(), toString и функции override method и delegate method. В общем, очень классно и полезно

  для организма.

• Build CTRL + F9 (Win)/CMD + F9 (Mac)

  Just builds.

• Build and Run SHIFT + F10 (Win)/CTRL + R (Mac)

  Not only builds.

Это самые полезные, на мой взгляд, хоткеи, которыми я пользовался или пользовался бы, знай я о них раньше. Подводя итог, Android Studio обладает большим потенциалом так называемого «невидимого интерфейса», облегчающего жизнь простых кодеров.

P.S. На заметку новичкам от новичка: Если вы привыкли к Ctrl+Z — отмене и Ctrl+Y — отмене отмены, отвыкайте! Отмена действительно Ctrl+Z, а вот отмена отмены Ctrl+Shift+Z.

Иногда в приложении встречаются ошибки, которые нельзя увидеть даже после запуска. Например, код компилируется, проект запускается, но результат далёк от желаемого: приложение падает или вдруг появляется какая-то ошибка (баг). В таких случаях приходится «запасаться логами», «брать в руки отладчик» и искать ошибки.

Часто процесс поиска и исправления бага состоит из трёх шагов:

1. Воспроизведение ошибки — вы понимаете, какие действия нужно сделать в приложении, чтобы повторить ошибку.
2. Поиск места ошибки — определяете класс и метод, в котором ошибка происходит.
3. Исправление ошибки.

Если приложение не падает и чтение логов ничего не даёт, то найти точное место ошибки в коде помогает дебаггер (отладчик) — инструмент среды разработки.

    Чтобы посмотреть на логи и воспользоваться дебаггером, давайте напишем простое тестовое (и заведомо неправильное) приложение, которое даст нам все возможности для поиска ошибок.

    Это будет приложение, которое сравнивает два числа. Если числа равны, то будет выводиться результат «Равно», и наоборот. Начнём с простых шагов:

1. Открываем Android Studio. 
2. Создаём проект с шаблоном Empty Activity. 
3. Выбираем язык Java, так как его, как правило, знают больше людей, чем Kotlin. 

Нам автоматически откроются две вкладки: activity_main.xml и MainActivity.java. Сначала нарисуем макет: просто замените всё, что есть в activity_main.xml, на код ниже:

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:app="http://schemas.android.com/apk/res-auto"
  xmlns:tools="http://schemas.android.com/tools"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  tools:context=".MainActivity">
 
  <EditText
     android:id="@+id/first_number_et"
     android:layout_width="wrap_content"
     android:layout_height="wrap_content"
     android:ems="10"
     android:gravity="center"
     app:layout_constraintLeft_toLeftOf="parent"
     app:layout_constraintRight_toRightOf="parent"
     app:layout_constraintTop_toTopOf="parent" />
 
  <EditText
     android:id="@+id/second_number_et"
     android:layout_width="wrap_content"
     android:layout_height="wrap_content"
     android:ems="10"
     android:gravity="center"
     app:layout_constraintLeft_toLeftOf="parent"
     app:layout_constraintRight_toRightOf="parent"
     app:layout_constraintTop_toBottomOf="@+id/first_number_et" />
 
  <Button
     android:id="@+id/button"
     android:layout_width="wrap_content"
     android:layout_height="wrap_content"
     android:text="Равно?"
     app:layout_constraintLeft_toLeftOf="parent"
     app:layout_constraintRight_toRightOf="parent"
     app:layout_constraintTop_toBottomOf="@+id/second_number_et" />
 
  <TextView
     android:id="@+id/answer_tv"
     android:layout_width="wrap_content"
     android:layout_height="wrap_content"
     android:text=""
     android:textSize="32sp"
     app:layout_constraintLeft_toLeftOf="parent"
     app:layout_constraintRight_toRightOf="parent"
     app:layout_constraintTop_toBottomOf="@+id/button" />
</androidx.constraintlayout.widget.ConstraintLayout>

Можете запустить проект и посмотреть, что получилось:

Теперь оживим наше приложение. Скопируйте в MainActivity этот код:

public class MainActivity extends AppCompatActivity {
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_main);
 
     final Button button = (Button) findViewById(R.id.button);
     final EditText first = (EditText) findViewById(R.id.first_number_et);
     final EditText second = (EditText) findViewById(R.id.second_number_et);
     final TextView answer = (TextView) findViewById(R.id.answer_tv);
 
     button.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
           Integer firstInt = Integer.parseInt(first.getText().toString());
           Integer secondInt = Integer.parseInt(second.getText().toString());
           if (firstInt == secondInt) {
              answer.setText("Равно");
           } else {
              answer.setText("Равно");
           }
        }
     });
  }
}

В этом коде всё просто: 

1. Находим поля ввода, поле с текстом и кнопку.
2. Вешаем на кнопку слушатель нажатий.
3. По нажатию на кнопку получаем числа из полей ввода и сравниваем их.
4. В зависимости от результата выводим «Равно» или «Не равно».

Запустим приложение и введём буквы вместо чисел:

Нажмём на кнопку, и приложение упадёт! Время читать логи. Открываем внизу слева вкладку «6: Logcat» и видим:

Читать логи просто: нужно найти красный текст и прочитать сообщение системы. В нашем случае это java.lang.NumberFormatException: For input string: «f». Указан тип ошибки NumberFormatException, который говорит, что возникла какая-то проблема с форматированием числа. И дополнение: For input string: «f». Введено “f”. Уже можно догадаться, что программа ждёт число, а мы передаём ей символ. Далее в красном тексте видно и ссылку на проблемную строку: at com.example.appdebugging.MainActivity$1.onClick(MainActivity.java:26). Проблема в методе onClick класса MainActivity, строка 24. Можно просто кликнуть по ссылке и перейти на указанную строку:

int firstInt = Integer.parseInt(first.getText().toString());

Конечно, метод parseInt может принимать только числовые значения, но никак не буквенные! Даже в его описании это сказано — и мы можем увидеть, какой тип ошибки этот метод выбрасывает (NumberFormatException).

Здесь мы привели один из примеров. Типов ошибок может быть огромное количество, все мы рассматривать не будем. Но все ошибки в Logcat’е указываются по похожему принципу: 

• красный текст;
• тип ошибки — в нашем случае это NumberFormatException;
• пояснение — у нас это For input string: «f»;
• ссылка на строку, на которой произошла ошибка — здесь видим MainActivity.java:26. 

Исправим эту ошибку и обезопасим себя от некорректного ввода. Добавим в наши поля ввода android:inputType=»number», а остальной код оставим без изменений:

...
<EditText
  android:id="@+id/first_number_et"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:ems="10"
  android:gravity="center"
  android:inputType="number"
  app:layout_constraintLeft_toLeftOf="parent"
  app:layout_constraintRight_toRightOf="parent"
  app:layout_constraintTop_toTopOf="parent" />
 
<EditText
  android:id="@+id/second_number_et"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:ems="10"
  android:gravity="center"
  android:inputType="number"
  app:layout_constraintLeft_toLeftOf="parent"
  app:layout_constraintRight_toRightOf="parent"
  app:layout_constraintTop_toBottomOf="@+id/first_number_et" />
...

    Теперь можем вводить только числа. Проверим, как работает равенство: введём одинаковые числа в оба поля. Всё в порядке:

На равенство проверили. Введём разные числа: 

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

1. Воспроизведём ошибку: да, ошибка воспроизводится стабильно с любыми двумя разными числами.
2. Подумаем, где может быть ошибка: наверняка там, где сравниваются числа. Туда и будем смотреть.
3. Исправим ошибку: сначала найдём её с помощью дебаггера, а когда поймём, в чём проблема, — будем исправлять.

И здесь на помощь приходит отладчик. Для начала поставим точки останова сразу в трёх местах:

    Чтобы поставить или снять точку останова, достаточно кликнуть левой кнопкой мыши справа от номера строки или поставить курсор на нужную строку, а затем нажать CTRL+F8. Почему мы хотим остановить программу именно там? Чтобы посмотреть, правильные ли числа сравниваются, а затем определить, в какую ветку в нашем ветвлении заходит программа дальше. Запускаем программу с помощью сочетания клавиш SHIFT+F9 или нажимаем на кнопку с жучком:

    Появится дополнительное окно, в котором нужно выбрать ваш девайс и приложение:

Вы в режиме дебага. Обратите внимание на две вещи:

1. Точки останова теперь помечены галочками. Это значит, что вы находитесь на экране, где стоят эти точки, и что дебаггер готов к работе.
2. Открылось окно дебага внизу: вкладка «5: Debug». В нём будет отображаться необходимая вам информация.

    Введём неравные числа и нажмём кнопку «РАВНО?». Программа остановилась на первой точке:

Давайте разбираться:

1. Сразу подсвечивается синим строка, где программа остановлена: в окне кода на 28-й строке и в левом окне отладчика (там даже можно увидеть, какой метод вызван, — onClick).
2. В правом, основном окне отладчика, всё гораздо интереснее. Здесь можно увидеть инстансы наших вью (answer, first, second), в конце которых серым текстом даже отображаются их id. Но интереснее всего посмотреть на firstInt и secondInt. Там записаны значения, которые мы сейчас будем сравнивать.

Как видим, значения именно такие, какие мы и ввели. Значит, проблема не в получении чисел из полей. Давайте двигаться дальше — нам нужно посмотреть, в правильную ли ветку мы заходим. Для этого можно нажать F8 (перейти на следующую строку выполнения кода). А если следующая точка останова далеко или в другом классе, можно нажать F9 — программа просто возобновит работу и остановится на следующей точке. В интерфейсе эти кнопки находятся здесь:

Остановить дебаггер, если он больше не нужен, можно через CTRL+F2 или кнопку «Стоп»:

    В нашем случае неважно, какую кнопку нажимать (F9 или F8). Мы сразу переходим к следующей точке останова программы:

Ветка правильная, то есть логика программы верна, числа firstInt и secondInt не изменились. Зато мы сразу видим, что подпись некорректная! Вот в чём была ошибка. Исправим подпись и проверим программу ещё раз.

    Мы уже починили два бага: падение приложения с помощью логов и некорректную логику (с помощью отладчика). Хеппи пас (happy path) пройден. То есть основная функциональность при корректных данных работает. Но нам надо проверить не только хеппи пас — пользователь может ввести что угодно. И программа может нормально работать в большинстве случаев, но вести себя странно в специфических состояниях. Давайте введём числа побольше и посмотрим, что будет:

Не сработало — программа хочет сказать, что 1000 не равна 1000, но это абсурд. Запускаем приложение в режиме отладки. Точка останова уже есть. Смотрим в отладчик:

Числа одинаковые, что могло пойти не так? Обращаем внимание на тип переменной — Integer. Так вот в чём проблема! Это не примитивный тип данных, а ссылочный. Ссылочные типы нельзя сравнивать через ==, потому что будут сравниваться ссылки объектов, а не они сами. Но для Integer в Java есть нюанс: Integer может кешироваться до 127, и если мы вводим по единице в оба поля числа до 127, то фактически сравниваем просто int. А если вводим больше, то получаем два разных объекта. Адреса у объектов не совпадают, а именно так Java сравнивает их.

Есть два решения проблемы:

1. Изменить тип Integer на примитив int.
2. Сравнивать как объекты.

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

if (firstInt.equals(secondInt)) {
  answer.setText("Равно");
} else {
  answer.setText("Не равно");
}

Проверяем:

Всё работает. Наконец-то! Хотя… Давайте посмотрим, что будет, если пользователь ничего не введёт, но нажмёт на кнопку? Приложение опять упало… Смотрим в логи:

Опять NumberFormatException, при этом строка пустая. Давайте поставим точку останова на 26-й строке и заглянем с помощью отладчика глубже.

Нажмём F8 — и перейдём в глубины операционной системы:

    Интересно! Давайте обернём код в try/catch и посмотрим ошибке в лицо. Если что, поправим приложение. Выделяем код внутри метода onClick() и нажимаем Ctrl+Alt+T:

Выбираем try / catch, среда разработки сама допишет код. Поставим точку останова. Получим:

Запускаем приложение и ловим ошибку:

Действительно, как и в логах, — NumberFormatException. Метод parseInt выбрасывает исключение, если в него передать пустую строку. Как обрабатывать такую проблему — решать исключительно вам. Два самых простых способа:

1. Проверять получаемые строки first.getText().toString() и second.getText().toString() на пустые значения. И если хоть одно значение пустое — говорить об этом пользователю и не вызывать метод parseInt.
2. Или использовать уже готовую конструкцию try / catch:

Теперь-то точно всё в порядке! Хотя профессиональным тестировщикам это приложение никто не отдавал: поищете ещё ошибки? 🙂

4 ответа

Лучший ответ

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

ADB = Android Debug Bridge

Все общение с подключенным устройством или эмулятором происходит через утилиту командной строки ADB (Android Debug Bridge) — данный инструмент входит в Android SDK и скачать его можно на официальной странице.

Debugger в Android Studio

Посмотреть как программа себя ведет по шагам, какие значения принимают переменные и т.д. позволяет debugger, встроенный в среду разработки Android Studio.

Что такое Stacktrace

Stacktrace — это последовательность вызовов, которая привела до определенного момента в коде. Когда приложение крэшится, то, чтобы понять почему это произошло, зачастую, достаточно открыть Logcat и посмотреть stacktrace. В нем будет информация, что, где и почему упало.

В данном примере видно, что на 63 строке в классе SingleBankConnectedFragment произошел IllegalStateException.

StackTrace и Proguard

Важное замечание — если вы обфусцировали ваше приложение и оно упало уже после этого, то логи читать чуть чуть сложнее. Есть и хорошая новость — при сборке приложения создается mapping файл, в котором указывается какие классы как стали называться. В Google play developer console например можно этот файл даже загрузить, чтобы расшифровка логов происходила автоматически.

Breakpoint

Breakpoint, или по-русски «Точка останова» — флаг, устанавливающийся на определенную строчку-инструкцию в программе. Она говорит, что в этом месте исполнение приложения надо поставить на паузу. После этого разработчик сможет посмотреть значения переменных в данный момент для поиска багов. Далее надо решить — пойти ли дальше по шагам, зайти ли внутрь очередной функции или просто возобновить исполнение.

Для того, чтобы установить Breakpoint достаточно нажать на область рядом с номером строки

Чтобы запустить программу в debug режиме, есть специальная кнопка в панели Android studio

Также можно подключиться к уже выполняющемуся процессу

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

Вычисление значений на лету

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

Также можно произвести любые вычисления в данном контексте

Подмена значений переменных на лету

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

Условный Breakpoint

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

программа остановится, только если выполнится условие для данного Breakpoint.

Layout inspector в Android Studio для дебага View

В Android Studio есть одна очень полезная вещь для дебага — Layout inspector. Он позволяет просмотреть UI открытой активности к разрезе отдельных View. Это бывает удобно, особенно если

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

Layout inspector вызывается из меню Tools -> Layout inspector

Инструмент позволяет прямо в Android studio видеть элементы интерфейса запущенного Android приложения, посмотреть свойства отдельно взятого View и увидеть целиком иерархию конкретно взятого интерфейса

Логи как средство для дебага

Когда дело касается порядка вызова методов, особенно когда методы асинхронные, бегать по коду в режиме дебага не удобно. Тогда на помощь приходят логи и android logcat. Инструмент, позволяющий получить логи из android приложения.

Разместив вывод в лог в интересующих методах можно наблюдать порядок их вызова.

Hint: для удобства и ускорения работы с логами, можно использовать Live template в Android Studio

Мой шаблон для расстановки логов с именем logs выглядит так

Log.e("!@#", "$package$.$method$:$line$");

Вывод в канал ошибок лога с тэгом !@#, что позволяет легко его отфильтровать и сообщением, которое содержит имя пакета, класс и строку.

Находясь на нужной строчке остается нажать Ctrl + J (вызов диалога добавления шаблона), написать logs и нажать Enter

И IDE сама добавит строку, вида

Log.e("!@#", "com.package.test.MyActivity:64");

Сетевой мониторинг

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

Okhttp

Okhttp — популярный HTTP клиент, который позволяет включить логирование сетевых запросов практически из коробки.

Добавляем в проект библиотеку logging-interceptor

implementation 'com.squareup.okhttp3:logging-interceptor:3.10.0'

и при конфигурировании Okhttp клиента добавляем нужный interceptor, а для того, чтобы логи не попали в релизную версию наверняка, условием добавления логирования сетевых запросов можно определить как сборка Debug версии приложения

HttpLoggingInterceptor logging = new HttpLoggingInterceptor();
logging.setLevel(HttpLoggingInterceptor.Level.BODY);
OkHttpClient.Builder builder = new OkHttpClient.Builder();
if (BuildConfig.DEBUG) {
  builder.addInterceptor(logging);
}
OkHttpClient client = builder.build();

Retrofit

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

builder.client(okHttpClient);

Fiddler, Charles и другие прокси

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

Debug обфусцированного кода

При дебаге кода после обфускации надо помнить, что номера строк и имена методов не совпадают с тем, что вы видите в исходниках. При сборке будет создан map file, который поможет соотнести stracktrace в продакшене с вашим кодом.

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