Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Когда и как избежать использования узлов для всего

Узлы дёшевы в производстве, но даже они имеют свои пределы. В проекте могут быть десятки тысяч узлов, которые всё делают. Однако чем сложнее их поведение, тем большее напряжение они вносят в работу проекта.

Godot предоставляет более лёгкие объекты для создания API, которые используют узлы. Обязательно помните об этом как о вариантах при разработке того, как вы хотите построить функции своего проекта.

  1. Object: Максимальный лёгкий объект, исходный объект должен использовать ручное управление памятью. С учётом сказанного, нетрудно создать свои собственные структуры данных, даже структуры узлов, которые также легче, чем класс Node.

    • Пример: Смотрите узел Tree. Он поддерживает высокий уровень настройки для таблицы содержимого с произвольным количеством строк и столбцов. Данные, которые он использует для создания своей визуализации, на самом деле представляют собой дерево объектов TreeItem.

    • Преимущества: Упрощение API до объектов меньшего масштаба позволяет повысить его доступность и сократить время итерации. Вместо того чтобы работать со всей библиотекой Node, можно создать сокращённый набор объектов, из которых узел может генерировать и управлять соответствующими подузлами.

    Примечание

    С ними нужно быть осторожным. Можно сохранить объект в переменной, но эти ссылки могут стать недействительными без предупреждения. Например, если создатель объекта решит удалить его из ниоткуда, это вызовет состояние ошибки при следующем доступе к нему.

  2. RefCounted: Только немного сложнее, чем Object. Они отслеживают ссылки на себя, удаляя загруженную память только тогда, когда больше не существует ссылок на себя. Они полезны в большинстве случаев, когда нужны данные в пользовательском классе.

    • Пример: См. объект FileAccess. Он функционирует так же, как и обычный объект, за исключением того, что его не нужно удалять самостоятельно.

    • Преимущества: такие же, как и у объекта.

  3. Resource: Лишь немного сложнее, чем RefCounted. Они обладают врожденной способностью сериализовать/десериализовать (т.е. сохранять и загружать) свойства своих объектов в/из файлов ресурсов Godot.

    • Пример: Scripts, PackedScene (для файлов сцены) и другие типы, например каждый из классов AudioEffect. Каждый из них может быть сохранён и загружен, поэтому они происходят из Resource.

    • Преимущества: О преимуществах Ресурса перед традиционными методами хранения данных уже много сказано. Однако в контексте использования ресурсов над узлами их основное преимущество заключается в совместимости с Инспектором. Будучи почти такими же легковесными, как Object/RefCounted, они все же могут отображать и экспортировать свойства в Инспекторе. Это позволяет им выполнять ту же задачу, что и вложенным узлам, с точки зрения удобства использования, но при этом повышает производительность, если планируется иметь много таких ресурсов/узлов в сцене.