Today I Learned - Day 60 [Get Component 최적화]

※ 금일의 TIL은 다소 간단하게 작성할 예정이다.

 

Unity를 다루는 사람이라면 다들 GetComponent가 무거운 연산이라는 것은 익히 알고 있을 것이다.

그럼에도 이를 안 쓸 수가 없는 영역이라는 것도 알고 있을 것이다.

그렇다면 이에 의해서 발생하는 문제점은 무엇이고, 어떻게 대처해야 하는 가.

오늘을 이에 대해서 정리할 예정이다.

---

GetComponent, TryGetComponent, GetComponentInChilren

게임오브젝트에서 컴포넌를 가져오는 함수들이다.

각각 다음 동작을 수행한다.

• GetComponent<T>() : 해당 GameObject에서 컴포넌트를 가져오는 함수. 없을 경우 null값이 반환된다.
• TryGetComponent(out T): 해당 GameObject에서 컴포넌트를 가져와 '보'고, 가져왔다면 true를, 실패했다면 false를 반환한다.
• GetComponentInChildren<T>(): 해당 GameObject '와' 하위 GameObject들에서 원하는 종류의 컴포넌트 중 가장 먼저 검색되는 컴포넌트를 반환한다.
  • 반환값을 배열으로 형성할 수도 있다. < T[] GetComponentInChildren<T>() >

'탐색' 함수인 만큼, 셋 다 연산이 무거운 편이다. 특히 하위 오브젝트 까지 다 검색하는 GetComponentInChildren이 특히 더 무거운 편.

때문에 남용하는 것은 좋지 않으나, Unity로 게임을 만들다 보면 결국 어마어마하게 사용할 수 밖에 없는 기능.

그러면, 사용하는 것을 조금이나마 줄이면 될 터다.

그 방법을 간략하게 정리 해 보자.

---

초기화에서 미리 해 놓기

초기화를 할 때에 GetComponent로 변수 할당을 하고, 나머지는 객체 간 상호작용으로 교환하는 방식을 사용하는 방법.

어떤 컴포넌트가 필요한지 미리 설정 해 두고 미리 가져와야 하기 때문에 전체적인 구조에 따라서 지속적으로 수정, 보완, 삭제를 해 줘야하긴 하지만, 사실상 이게 정석이라고 해야 될 정도로 획기적으로 GetComponent의 수가 줄어든다.

특히 Pacade 패턴을 활용해서 구성하면 정말로 깔끔하고 효율성 높은 구성을 형성할 수 있게 된다.

---

중재자를 통한 교환

중재자 오브젝트를 경유해서 컴포넌트를 가져올 수 있도록 구성하는 방법.

충돌 판정 같은 경우에는 사용하기 난감해 지기는 하지만, 일단 사용할 수 있는 분야 쪽에서는 GetComponent의 횟수를 크게 줄일 수 있다.

중재자로는 싱글톤을 쓰는 것이 대체로 편한 편이다. 또한 생성 주체가 중재자 역할을 맡는다던지 하는 방법도 있다.

---

오브젝트 풀

이건 컴포넌트와 관계 없지 않는가? 라고 할 수도 있는데, 이미 GetComponent를 해 둔 오브젝트를 오브젝트 풀으로 비축해 둔 뒤에 불러와서 쓰는 것.

오브젝트 풀 자체가 '생성과 파괴의 부하를 줄이기 위해서' 쓰는 기법인지라, 유사한 상황에서 문제가 되는 GetComponent에도 유효한 편이다.

 

브릿지 패턴이나 FSM과 같은 디자인 패턴도 같이 활용하여 내부 클래스를 변경하는 것으로 여러 기능을 아우를 수 있게 구성하는 방식으로 오브젝트 풀의 효율을 더 높일 수도 있다.

[물론, 이는 GetComponent의 설명이라기 보다는 오브젝트 풀의 설명에 가깝긴 하다.]

---

Unity를 다루다 보면 의외로 GetComponent로 인해서 최적화 이슈가 발생하는 경우가 꽤 잦다.

Unity Editor 자체의 한계인 경우도 있기는 하지만, 그렇다고 매번 빌드 해서 테스트를 할 수는 없는 노릇이니 말이다.

그렇다 보니, 개인적으로는 GetComponent를 줄이는 방법에 대해서는 어느 정도 숙제해둬야할 것이라고 생각한다.

아마 상기한 방법 말고도 이래저래 많이 있을 것이다.