Должен ли список приложений iOS быть сжат в целях оптимизации?

#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. Спасибо Алексею. Я проверю ваше решение.