[Unity] Unity의 custom 비교 연산자 ==

Memory Leak(메모리 누수) 관련 구글링 도중 재미있는 내용이 있어 공부해보았다. 

 

https://note4iffydog.tistory.com/81

유니티 - Unity Memory Leak 이유와 관리 방법(Memory Profiler)

위 블로그를 통하여 원문 공부 내용

 

Memory Leak의 원인 중 하나인 instance 잔류 문제에 관한 주제이다. 

Unity 스크립트는 C#으로 작성하지만, 엔진은 C++로 구성되어있다.

그 실행 과정에서 동적 메모리 관리 방식의 차이에서 발생하는 문제였다. 

 

C++과 C#의 가장 큰 차이가 포인터 개념의 명시적 차이라고 생각했는데,

Unity Engine에서 C# Object를 C++의 Native Object의 포인터로 사용하고 있어 재미있었다. 

 

https://unity.com/kr/blog/engine-platform/custom-operator-should-we-keep-it

Custom == operator, should we keep it?

 

Untiy 공식 블로그에 따르면, null 체크를 하기 위한 아래 코드의 역할을 설명하고 있다. 

if (myGameObject == null) {}

 

역할

1. Editor에서 myGameObject가 Monobehavior 객체 필드인 경우, null이라면 해당 필드를 실제 null로 설정하지 않고있다. 

== 연산자를 통해 가짜 null 객체로 정보를 설정하여 전달하고, null 참조 오류에 대한 정보를 에디터에 표시하는 역할을 하고 있다. 

 

2. C#의 GameObject는 실제 C++ 엔진 내부의 Native Object에 대한 포인터(wrapper object)이다. 

C++의 Native Object는 명시적 lifetime을 가져 직접 관리하지만, C#의 Object는 GC가 알아서 lifetime을 관리하기 때문에 Destroy된 Native Object를 Object가 GC에 의해 정리되기 전에 참조한다면 null을 반환한다.

(1번 과정을 통하여 가짜 null 반환)  

 

 

블로그에서는 이 ==연산자에 대한 단점도 말하고 있다. 

단점

1. 직관적이지 않다. 

 

2. ==연산자는 thread에 안전하지 않아 외부 thread에서는 비교 불가능

 

3. ??연산자와는 일관성 없이 작동한다. 

??와 == 연산자 모두 null을 검사하지만, ??는 진짜 null을 반환한다. (역할 1 수행하지 못 함)

 

이후는

아래 참조 내용들, object.destroyed로 바꾸는 것을 고려하지만 사용자 경험적 관점에서의 고민들이 적혀있다. 

null을 체크하여 가짜 null object를 반환하는 과정이 생각보다 비용이 많이 든다는 내용 또한 적혀있다. 

역할1번은 빌드파일이 아닌 에디터에서만 가짜 null을 반환하는 과정을 거치기 때문에 프로파일링은 실제 빌드 파일로 진행해야 한다고 한다. 

 

 

이에 ??연산자 또한 공부해보았다. 

실제 회사에서 업무를 진행하며 실무 코드를 보게 되었는데, null 체크를 위 방식이 아니라 .? 연산자를 사용하여 진행하고있었다. 이에 ?.와 ?? 연산자도 궁금하여 공부해보았다. 

 

 

- ?. 연산자와 ?? 연산자 -

2024.08.23 - [Unity/공부] - [Unity] ?. 연산자와 ?? 연산자

[Unity] ?. 연산자와 ?? 연산자