как посмотреть логи на mac os
Отслеживание проблем и ошибок в Mac OS
Автор: Елена Новикова | Категория: Mac OS
Появилось ли сообщение об ошибке?
Это раздражает, но компьютерные сообщения об ошибках часто оказываются невразумительными и малополезными для того, чтобы можно было решить вопрос сразу. Однако коды ошибок и текст сообщений могут указать направление, в котором надо двигаться: либо это поиск в онлайновых базах данных, либо передача информации специалисту технической поддержки. Поэтому всегда необходимо записывать весь текст сообщения об ошибке, когда оно появляется. Если приложение предлагает отправить разработавшей его компании сообщение об ошибке, обязательно прочтите его (даже если вы не собираетесь его отправлять).
Нет ли сообщений об ошибках в «Консоли»?
Если ошибка произошла в фоновом режиме, предупреждающее сообщение не появится. Однако весьма вероятно, что Mac сделал запись об ошибке в сообщении «Консоли» (Console).
Чтобы проверить это, откройте Finder и выберите «Программы» (Applications) => «Утилиты» (Utilities) => «Консоль» (Console). Следует проверить также журнал «Консоли» (выберите «Файл» (File) О «Открыть журнал консоли» (Open Console Log)) и системный журнал (выберите «Файл» (File) => «Открыть» (Open System Log). Иногда трудно понять сразу, на что именно надо обратить внимание в окне «Консоли».
Для начала поищите в колонке «Отправитель» (Sender) название программы, которая, по вашим предположениям, может быть источником проблемы. Обращайте внимание только на те сообщения, которые записаны примерно в то же время, когда произошла неполадка. И хотя любое сообщение из тех, которые вы увидите, скорее всего, окажется слишком сложным, чтобы вы могли его расшифровать, оно будет понятно специалисту техподдержки. Можно также искать решение проблемы в Google.
Изменяли ли вы недавно какие-либо настройки программ?
Если да, попробуйте вернуть старые настройки и посмотрите, не приведет ли это к исправлению неполадки. Если попытка окажется неудачной, проверьте сайт разработчика: нет ли там исправлений для этой программы. Можно также попробовать удалить программу и установить ее вновь.
Устанавливали ли вы недавно новую программу?
Если вы подозреваете, что нестабильность системы вызвана новой программой, перезагрузите Mac и попробуйте поработать, не пользуясь ею. (Если программа применяет объекты, которые автоматически запускаются при загрузке компьютера, убедитесь, что вы деактивировали их) Если все наладилось, то, вероятно, причиной сбоя была эта новая программа.
Попробуйте пользоваться ею, когда ни одна другая программа не запущена. Необходимо также посмотреть в файле README этой программы (если он есть) описание стандартных проблем и способов их устранения. Хорошо бы проверить, совместима ли версия программы с версией OS X, установленной на компьютере. (Например, некоторые более старые версии программ плохо работают в новых версиях Mac OS X, таких как Lion или Snow Leopard.)
Далее, можно попробовать переустановить программу. Аналогично, если вы недавно устанавливали на какую-то программу обновление, попробуйте это обновление удалить.
Устанавливали ли вы недавно новое устройство?
Если недавно было установлено новое устройство или обновлен драйвер уже имеющегося устройства, это может быть причиной проблемы. Попробуйте прибегнуть к обычным методам поиска неполадок оборудования.
Устанавливали ли вы недавно какие-либо обновления?
Иногда обновления, предназначенные для устранения одной неисправности, вызывают появление других. Отменить установку обновления программы невозможно, поэтому единственным выходом является восстановление компьютера Mac и возврат к предыдущему состоянию.
Изменяли ли вы недавно какие-либо из системных настроек?
Если трудности начались после того, как вы изменили конфигурацию компьютера, попробуйте вернуть все в первоначальное состояние. Даже такие кажущиеся невинными действия, как включение экранной заставки, могут вызвать неполадки в работе, поэтому не отбрасывайте какие-либо предположения с ходу.
[iOS] Просмотр системных логов
Существует несколько способов просмотреть логи с iOS-устройства.
2. Через XCode — к сожалению, среда разработки XCode доступна исключительно для MacOS. По этой и многим другим причинам было бы неплохо, если тестировщики iOS-приложений имели в своем распоряжении хотя бы Mac mini. Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать кнопку «Use for Development», после чего в разделе «Device Logs» уже можно непосредственно просматривать логи и, что не маловажно, импортировать их!
3. Через программу «iPhone Configuration Utility» — хотя основная функция этой утилиты заключается в настройки профилей для iOS-устройств, в ней имеется консоль, куда выводятся все логи с подключенного устройства. Незаменимая вещь для тестировщика. К тому же, утилита доступна и для Windows.
4. Через синхронизацию iTunes — каждый раз, когда вы синхронизируете свое iOS-устройство с iTunes на компьютере, логи сохраняются в следующие директории:
Windows XP
C:\Documents and Settings\ \Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\
Windows Vista or 7
C:\Users\ \AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\
Как узнать, что в твой Mac залезали без спроса. На работе или дома
Кто-то тайком пользуется твоим компьютером? Не беда.
Вы вернулись домой и заметили, что ваш компьютер как-то не так стоит, повернут монитор или крошки лежат на столе? Вы думаете, что в ваше отсутствие кто-то из домашних залез в компьютер без разрешения? Как же найти доказательства этих предположений?
Здесь я расскажу, как вычислить «тайных лазутчиков», а также как узнать, что именно они делали на вашем компьютере.
1. Проверьте историю браузера
Это самый простой и быстрый способ узнать, что кто-то пользовался вашим компьютером и заходил в Интернет. Но все прекрасно понимают, что умные люди всегда удаляют историю браузера, тем более, если они используют чужой компьютер.
Скорее всего, ваш подозреваемый не так глуп, чтобы оставить настолько явные следы своего присутствия, не так ли? Но и здесь есть подвох!
«Лазутчик» мог удалить только свою историю посещений, а мог удалить ее вместе с вашей предыдущей историей. Если вы заходите в браузер и видите пустую историю, но точно знаете, что сами ее не удаляли, то это первый звоночек о том, что кто-то без вас пользовался вашим компьютером.
Если ваш «шпион» совсем не глуп, то мог использовать приватную сессию браузера, в таком случае с историей посещений все будет в порядке. Но и здесь можно отследить его действия с помощью интернет-службы OpenDNS, эта услуга, конечно, платная и подключать ее нужно заранее, но для некоторых она может оказаться незаменимой.
Служба OpenDNS позволяет в течение года хранить каждый URL, который посещали из вашей домашней сети.
2. Проверьте логи на компьютере
Знайте, что никакая деятельность на компьютере не проходит бесследно. На каждом компьютере хранится список абсолютно всех действий, которые он выполнял. И эта замечательная функция становится очень кстати, когда речь идет о подозрениях в тайном использовании вашего компьютера.
К тому же логи хранятся с обозначением времени, что поможет вам точно отследить активность на компьютере в ваше отсутствие.
Журналы Windows содержат довольно много информации о работе пользователей, ходе загрузки операционной системы и ошибках в работе приложений и ядра системы. Вот туда мы и заглянем. Откройте «Панель управления», найдите пункт «Администрирование» и выберите «Управление компьютером». Здесь вы увидите «Просмотр событий», вот в этом пункте меню и находятся «Журналы Windows».
Их несколько: Приложение, Безопасность, Установка, Система. Журнал безопасности обязательно содержит информацию о входе в систему всех пользователей. Журнал приложений содержит информацию о приложениях, которые были запущены в ваше отсутствие.
Именно эти два журнала должны дать вам убедительный ответ, пользовался кто-то вашим компьютером или нет.
Для пользователей Mac также есть способ посмотреть логи и увидеть время активности на компьютере. Для этого всего лишь нужно зайти в /Applications/Utilities/Console.app, выбрать «Все сообщения» («All Messages») и вы получите полный список действий и время их совершения.
В этом случае главное – понимать, что именно делали вы на своем компьютере, а что ваш «лазутчик».
3. Ставим ловушку для шпиона
Если вы не нашли никаких доказательств из 1 и 2 пункта, но все равно считаете, что кто-то пользуется вашим компьютером без вашего ведома, то можно попробовать поставить ловушку и взять его с поличным. Для этого есть несколько способов.
Первый способ подходит для пользователей Windows и не отличается особой сложностью. Нужно всего лишь зайти в «Планировщик заданий Windows» и создать простую задачу. При создании задачи укажите событие (триггер) «Вход в Windows».
Теперь продумайте, что вы бы хотели сделать, когда без вас кто-то войдет в компьютер. Самый простой вариант — послать самому себе письмо, например, на коммуникатор.
Хотя лично мне больше понравился бы другой вариант – «Запустить программу». А потом бы я скачал какую-нибудь программу-розыгрыш из тех, что удаляют меню Пуск или включают аудиозапись с вашим грозным голосом на мощных колонках с отличным звуком, например, Bose SoundTouch 20 Series III. Представьте себе лицо неизвестного в этот момент!
Второй вариант подходит абсолютно для всех устройств – это программа Prey (Добыча). Это приложение, которое будучи запущенным на компьютере/телефоне, сидит тихо и помалкивает, а по сигналу хозяина начинает втихую следить за действиями текущего пользователя. Также есть приложение Elite Keylogger, которое отслеживает все действия мыши или клавиши, нажатые на клавиатуре.
Есть как бесплатные, так и платные и более расширенные версии этих приложений. Но поймать «шпиона» на месте преступления – это стоит того.
4. Камера не обманет
Если же вы по какой-то причине не смогли найти доказательства тайного проникновения в ваш компьютер, но уверены, что это происходило и будет происходить дальше, то можете воспользоваться самым старым и верным способом поймать подозреваемого со всеми доказательствами.
Это, конечно же, поставить скрытую камеру. Благо, сейчас есть совсем маленькие камеры, которые, к тому же, могут транслировать все происходящие прямо к вам в телефон. Главное – установите камеру так, чтобы ваш «шпион» ее не нашел, например, спрячьте на книжной полке или в цветочном горшке неподалеку от компьютера.
И вуаля! Вы каждую минуту можете следить за тем, что происходит с вашим компьютером и вообще в комнате, пока вы отсутствуете.
Друзья, на самом деле, вопрос личных данных тревожит сейчас многих, и вряд ли кто-то отнесся бы спокойно к тому, что посторонний человек залезает в ваш компьютер, но не всегда стоит превращать это в расследование, а потом еще и, возможно, в конфликт.
Иногда достаточно просто спросить у человека, и он сам признается. И, может быть, это был не интерес к вашим данным, а острая необходимость выйти в интернет или что-то подобное. Не забывайте узнавать причину действий вашего «шпиона»!
Юрий Андреев
Люблю Apple, рассказываю о гаджетах, кино и полезных вещах из мира IT.
View log messages in Console on Mac
Use Console to view log messages collected by your computer and other connected devices. These log messages may deal with system events, dialog text, errors, status, and other communications. If a problem occurs, you may be able to find information about the cause of the problem by viewing either log messages or activities.
Note: If you’re not logged in as an administrator, you need to enter an administrator name and password to view log messages.
In the Console app 
on your Mac, in the Devices list on the left, select the device you want to view log messages for (such as your Mac, iPhone, iPad, Apple Watch, or Apple TV). If you don’t see the Devices list, click the Sidebar button 
in the Favorites bar.
In the window to the right, click “Start streaming.”
The log messages for the device appear in the window to the right.
The type of log message is indicated by a dot in the Type column:
Red: Faults
Yellow: Errors
Dark gray: Debug log messages
Light gray: Info log messages
Note: If there is no dot in the Type column, the log message is the default type.
Do any of the following:
View an entire log message in the Messages column: Click the log message, then press the Right Arrow key, or choose View > Expand Selected Row. To shorten the log message to one line again, press the Left Arrow key, or choose View > Collapse Selected Row.
View all details of a log message: Click Details in the log message details in the lower half of the Console window. If you don’t see the log message details, click the Info button 
in the toolbar (or use the Touch Bar), or choose View > Show Info Pane. To see fewer details, click Hide.
Search for a specific log message in the current view: Click the log message, then press Command-F. See Find text in log messages and reports.
While viewing log messages, you can move columns and change which columns appear; view the most recent activity; and apply saved searches. See Customize the log window.
Демистификация аварийных журналов iOS
Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!
Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?
Вот когда пригодятся аварийные журналы iOS. В большинстве случаев, вы получите очень подробную и полезную информацию о причинах аварии, это вроде обратной связи от хорошего учителя.
В этом уроке вы узнаете, как выглядят аварийные журналы, а также как получить аварийный журнал из iOS-устройства и iTunes Connect. Вы узнаете о символизации и о том, как вернуться от аварийного журнала назад, в код. Мы также займёмся отладкой приложения с ошибками, которые могут привести к сбою в определенных ситуациях.
Что это за аварийный журнал и где его взять?
Когда приложение «падает», то есть аварийно завершает свою работу на устройстве iOS, операционная система создает отчет о сбое или аварийный журнал. Этот журнал сохраняется на устройстве.
Вы можете найти много полезной информации в аварийном журнале, в том числе те причины, по которым приложение аварийно завершило работу. Как правило, там есть полная трассировка стека каждого исполняемого потока, так что вы сможете увидеть, что происходило в каждом потоке в момент аварии, а также определить поток, где произошла катастрофа.
Есть много способов, как получить аварийный журнал с устройства.
Устройство, которое синхронизируется с iTunes, хранит свои аварийные журналы на ПК. В зависимости от ОС, вот места, где их можно найти:
(5) Состояние потока
Этот раздел содержит значения в регистрах на момент сбоя. Обычно этот раздел не нужен, потому что трассировка потоков уже дала вам необходимую информацию, чтобы решить вашу проблему.
(6) Дамп памяти
В этом разделе перечислены все модули, которые были загружены в память на момент сбоя.
Демистификация с помощью символизации
Первый взгляд на трассировку потоков говорит о том, там нет смысла. Ты привык работать с именами функций и номерами строк, а не загадочными письменами, вроде этого:
Процесс преобразования этих шестнадцатеричных адресов исполняемого кода в имена методов и номера строк называется символизация (symbolification).
Когда вы получаете аварийный журнал от устройства используя Органайзер Xcode, то символизация автоматически происходит через несколько секунд. Строчка из журнала сбоя выше после символизации выглядит так:
Чтобы Xcode смог символизировать аварийный журнал, он должен иметь доступ к файлу приложения, который был загружено в App Store, и DSYM-файлу, который был создан при компиляции приложения. Тут должно быть точное соответствие версий, в противном случае аварийный журнал не может быть полностью символизирован.
То есть, важно сохранять каждую сборку, которую вы распространяете среди пользователей. Когда вы архивируете ваше приложение перед отправкой, Xcode сохраняет откомпилированный файл. Вы можете найти все архивы вашего приложения в Xcode Organizer, вкладка Archives.
Примечание: Вам нужно хранить и откомпилированный файл приложения и dSYM-файл, чтобы иметь возможность в полной мере символизировать отчеты о сбоях. Вы должны архивировать эти файлы для каждой сборки, которую вы выкладываете в iTunes Connect.
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 (Исключение), см. приведенный выше пример. Есть несколько кодов исключений, которые могут возникнуть чаще, чем остальные.
Как правило, код исключения начинается с текста, потом одна или несколько шестнадцатеричных значений, которые являются процессор-специфичными кодами и которые могут дать вам информацию о характере сбоя. Эти коды могут сказать вам почему приложение аварийно остановлено, то ли из-за ошибки программирования, то ли из-за неверного доступа к памяти, то ли по какой-то другой причине.
Вот некоторые из наиболее распространенных кодов исключения:
Примечание: Помните, что принудительное прекращение приложения, находящегося в фоне, путём удаления его из списка задач не вызывает создания аварийного журнала. После того, как приложение было приостановлено, оно может быть прекращено операционной системой в любое время. И аварийный журнал создан не будет.
В омут головой!
Вы можете скачать исходный код приложения отсюда.
Сценарий 1. Плохой код на завтрак
Да ладно, не принимайте близко к сердцу! Как любой из этих комментариев даст вам подсказку? Взгляните лучше в аварийный журнал:
Это значит, что приложению не удалось уложиться при запуске в отведённое для этого время и сторожевой таймер операционной системы прекратил работу приложения. Круто! Вы нашли причину, но почему (и что ещё более важно, где) это происходит?
Смотрим дальше журнал. Трассировку потоков принято читать в обратном порядке, снизу вверх. Самый последний фрейм (25 фрейм: libdyld.dylib) – это первый вызов, затем фрейм 24, Rage Masters, main (main.m:16) и так далее.
Нам интересны фреймы, которые связаны с кодом вашего приложения. Так что игнорируйте системные библиотеки и фреймворки. Вот эта строчка нам интересна:
Приложение получило сбой в методе application:didFinishLaunchingWithOptions:, в 35-ой строке файла RMAppDelegate.m (RMAppDelegate.m: 35). Откройте Xcode и посмотрите на эту строку:
Да, вот оно! Синхронный вызов веб-сервиса? В главном потоке? В application:didFinishLaunchingWithOptions. Кто писал этот код?
Чтобы перенести вызов в другое место потребуются значительные изменения, поэтому, в данный момент, просто сделаем минимум изменений, просто, чтобы приложение аварийно не останавливалось при запуске. Вы всегда можете вернуться к этому вопросу и сделать это совсем правильно. Замените строку «плохого» кода (и три строки после неё) на асинхронную версию:
Сценарий 2. Где эта кнопка?
Пользователь пишет: «Я не могу отметить моего любимого персонажа закладкой. Когда я пытаюсь это сделать, приложение падает. «.
Другой пользователь: «Закладки не работают. Я вхожу в Подробную информацию, нажимаю на кнопку «Закладка» и БА-БАХ!»
Эти жалобы о многом не говорят, и существует куча причин, почему программа так себя ведёт. Посмотрим в аварийный журнал:
Обычно этого не происходит, так как если вы вызываете метод «foo» объекта «bar», то компилятор выдаст ошибку, что метод «foo» не существует. Но когда вы косвенно вызываете метод используя селектор, компилятор не сможет определить, существует или нет метод у объекта.
Вернёмся к аварийному журналу. Он говорит, что аварийный останов произошёл в потоке №0. Это значит, что у нас, скорей всего, ситуация, когда метод был вызван объектом главного потока, там где объект не реализует метод.
Если вы продолжите читать журнал трассировки, вы видите, что единственный вызов, связанный с вашим кодом – это фрейм 22, main.m: 16. Это не особенно помогло.
Посмотрим на вызовы фреймворков, и видим это:
Это не ваш код. Но по крайней мере, есть подтверждение, что был вызов нереализованного метода объекта.
Идём в RMDetailViewController.m, где реализована кнопка закладок. Найдём код, который делает закладку:
Тут всё выглядит нормально, так что проверим сториборд (XIB файл) и убедимся, что кнопки подключены правильно.
Вот оно! В MainStoryboard.storyboard, кнопка связана с bookmarkButtonPressed: вместо bookmarkButtonPressed (обратите внимание на двоеточие в конце, которое говорит о том, что у метода есть параметр). Чтобы это исправить, замените название метода на такой:
Конечно, вы можете просто удалить связь с неправильным методом в XIB-файле и связать событие к правильным методом. В любом случае сработает.
И вот ещё одна причина аварийного останова устранена.
Сценарий 3. Закладкой больше, закладкой меньше.
Ещё одна жалоба от пользователя: «Я не могу удалить закладку на персонажа из окна закладок. «. И ещё одно письмо о том же: «Если я пытаюсь удалить персонажа из закладок, приложение падает. «
К этому моменту, вы уже привыкли, что письма от пользователей не бывают полезными. К аварийным журналам!
Этот журнал очень похож на предыдущий аварийный журнал. Тут тоже SIGABRT исключение. Может тут та же причина: отправка сообщения объекту, у которого не реализован метод?
Давайте посмотрим трассировку, какие методы вызывались. Начните с нижней части. Последний вызов на ваш код в Rage Masters был в фрейме №6:
Посмотрим на фреймы дальше:
В фрейме №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 и другие.
При нехватке памяти iOS посылает предупреждение о низком уровне памяти активному приложению и завершает фоновые процессы. Если активное приложение продолжает увеличивать использование памяти, iOS завершает его.
Чтобы найти причину проблем с нехваткой памяти, необходимо профилировать приложение, используя утилиту Instruments. Если вы не знаете, как это делать, есть учебник. Вместо этого, мы решим проблему «в лоб», просто обработаем в нашей программе событие о нехватке памяти.
Перейдите в Xcode в RMLollipopLicker.m. Это там реализован контроллер представления лизания леденца. Взгляните на исходный код:
Когда пользователь нажимает кнопку запуска, приложение запускает в фоновом режиме процедуру lickLollipop несколько раз, а затем обновляет на экране количество лизаний. lickLollipop читает большую строку NSString из PLIST-файла и добавляет её в массив. Эти данные не критичны, и могут быть воссозданы, не влияя на работу пользователей.
И всё будет хорошо!
Что дальше?
Ура, вы прошли через все четыре сценария развития аварийных ситуаций! Ваше приложение работает намного лучше, и вы получили важные навыки отладки по ходу обучения.