iOS: лучший способ кодировать / декодировать объекты, интенсивно использующие память - PullRequest
2 голосов
/ 01 декабря 2011

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

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

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

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

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

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

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

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

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

1 Ответ

0 голосов
/ 01 декабря 2011

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

...