Quali di questi due codici sono "migliori"? Fare una variabile locale o una variabile di classe?

Sto facendo più giochi e faccio domande più stupide.

Spero che questo sia molto breve. Sto creando una classe molto semplice che sposta semplicemente un oggetto Player applicando forza a un corpo rigido, ma mi ha fatto meravigliare, dovrei fare un riferimento di classe all'rb o solo una variabile locale all'interno di Aggiorna ogni frame? (tenendo presente che esiste già nella classe genitore Unità Monobehaviour.GameObject).

Mi chiedo se fare molte variabili locali rallenterebbe il ciclo nel suo insieme (per locale intendo all'interno della funzione stessa e non ai vertici della classe - spero di usare il termine corretto).

Ecco cosa intendo, i due modi in cui stavo pensando di farlo:

public class Player : MonoBehaviour {

private void FixedUpdate()
{
    Rigidbody rb = GetComponent<Rigidbody>();

    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

o...

public class Player : MonoBehaviour {
Rigidbody rb;

private void Awake()
{
    rb = GetComponent<Rigidbody>();
}

private void FixedUpdate()
{
    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

In generale, ho scoperto che dovresti esaminare i dati nel modo più stretto possibile per iniziare e ampliare l'ambito come scopri che è necessario. Ciò significa che se puoi renderlo una variabile locale anziché un membro, probabilmente dovresti iniziare da lì.

Questo perché un ambito più ristretto riduce il numero di posizioni nel codice in cui è necessario ragionare su tali dati e quindi riduce il numero di posizioni che è possibile ragionare in modo errato (il che porta a bug).

Dichiarare effettivamente le variabili locali da sole non sarà mai una preoccupazione per le prestazioni: sono economiche e i compilatori moderni possono persino ottimizzare gli "extra".

Inizializzarli può essere una preoccupazione; nel tuo caso il tuo corpo rigido viene controllato ogni volta tramite GetComponent, che ha un costo diverso da zero. Se sai che il componente del corpo rigido non cambierà per questo particolare oggetto di gioco, puoi cercarlo una volta e memorizzare il risultato in una variabile membro ed evitare un piccolo overhead per chiamata.

È improbabile che l'overhead per chiamata sarà significativo in questo caso, ma col tempo questo potrebbe sommarsi per molti componenti. Vorresti applicare un profiler per essere sicuro.

Quindi, per riassumere: in generale, per impostazione predefinita rendere le cose il più locali possibile, ma in questo caso è probabilmente ragionevole fare rbun membro in modo da poter eseguire la ricerca una volta dentro Awakeed evitare di doverlo fare ogni FixedUpdatechiamata.

La risposta di Josh Petrie è molto buona: ecco una prospettiva complementare.

Quando si lavora con codice di cui si capisce abbastanza bene il dominio, è possibile oscillare le variabili nel punto in cui hanno senso.

Ad esempio, se ho una Personclasse con un waveGoodbyemetodo, è possibile che la mia classe non avesse un handoggetto prima e quindi potrei dichiararlo localmente waveGoodbye. Ora qui è ovvio che una persona ha una mano, quindi potresti dichiararla naturalmente come membro Personsenza pensarci, ma si applica lo stesso problema.

Se dichiari handlocalmente, in seguito potresti aggiungere un karateChopmetodo che richiede anche una mano. Questo è quando dichiarare le variabili localmente può diventare problematico - perché gli sviluppatori junior spesso ricorrono a copiare / incollare la dichiarazione da waveGoodbyee ora hai lo stesso concetto situato in due punti. Eventuali modifiche devono handquindi essere modificate in entrambi i punti e quindi inizia una collina di formiche .

Quindi tutto sommato,

1. Se sei sicuro del posizionamento della tua dichiarazione, cercala dove ha senso.

2. Se non sei sicuro, avvia localmente e assicurati di eseguire il refactoring quando ottieni un soffio di riutilizzo del codice.
   
   

Modifica: Oh, e non fare lo stesso errore che ho di passare troppo tempo a capire dove intendere le tue dichiarazioni. È difficile comprendere la struttura dei tuoi dati in anticipo e mentre scrivi il tuo codice la struttura ha un modo di rivelarsi.