iOS: лучший способ кодировать/декодировать объекты с интенсивным использованием памяти

Я новичок в программировании iOS и изо всех сил пытаюсь решить, как лучше всего кодировать объекты с интенсивным использованием памяти с использованием протокола NSCoding.

У меня есть большое количество объектов Item. С каждым элементом связано множество изображений высокого разрешения. Кроме того, каждый элемент принадлежит к категории элементов, которая может содержать 100 элементов.

Насколько я могу судить, у меня есть несколько разных вариантов кодирования:

  1. Кодировать весь объект ItemCategory
  2. Удалите класс ItemCategory, создайте только свойство itemCategory для каждого объекта Item и просто закодируйте отдельные объекты Item.

Мне кажется, что №1 будет расточительно дорого. Чтобы добавить новый элемент в ItemCategory, мне придется декодировать всю ItemCategory (что означает декодирование тех сотен изображений, связанных с содержащимися в нем элементами), добавить элемент, а затем перекодировать все это. (опять же, вместе со всеми этими изображениями).

Но № 1 кажется правильным способом сделать это с точки зрения структуры кода. # 2 заставляет меня придумать менее интуитивный способ хранения элементов и связывания их с соответствующими категориями элементов.

Если бы я пошел с # 1, есть ли способ декодировать только определенные части объектов, чтобы я не получал инициализацию всех этих изображений, когда мне на самом деле не нужно их отображать? Одна мысль, которая пришла мне в голову, заключается в том, чтобы на самом деле не кодировать UIImages Item вместе с самим Item, а просто имя изображения. Таким образом, образ будет инициализироваться только при необходимости, и его можно будет выпустить, не высвобождая весь элемент, если это необходимо. Я полагаю, что это своего рода подход к реляционной базе данных.

Я чувствую, что должен быть стандартный способ справиться с такой ситуацией, не так ли?

Или мой страх по поводу потребления памяти необоснован? Возможно, это можно рассматривать как пример «преждевременной оптимизации», но решение, которое я принимаю сейчас, сильно повлияет на структуру данных приложения. Переход с варианта № 1 на вариант № 2 в будущем был бы некрасивым :)


person maxedison    schedule 01.12.2011    source источник


Ответы (1)


Возможно, вы можете использовать CoreData и постоянный магазин. CoreData упрощает управление отношениями. Вы можете создавать объекты, которые имеют отношения, управляемые системой. Итак, в вашем случае, возможно, у вас может быть 3 объекта: категория, элемент и изображения, а также отношение «один ко многим» между категорией и элементами и отношение «один ко многим» между элементом и изображениями, что означает, что каждая категория может иметь несколько элементов , и у каждого элемента есть несколько изображений, тогда, когда вам нужно, вы можете создавать новые изображения и добавлять их к определенному элементу или искать все изображения в элементе.

Я надеюсь, что это было понятно, но CoreData отлично подходит для управления отношениями, и с моделью данных очень легко работать.

person tams    schedule 01.12.2011
comment
Это, безусловно, пришло мне в голову, когда я начал думать о том, чтобы просто кодировать имя изображения при кодировании объекта Item, а не кодировать изображение вместе с ним. Правда в том, что у меня нет четкого представления о том, когда лучше использовать NSCoding, а когда CoreData. Не могли бы вы уточнить это? Потому что кажется, что я мог бы создать эти отношения с помощью NSCoding, поэтому я действительно не понимаю преимущества, которое может предоставить CoreData. - person maxedison; 01.12.2011
comment
CoreData реализован поверх базы данных. Важной особенностью здесь будет то, что он ошибается в объектах по мере необходимости. - person David Dunham; 01.12.2011
comment
@maxedison Я думаю, что вы можете добиться одного и того же с помощью обоих методов. NSCoding легко реализовать, но я думаю, что CoreData проще запрашивать, чтобы вы могли легко получить только одно изображение из элемента определенной категории. Но Core Data может быть немного сложным, и работая с ним, я обнаружил, что его труднее изменить, но это работает для меня, особенно потому, что для моего приложения важны отношения, которые CoreData обрабатывает неявно, что является еще одним преимуществом. - person tams; 02.12.2011
comment
Спасибо, парни. Я собираюсь начать изучать Core Data, прежде чем принимать решение. - person maxedison; 03.12.2011