Продвинутый дебаг в Xcode: средства отладки, про которые часто забывают

Как снять логи с iphone через xcode. Рассказ о часто игнорируемых средствах отладки кода в Xcode вроде влияния на состояние приложения и редактирование UI без перезагрузки.

Продвинутый дебаг в Xcode: средства отладки, про которые часто забывают

Senior iOS-разработчик Noveo напоминает о доступных из коробки, но часто игнорируемых разработчиками средствах отладки кода в среде Xcode: продвинутое использование брейкпоинтов, влияние на состояние приложения, редактирование UI без перезагрузки и другие техники, которые помогут ускорить отладку приложения или поиск багов.

Intro

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

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

Давайте посмотрим на процесс изнутри. Я привёл немного странный пример, но он достаточно связан с ежедневной рутиной и отлично опишет большинство кейсов. Этот код вычисляет высоту ячейки таблицы. Высота зависит от некоторых констант и параметров. Допустим, в некоторых случаях высота рассчитывается неверно. Наша задача — изучить эту функцию, например узнать значение флага showTitle в момент вычисления. Что первым приходит на ум? Правильно, поместить print() для отладки.

Запускаем проект — он у нас большой, да и Xcode неидеальный. Чаще всего происходит всем знакомая ситуация: добавили одну строчку и ждём минуту, пока соберётся. А ведь кроме сборки и запуска нужно ещё и восстановить условия, добраться до нужного экрана, воспроизвести проблему и только после этого посмотреть вывод свежедобавленного print ‘a.

Как это обычно бывает, с первого раза расставить print ‘ы в полезных местах довольно трудно. Так произошло и в этот раз. Само по себе знание о состояниии флага нам почти ни о чём не говорит, поэтому было решено добавить ещё один print с информацией об элементе, для которого производится расчёт. Затем мы пожелали переопределить некоторые значения констант и сделать исключение для одного элемента.

Код после экспериментов

И снова нас ждёт сборка, воспроизведение условий и анализ. Мне кажется, все через это проходили и, надеюсь, это — притянутая за уши история, существующая лишь как вводная для этой статьи. Справедливости ради замечу, что отладка через print ’ы сама по себе не является чем-то плохим. Порой это единственный способ отладить что-то в сложных ситуациях, например когда ошибки происходят в оптимизированном компилятором коде. Но сегодня разговор пойдёт о простых сценариях, которые чаще всего происходят во время разработки.

Breakpoints

Мы уже выяснили, что отладка через добавление вывода в консоль не совсем эффективна и нам нужен какой-то инструмент, который облегчит нам жизнь. Таким инструментом являются брейкпоинты. Все мы любим этот механизм, который представлен практически в любой среде разработки на любых платформах и языках, и пользуемся им. Где-то он реализован лучше, где-то хуже, но в целом Apple предоставила нам мощный и гибкий механизм точек останова. Однако, работая с разными людьми, я заметил, что пользуются ими в большинстве случаев исключительно для остановки программы — просто чтобы убедиться, что её выполнение пошло по запланированному сценарию. Иногда люди пользуются консолью отладки и командой po, но лишь в тех случаях, когда нужно разок выяснить состояние переменной. Я предлагаю рассмотреть дополнительные возможности отладчика, встроенного в нашу IDE, и привести примеры ситуаций, в которых они могут пригодиться.

Conditional breakpoints

Окно редактирования брейкпоинта

Начнём с очевидного: conditional breakpoints. Как ни странно, строка, позволяющая указать условия срабатывания брейкпоинта, всегда у нас перед глазами, но почему-то люди удивляются такой возможности. Для удивлённых самим наличием такого диалога — его можно увидеть, если дважды нажать на сам брейкпоинт. В эту строку можно записать любое выражение, которое может вернуть булево значение, будь то сравнение переменной из текущей области видимости или вовсе значение какого-то синглтона. Но будьте внимательны — медленно вычисляемое выражение способно существенно снизить производительность вашей программы.

Skipping

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

Actions

Но самое интересное дня нас кроется за кнопкой Add Action. Эта кнопка позволяет добавить дополнительное действие, которое будет вызвано в момент срабатывания брейкпоинта. Как вы видите, есть 6 типов действий, которыми можно дополнить брейкпоинт:

  1. Apple script. Позволяет запустить скрипт на одноименном языке.
  2. Capture GPU Frame. Для отладки приложений, использующих движок Metal, может потребоваться эта опция.
  3. Debugger command. Позволяет выполнить команду отладчика. О ней мы поговорим позже.
  4. Log-message. Позволяет вывести текстовое сообщение в лог.
  5. Shell command. Позволяет выполнить произвольную команду в среде, дефолтной для системы командной оболочки, sh/bash/zsh.
  6. Sound. Позволяет проиграть звук из динамиков компьютера, на котором запущен Xcode.

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

Log message

Редактирование брейкпоинта с экшеном Log Message

Рассмотрим чуть более подробно тип дополнительного действия «Log message».

13–14 мая, Екатеринбург, От 500 до 9500 ₽

Если мы его выберем, к нашим услугам окажется строка ввода формата сообщения. Обратите внимание, что в строке можно указывать полезные плейсхолдеры, два из которых позволяют подставить информацию о брейкпоинте и одно, самое полезное, позволяет подставить результат вычисления произвольного выражения. Таким выражением может быть переменная или любая другая конструкция используемого вами языка программирования. Но это не имеет никакого смысла, если не поставить галочку «Automatically continue after evaluating actions». Именно она в паре с любым из действий позволит нам экономить время на дебаге. Больше не нужно писать print() , пересобирать проект и ждать вечность. В любой момент времени, без перезапуска проекта вам доступен вывод в консоль отладки любой информации о ходе выполнения программы. А для знающих толк в извращениях дебаге Apple предусмотрела возможность воспроизвести выражения, используя встроенный синтезатор речи.

Shell command

Редактирование брейкпоинта с экшеном shell command

Нетрудно догадаться, что этот экшен позволяет запустить произвольную команду в стандартной оболочке терминала ОС. Как и «Log message», она позволяет вычислить результат выражения в текущем контексте и дополнить им аргументы вызова команды. Для чего это может быть полезно? Примеров использования можно придумать массу. Из реальной жизни: запуск троттлинга через Charles. Необходимо было замедлять запросы из определённой точки, при этом в остальное время соединение должно было быть полноценным. Я не успевал включать-выключать троттлинг вручную и ещё совершать действия в симуляторе. Такой трюк с брейкпоинтом и «Shell command» отлично меня выручил. В другой раз мне понадобилось изменять информацию на сервере прямо параллельно с запросом, чтобы отловить довольно странный баг. Тут тоже был кстати этот вид брейкпоинта. Особые извращенцы могут собрать конструкцию на Arduino с электрошокером и бить себя током при каждом срабатывании нежелательного кода. Шучу. Не пытайтесь это воспроизвести в реальной жизни.

Debugger command

Редактирование брейкпоинта с экшеном Debugger command

Одним из самых интересных видов экшенов я считаю «Debugger command». Этот экшен позволяет действительно безгранично влиять на отлаживаемую программу. Debugger command — это команды отладчика LLDB, а LLDB — это отладчик для проекта LLVM, который сейчас используется Apple и Xcode для сборки программ. Отладчик LLDB позволяет подключаться к процессу, прерывать выполнение программы и воздействовать на её память. Для этого отладчик имеет множество команд, некоторые из которых станут героями сегодняшнего повествования. Именно благодаря отладчику LLDB у нас в принципе есть такая замечательная возможность отлаживать программу, в частности устанавливать брейкпоинты. Начнём мы с самой известной команды — po . Наверняка многие из вас уже не раз использовали эту команду при отладке, но для меня в своё время это стало открытием, хотя я уже имел некоторый опыт в разработке под iOS на тот момент. Po — это сокращение от print object. Команда позволяет вычислить выражение из правой части от команды и распечатать в консоли результат выполнения. При этом у объекта запросится его debugDescription, если он определён, или просто description, если нет. У po существует команда-прародитель — print , или p , которая точно так же вычислит выражение и распечатает результат, но только в этом случае вам будет доступна сырая информация об объекте или скалярном типе. Обе эти команды будут компилировать введенное выражение в текущем контексте, что неминуемо замедлит выполнение кода при срабатывании брейкпоинта. К счастью, в Xcode 10.2 Apple добавили ещё одну команду отладчика — v , которая работает значительно быстрее. Она позволяет вывести в консоль значение переменной из текущей области видимости, но, в отличии от p и po , без компиляции выражения. Естественное ограничение, накладываемое этой особенностью, — вывод в консоль возможен только для хранимых свойств.

Пример использования команды «v» и её ограничений

Affecting execution flow

Такая комбинация (брейкпоинт + debugger command po + автоматическое продолжение) заменит нам описанную ранее Log message. Что же ещё мы можем сделать с помощью такой комбинации? Например, с помощью дебаггера мы можем пропустить выполнение нескольких строчек кода, будто они закомментированы. При этом вам не нужно пересобирать программу и заново воспроизводить условия. Для этого достаточно ввести thread jump —by 1 для скачка вперёд на одну строчку или же thread jump —line 44 для перехода, как вы уже могли догадаться, к 44 строчке. Но будьте осторожны — вы не можете на 100% безопасно перепрыгивать по строчкам. Дело в том, что вы можете перепрыгнуть через инициализацию некоторой переменной, и это вызовет краш. Дело осложняется тем, что Swift «ленив» по своей природе, и инициализация может происходить не там, где вам кажется. Плюс компилятор при сборке вашей программы вставляет дополнительные инструкции, например для управления памятью, пропуская которые вы рискуете получить в лучшем случае утечку, в худшем — краш.

Affecting debugger

Редактирование брейкпоинта с введенной командой

Кроме влияния на вашу программу, с помощью отладчика вы можете влиять на сам отладчик. Например, мы можем поставить брейкпоинт из брейкпоинта. Вы спросите, зачем это нужно? Бывают методы общего назначения, которые срабатывают по ряду триггеров. Например функция по отправке сообщения в аналитику может вызываться сотню раз в секунду, а нам нужно отловить именно ту отправку, которую породит нажатие на кнопку. В этом случае мы можем поставить брейкпоинт на метод нажатия кнопки и добавить команду установки брейкпоинта на произвольной строке программы в произвольном файле. Команда bp s -o -f Calc.swift -l 44 расшифровывается как breakpoint set one-shot на файл Calc.swift на строку 44. Модификатор -o или —one-shot создаст специальный тип брейкпоинта, который «живёт» ровно до момента своего срабатывания, а после исчезает. Таким нехитрым способом мы можем создавать интересные алгоритмы установки брейкпоинтов для отладки нетривиальных багов.

Other breakpoints types

Панель переключения видов левой функциональной колонки Xcode c открытым Breakpoint Navigator и несколькими брейкпоинтами

А есть ли ещё виды брейкпоинтов, о которых мы можем не знать? Конечно, есть. Xcode позволяет добавить некоторые виды брейкпоинтов, которые не относятся к какому-то конкретному файлу и строке. В Xcode есть вкладка Breakpoint Navigator, которая позволяет управлять уже созданными брейкпоинтами сквозь все файлы проекта, а также создавать новые. Внизу окна нашего IDE есть кнопка со значком плюса.

Нижняя функциональная панель левой колонки Xcode при открытом Breakpoint Navigator

Это позволяет использовать 6 дополнительных типов брейкпоинтов:

  1. Swift Exception брейкпоинт — брейкпоинт, останавливающий программу при срабатывании не перехваченного throw для Swift кода.
  2. Exception брейкпоинт — то же самое, но для мира ObjC. Может показаться, что это не актуальный в современном мире брейкпоинт, но это не так. Стоит помнить, что нам пока всё ещё нужен UIKit, написанный на ObjC, ошибки которого мы можем отловить с помощью такого вот брейкпоинта.
  3. Symbolic breakpoint — позволяет останавливать процесс выполнения программы при выполнении кода, ассоциированного с некоторым идентификатором, который Apple называет символом. О символах я расскажу чуть позже.
  4. OpenGL ES Error брейкпоинт — брейкпоинт, останавливающий программу при возникновении ошибки OpenGL при разработке соответствующих приложений.
  5. Constraint Error breakpoint — очевидно, остановит вашу программу при возникновении ошибки автолейаута.
  6. Test Failure breakpoint может вам помочь при отладке тестов.

Так как уместить в этой сессии обзор всех типов точек останова не представляется возможным, я остановлюсь только на самых часто используемых. По своему опыту — я всегда использую Exception breakpoint. Довольно часто при разработке программ я сталкиваюсь с перехваченными системными исключениями, отладить которые порой проблематично из-за крайне неинформативного call stack’а. Думаю, вы сталкивались хоть раз с такой или подобной ошибкой:

Сообщение в Debugger Console при падении приложения из-за не перехваченного исключения ObjectiveC

Exception breakpoint

Для того, чтобы сделать стек вызова более информативным, мы можем добавить Exception breakpoint. Он позволит остановить программу прямо на моменте выброса исключения и отследить цепочку событий, которые привели к такому результату. По умолчанию неперехваченное исключение вызовет аварийную остановку приложения, и в стеке вызова мы ничего полезного не увидим, т.к. исключение будет пробрасываться вверх по стеку вызова и вся информация о месте выброса будет утеряна. Exception breakpoint позволяет остановить программу в момент выброса исключения и уже привычными нами методами получить гораздо больше информации о проблеме, пройдясь по стеку вызова и просмотрев значения переменных, если это необходимо. Я считаю этот тип брейкпоинта очень полезным и использую его на всех проектах по умолчанию. Для этого в Xcode есть удобный механизм, который позволяет указать брейкпоинту уровень и хранить его на трёх уровнях:

  1. Проект.
  2. Воркспейс.
  3. Пользователь.

Просто нажмите на брейкпоинт правой кнопкой мыши и выберите Move breakpoint. Перенесённый на уровень пользователя, брейкпоинт будет доступен на всех проектах, какой бы вы ни открыли в вашем Xcode.

Symbolic Breakpoint

Окно добавления Symbolic Breakpoint

Вторым часто используемым типом брейкпоинтов является Symbolic Breakpoint. Ранее я уже писал, что этот брейкпоинт позволяет останавливать программу при выполнении кода, ассоциированного с каким-то символом, и обещал рассказать подробнее про символы. Так вот, символы — это человекопонятные идентификаторы, которые ассоциируются с тем или иным адресом в памяти. LLDB умеет маппить известные ей символы в адреса функций и наоборот. При каждой сборке проекта система создаёт особый бандл из специальных файлов в формате dSYM, которые расшифровываются как Debug Symbols. Эти файлы хранят что-то вроде таблицы, содержащей в себе некоторые адреса методов и некоторые идентификаторы, среди которых сигнатуры методов, имена файлов, смещения и номера строк. Именно благодаря этим файлам мы можем поставить брейкпоинт на строку файла, получить читаемый стек вызова или расшифровать crashlog приложения из AppStore.

Благодаря этому механизму мы можем поставить брейкпоинт на любом методе класса, зная только его название. При этом нам не нужно достоверно знать, где этот метод объявлен и доступны ли вообще нам исходные файлы. Давайте рассмотрим реальный пример. Вас перевели на новый проект, и первая задача — исправить непонятное поведение на форме ввода данных кредитной карты, когда посреди набора фокус вдруг перепрыгивал на поле ввода имени. Сходу ничего не понятно, кода много, но симптомы ясны. Для расследования необходимо понять, кто и почему инициирует смену фокуса. Можно долго читать код, искать логику в неочевидных расширениях классов, а как надоест — сделать наследника UITextField , переопределив там метод becomeFirstResponder() , поменять реализации и уже там поставить брейкпоинт. А можно за 10 секунд создать символьный брейкпоинт -[UITextField becomeFirstResponder] , и программа остановится в момент смены фокуса. По цепочке бэктрейса мы сможем легко восстановить последовательность событий, которые приводят к нежелательным результатам.

У тех, кто пользуется таким видом брейкпоинта в первый раз, наверняка возник вопрос: а что это за символ -[UITextField becomeFirstResponder] ? Это ObjectiveC-сигнатура метода установки текста для лейбла. Использование ObjectiveC обусловлено тем, что UIKit написан именно на этом языке. Пара слов для тех, кто имел мало опыта с ObjectiveC. Знак минуса обозначает, что нас интересует инстанс-метод, а не метод класса, далее в квадратных скобках записывается название класса и через пробел метод, двоеточие указывает на то, что этот метод принимает параметр. Тут можно возразить, что пример притянут за уши. Я согласен — в хорошем коде не будет десятка мест с установкой текста лейбла, но моя цель — показать, как это может работать. Давайте рассмотрим более реальный пример. Допустим, для целей отладки нам может понадобиться распечатать последовательность показа вью контроллеров. Добавляем брейкпоинт с символом -[UIViewController viewDidAppear:] , указываем дополнительное действие po NSStringFromClass([instance class]) и, конечно же, не забываем поставить галочку «Automatically continue after evaluating actions».

Мы снова вынуждены использовать ObjC, даже в дополнительной команде, так как находимся в его контексте. Что касается Swift, то символы записываются как название ClassName.methodName(param:) . Прописывать параметры не обязательно, LLDB попытается разрешить неоднозначность, если есть методы с одинаковым названием, но разными параметрами.

Рассказывая о символьных брейкпоинтах, я не могу не рассказать о возможности искать символы. Остановив программу любым способом, с помощью брейкпоинта или же просто нажав на пиктограмму паузы, мы можем воспользоваться командой image lookup -r -n и найти интересующие вас символы в вашей программе и во всех загруженных библиотеках. Это действительно делает вас чуть ли не богом дебага, потому как вы властны искать символы везде, скажем в UIKit’e, искать приватные методы, останавливать и изучать внутреннее устройство системных библиотек. Надеюсь, я убедил в вас в силе этого метода и он не раз поможет вам сэкономить время.

Поиск приватного метода в UIKite с помощью image lookup

Watchpoints

Вотчпоинты позволяют останавливать программу, когда изменяется значение переменной. Корректнее будет сказать, что этот механизм позволяет следить за изменениями памяти по заданному адресу с заданным размером, но благодаря LLDB и Xcode разработчику достаточно сделать несколько кликов. Использование вотчпоинтов будет удобным, когда за изменением переменной не следует никакого сайд-эффекта прямо после изменения, но её состояние важно для отложенных вычислений. В ряде случаев может быть непонятно, что инициирует это изменение, и вотчпоинты позволят быстро узнать это. Достаточно приостановить выполнение программы в контексте нужного класса и воспользоваться окном Variables View. Тут будут перечислены переменные в текущем фрейме, доступные к отлаживанию. В крупных проектах вычисление доступных переменных и их типов может занимать некоторое время, поэтому иногда нужно подождать несколько (десятков?) секунд перед тем, как переменные будут доступны к манипуляциям над ними. Приятным бонусом является возможность «заглянуть» внутрь объектов Objective-C: функциональность Variables View позволяет увидеть приватные переменные этих объектов. По клику правой кнопки мыши по переменной нам доступно не так много опций — мы можем изменять значение переменных скалярных типов и, собственно, добавлять вотчпоинты.

Левая колонка DebuggerView, с контекстным меню по одной из переменных

Конечно же, вотчпоинт можно установить и командой LLDB: watchpoint set variable <variable_name> , или, пользуясь функцией сокращения команд LLDB, просто: w s v <variable_name> , но помните, что переменная должна быть видна отладчику, то есть находиться в текущем фрейме. Помимо установки брейкпоинта на изменение переменной, нам доступна установка вотчпоинта на область памяти: watchpoint set expression — 0x0d78ab5ea8 . В обоих случаях при изменении содержимого памяти по отслеживаемому адресу произойдет прерывание программы. Установленные точки останова можно посмотреть командой watchpoint list или в Debugger navigator. Так как любые вотчпоинты в итоге следят за адресом памяти, они становятся неактуальны после перезапуска и не сохраняются между перезапусками приложения. Даже если вы установили брейкпоинт на изменение переменной, под капотом механизм lldb вычислил её адрес и поставил вотчпоинт по этому адресу.

Affecting state

Будем закругляться. Последнее, о чем я хотел поведать в рамках этой статьи, — влияние на состояние приложения из LLDB. До этого я говорил только об изменении состояния какого-либо объекта системы при остановке по брейкпоинту. Но что, если нам требуется приостановить программу в произвольный момент времени? Нажатие на значок паузы приводит к приостановке программы, но вот вместо привычного нам кода мы увидим код ассемблера. Так как же добраться до произвольного объекта и выполнить с ним хитрые манипуляции?

Memory graph

Панель инструментов отладчика Xcode с подсвеченной кнопкой Memory Graph

Большинство iOS-разработчиков уже с первых месяцев своей работы используют этот инструмент. Для тех, кто ни разу им не пользовался, поясню. Memory graph позволяет сделать дамп памяти программы и отобразить в виде списка и графа все экземпляры объектов, которые сейчас находятся в памяти. Зачастую этот инструмент используется для выявления утечек объектов и анализа связей, которые привели к такому результату. Но сегодня от этого инструмента нам нужна только возможность остановить программу в произвольное время, найти нужный объект и узнать его адрес. Но что мы можем сделать с этой, казалось бы, бесполезной информацией?

На самом деле — всё, что угодно. Тут нам на помощь приходит мощь ObjC. Мы можем написать [0x7fafffa54a5 setValue:[UIColor redColor] forKey:@»switchedOffColor»] — и мы уже поменяли значение цвета выключенной лампы на красный, используя стандартные методы NSObject , доступные нам из коробки. Но что, если нам недостаточно этих методов, а нужно «дёрнуть» за свои рычаги? Всё просто — мы можем использовать кастинг: [(MyLamp *)0x7fafffa54a5 powerOff] . Используя подобные техники можно воздействовать на любые сервисы, менеджеры и вью модели вашего приложения в любой момент времени. Мы можем сохранить значение этого адреса в переменную для удобства: (MyLamp *)$lamp = 0x7fafffa54a5 . Важно, что название переменной должно начинаться со знака доллара. Это переменная будет жить до полной остановки программы, то есть ей можно пользоваться не только в текущем сеансе отладки, но и при следующем прерывании программы в рамках одного запуска. ObjectiveС предоставляет поистине широкие возможности для того, чтобы похакать текущее состояние и обойти многие ограничения, но что делать с классами, доступными только в Swift? Конечно же, при попытке кастинга Swift-класса в ObjC-контексте ничего не произойдёт. К счастью, в Swift есть подобный механизм. Точнее, функция, имя которой — unsafeBitCast . Мы вправе использовать его с адресом: unsafeBitCast(0x7fafffa54a5, to: MySwiftLamp.self) и получить экземпляр класса MySwiftLamp по адресу. Помните, её использование небезопасно, о чём нам намекает её имя, и её крайне осторожно нужно применять в коде приложения. Хотя, когда вам осознанно нужно будет использовать эту функцию, вы будете достаточно опытны для таких предупреждений.

View Hierarchy

Панель инструментов отладчика Xcode с подсвеченной кнопкой View Hierarchy

Рядом со инструментом Debug Memory Graph соседствует другой, не менее полезный инструмент, — View Hierarchy. Он позволяет быстро найти нужную View, посмотреть её параметры и лейаут, посмотреть активные и неактивные констрейнты. С iOS 11 этот инструмент ещё научился отображать ViewController’ы в иерархии, таким образом находить нужную View стало легче. Неочевидным тут является возможность фильтрации по имени и возможность отключить/включить отображение View, скрытых за экраном. Также я обратил внимание, что редко кто пользуется панелью управления внизу окна визуального отображения View.

Панель инструментов отладчика View Hierarchy

Кроме того, что она может регулировать глубину просмотра иерархии, она позволяет указать «включить отображение обрезанного контента» и «включать отображение констрейнтов». Обязательно поиграйтесь со всеми инструментами, я уверен — вы найдете полезное для себя применение для некоторых из них. Но в рамках этого рассказа нам нужна только возможность найти нужную View и узнать её адрес. Далее действуем по накатанной: po unsafeBitCast(0x7fafffa54a5, to: UIView.self) , но в таком случае мы получим ошибку. Мы сейчас находимся в контексте ObjectiveC и не можем использовать po со Swift-кодом. Мы вынуждены использовать команду expession, или просто e с указанием языка: e -l Swift — unsafeBitCast(0x7fafffa54a5, to: UIView.self) , но и тут наши попытки не увенчаются успехом, мы получим ошибку error: <EXPR>:3:35: error: use of unresolved identifier ‘UIView’ . Это произойдет из-за модульной природы Swift’а. Для успешного выполнения операции нам потребуется сделать импорт модуля UiKit: e -l Swift — import UIKit , и после этого мы наконец добьёмся результата: e -l Swift — unsafeBitCast(0x7fafffa54a5, to: UIView.self) .

Ура! Мы получили описание в консоли. Теперь давайте попробуем поменять, скажем, цвет её бэкграунда. Для начала сохраним View в переменную, чтобы облегчить процесс доступа к ней. Как и в случае с ObjectiveC, при создании переменной в LLDB контексте её название должно начинаться со знака доллара: e -l Swift — let $view = unsafeBitCast(0x7fafffa54a5, to: UIView.self) , далее мы можем применить необходимые изменения: e -l Swift — $view.backgroundColor = .red . Чтобы увидеть изменения, необходимо продолжить выполнение программы. Но есть способ увидеть изменения и без этого, находясь в режиме «паузы». Дело в том, что мы не видим изменения не потому, что приложение приостановлено, а потому, что все изменения UIView копятся в транзакцию CALayer и применяются только в конце «вращения» текущего RunLoop’а с помощью вызова CATrasaction.flush() . Когда приложение приостановлено для отладки, операционная система всё ещё живёт своей жизнью, вы можете свернуть это приложение и открыть другое. Операционная система всё ещё опрашивает состояние UI вашего приложения и отрисовывает ваше приложение несколько десятков раз в секунду, только RunLoop приостановлен, CATrasaction.flush не вызывается, изменения не применяются. Да, достаточно сделать вызов e -l Swift — CATrasaction.flush() , и мы увидим изменения.

На этом пора завязывать. Надеюсь, приведённые примеры кому-то облегчат жизнь, сохранят время и нервы. Добавьте в закладки, и в следующий раз, когда на поиск и отладку очередного бага у вас будет уходить более 15 минут, загляните в эту статью — возможно, какой-нибудь приём вам пригодится.

Демистификация аварийных журналов iOS

Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!

Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?

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

В этом уроке вы узнаете, как выглядят аварийные журналы, а также как получить аварийный журнал из iOS-устройства и iTunes Connect. Вы узнаете о символизации и о том, как вернуться от аварийного журнала назад, в код. Мы также займёмся отладкой приложения с ошибками, которые могут привести к сбою в определенных ситуациях.

Что это за аварийный журнал и где его взять?

Когда приложение «падает», то есть аварийно завершает свою работу на устройстве iOS, операционная система создает отчет о сбое или аварийный журнал. Этот журнал сохраняется на устройстве.

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

Есть много способов, как получить аварийный журнал с устройства.
Устройство, которое синхронизируется с iTunes, хранит свои аварийные журналы на ПК. В зависимости от ОС, вот места, где их можно найти:

В этом журнале куча таинственных вещей. Давайте пройдемся по его разделам:

(1) Информация о процессе

  • Incident Identifier — уникальный идентификатор журнала сбоя.
  • CrashReporter Key — тоже уникальный ключ, который связан с идентификатором устройства. Хотя он анонимизирован, он дает вам очень полезную информацию: если вы видите, что все ваши 100 аварийных журналов имеют один и тот же параметр CrashReporter Key (или только два разных), это означает, что эта проблема — не широко распространенная проблема, а ограничена только одним или несколькими устройствами.
  • Hardware Model — тип устройства. Если вы получаете много аварийных журналов от одной и той же модели устройства, это может означать, что ваше приложение не работает должным образом с конкретной моделью. В нашем примере это iPhone 4S.
  • Process — имя приложения. Число в квадратных скобках – это идентификатор процесса приложения в момент сбоя.
  • Следующие несколько строк должны быть понятны и так.

(2) Основная информация

Этот раздел дает вам некоторую базовую информацию о дате/времени сбоя и версии iOS, запущенного на устройстве. Если у вас много журналов сбоев от iOS 6.0, это может означать, что эта проблема специфична для iOS 6.

(3) Исключение

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

(4) Трассировка потоков

Этот раздел содержит трассировку для всех потоков приложения. Трассировка представляет собой список всех активных фреймов в момент сбоя. Мы видим, какие функции вызывались, когда произошёл сбой. Рассмотрим следующую строку:

  • Номер фрейма — в данном случае, 2.
  • Название модуля — в этом случае, XYZLib.
  • Адрес функции, которая была вызвана — в данном случае, 0x34648e88.
  • В четвертой колонке две части, базовый адрес и смещение. Тут это 0×83000 + 8740, где первое число указывает на файл, а вторая — на строку кода в файле.

(5) Состояние потока

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

(6) Дамп памяти

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

Демистификация с помощью символизации

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

Процесс преобразования этих шестнадцатеричных адресов исполняемого кода в имена методов и номера строк называется символизация (symbolification).

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

Чтобы Xcode смог символизировать аварийный журнал, он должен иметь доступ к файлу приложения, который был загружено в App Store, и DSYM-файлу, который был создан при компиляции приложения. Тут должно быть точное соответствие версий, в противном случае аварийный журнал не может быть полностью символизирован.

То есть, важно сохранять каждую сборку, которую вы распространяете среди пользователей. Когда вы архивируете ваше приложение перед отправкой, Xcode сохраняет откомпилированный файл. Вы можете найти все архивы вашего приложения в Xcode Organizer, вкладка Archives.

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

Если вы используете пункт меню Build and Archive, файлы будут сохранены в нужном месте автоматически.

Сбои, вызванные нехваткой памяти

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

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

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

В аварийных журналах, созданных при нехватке памяти, нет раздела с трассировкой потоков приложения. Вместо этого, есть отчёт об использовании памяти каждым процессом с указанием количества страниц памяти. (На момент написания документа – одна страница равняется 4 Кб.)

Пометка (jettisoned) рядом с названием процесса говорит о том, что процесс был завершён iOS, чтобы освободить память. Если такая пометка около вашего приложения, это означает, что ваше приложение было аварийно остановлено, так как использовало слишком много памяти.

Журнал сбоя, вызванного нехваткой памяти выглядит примерно так:

Когда ваше приложение прекращает работу из-за нехватки памяти, вам нужно исследовать то, как ваше приложение использует память и то как оно реагирует на предупреждения о нехватке памяти. Вы можете использовать утилиту Instruments, профили Allocations и Leaks, чтобы обнаружить утечки памяти. Если вы не знаете, как использовать эти инструменты, почитайте это руководство для начала.

И не забывайте о виртуальной памяти! Профили Leaks и Allocations утилиты Instruments не отслеживают графическую память. Вам необходимо при запуске профиля Allocations просмотреть данные профиля VM Tracker, чтобы узнать об использовании графической памяти.

Профиль VM Tracker по-умолчанию отключен. Для профилирования вашего приложения с VM Tracker, выберите строку с названием профиля VM Tracker в запущенной с профилем Allocations утилите Instrument, там поставьте флаг Automatic Snapshotting или просто нажмите кнопку Snapshot Now.

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

Коды исключений

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

Код исключения указывается в разделе № 3 (Исключение), см. приведенный выше пример. Есть несколько кодов исключений, которые могут возникнуть чаще, чем остальные.

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

Вот некоторые из наиболее распространенных кодов исключения:

  • 0xbaaaaaad: Читается как «плоооохой». Код говорит о том, что это не аварийный журнал, а это stackshot – журнал, содержащий состояние стека системы в данный момент. Чтобы получить stackshot, нажмите одновременно на кнопку Home и любую клавишу регулировки громкости. Часто эти журналы создаются пользователями случайно и не указывают на ошибку.
  • 0xc00010ff: Читается как «cool off» (остынь). Код говорит о том, что приложение было принудительно закрыто операционной системой в ответ на тепловое событие (стало горячо или холодно). Это может быть вызвано проблемой с конкретным устройством, или состоянием окружающей среды.
  • 0x8badf00d: Читается как «ate bad food» (ели плохую еду). Этот код значит, что приложение было прекращено iOS по таймауту. Обычно это происходит из-за того, что время, которое потратило ваше приложение на запуск, останов или отклик на системные события было больше, чем нужно.
  • 0xbad22222: Этот код означает, что ваше VoIP-приложение была прекращено iOS из-за слишком частых обращений.
  • 0xdead10cc: Читается как «deadlock» (тупик). Код означает, что ваше приложение, находясь в фоновом режиме, занимало какие-нибудь системные ресурсы (вроде базы данных адресной книги).
  • 0xdeadfa11: Читается как «deadfall» (западня). Код значит, что приложение было принудительно закрыто пользователем. Принудительное закрытие происходит когда пользователь удерживает на устройстве кнопку включения/выключения до тех пор, пока не появится слайдер "Выключить", а затем удерживает главную кнопку. Согласно документации Apple, принудительный выход является причиной исключения с кодом 0xdeadfa11, потому, что приложение к тому моменту перестало отвечать.

В омут головой!

Теперь у вас есть вся основная справочная информация, чтобы нырнуть в омут аварийных журналов, а также исправить некоторые неприятные ошибки! Теперь основной сценарий развития событий:
Вы только что начали работу в Rage-O-Rage LLC. У компании есть хорошо продаваемое в App Store приложение — Rage Masters.

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

Вы можете скачать исходный код приложения отсюда.

  • Загрузите исходный код и откройте проект в Xcode.
  • Подключите авторизированное iOS-устройство с корректным профилем (Provisioning Profile).
  • Выберите iOS-устройство, а не Simulator в качестве цели на панели инструментов Xcode и запустите приложение.
  • Как только на устройстве вы увидите экран приложения по-умолчанию (полноэкранное изображение приложения), нажмите кнопку остановки в Xcode.
  • Закройте Xcode.
  • Запустите приложение непосредственно на устройстве.
  • Протестируйте описанные ниже сценарии, затем подключите устройство к ПК и получить аварийные журналы из Xcode.

Сценарий 1. Плохой код на завтрак

Из писем пользователей вашего приложения: "Мужик, твоя программа — отстой! Я скачал её на свой iPod Touch, iPhone и iPod Touch моего сына. На всех устройствах, она упала сразу после запуска. "
Другое письмо: "Я загрузила вашу программу, но она не запускается. Я в печали. "
Следующее письмо более конкретное: «Я не могу запустить вашу программу. Я скачал её на все мои устройства и все устройства моей жены. На всех устройствах программа вываливается при запуске. "

Да ладно, не принимайте близко к сердцу! Как любой из этих комментариев даст вам подсказку? Взгляните лучше в аварийный журнал:

Нашли в чем проблема? Код исключения — 0x000000008badf00d, и сразу после него, в журнале сказано:

Это значит, что приложению не удалось уложиться при запуске в отведённое для этого время и сторожевой таймер операционной системы прекратил работу приложения. Круто! Вы нашли причину, но почему (и что ещё более важно, где) это происходит?

Смотрим дальше журнал. Трассировку потоков принято читать в обратном порядке, снизу вверх. Самый последний фрейм (25 фрейм: libdyld.dylib) – это первый вызов, затем фрейм 24, Rage Masters, main (main.m:16) и так далее.
Нам интересны фреймы, которые связаны с кодом вашего приложения. Так что игнорируйте системные библиотеки и фреймворки. Вот эта строчка нам интересна:

Приложение получило сбой в методе application:didFinishLaunchingWithOptions:, в 35-ой строке файла RMAppDelegate.m (RMAppDelegate.m: 35). Откройте Xcode и посмотрите на эту строку:

Да, вот оно! Синхронный вызов веб-сервиса? В главном потоке? В application:didFinishLaunchingWithOptions. Кто писал этот код?

Во всяком случае, теперь это ваша работа — исправить это. Этот вызов должен быть асинхронным, а еще лучше, должен быть выполнен в другой части приложения, после того как application:didFinishLaunchingWithOptions: вернёт YES.

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

Сценарий 2. Где эта кнопка?

Пользователь пишет: "Я не могу отметить моего любимого персонажа закладкой. Когда я пытаюсь это сделать, приложение падает. ".
Другой пользователь: "Закладки не работают. Я вхожу в Подробную информацию, нажимаю на кнопку «Закладка» и БА-БАХ!"

Эти жалобы о многом не говорят, и существует куча причин, почему программа так себя ведёт. Посмотрим в аварийный журнал:

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

Обычно этого не происходит, так как если вы вызываете метод "foo" объекта "bar", то компилятор выдаст ошибку, что метод "foo" не существует. Но когда вы косвенно вызываете метод используя селектор, компилятор не сможет определить, существует или нет метод у объекта.

Вернёмся к аварийному журналу. Он говорит, что аварийный останов произошёл в потоке №0. Это значит, что у нас, скорей всего, ситуация, когда метод был вызван объектом главного потока, там где объект не реализует метод.

Если вы продолжите читать журнал трассировки, вы видите, что единственный вызов, связанный с вашим кодом – это фрейм 22, main.m: 16. Это не особенно помогло.
Посмотрим на вызовы фреймворков, и видим это:

Это не ваш код. Но по крайней мере, есть подтверждение, что был вызов нереализованного метода объекта.

Идём в RMDetailViewController.m, где реализована кнопка закладок. Найдём код, который делает закладку:

Тут всё выглядит нормально, так что проверим сториборд (XIB файл) и убедимся, что кнопки подключены правильно.

Вот оно! В MainStoryboard.storyboard, кнопка связана с bookmarkButtonPressed: вместо bookmarkButtonPressed (обратите внимание на двоеточие в конце, которое говорит о том, что у метода есть параметр). Чтобы это исправить, замените название метода на такой:

Конечно, вы можете просто удалить связь с неправильным методом в XIB-файле и связать событие к правильным методом. В любом случае сработает.
И вот ещё одна причина аварийного останова устранена.

Сценарий 3. Закладкой больше, закладкой меньше.

Ещё одна жалоба от пользователя: "Я не могу удалить закладку на персонажа из окна закладок. ". И ещё одно письмо о том же: "Если я пытаюсь удалить персонажа из закладок, приложение падает. "

К этому моменту, вы уже привыкли, что письма от пользователей не бывают полезными. К аварийным журналам!

Этот журнал очень похож на предыдущий аварийный журнал. Тут тоже SIGABRT исключение. Может тут та же причина: отправка сообщения объекту, у которого не реализован метод?

Давайте посмотрим трассировку, какие методы вызывались. Начните с нижней части. Последний вызов на ваш код в Rage Masters был в фрейме №6:

Это вызов метода UITableViewDataSource. И что? Если вы не уверены, что компания Apple реализовала этот метод — можете переписать его, но не похоже, что это так. Кроме того, это дополнительный, не обязательный метод делегата. Так что проблема не в вызове нереализованного метода.

Посмотрим на фреймы дальше:

В фрейме №5, UITableView вызывает другой собственный метод, deleteRowsAtIndexPaths:withRowAnimation: а потом вызывается _endCellAnimationsWithContext:, который выглядит как внутренний метод Apple. Затем, происходит исключение фреймворка Foundation, handleFailureInMethod:object:file:lineNumber:description:.

Если собрать это вместе с жалобами пользователей, то это выглядит так, как будто вы имеете дело с ошибкой в процедуре удаления UITableView. Идём в Xcode. Вы знаете, куда идти? Может ли это сказать нам аварийный журнал? Смотрим строку №68 в RMBookmarksViewController.m:

Нашли, где проблема? Я буду ждать, пока вы не найдёте.

Кто-то забыл про источник данных! Код удаляет строку в представлении, но не меняет источник данных. Чтобы это исправить, замените код на следующий:

Вот так будет с каждой ошибкой! Бац! Бах! Бум!

Сценарий 4. Леденец

Письмо: "Мое приложение падает, когда персонаж лижет леденец. ". Другой пользователь: "Я нажимаю кнопку «Лизнуть леденец» несколько раз, а затем приложение вылетает!"

Вот аварийный журнал:

Этот журнал очень отличается от тех, что мы видели до сих пор!

Это аварийный журнал нехватки памяти iOS 6. Как уже говорилось ранее, аварийный журнал нехватки памяти отличается от других аварийных журналов, потому что он не указывает на конкретный файл или строку кода. Вместо этого, он рисует картину, сложившуюся в памяти устройства в момент ситуации, которая привела к аварийному останову.

Заголовок, впрочем, похож на заголовок обычного аварийного журнала: те же поля Incident Identifier, CrashReporter Key, Hardware Model, OS Version и другие.

  • Free pages – количество свободной памяти в страницах. Каждая страница соотвествтвует примерно 4КБ, поэтому наш журнал говорит о свободной памяти в размере около 3 872 КБ (или 3,9 МБ).
  • Purgeable pages – часть памяти, которая может быть очищена от предыдущего использования и снова использована. В нашем журнале её 0 КБ.
  • Largest process – имя приложения, которое использовало самое большое количество памяти на момент аварийного останова, и там написано наше приложение!
  • Processes — список процессов, а также как они использовали память во время аварии. Тут имя процесса (первый столбец), уникальный идентификатор процесса (второй столбец) и количество страниц, используемых в процессе (третий столбец). В последнем столбце (State), вы видите состояние каждого приложения. Как правило, приложения, которые привели к аварийному останову находятся в состоянии frontmost. И тут наш Rage Masters, который использует 28591 страниц (или 114 364 МБ) — это много памяти!

Как правило, самый большой процесс и процесс в состоянии frontmost – это один и тот же процесс, а также это тот процесс, который привел к аварийному останову из-за нехватки памяти. Но вы можете увидеть некоторые случаи, когда крупнейшие процессы и процессы в состоянии frontmost – это не то же самое. Например, если вы видите, что больше всего памяти потребляет процесс SpringBoard, можете игнорировать его, потому что SpringBoard — это главный процесс, отвечающий за главный экран в Apple iOS. С него запускаются и загружаются все установленные приложения. Он всегда активен.

При нехватке памяти iOS посылает предупреждение о низком уровне памяти активному приложению и завершает фоновые процессы. Если активное приложение продолжает увеличивать использование памяти, iOS завершает его.

Чтобы найти причину проблем с нехваткой памяти, необходимо профилировать приложение, используя утилиту Instruments. Если вы не знаете, как это делать, есть учебник. Вместо этого, мы решим проблему «в лоб», просто обработаем в нашей программе событие о нехватке памяти.
Перейдите в Xcode в RMLollipopLicker.m. Это там реализован контроллер представления лизания леденца. Взгляните на исходный код:

Когда пользователь нажимает кнопку запуска, приложение запускает в фоновом режиме процедуру lickLollipop несколько раз, а затем обновляет на экране количество лизаний. lickLollipop читает большую строку NSString из PLIST-файла и добавляет её в массив. Эти данные не критичны, и могут быть воссозданы, не влияя на работу пользователей.

Заведите хорошую привычку — пользоваться любой ситуацией, когда можно очистить данные, которые можно потом восстановить без ущерба для пользователей. Так вы освобождаете память, что делает вероятность появления предупреждений о нехватке памяти менее вероятной.
Итак, как можно улучшить код в нашем случае? Реализовать didReceiveMemoryWarning и избавиться от данных в массиве lollipops:

И всё будет хорошо!

Что дальше?

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

Xcode уроки. Урок 1. Интерфейс IDE Xcode и шаблоны

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

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

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

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

Краткое описание IDE Xcode

Компания Apple создала мощные наборы инструментов для разработчиков ПО. Все эти инструменты объединены в одном приложении под названием Xcode, который позволяет разработчику создавать, тестировать, развертывать и распространять приложения.

Xcode – это интегрированный программный продукт компании Apple для разработки программного обеспечения для платформ: iOS, macOS, WatchOS и tvOS. Xcode уникален и поддерживает целый ряд технологий, он содержит все, что необходимо разработчику: интуитивно понятный редактор кода с подсветкой синтаксиса, расширенные возможности отладки программ, простой, но многофункциональный интерфейс и многое другое.

Xcode поддерживает языки программирования: C, C++, Objective-C, Java, AppleScript, Python, Ruby, ResEdit и Swift, с различными моделями программирования, включая, но не ограничиваясь, Cocoa, Carbon и Java. Сторонние разработчики добавили поддержку GNU Pascal, Free Pascal, Ada, C#, Perl и D.

Самая первая версия Xcode была выпущена в 2001 году, с тех пор было выпущено целых 9 версий этой программы, которая распространяется в Apple Store абсолютно бесплатно для разработчиков. На сегодняшний день, 9 версия Xcode – это самая свежая стабильная версия. С момента выхода первой версии данной IDE в 2001 году, среда разработки менялась в положительную сторону. Внедрялись новые технологии и наборы инструментов, которые помогали разработчику в процессе создания приложений.

Interface Builder

Interface Builder – Это интерфейсный редактор, который позволяет проектировать и создавать полный пользовательский интерфейс мобильных приложений. Является составной частью IDE Xcode. Компания Apple позаботилась о том, чтобы интерфейс Xcode был дружелюбен и понятен:

1

На рисунке цифрами обозначены отдельные элементы программы:

  1. В левом краю расположен Project Navigator (навигатор проекта), где отображаются все файлы проекты, которые могут содержать программный код или какие-либо настройки.
  2. Слева в Interface Builder располагается схема документа, где можно посмотреть все визуальные элементы, добавленные в окно приложения, которые будут отображаться на экране устройств. Нажав на стрелочку рядом с «View Controller», можно увидеть иерархию элементов на текущем «экране». На рисунке 3.1 всего один View Controller с одним пустым View.
  3. Данная стрелка расположена слева от главного окна View Controller и указывает на то, что данный лист или «экран» является входным, то есть появляется при первоначальной загрузке приложения на устройстве или эмуляторе.
  4. Внизу Interface Builder видны надписи «w Any», «h Any». Эти надписи значат, что в данный момент редактируется внешний вид приложения, которое будет работать в интерфейсе любого размера.
  5. Наверху маленькие иконки отображают, соответственно, окно самого View Controller’а, First Responder, Exit.
  6. Внизу справа Interface Builder’а четыре иконки для Auto Layout.
  7. Справа вверху Interface Builder’а располагается Inspectors (инспекторы) для выбранного вами элемента. Здесь легко можно настраивать атрибуты элементов интерфейса, таких как: шрифт, размер текста, цвет текста, тени и т.д.
  8. Внизу в панели справа находится библиотека объектов (Libraries), в которой отображаются различные элементы интерфейса, которые можно использовать в проекте.

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

Настройки проекта Xcode и файлы проекта

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

Файл проекта «AppDelegate.swift» содержит в себе специальный программный код с функциями. Этот файл является важным и содержит следующие некоторые методы:

1) Методы, необходимые для конфигурации и загрузки приложения в память;

2) Методы, которые должны вызываться при сворачивании приложения или, например, при входящем звонке;

3) Методы, которые срабатывают при переходе в фоновый режим работы приложения;

4) Методы обновления информации приложения при переходе в активный режим работы;

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

Файл проекта «ViewController.swift» содержит в себе основной программный код любого приложения, написанного в Xcode.

Файл проекта «Main.storyboard» является основным при создании интерфейса приложения, ведь именно в нём содержится информация о расположении различных элементов (текстовых полей, кнопок, количества окон и др.). Из библиотеки объектов легко можно перетаскивать элементы будущего интерфейса (label, button, text field и многие др.) и помещать на экран приложения.

Например, на рисунке можно увидеть, что на главном экране приложения добавлены из библиотеки: два TextField, три Lable, Button и Switch. К этим элементам можно привязывать код или выводить какую-либо информацию, а также изменять их размеры, перемещать и менять различные свойства: цвет, шрифт и т.д.

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

Файл проекта «images. xcassets» содержит в себе иконки и изображения, которые в дальнейшем будут использоваться в проекте.

Файл проекта «LaunchScreen.xib» – это то, что показывается пользователю при загрузке приложения. Здесь можно добавлять любые элементы из библиотеки объектов, которые будут создавать общий вид, являющийся, по сути, загрузочной заставкой приложений.

Создание проекта и шаблоны в Xcode

Создать проект в среде Xcode несложно. Чтобы это сделать, необходимо запустить Xcode и выбрать «Create a new Xcode project» на первоначальном экране приветствия.

Apple предоставляет по умолчанию множество различных шаблонов проектов для iOS, каждый из которых полезен для начала работы над различными проектами:

Шаблон Single View Applications самый простой и является отправной точкой для многих приложений. Создаётся совершенно пустой интерфейс, который может изменяться разработчиком по своему усмотрению.

Шаблон Master-Detail App подходит, если планируется, что приложение будет активно использовать элемент UITableView. По умолчанию Xcode создаёт проект, который имеет вид таблицы, куда пользователь может добавить строку, используя в правом углу панель навигации.

Шаблон Page-Based Application создаёт страницу-книгу, позволяя пользователю перелистывать страницы. Такой шаблон подходит, если планируется создать приложение, которое отображает информацию в книжном формате, т.е. пользователь будет просматривать страницы свайпом влево или вправо.

Шаблон Tabbed Applications создаёт панель вкладок и две готовые вкладки. При переключении вкладок происходит переход к разным частям приложения.

Шаблон Games позволяет создавать игры, используя технологии Apple OpenGL ES, GLKit, Scene Kit и Metal.

Для создания базового приложений подойдёт шаблон Single View. После того, как шаблон выбран, необходимо нажать кнопку «Next» для перехода на следующее окно:

2

Далее необходимо заполнить поля:

3

Product Name (Название продукта) – название будущего приложения. Название проекта в будущем можно изменить во время разработки.

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

Organization Name (Название организации) и Organization Identifier (Идентификатор организации) – поля требуются для указания компании, которая разрабатывает программное обеспечение. Необходимо для того, чтобы подать заявку в App Store для публикации приложения. Идентификатор организации в стиле обозначения обратного имени домена. Например, если название организации «togu», то идентификатор организации будет «com.togu».

Language (Язык) – поле со списком, состоящее из двух языков, на одном из которых будет происходить разработка мобильного приложения: Swift или Objective C.