코루틴 조금 더 자세한 내용

이전글은 여기서 참조하시기 바랍니다.

https://kyungtaek.tistory.com/90

코루틴 정의 및 LifeCycle에서의 순서

---

코루틴 분석

코루틴은 다른 스크립트 코드와 다르게 실행된다고 합니다.

대부분의 Unity 스크립트 코드는 단일 위치의 성능 트레이스 내, 특정 콜백 호출 아래에 나타나지만

반면, 코루틴의 CPU코드는 항상 트레이스의 두 곳에서 나타난다고 합니다.

 

* 두 곳에서 나타난다는 부분은 아직 이해하지 못했습니다.

 

코루틴의 모든 시작 코드(코루틴 메서드의 시작부터 첫 번째 yield문까지)는 Unity가 코루틴을 시작할 때마다 트레이스에 나타납니다.

시작 코드는 StartCoroutine 메서드가 호출될 때마다 종종 나타납니다.

Unity 콜백(IEnumerator를 반환하는 Start콜백 등)에서 생성된 코루틴은 각 Unity 콜백에서 최초로 나타납니다.

 

코루틴의 나머지 코드(즉 다시 시작하는 시점에서부터 실행이 종료될 때 까지의코드)는 Unity 메인 루프에 있는 DelayedCallManager 라인에서 나타나게 됩니다.

이는 Unity가 코루틴을 실행하는 방법 때문에 발생한다고 합니다.

C# 컴파일러는 코루틴을 지원하는 클래스 인스턴스를 자동으로 생성합니다.

그런 다음 Unity는 이 오브젝트를 사용하여 단일 메서드를 여러 번 호출하는 동안 코루틴의 상태를 추적합니다.

코루틴에서 로컬 범위 변수가 yield호출이 진행되는 동안 유지되어야 하기 때문에 Unity는 로컬 범위 변수를 생성된 클래스로 옮깁니다.

이렇게 하면 코루틴이 작동되는 동안 힙에 할당된 상태로 남아있습니다.

이 오브젝트는 또한 코루틴의 내부 상태를 추적하여 yield 호출 이후에 코루틴이 코드의 어느 부분부터 다시 시작해야 하는지를 기억합니다.

 

그렇기 ㅂ때문에 코루틴을 시작할 때 메모리 사용량은 고정된 오버헤드 할당에 로컬 범위 변수의 크기를 합한 양과 동일합니다.

 

코루틴을 시작하는 코드는 오브젝트를 생성하고 호출하며 그 이후 Unity의 DelayedCallManager가 코루틴의 yield 조건이 만족 될 때마다 다시 오브젝트를 호출합니다. 코루틴은 보통 다른 코루틴의 외부에서 시작하기 때문에 이는 yield 호출과 DelayedCallManager 사이에서 실행 오버헤드를 나눕니다.

 

Unity 프로파일러를 사용하여 애플리케이션에서 코루틴을 실행하는 부분을 검사하고 이해 할 수 있습니다.

이렇게 하려면 모든 스크립트 코드를 프로파일링 하고 모든 함수 호출을 기록하는 세부 프로파일링을 활성화하여 애플리케이션을 프로파일링합니다.

그런다음 CPU 사용 프로파일러 모듈을 사용하여 애플리케이션에서의 코루틴을 조사할 수 있습니다.

 

** 일련의 작업을 최대한 적은 수의 개별 코루틴으로 압축하는 것이 가장 좋습니다.

** 중첩 코루틴은 코드 명료성과 유지관리에 용이하지만 코루틴이 오브젝트를 추적하기 때문에 더 많은 메모리가 소모됩니다.

** 코루틴이 매 프레임마다 실행되고 오래 실행되는 작업에서 yield 되지 않는 경우 Update 또는 LateUpdate 콜백으로 대체하는것이 더 효과적입니다.

** 오래 실행되거나 무한 루프되는 코루틴의 경우에 유용합니다.