긴 프레임이 일이 아니라 기다림일 때

멀쩡한 코드를 며칠 뜯게 되는 착각

프로파일러에서 가장 긴 막대를 보고 그 함수를 고치려 드는 게 보통입니다. 그런데 모바일 빌드에서 자주 나오는 가장 긴 막대는 실제 계산이 아니라 화면 출력을 기다리는 구간입니다. 이걸 작업으로 착각하면 아무 문제 없는 코드를 며칠 뜯습니다.

타임라인에서 볼 건 두 가지입니다. 긴 프레임이 규칙적으로 번갈아 나오는가, 그리고 그 안에서 제일 큰 덩어리가 대기 마커인가.

에디터 프로파일링으로는 안 보입니다

에디터는 창 안에서 렌더링하니 기기의 표시 동기화와 조건이 다릅니다. 프레임 페이싱 문제는 기기에 붙은 빌드에서만 제대로 보입니다.

1. 개발 빌드로 만들고 오토커넥트 프로파일러를 켭니다.
2. 기기에서 실행하고 프로파일러를 붙입니다.
3. 타임라인 뷰로 바꿔 한 프레임 안의 구성을 봅니다.
4. 대기 마커의 비중을 먼저 읽습니다.

// 내 코드 구간에 이름을 붙여 두면 대기와 구분이 쉽습니다
static readonly ProfilerMarker BallStep = new("IceBreaker.BallStep");

void FixedUpdate()
{
    using (BallStep.Auto())
        StepBalls();
}

대기가 크게 나올 때 보는 값

표시 동기화 설정과 목표 프레임 레이트가 서로 안 맞으면 대기가 커집니다. 목표를 30으로 두고 동기화를 매 프레임으로 잡으면 남는 시간이 전부 대기로 잡힙니다.

Application.targetFrameRate = 60;
QualitySettings.vSyncCount = 0; // 모바일에서는 플랫폼이 무시할 수 있습니다

대기 비중을 읽고 나면 길이 두 갈래로 갈립니다

남은 긴 프레임이 여전히 내 코드면 그때 함수 단위로 들어갑니다. 반대로 대기가 대부분이면 코드는 놔두고 렌더링 부하와 해상도 스케일부터 봅니다. 이 갈림길을 먼저 정하지 않으면 어느 쪽이든 헛일이 됩니다.