-
iOS UI Hitch를 진단하는 법: Render Loop와 프레임 파이프라인WWDC 정리 2026. 9. 22. 23:48반응형
스크롤이 잠깐 멈추거나 화면 전환이 한 번 튀는 현상은 보통 ‘FPS 저하’로 설명된다. 하지만 iOS에서 실제로 확인해야 할 문제는 단순한 평균 FPS가 아니라, 새 프레임이 다음 표시 시점(VSYNC)까지 준비되지 못한 이유다. Apple Tech Talk 「Explore UI animation hitches and the render loop」를 바탕으로 UI hitch를 진단하는 기준을 정리한다.
Hitch: 이전 프레임이 한 번 더 보이는 순간
Hitch는 프레임이 기대한 시점보다 늦게 표시되는 현상이다. 다음 프레임이 마감 시각을 놓치면 시스템은 기존 프레임을 한 번 더 표시한다. 사용자는 콘텐츠가 멈췄다가 앞으로 점프하는 것처럼 느낀다. 스크롤, 애니메이션, 전환처럼 입력과 화면 변화가 직접 연결된 구간에서 특히 민감하다.

따라서 문제를 찾는 출발점은 ‘무엇이 느렸는가’보다 어느 단계가 다음 VSYNC를 놓쳤는가여야 한다. 일반적인 60Hz 화면에서는 프레임 하나가 약 16.67ms의 간격으로 표시되고, 120Hz 모델에서는 그 간격이 약 8.33ms로 줄어든다. 중요한 것은 숫자 자체가 아니라, 그 시간 안에 프레임 파이프라인 전체가 완료되어야 한다는 점이다.
Render Loop는 하나의 작업이 아니라 파이프라인이다
Render Loop는 이벤트가 앱에 들어온 뒤 UI 변경이 화면에 나타날 때까지의 흐름이다. 터치·타이머·네트워크 콜백이 앱에 전달되고, 앱은 변경 사항을 제출한다. 이후 Render Server가 화면 합성을 준비하고 GPU가 실행한 결과가 다음 VSYNC에 표시된다.

발표는 이를 앱 프로세스, Render Server, Display의 세 단계로 설명하고, 더 세밀하게는 다음 다섯 phase로 구분한다.
- Event: 입력과 콜백을 수신하고 UI 변경을 결정한다.
- Commit: 레이아웃·커스텀 드로잉을 수행하고 변경된 layer tree를 제출한다.
- Render prepare: Render Server가 렌더링 실행을 준비한다.
- Render execute: GPU가 레이어를 합성하고 최종 이미지를 만든다.
- Display: 완성된 프레임을 다음 VSYNC에 표시한다.
이 분해가 중요한 이유는 ‘메인 스레드가 바쁘다’만으로 모든 hitch를 설명할 수 없기 때문이다. 앱이 commit을 제때 마쳤더라도 Render Server나 GPU가 늦으면 화면은 여전히 끊길 수 있다.

Commit hitch와 Render hitch를 분리해서 봐야 하는 이유
Commit hitch는 앱 프로세스가 Event 또는 Commit phase에서 마감 시각을 넘긴 경우다. 무거운 이벤트 처리, 레이아웃 계산, 동기 I/O, 커스텀 드로잉처럼 앱 쪽 작업이 원인이 될 수 있다. 다음 VSYNC 시점에 Render Server가 처리할 새 제출물을 받지 못하므로 파이프라인 전체가 한 프레임 늦어진다.
Render hitch는 앱이 제출을 제때 했지만 Render prepare 또는 Render execute가 늦어진 경우다. 이때는 복잡한 layer tree, 과도한 블렌딩, 오프스크린 렌더링, GPU 부하가 후보가 된다. 두 유형은 화면에서는 동일한 끊김으로 보이지만, 조사할 프로파일과 최적화 지점은 전혀 다르다.

Hitch time ratio: 평균 FPS보다 먼저 볼 수 있는 지표
개별 hitch의 길이는 한 사건을 설명한다. 하지만 스크롤처럼 긴 상호작용과 짧은 전환을 비교하려면 구간 단위의 지표가 필요하다. Apple은 hitch time ratio를 구간의 총 hitch time을 구간 지속 시간으로 나눈 값으로 설명한다.
hitch time ratio = 구간의 총 hitch time ÷ 구간의 지속 시간
단위는 ms/s다. 즉 사용자가 1초 동안 끊김을 경험한 시간이 얼마인지 보여 준다. 이 지표는 절대적인 통과 기준이라기보다, 개선 우선순위를 정하는 데 유용하다. 특정 전환이나 스크롤 구간에서 비율이 높다면 평균 FPS가 좋아 보여도 별도로 조사할 근거가 된다.

UI hitch를 조사하는 순서
- 사용자가 끊김을 느낀 정확한 동작을 재현한다.
- 프레임이 어느 VSYNC를 놓쳤는지 확인한다.
- Event/Commit 지연인지, Render Server/GPU 지연인지 분리한다.
- 개별 hitch와 구간 전체의 hitch time ratio를 함께 비교한다.
- 수정 후 동일한 사용자 동작에서 끊김이 실제로 줄었는지 다시 측정한다.
핵심은 ‘프레임 수를 높인다’가 아니다. 이벤트 처리, commit, 렌더링 준비, GPU 실행이 각각의 마감 시각을 지키도록 병목을 식별하고 제거하는 일이다. Render Loop 관점은 UI 끊김을 하나의 증상이 아니라, 진단 가능한 파이프라인 문제로 바꿔 준다.
참고
Apple Tech Talk — Explore UI animation hitches and the render loop
https://developer.apple.com/videos/play/tech-talks/10855/반응형