Управление памятью на iPhone

Question

Хорошо ......

Я реализую простое приложение OpenGL ES на iPhone, и недавно я добавил в Pinch Media Analytics. Это помогло обнаружить проблему с управлением памятью, и я не совсем уверен, как ее решить.

В идеальном мире мое приложение, которое загружает файлы PNG и .CAF в didFinishLoading, запустится, загрузит все свои ресурсы и будет нормально работать.

* 1006. не хватает памяти

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

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

- (void)didReceiveMemoryWarning
{ 
  // default behavior is to release the view if it doesn't have a superview.

  // remember to clean up anything outside of this view's scope, such as
  // data cached in the class instance and other global data.
  [super didReceiveMemoryWarning];
}

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

Answer 1

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

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

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

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

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

Answer 2

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

Если у вас более одного вида, они могут быть освобождены, если они не видны. Если это произойдет, соответствующий контроллер будет отправлен setView: с nil. Я справляюсь с этим, немедленно освобождая все IBOutlet переменные, чтобы они были правильно установлены, когда представление снова загружается из xib.

Это подход, который я использую в обычном, не-OpenGL ES-приложении, которое имеет> 6 представлений и работает согласованно, даже когда у меня 4 уровня глубины в представлении навигации и все предыдущие контроллеры имеют свои представления, установленные на nil - при переходе назад не происходит сбоя, хотя при перезагрузке видов задержка сохраняется.

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

Answer 3

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

Здесь есть хороший маленький учебник:

http://iphonedevelopment.blogspot.com/2008/12/preparations-for-porting-nehe-lesson-06.html

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

[Отказ от ответственности: я не гуру по оптимизации OpenGL ES. Не очень приятным выстрелом.]