GetComponent < Transform > ()와 this.transform 사용의 차이점은 무엇입니까?

속도 (빠름에서 느림) :

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

그리고 UnityEngine.dll C # 바이너리를 디스 어셈블하면 변환이 GetComponent (Component 클래스 멤버)를 호출하지 않고 내부 모노 런타임 메서드를 호출하는 것을 볼 수 있습니다. 다음은 변환 코드입니다.

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

그리고 여기에 분해 된 Component 클래스의 GetComponent 메서드가 있습니다.

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는 제네릭을 사용하는 일종의 Finding 함수입니다. 따라서 “캐싱보다 약간 느립니다.

원본 출처 :

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

바이너리 분해 :

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

As Jinbom은 여기서 가장 큰 차이점은 속도라고 말했습니다.

그러나 이것은 GameObject의 transform 속성에만 해당된다는 점에 유의해야합니다. 카메라 및 강체와 같은 다른 속성은 편의 속성 일 뿐이며 성능이 동일하도록 내부에서 GetComponent <>를 호출합니다. Unity가 캐시 된 버전을 반환하는 대신 구성 요소를 검색 할 것이 분명하지 않기 때문에 Unity가 Unity에서 이러한 “도우미”속성을 무시한 이유입니다.

질문에 언급 된 transform 속성을 사용하는 경우 다른 모든 구성 요소는 GetComponent <>를 사용하여 첫 번째 사용 가능한 기회에 캐시되어야하며 그 이후에 캐시 된 값을 사용해야합니다.

지금은 this.transform 구문으로 인해 모든 게임 개체에 Transform 구성 요소가 있다고 가정 할 수 있습니다. 제 생각에는 Unity가 GetComponent<>() 구문으로 API를 업데이트했기 때문에 나중에 Transform과 같은 “특별한”구성 요소없이 게임 오브젝트를 가질 수있었습니다.

그런 다음에는 게임 오브젝트가 Transforms와 함께 제공되지 없는 “순수한”아키텍처를 가질 수 있습니다 (편집자가 여전히 기본적으로 규칙으로 추가 할 수 있음).

댓글

댓글

• Transform 는 이러한 방식으로 작동하는 유일한 구성 요소입니다. 어쨌든 저는 ' 미래의 추측에 의존하는 것이 좋은 답이라고 생각하지 않습니다. Unity는 이러한 방식으로 이동하는 것에 대한 제안을 보여주지 않았으며, 개인적으로 그럴 것이라고 생각합니다 (게임에 물리적 인 물체가 있다는 점을 감안할 때 위치 및 크기 와 같은 물리적 상태와 관련된 정보를 포함해야합니다.
• 또한 이것은 주석으로 보입니다. 내 질문에 대한 답변이 없습니다.