Предупреждение памяти и авария (ARC) - как определить, почему это происходит?

Ответ 1

Чтобы ответить на ваш вопрос: Идентификация проблем с предупреждениями о памяти и сбоями с ARC в основном работает, как и раньше, с ручным удержанием (MRR). ARC использует retain, release и autorelease точно так же, как MRR, он только вставляет вызовы для вас и имеет некоторые оптимизации на месте, что в некоторых случаях должно даже снизить потребление памяти.

Относительно вашей проблемы:

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

• Вы упомянули, что используете NSOperationQueue. Если вы переопределите -[NSOperationQueue main], убедитесь, что вы завершаете весь контент метода в @autoreleasepool { ... }. Пул авторесурсов уже может быть установлен, но он не гарантируется (и даже если он есть, он может быть примерно дольше, чем вы думаете).

• Если 1. не помогло, и у вас есть цикл, обрабатывающий изображения, оберните внутреннюю часть цикла в @autoreleasepool { ... }, чтобы немедленно очистить временные объекты.

• Вы упомянули, что используете NSOperationQueue. Поскольку iOS 4, рисование в графическом контексте в UIKit является потокобезопасным, но если документация правильная, UIGraphicsBeginImageContext следует еще только вызывать в основном потоке! Обновление: теперь в документах указано, что с iOS 4 функция может быть вызвана из любого потока, так как на самом деле это необязательно! Чтобы быть в безопасности, создайте контекст с помощью CGBitmapContextCreate и выберите изображение с CGBitmapContextCreateImage. Что-то в этом роде:

  CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
  CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, colorSpace, kCGImageAlphaPremultipliedLast);
  CGColorSpaceRelease(colorSpace);
  
  // draw to the context here
  
  CGImageRef newCGImage = CGBitmapContextCreateImage(context);
  CGContextRelease(context);
  UIImage *result = [UIImage imageWithCGImage:newCGImage scale:scale orientation: UIImageOrientationUp];
  CGImageRelease(newCGImage);
  
  return result;
  

Ответ 2

Итак, вы ничего не делаете относительно управления памятью (их нет!) выглядит ненадлежащим. Однако вы упоминаете использование NSOperationQueue. Те UIGraphics... звонки помечены как не потокобезопасные, но другие заявили, что они относятся к iOS 4 (я не могу найти окончательного ответа на этот вопрос, но напомню, что это правда.

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

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

• в любом из ваших классов, которые используют множество изображений, добавьте метод dealloc(), который просто регистрирует его имя и некоторый идентификатор.

• вы можете попытаться добавить dealloc в UIImage, чтобы сделать то же самое.

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

• когда вы хотите убедиться, что что-то выпущено, установите ivar или свойство в nil

Прошлым летом я преобразовал проект в 100 файлов в ARC, и он отлично работал из коробки. Я преобразовал несколько проектов с открытым исходным кодом в ARC, а также только с одной проблемой, когда я неправильно использовал мост. Эта технология является твердосплавной.

Ответ 3

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

Я однажды написал тестовое приложение, которое создавало множество объектов с автореализацией после нажатия кнопки. Я смог быстрее (и создавать объекты) быстрее, чем ОС удалось освободить память. Память медленно увеличивалась, поэтому после значительного времени или просто с использованием более крупных объектов я бы наверняка сбил приложение и заставил устройство перезагружаться (выглядит действительно эффективно;)). Я проверил это с помощью инструментов, которые, к сожалению, повлияли на тест и сделали все медленнее, но я полагаю, что это верно и при использовании инструментов.

В то же время я работал над большим проектом, который довольно сложный и имеет много пользовательского интерфейса, созданного из кода. У него также много обработки строк, и никто не заботился о том, чтобы использовать release - в последний раз было несколько тысяч вызовов автоответчика. Таким образом, после 5 минут немного расширенного использования этого приложения, он сбой и перезагрузка устройства.

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