관리 메뉴

김종권의 iOS 앱 개발 알아가기

[WWDC2025] SwiftUI 최적화 프로파일링 - Optimize SwiftUI performance with Instruments (5) 본문

최적화하기

[WWDC2025] SwiftUI 최적화 프로파일링 - Optimize SwiftUI performance with Instruments (5)

jake-kim 2025. 12. 24. 01:32

<WWDC 에는 나오지 않지만 중요한 정보>

SwiftUI Instruments 에 중요한 것

https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-256-whats-new-in-swiftui/

빨간색 선 기준

  • 기준: View의 body 계산 시간이 1.0ms를 초과할 때 표시
  • 의미: 매우 심각한 성능 저하 상태
  • 영향: 120Hz 디스플레이(ProMotion) 환경에서 프레임당 가용 시간은 약 8.3ms인데, 뷰 하나 그리는 데 1ms를 넘겨버리면 실제 렌더링 루틴 전체가 꼬이며 눈에 띄는 Hitch(버벅임)가 발생

주황색 선 기준

  • 기준: View의 body 계산 시간이 0.5ms를 초과할 때 표시
  • 의미: 성능 저하 주의 단계
  • 영향: 당장 화면이 멈추지는 않더라도, 이런 뷰가 리스트(List/ScrollView) 내부에 많아지면 누적 연산 시간이 늘어나 프레임 드랍의 직접적인 원인이 됨

수치의 의미

  • SwiftUI의 Render Loop는 단순히 body만 읽고 끝나는 게 아님
  • Body 계산 → 레이아웃 결정 → 뷰 트리 비교(Diffing) → GPU Commit 과정을 한 프레임 안에 다 끝내야 하기 때문
  • 즉, body 연산에서 이미 1ms를 써버리면 나머지 과정을 수행할 시간이 부족해 시스템 전체 성능에 과부하를 줌

과부하 예시) 

  • 리스트 누적 연산: 화면에 셀 10개가 보일 때 각 셀의 body가 1ms라면, 순수 연산만 10ms가 소요되어 ProMotion 기준(8.3ms)을 즉시 초과하고 스크롤 렉을 유발함
  • 프레임 점유율: 120Hz 환경에서 뷰 하나가 1ms를 쓰면 전체 가용 시간의 12% 이상을 혼자 점유하게 되어, 레이아웃 및 GPU 렌더링 등 후속 공정의 시간을 뺏음
  • 복합 계층의 위기: 상위 뷰 변경으로 하위 뷰들이 줄줄이 재계산될 때, 각 서브뷰가 0.5ms씩만 잡아먹어도 전체 렌더링 파이프라인이 금방 마비됨
Comments