#ios #serialization
#iOS #сериализация
Вопрос:
Приложение, которое я разрабатываю, использует много списков, которые занимают много места. Я рассматриваю возможность архивирования файлов plist. Во время выполнения приложение разархивирует их в NSData и десериализует в NSDictionary, используя NSPropertyListSerialization для последующего использования.
Есть ли что-нибудь рискованное в этом подходе? Или это бесполезно, если для вывода списка свойств установлена двоичная кодировка.
Комментарии:
1. И какой самый большой размер одного из ваших файлов .plist?
Ответ №1:
Если вы подходите к тому, что рассматриваете возможность архивирования списков свойств для экономии места, я думаю, пришло время перейти к другому формату. Списки свойств хороши для хранения нескольких значений по умолчанию или некоторых настроек, но они не являются заменой базы данных.
Моя рекомендация заключалась бы в том, чтобы рассмотреть возможность переноса этих данных в базу данных Core Data. Если вы пытаетесь встроить большие цифровые файлы в виде элементов в списке свойств, рассмотрите возможность сохранения их как отдельных ресурсов в вашем пакете приложений или в каталоге / Documents вашего приложения.
Core Data позволит вам загружать элементы по мере необходимости, экономя время загрузки и память, а его база SQLite обеспечит быстрое чтение / запись.
Комментарии:
1. Я выбрал plist, чтобы нам было проще редактировать данные / обмениваться ими с другими пользователями. Данные готовятся многими людьми, поэтому мне нужно иметь возможность использовать простые инструменты для доступа / изменения данных. Вот почему я выбрал маршрут plist. Данные в основном доступны только для чтения, и я не выполняю поиск по ним.
Ответ №2:
Если настройки вашего проекта настроены правильно (то есть, упомянутая вами кодировка вывода списка свойств установлена в двоичном формате в настройках активного целевого объекта), все файлы .plist будут преобразованы в двоичную форму. Загляните в пакет вашего продукта сборки и проверьте, каковы размеры файлов.
Обновить:
Дальнейшее исследование показывает, что если вы добавите каталог, содержащий ваши файлы plist, в качестве ссылки на папку, Xcode не будет заглядывать в него, он просто скопирует его содержимое в созданный пакет. Следовательно, вам следует самостоятельно конвертировать списки с помощью plutil.
Возможный способ автоматизировать задачу — добавить этап сценария сборки к вашей цели в Xcode и заставить его рекурсивно копировать все файлы из каталога A
в каталог B
, преобразуя все файлы, которые заканчиваются на .plist. Затем добавьте B
в свою цель в качестве ссылки вместо A
и все готово.
Вы также могли бы просто создать новый каталог для двоичных списков и добавить их в свой целевой файл вместо обычных списков XML.
Вот как может выглядеть скрипт. Предположим, что все ваши списки plist хранятся в каталоге с именем dir
(или любом из его подкаталогов), и он расположен по адресу path /path/to/dir
. Чтобы преобразовать их все в каталог /path/to/B
, можно написать следующее:
#!/bin/bash
find "/path/to/dir" -iname '*.plist' | xargs -L 1 -J % cp % "/path/to/B"
find "/path/to/B" -iname '*.plist' | xargs -L 1 plutil -convert binary1
Комментарии:
1. Я заглянул внутрь пакета приложений, они все еще в формате xml. И размер точно такой же, как до того, как он был упакован в приложение.
2. Если вы просматриваете пакет приложений с помощью Finder, он отобразит .plist в виде XML. Я просто смотрю Info.plist в одном из моих приложений из Terminal.app, и это в двоичном формате.
cat Info.plist
и дайте мне знать, что вы получите. Затем снова используйтеplutil -convert xml1 Info.plist
иcat
выходные данные.3. Info.plist является двоичным, поэтому другой пользовательский список, который я создал для приложения, расположен на том же уровне, что и Info.plist. Но все остальные файлы plist внутри папки не являются двоичными. Может ли иметь значение местоположение файла plist?
4. Спасибо Алексею. Я проверю ваше решение.