NSXMLParser стратегия памяти iPhone для больших xml

Я строю алгоритм синтаксического анализа, используя NSXMLParser. У меня есть сомнения относительно того, что является лучшей стратегией для сохранения моего использования памяти на минимуме.NSXMLParser стратегия памяти iPhone для больших xml

У меня есть объект valueObject (например, «Person»), этот объект имеет ≈ 30 свойств NSString, а при разборе xml я постоянно выделяю и отпускаю временный объект Person при переходе узлов. Я проверил это, и в любой момент создается только один из этих объектов Person. Когда узел перемещается, а Person «build», я передаю Person в NSMutableArray и освобождаю это Person. Кажется, проблем нет. (Мне нужен массив для tableView). Когда я достигаю 50+ объектов Person в массиве, мое приложение просто завершает работу, didReceiveMemoryWarning не вызывается, никаких других предупреждений, no parseErrorOccurred, ничего?

Если я ограничу количество человек в xml, приложение просто отлично, я не смог найти утечки памяти с помощью инструментов. Я думаю, что я просто не могу удержать 50+ объектов Person в массиве ... кажется немного суровым, но у меня не так много опыта работы с iPhone, так что это всего лишь предположение.

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

Что было бы хорошей стратегией для хранения объектов Person? или мне не хватает огромной утечки памяти, так как iPhone должен иметь возможность обрабатывать гораздо больше, чем это?

Надежда некоторые опытные разработчики могут мне точку в правильном направлении :)

Спасибо!

источник

2009-11-03 RickiG

Некоторые примеры кода будет полезным – ACBurk

Как долго эти строки? Как правило, на iPhone 3G и более старых моделях ваше приложение должно иметь как минимум 20 МБ доступной памяти (гораздо больше на 3G). Конечно, это не абсолютное правило, а достойное эмпирическое правило. Занять эту большую память с 50 объектами будет означать ~ 400-500 КБ на объект Person. Это в шале? Если это так, вам, вероятно, потребуется стратегия управления памятью, которая не сохраняет все объекты в памяти одновременно. Core Data, вероятно, может помочь вам в этом.

источник

2009-11-04 00:49:16

Привет Оле Спасибо Я искал некоторое представление в этой манере:) мои объекты Person составляют около 0.1KB. Я начинаю думать, что это веб-сервис, откуда я получаю данные, которые действуют. Я продолжал тестирование с разным количеством xml, вылитым в мой скрипт, и он не падал последовательно в симуляторе Мне кажется, что если я запустил его с помощью инструментов, он не потерпит крах, а просто вырастет до ≈250 МБ. Я полагаю, что Nathan что-то делает, инструменты не могут найти никаких утечек, и в тот момент, когда выполняется синтаксический анализ (и URLConnection и XMLParser освобождены), выделенные MB от 250 до 1.5. Спасибо :) – RickiG

У меня есть базовая модель данных на месте, но на самом деле думаю, что это безумие, чтобы использовать это для отображения 50 результатов поиска. Я думаю, что ошибка похоронена где-то в другом месте, может быть, я должен замедлиться и лучше выглядеть в инструментах Инструменты. Спасибо – RickiG

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

источник

2009-11-04 00:55:30

Как я понимаю NSXMLParser, '-parse' является синхронным методом, т. Е. Он не возвращается в цикл выполнения до тех пор, пока процесс разбора не завершится. В таком случае вы не получили бы предупреждения о памяти, не так ли? –

Это зависит ... Лично я никогда не разбираюсь в XML-анализе по основному потоку (прежде всего, чтобы избежать икоты UI), поэтому основной цикл запуска продолжает обрабатывать события просто отлично. –

Несмотря NSXMLParser быть SAX-анализатор на основе его не поддержки разбора входного потока, что означает, что весь XML-строка, разбираем хранится в памяти. Это само по себе является большой проблемой, но при анализе проблема ухудшается, когда вы начинаете дублировать строковые данные из XML в своих объектах Person.

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

Первая проблема может быть решена с помощью AQXMLParser из AQToolkit библиотеки Джима милочки, которая обеспечивает NSXMLParser -как API, но с поддержкой потоковой передачи данных с диска.

Вторая проблема может быть решена с использованием технологии сохранения на основе диска, например Core Data, SQLite Persistent Objects или даже для простого хранения объектов Person на диске.

источник

2009-11-04 13:29:41

С уважением, Nathan Это для меня непостижимое :) Я был уверен, что SAX-анализатор будет читать поток, а не только кусок из памяти:/Я попытаюсь найти в ToolKit, который вы рекомендуете, благодаря устранению этого недоразумения в NSXMLParser для меня! – RickiG

Я также должен был упомянуть, что вам действительно не нужен весь AQToolkit ... просто отпустите iPhoneNonatomic.h, AWXMLParser.h, AWXMLParser.m, AWXMLParserDelegate.h и AWXMLParserDelegate.m в свой проект. Затем вы можете использовать API-интерфейс «initWithStream:», а не API NSWMLParser «initWithData:». –

Есть ли у них исходный код ARC? –

Ответ изрубить входящий поток, я написал пост об этом некоторое время назад: https://lukassen.wordpress.com/2010/01/15/feeding-nsxmlparser-a-stream-of-xml/

источник

2013-07-16 07:01:51 CocoaChris

NSXMLParser стратегия памяти iPhone для больших xml

ответ

Смежные вопросы