Отчет об ошибках mac os
Обновлено: 03.07.2024
Ваш Mac хранит системные журналы, которые могут помочь диагностировать и устранять проблемы с macOS и вашими установленными приложениями. Эти журналы хранятся в виде текстовых файлов журнала на системном диске вашего Mac, и macOS также включает в себя приложение для их просмотра.
Просмотр системных журналов в консольном приложении
Чтобы просмотреть системные журналы Mac, запустите консольное приложение. Вы можете запустить его с помощью Spotlight, нажав Ctrl + Space, набрав «Console», а затем нажав Enter. Вы также найдете его в Finder> Приложения> Утилиты> Консоль.
Консольное приложение, также известное как Console.app, похоже на Windows Event Viewer для Mac.
Дополнительные журналы доступны в разделе Отчеты. Чтобы просмотреть журналы сбоев и зависаний приложений, нажмите «Системные отчеты» для системных приложений или «Пользовательские отчеты» для пользовательских приложений. Вы увидите различные журналы с расширениями файлов, такими как .crash, .diag и .spin. Нажмите на них, чтобы просмотреть их на панели информации.
Если вам нужна дополнительная информация о причине сбоя приложения в вашей системе, вы можете найти его здесь. Разработчику приложения может понадобиться эта информация для исправления сбоя, который также происходит на вашем Mac.
Чтобы просмотреть файл системного журнала, нажмите «system.log». Чтобы просмотреть другие журналы, относящиеся к конкретному приложению, просмотрите другие папки здесь. «
Library / Logs» — это папка журнала приложения для вашей текущей учетной записи пользователя Mac, «/ Library / Logs» — это папка журнала приложения для всей системы, а «/ var / log» обычно содержит журналы для системных служб низкого уровня. , Панель поиска также работает для фильтрации этих файлов журнала.
Чтобы просмотреть журналы другой учетной записи пользователя Mac, расположенные в разделах «Отчеты пользователя» или «
/ Библиотека / Журналы», вам необходимо войти в систему под этим пользователем, а затем открыть консольное приложение.
Найти файлы журналов на диске
Эти журналы представляют собой текстовые файлы, которые вы также можете найти на локальном диске вашего Mac. Это означает, что вы можете просматривать их в Finder или через терминал, открывать их в других приложениях, использовать с ними инструменты командной строки и создавать резервные копии файлов.
Увы, большинство компьютерных болезней не проходят просто так. Если проблема трудноразрешима, первое, что вы должны сделать, - это определить ее источник. Для этого нет легких путей, но цели можно достичь системным подходом.
Благодаря многолетнему опыту было обнаружено, что оптимальный способ - задать ряд вопросов, которые помогут получить нужную информацию и сузить список возможных причин:
Чтобы проверить это, откройте Finder и выберите «Программы» (Applications) => «Утилиты» (Utilities) => «Консоль» (Console). Следует проверить также журнал «Консоли» (выберите «Файл» (File) О «Открыть журнал консоли» (Open Console Log)) и системный журнал (выберите «Файл» (File) => «Открыть» (Open System Log). Иногда трудно понять сразу, на что именно надо обратить внимание в окне «Консоли».
Изменяли ли вы недавно какие-либо настройки программ?
Если да, попробуйте вернуть старые настройки и посмотрите, не приведет ли это к исправлению неполадки. Если попытка окажется неудачной, проверьте сайт разработчика: нет ли там исправлений для этой программы. Можно также попробовать удалить программу и установить ее вновь.
Устанавливали ли вы недавно новую программу?
Если вы подозреваете, что нестабильность системы вызвана новой программой, перезагрузите Mac и попробуйте поработать, не пользуясь ею. (Если программа применяет объекты, которые автоматически запускаются при загрузке компьютера, убедитесь, что вы деактивировали их) Если все наладилось, то, вероятно, причиной сбоя была эта новая программа.
Попробуйте пользоваться ею, когда ни одна другая программа не запущена. Необходимо также посмотреть в файле README этой программы (если он есть) описание стандартных проблем и способов их устранения. Хорошо бы проверить, совместима ли версия программы с версией OS X, установленной на компьютере. (Например, некоторые более старые версии программ плохо работают в новых версиях Mac OS X, таких как Lion или Snow Leopard.)
Далее, можно попробовать переустановить программу. Аналогично, если вы недавно устанавливали на какую-то программу обновление, попробуйте это обновление удалить.
Устанавливали ли вы недавно новое устройство?
Если недавно было установлено новое устройство или обновлен драйвер уже имеющегося устройства, это может быть причиной проблемы. Попробуйте прибегнуть к обычным методам поиска неполадок оборудования.
Устанавливали ли вы недавно какие-либо обновления?
Иногда обновления, предназначенные для устранения одной неисправности, вызывают появление других. Отменить установку обновления программы невозможно, поэтому единственным выходом является восстановление компьютера Mac и возврат к предыдущему состоянию.
Изменяли ли вы недавно какие-либо из системных настроек?
Если трудности начались после того, как вы изменили конфигурацию компьютера, попробуйте вернуть все в первоначальное состояние. Даже такие кажущиеся невинными действия, как включение экранной заставки, могут вызвать неполадки в работе, поэтому не отбрасывайте какие-либо предположения с ходу.
Компьютеры Apple имеют множество полезных фишек и возможностей. Одной из таких особенностей является встроенный тест оборудования.
С его помощью можно самостоятельно диагностировать неисправность компьютера, найти неработоспособный элемент и разобраться в причине поломки.
Тест производительности не заменит полноценный поход в сервисный центр, но в ряде случаев окажется очень полезен для обычных пользователей.
Как можно проверить Mac в домашних условиях
На всех современных компьютерах Mac есть встроенная утилита для диагностики аппаратной части компьютера. Она позволяет произвести проверку большинства узлов и компонентов, выявить сбои в работе или нерабочий элемент на устройстве.
Разделяют две принципиально отличающиеся версии утилиты для диагностики Mac: Apple Hardware Test (Функциональный тест оборудования Apple) и Apple Diagnostics.
Первая версия программы (Apple Hardware Test) запускается на компьютерах Mac, которые были выпущены до июня 2013 года, а на более новых моделях используется вторая (Apple Diagnostics).
Подобные тесты могут выявить проблемы с большинством из компонентов Mac. Система поочередно опрашивает на наличие ошибок накопители, оперативную память, беспроводные модули, контроллер питания, аккумулятор и другие компоненты компьютера.
Проверка не займет много времени, обычно тест оборудования проходит от 2 до 5 минут.
Что нужно сделать перед проверкой
Перед запуском утилиты для проверки железа следует сделать следующее:
▪️ Отключите все периферийные устройства от Mac. Нужно отсоединить проводные принтеры, накопители, приводы для дисков, любое стороннее аудио- или видеооборудование, внешние видеокарты.
Рекомендуется оставить подключенными лишь клавиатуру, мышь\трекпад и монитор.
▪️ Перед запуском теста на MacBook обязательно подключите ноутбук к источнику питания.
▪️ Убедитесь, что Mac подключен по Wi-Fi или Ethernet кабелю к сети. В некоторых случаях может потребоваться загрузка дополнительных файлов для проведения тестирования.
Как запустить Apple Hardware Test на моделях до 2013 года
Интерфейс Apple Hardware Test на старых компьютерах Mac до 2013 года
1. Выключите Mac. Именно выключите, а не перезагрузите.
2. Включите компьютер и сразу же зажмите клавишу D (иногда cmd+D) до появления окна восстановления по интернету.
3. Введите пароль от вашего Wi-Fi и дождитесь загрузки теста.
4. Выберите русский язык в диалоговом окне и нажмите серую кнопку для продолжения.
5. Откроется меню Hardware Test.
6. Когда кнопка Тест станет активна, можно начать проверку. Для этого нажмите на кнопку или на клавишу T на клавиатуре.
7. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
Прервать тестирование можно нажатием на соответствующую кнопку или при помощи сочетания клавиш Command + .
Как запустить Apple Diagnostics на моделях Mac с 2013 по 2016 годы
Интерфейс Apple Diagnostics на компьютерах Mac с 2013 по 2016 годы выпуска
1. Выключите Mac.
2. Включите компьютер с нажатыми клавишами D (иногда cmd+D) до появления системного меню.
3. Выберите русский язык в диалоговом окне и нажмите копку Далее.
4. Подтвердите запуск теста оборудования.
5. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
После окончания тестирования доступны такие действия и горячие клавиши:
▸ запуск повторного тестирования Command + R
▸ получение дополнительной информации Command + G
▸ перезагрузка Mac клавиша R
▸ выключение компьютера клавиша S
Как запустить Apple Diagnostics на моделях Mac с 2016 года и новее
Интерфейс Apple Diagnostics на компьютерах Mac с 2016 года выпуска по настоящее время
1. Выключите Mac.
2. Включите компьютер с нажатой клавишей D (иногда cmd+D) до появления системного меню.
3. Тестирование начнется автоматически. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
После окончания теста будут доступны те же действия, что и в предыдущем случае.
Почему не запускается тест оборудования
Тест оборудования может не запускаться и Mac будет переходить к обычной загрузке в следующих случаях:
Во-первых, если вы не отключили какие-либо сторонние устройства. Мешать запуску теста могут даже подключенные флешки или Type-С переходники.
Во-вторых, если вы используете неоригинальную беспроводную клавиатуру с Mac. Только родная Bluetooth клавиатура может подключаться к компьютеру на этапе загрузки и посылать команды перед запуском операционной системы. Подойдут лишь сторонние проводные клавиатуры.
В-третьих, загрузочная область системы с тестом оборудования может быть повреждена. При этом попробуйте запустить Mac с зажатыми клавишами Option (Alt) + D. Компьютер запустит систему диагностики по сети.
В-четвертых, запуску утилиты может мешать установленный пароль прошивки.
На время тестирования компьютера его следует отключить:
1. Перезагружаем Mac с зажатыми клавишами Command + R для загрузки в режиме восстановления.
2. В строке меню выбираем Утилиты – Утилита пароля прошивки (в некоторых версиях macOS пункт называется Утилита безопасного запуска).
3. Нажимаем Выключить пароль прошивки и указываем установленный ранее пароль.
4. Перезагружаем компьютер.
Как трактовать результаты теста
Тест Apple Diagnostics не выявил проблем
После окончания проверки на экране увидите один или несколько кодов ошибок, например:
Код ADP000: отсутствие проблем с аппаратным обеспечением Mac.
Коды CNW007 или CNW008: невозможность подключения к сети или проблемы с беспроводным модулем.
Код PPT001: проблемы с аккумулятором на MacBook. Это может быть как слишком высокий износ батареи, так и проблемы с зарядкой.
Детально со всеми возможными кодами ошибок аппаратного теста Mac можете ознакомиться на сайте Apple.
Когда нужно делать тест оборудования
Результат теста Apple Diagnostics с парой ошибок
Если изучить предложенные варианты действий в случае возникновения ошибок, заметите, что купертиновцы почти всегда рекомендуют посетить сервисный центр. Зачем же тогда производить тест оборудования в домашних условиях?
Во-первых, тест оборудования рекомендуется запускать при покупке Mac на вторичном рынке. Так можно сразу выявить неработающие модули или компоненты компьютера.
Во-вторых, тест пригодится в случае возникновения проблем после самостоятельного апгрейда Mac.
В-третьих, перед походом в сервисный центр нелишним будет самому знать о возможных проблемах с компьютером.
Не ленитесь запускать Apple Hardware Test или Apple Diagnostics, если Mac начал вести себя странно. Тестирование займет всего несколько минут, зато сразу сможете отбросить проблемы с железом и искать причину в ПО.
(33 голосов, общий рейтинг: 4.33 из 5)
Вот когда пригодятся аварийные журналы iOS. В большинстве случаев, вы получите очень подробную и полезную информацию о причинах аварии, это вроде обратной связи от хорошего учителя.
В этом уроке вы узнаете, как выглядят аварийные журналы, а также как получить аварийный журнал из iOS-устройства и iTunes Connect. Вы узнаете о символизации и о том, как вернуться от аварийного журнала назад, в код. Мы также займёмся отладкой приложения с ошибками, которые могут привести к сбою в определенных ситуациях.
Что это за аварийный журнал и где его взять?
Когда приложение «падает», то есть аварийно завершает свою работу на устройстве iOS, операционная система создает отчет о сбое или аварийный журнал. Этот журнал сохраняется на устройстве.
Вы можете найти много полезной информации в аварийном журнале, в том числе те причины, по которым приложение аварийно завершило работу. Как правило, там есть полная трассировка стека каждого исполняемого потока, так что вы сможете увидеть, что происходило в каждом потоке в момент аварии, а также определить поток, где произошла катастрофа.
Есть много способов, как получить аварийный журнал с устройства.
Устройство, которое синхронизируется с iTunes, хранит свои аварийные журналы на ПК. В зависимости от ОС, вот места, где их можно найти:
- Номер фрейма - в данном случае, 2.
- Название модуля - в этом случае, XYZLib.
- Адрес функции, которая была вызвана - в данном случае, 0x34648e88.
- В четвертой колонке две части, базовый адрес и смещение. Тут это 0×83000 + 8740, где первое число указывает на файл, а вторая - на строку кода в файле.
(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 (Исключение), см. приведенный выше пример. Есть несколько кодов исключений, которые могут возникнуть чаще, чем остальные.
Как правило, код исключения начинается с текста, потом одна или несколько шестнадцатеричных значений, которые являются процессор-специфичными кодами и которые могут дать вам информацию о характере сбоя. Эти коды могут сказать вам почему приложение аварийно остановлено, то ли из-за ошибки программирования, то ли из-за неверного доступа к памяти, то ли по какой-то другой причине.
Вот некоторые из наиболее распространенных кодов исключения:
- 0xbaaaaaad: Читается как «плоооохой». Код говорит о том, что это не аварийный журнал, а это stackshot – журнал, содержащий состояние стека системы в данный момент. Чтобы получить stackshot, нажмите одновременно на кнопку Home и любую клавишу регулировки громкости. Часто эти журналы создаются пользователями случайно и не указывают на ошибку.
- 0xc00010ff: Читается как «cool off» (остынь). Код говорит о том, что приложение было принудительно закрыто операционной системой в ответ на тепловое событие (стало горячо или холодно). Это может быть вызвано проблемой с конкретным устройством, или состоянием окружающей среды.
- 0x8badf00d: Читается как «ate bad food» (ели плохую еду). Этот код значит, что приложение было прекращено iOS по таймауту. Обычно это происходит из-за того, что время, которое потратило ваше приложение на запуск, останов или отклик на системные события было больше, чем нужно.
- 0xbad22222: Этот код означает, что ваше VoIP-приложение была прекращено iOS из-за слишком частых обращений.
- 0xdead10cc: Читается как «deadlock» (тупик). Код означает, что ваше приложение, находясь в фоновом режиме, занимало какие-нибудь системные ресурсы (вроде базы данных адресной книги).
- 0xdeadfa11: Читается как «deadfall» (западня). Код значит, что приложение было принудительно закрыто пользователем. Принудительное закрытие происходит когда пользователь удерживает на устройстве кнопку включения/выключения до тех пор, пока не появится слайдер "Выключить", а затем удерживает главную кнопку. Согласно документации Apple, принудительный выход является причиной исключения с кодом 0xdeadfa11, потому, что приложение к тому моменту перестало отвечать.
Примечание: Помните, что принудительное прекращение приложения, находящегося в фоне, путём удаления его из списка задач не вызывает создания аварийного журнала. После того, как приложение было приостановлено, оно может быть прекращено операционной системой в любое время. И аварийный журнал создан не будет.
В омут головой!
Вы можете скачать исходный код приложения отсюда.
- Загрузите исходный код и откройте проект в 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. Кто писал этот код?
Чтобы перенести вызов в другое место потребуются значительные изменения, поэтому, в данный момент, просто сделаем минимум изменений, просто, чтобы приложение аварийно не останавливалось при запуске. Вы всегда можете вернуться к этому вопросу и сделать это совсем правильно. Замените строку «плохого» кода (и три строки после неё) на асинхронную версию:
Сценарий 2. Где эта кнопка?
Пользователь пишет: "Я не могу отметить моего любимого персонажа закладкой. Когда я пытаюсь это сделать, приложение падает. ".
Другой пользователь: "Закладки не работают. Я вхожу в Подробную информацию, нажимаю на кнопку «Закладка» и БА-БАХ!"
Эти жалобы о многом не говорят, и существует куча причин, почему программа так себя ведёт. Посмотрим в аварийный журнал:
Обычно этого не происходит, так как если вы вызываете метод "foo" объекта "bar", то компилятор выдаст ошибку, что метод "foo" не существует. Но когда вы косвенно вызываете метод используя селектор, компилятор не сможет определить, существует или нет метод у объекта.
Вернёмся к аварийному журналу. Он говорит, что аварийный останов произошёл в потоке №0. Это значит, что у нас, скорей всего, ситуация, когда метод был вызван объектом главного потока, там где объект не реализует метод.
Если вы продолжите читать журнал трассировки, вы видите, что единственный вызов, связанный с вашим кодом – это фрейм 22, main.m: 16. Это не особенно помогло.
Посмотрим на вызовы фреймворков, и видим это:
Это не ваш код. Но по крайней мере, есть подтверждение, что был вызов нереализованного метода объекта.
Идём в RMDetailViewController.m, где реализована кнопка закладок. Найдём код, который делает закладку:
Тут всё выглядит нормально, так что проверим сториборд (XIB файл) и убедимся, что кнопки подключены правильно.
Конечно, вы можете просто удалить связь с неправильным методом в XIB-файле и связать событие к правильным методом. В любом случае сработает.
И вот ещё одна причина аварийного останова устранена.
Сценарий 3. Закладкой больше, закладкой меньше.
Ещё одна жалоба от пользователя: "Я не могу удалить закладку на персонажа из окна закладок. ". И ещё одно письмо о том же: "Если я пытаюсь удалить персонажа из закладок, приложение падает. "
К этому моменту, вы уже привыкли, что письма от пользователей не бывают полезными. К аварийным журналам!
Давайте посмотрим трассировку, какие методы вызывались. Начните с нижней части. Последний вызов на ваш код в 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:
И всё будет хорошо!
Что дальше?
Ура, вы прошли через все четыре сценария развития аварийных ситуаций! Ваше приложение работает намного лучше, и вы получили важные навыки отладки по ходу обучения.
Читайте также: