Jakie są różnice między używaniem GetComponent < Transform > () a this.transform?

Szybkość (od szybko do wolno):

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

A jeśli zdemontujesz plik binarny UnityEngine.dll C #, zobaczysz, że transformacja nie wywołuje GetComponent (składnik klasy Component), po prostu wywołuje wewnętrzną metodę wykonawczą mono. Oto kod transformacji.

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

A oto zdemontowana metoda GetComponent klasy Component.

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 to rodzaj funkcji znajdującej przy użyciu typów ogólnych. Jest więc „trochę wolniejsza niż buforowanie.

Oryginalne źródło:

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

Zdemontowany plik binarny:

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>(); } } 

Jak Jinbom powiedział, że główną różnicą jest tutaj szybkość.

Należy jednak pamiętać, że dotyczy to tylko właściwości transform GameObject. Inne właściwości, takie jak kamera i sztywna obudowa, są po prostu właściwościami wygodnymi i wywołaj GetComponent <> pod maską, aby wydajność była identyczna. Z tego powodu Unity usunęło te „pomocnicze” właściwości w Unity, ponieważ nie jest od razu oczywiste, że Unity będzie szukać komponentu zamiast zwracać wersję z pamięci podręcznej.

Z wyjątkiem transform, o której mowa w pytaniu, wszystkie inne komponenty powinny być buforowane przy pierwszej możliwej okazji przy użyciu GetComponent <>, a następnie należy użyć tej wartości z pamięci podręcznej.

W tej chwili możesz założyć, że każdy obiekt gry będzie miał komponent Transform ze względu na składnię this.transform. Domyślam się, że Unity zaktualizowało swoje API za pomocą składni GetComponent<>(), aby w przyszłości móc mieć GameObjects bez „specjalnych” komponentów, takich jak Transform.

Następnie może mieć „czystszą” architekturę, w której GameObjects nie muszą przychodzić z transformacjami (chociaż edytor może nadal dodawać je domyślnie jako konwencję).

Komentarze

• Transform to jedyny komponent, który działa w ten sposób. Niezależnie od tego nie ' Nie sądzę, aby poleganie na przyszłych spekulacjach stanowiło dobrą odpowiedź. Jedność nie przedstawiła żadnych sugestii, aby pójść w ten sposób, a ja osobiście wątpię, że tak się stanie (biorąc pod uwagę, że posiadanie fizycznego obiektu w twojej grze wymaga , aby obiekt zawierał informacje dotyczące jego stanu fizycznego, takie jak pozycja i rozmiar ).
• Wydaje się również, że to komentarz na moje pytanie, ale nie odpowiada.

Jedynym powodem, dla którego this.transform w ogóle działa, jest to, że MonoBehavior implementuje wygodną właściwość komponentu Transform w GameObject, do którego jest dołączone zachowanie. … To raczej mylące. Myślę, że gameObject.transform jest bardziej poprawne semantycznie, ale to „rozdwajanie włosów”. Robią to samo.

Komentarze

• To nie daje odpowiedzi na moje pytanie. Jedynym powodem, dla którego cokolwiek działa, jest to, że zostało skonfigurowane, o co ci chodzi? Pytam o różnicę między this.transform a GetComponent<Transform>(), a nie this.transform i gameObject.transform.
• Znowu robią to samo.