Комментарии 12
Предположим, что у нас есть класс, состоящий из десяти свойств. Мы сериализовали объект этого класса, поместили в файл, а далее в коде у нас появляется необходимость изменить одно из десяти свойств в JSON файле. Вариант с тем, чтобы десериализовать файл, внести изменение одному свойству, а далее снова сериализовать - плохой вариант, поскольку операции сериализации и десериализации не самые легковесные. Здесь нам на помощь и приходит класс JObject.
Автор же в курсе что это та же самая десериализация только до ~20% медленнее чем десериализация в конкретный тип?
Не знал, в самом деле. Благодарю
Есть список полезностей, если интересно https://stackify.com/top-11-json-performance-usage-tips/
JSON всем хорош (поддержка на всех платформах и лёгкость расшифровки, доходящая до человекочитаемости), кроме увесистого занимаемого объёма.
Если Unity общается с сервером по сети, то уже стоит посмотреть в сторону protobuf/msgpack или бинарных протоколов (с утаптыванием данных в каждый бит), использования алгоритмов сжатия типа zstd/lz4 и тому подобных ухищрений. У них, разумеется, тоже есть недостатки (обе стороны должны иметь алгоритм дешифровки и держать при себе схемы пакетов, например proto-файл в случае выбора protobuf).
В статье нет ничего о Unity. Зачем притягивать её за уши?
Из притянутого за уши, PlayerTransform - неудачное название, сбивает с толку. В примере это чистые координаты.
Почему же? Статья касается движка, хоть и не погружена в него полностью. Были приведены примеры использования JSON в Unity по умолчанию (файлы manifest.json, packages-lock.json), упомянуто про JsonUtility, который является членом API UnityEngine так же, как и некоторые упомянутые в статье свойства. Установка NuGet и Newtonsoft.Json в статье производится в контексте юнити эдитора
Касательно именования класса соглашусь с вами, внесу небольшие изменения в статью
Енамы рекомендую аннотировать StringEnumConverter. Иначе индексы могут поехать, если хранить так данные игрока.
JSON в Unity за 10 минут