¿Cuáles son las diferencias entre usar GetComponent < Transform > () y this.transform?

La velocidad (de rápida a lenta):

cached _transform >> Component.transform >> Component.GetComponent<Transform> 

Y si desensambla un binario UnityEngine.dll C #, puede ver transform no llamar a GetComponent (miembro de la clase Component), simplemente llame al método interno de ejecución mono. Aquí está el código de transformación.

// UnityEngine.Component public Transform transform { get { return this.InternalGetTransform(); } } [WrapperlessIcall] [MethodImpl(MethodImplOptions.InternalCall)] internal extern Transform InternalGetTransform(); 

Y aquí está el método GetComponent de la clase Componente desensamblado.

public extern Component GetComponent(Type type); public T GetComponent<T>() where T : Component { return this.GetComponent(typeof(T)) as T; } [WrapperlessIcall] [MethodImpl(MethodImplOptions.InternalCall)] public extern Component[] GetComponents(Type type); 

GetComponent es una especie de función de búsqueda que utiliza genéricos. Por lo tanto, es un poco más lento que el almacenamiento en caché.

Fuente original:

public class Test : MonoBehaviour { Transform _transform; void Start() { _transform = this.transform; _transform = gameObject.GetComponent<Transform>(); } } 

Binario desmontado:

public class Test : MonoBehaviour { private Transform _transform; private void Start() { // == UnityEngine.Component::get_transform() this._transform = base.get_transform(); // == UnityEngine.Component::GetComponent<UnityEngine.Transform>() this._transform = base.get_gameObject().GetComponent<Transform>(); } } 

Como Jinbom dijo que la principal diferencia aquí es la velocidad.

Sin embargo, es importante señalar que este es solo el caso de la propiedad transform de GameObject. Otras propiedades como la cámara y el cuerpo rígido son solo propiedades de conveniencia y llaman a GetComponent <> debajo del capó para que el rendimiento sea idéntico. Es por esta razón que Unity ha desaprobado estas propiedades «auxiliares» en Unity, ya que no es inmediatamente obvio que Unity buscará el componente en lugar de devolver una versión en caché.

Con la excepción de la transform propiedad mencionada en la pregunta, todos los demás componentes deben almacenarse en caché en la primera oportunidad disponible usando GetComponent <> y ese valor en caché debe usarse a partir de entonces.

Ahora mismo puedes asumir que cada objeto del juego tendrá el componente Transformar debido a la this.transform sintaxis. Supongo que Unity actualizó su API con la sintaxis GetComponent<>() para que en el futuro pudieras tener GameObjects sin componentes «especiales» como Transform.

Entonces tú puede tener una arquitectura «más pura» en la que tus GameObjects no tienen que vengan con Transforms (aunque el editor aún podría agregarlos por defecto como una convención).

Comentarios

• Transform es el único componente que actúa de esta manera. Independientemente, yo no ' No creo que depender de la especulación futura sea una buena respuesta. Unity no ha mostrado ninguna sugerencia para moverse de esta manera, y personalmente dudo que lo hagan (dado que tener un objeto físico en su juego requiere que el objeto contenga información pertinente a su estado físico, como posición y tamaño ).
• Además, esto parece comentar en mi pregunta, pero no la responde.

La única razón por la que this.transform funciona es porque MonoBehavior implementa una propiedad de conveniencia para el componente Transform en el GameObject al que está asociado el comportamiento. … Es bastante engañoso. Creo que gameObject.transform es más semánticamente correcto, pero eso es muy divertido. Ellos hacen lo mismo.

Comentarios

• Esto no proporciona nada para responder a mi pregunta real. La única razón por la que cualquier cosa funciona es porque se configuró, ¿cuál es tu punto? Estoy preguntando sobre la diferencia entre this.transform y GetComponent<Transform>(), no this.transform y gameObject.transform.
• De nuevo, hacen lo mismo.