작동 방식 (How It Works)
WebAP의 효율성 비결은 모듈성과 수학적 접근 방식에 있습니다. 플러그인은 지연 원인을 "추측"하거나 화면 해상도를 맹목적으로 줄이려 하지 않습니다.
전체 시스템은 Tracker, Indexer, Scalers라는 세 가지 주요 계층으로 구성된 미세 조정된 파이프라인으로 작동합니다.
결정 파이프라인 (Decision Pipeline)
플러그인 아키텍처는 데이터 수집, 의사 결정, 실행을 엄격하게 분리합니다.
1. Tracker (관찰자)
매 프레임마다 Tracker는 프레임 시간과 순수 CPU 시간에 대한 원시 데이터를 수집합니다. 지수 이동 평균(Exponential Moving Average)을 계산하여 가비지 컬렉터(GC) 또는 에셋 로딩으로 인한 무작위 스파이크를 완화합니다.
Tracker는 결정을 내리지 않으며 두 가지 질문에만 대답합니다:
- "Target Min FPS를 따라가고 있나요?"
- "현재 지연되는 특정 하위 시스템(병목 현상)은 무엇인가요?"
2. Indexer (두뇌)
Indexer는 Tracker로부터 데이터를 수신하고 진행 방법을 결정합니다. 시스템의 중재자입니다.
FPS가 떨어지면 Indexer는 다음을 수행합니다:
- 시스템이 Cooldown 상태인지 확인합니다.
- 안티 요요 페널티 시스템을 평가합니다(자세한 내용은 안티 요요 페널티 참조).
- 사용 가능한 모든 Scaler의 비용을 계산합니다.
- 시각적 손상을 최소화하면서 성능을 극대화할 수 있는 Scaler에 명령을 내립니다.
3. Scalers (실행자)
Scaler는 Indexer로부터 명령을 받고 무거운 작업을 수행합니다. Unity API와 상호 작용하고 필수 설정(해상도 감소, 레이어 숨기기, 안티앨리어싱 비활성화)을 적용합니다.
병목 현상 (Bottlenecks): 온도계 없이 한계 찾기
WebAP는 디바이스 센서에 접근하지 않고도 부하 처리 시 무엇이 실패하는지 어떻게 정확하게 파악할까요? 엔진 자체 내에서 타이밍 비율을 분석합니다.
- CPU 병목 현상: Tracker는 메인 프로세서 스레드의 순수 시간을 총 프레임 시간으로 나눕니다. 이 비율이 **85%**를 초과하면 결론은 명백합니다. 프레임은 논리 또는 물리 연산에 의해 제한됩니다. 화면 해상도를 낮추거나 그림자를 끄는 것은 소용이 없습니다.
- GPU 병목 현상: 전체 FPS가 정상보다 낮지만 CPU 비율이 85% 미만인 경우 프로세서가 유휴 상태임을 나타냅니다. 비디오 카드가 제시간에 프레임을 렌더링하지 못하고 있습니다(Fillrate 병목 현상, 복잡한 셰이더 또는 Overdraw).
- 목표 프레임 속도(Target Frame Rate): 평균 VSync 대기 시간이 0보다 크면 프로세서와 비디오 카드 모두 모니터의 새로 고침 빈도보다 더 빨리 렌더링을 마친다는 뜻입니다. 시스템은 성능 여유(Performance Headroom)와 함께 작동하며 Indexer는 그래픽 품질을 원활하게 높일 수 있습니다.
Zero-GC: 성능 우선
지연으로부터 게임을 구하기 위해 고안된 플러그인 자체가 랙을 유발해서는 안 됩니다. WebAP 코어는 Hot Path 전반에 걸쳐 엄격한 메모리 절약(Zero-GC)을 염두에 두고 설계되었습니다.
- O(1) 원형 버퍼:
List<float>및Update의 무거운 루프 대신 Tracker는 고정 크기 배열(Ring Buffers)을 활용합니다. 평균 FPS 계산은 일정한 시간에 실행됩니다. Update에서 할당 제로: 코어에는new호출, 박싱 또는 람다가 포함되어 있지 않습니다. 가비지 컬렉터(GC)가 지울 것이 전혀 없습니다.- 대리자 캐시 (Delegate Cache): 복잡한 작업(
WebScaledPhysics2DRaycaster에서 클릭 가로채기)의 경우에도 느린 리플렉션(MethodInfo.Invoke)을 포기하고 빠른 컴파일된 델리게이트를 사용합니다.
투명성 (Invisibility)
이러한 최적화 덕분에 전체 WebAP 파이프라인의 오버헤드가 최소화됩니다. 프로세서는 모니터링되고 있다는 사실조차 눈치채지 못할 것입니다.