Влияет ли GetComponent <> () на производительность - PullRequest
0 голосов
/ 07 мая 2018

Как и в заголовке, GetComponent () сильно влияет на производительность.

Я спрашиваю об этом, потому что мне не нравится делать это так:

public class Player : MonoBehaviour
{
    PlayerStats playerStats = this.GetComponent<PlayerStats>();

    void Update()
    {
        var something = playerStats.Asd;
    }
}

Вместо этого мне нравится использовать это так:

public class Player : MonoBehaviour
{
    void Update()
    {
        var something = this.GetComponent<PlayerStats>().Asd;
    }
}

Причина этого в том, что мне нравится разбивать код на множество скриптов (мне легче потом что-то изменить, если необходимо, а также использовать один скрипт для нескольких объектов), и поэтому, если у меня много скриптов, мне нужно посмотреть если я уже определил PlayerStats playerStats...., но не только этот, но о многих из них.

Значит, использование второго подхода сильно замедлит мою игру?

Ответы [ 3 ]

0 голосов
/ 07 мая 2018

Стоит отметить, что ваш первый скрипт недействителен и не будет компилироваться. Правильный способ сделать это - сделать ее глобальной переменной, но кэшировать или инициализировать скрипт в функции Start или Awake. Эти функции запускаются один раз и используются для инициализации.

Примерно так:

PlayerStats playerStats;

void Start()
{
    playerStats  = this.GetComponent<PlayerStats>();
}

Чтобы ответить на ваш вопрос, функция GetComponent, влияющая на производительность, сильно преувеличена. Вы читаете это везде в Интернете, но это зависит от того, как часто оно используется. Если он используется время от времени или только в нескольких сценариях, то это совершенно нормально.

Если у вас есть сотни экземпляров сценариев, использующих GetComponent в функции Update, тогда вы начнете замечать небольшое снижение производительности, поскольку GetComponent выполняет вызов на нативную сторону. Итак, это зависит от того, как часто он вызывается и сколько экземпляров сценариев делают этот вызов в каждом кадре.


0 голосов
/ 07 мая 2018

Не думаю, что это действительно имеет значение. Я только что проверил и использовал цикл for, который зацикливался 1 000 000 раз и нашел одинаковую задержку 0,02 между двумя кадрами.

Это, как говорится, сделает ваш код чище, потому что Player.Stats.Asd чище, чем Player.GetComponent<PlayerStats>().Asd. Это делает более очевидным, каково намерение. Я уверен, что это все еще микрооптимизация, чтобы сохранить ее как переменную с public PlayerStats Stats { get; set; }, но это действительно, если вы используете это все время.

Вы не должны использовать переменную для каждого Component, потому что если вы сделаете это для каждого скрипта, используемая память начнет увеличиваться.

Также обратите внимание, что я называю это Stats, а не PlayerStats, потому что Player.PlayerStats излишне избыточен. Фактический тип должен называться PlayerStats да, чтобы не путать его, скажем, с EnemyStats, но когда вы собираетесь использовать оба, наличие Player.Stats и Enemy.Stats чище.

0 голосов
/ 07 мая 2018

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

Второй экземпляр вашего GetComponent вызова функции означает, что вы не кэшируете свои переменные, замедляя свой код с потенциально ненужными проверками.Поэтому мой совет - придерживаться первого экземпляра, в котором ваша переменная определяется в памяти, а затем изменяется, вместо того, чтобы каждый раз выделять память и затем изменять.

И примечание.Вам не нужно вызывать this.GetComponent, если скрипт присоединен к объекту, так как скрипт происходит от MonoBehaviour;Вы можете просто позвонить GetComponent<type>() и провести свой веселый день.:)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...