08 · 그래픽스와 UI 렌더링

← 챕터 목록

이 챕터는 "한 프레임이 어떤 경로로 화면에 뜨는가"를 뼈대로, 프레임 예산·CPU와 GPU의 분업·이미지 디코드와 다운샘플링·커밋 트랜잭션 단계별 병목까지 렌더링 성능의 공통 언어를 정리한다. 스크롤이 왜 끊기는지, 어디를 재보고 어디를 고쳐야 하는지를 판단하는 기준을 만드는 게 목표다.

Q1. 화면의 한 Frame은 어떤 단계를 거쳐 표시되는가?

CS 원리

래스터 디스플레이는 프레임버퍼(픽셀 배열)를 일정 주기(refresh rate)로 위에서 아래로 스캔아웃해 화면을 갱신한다. 렌더러가 버퍼를 쓰는 도중에 스캔아웃이 겹치면 화면이 위아래로 어긋나는 tearing이 생긴다. 이를 막으려고 더블/트리플 버퍼링을 두고, 스캔아웃 중인 front buffer는 건드리지 않은 채 back buffer에 렌더한 뒤 VSync 순간에 교체(swap)한다. 렌더링 자체도 "장면 기술 → 기하 변환 → 래스터화 → 합성 → 출력"처럼 여러 단계로 나뉘고, 이를 파이프라인으로 겹쳐 돌리면 처리량은 오르지만 한 프레임의 지연(latency)은 여러 주기로 늘어난다.

iOS에서는

iOS는 앱이 픽셀을 직접 그리지 않고 CALayer 트리만 기술하게 하는 Core Animation 아키텍처다. 실제 픽셀 렌더는 앱과 분리된 Render Server 프로세스가 담당한다. 런루프에 등록된 CATransaction 옵저버가 프레임 끝에서 커밋을 트리거하면, 커밋 트랜잭션 4단계가 돌고 그 결과가 Render Server로 넘어간다. Render Server는 이를 Metal 커맨드로 인코딩해 GPU에 제출하고, 화면 출력은 VSync에 동기화된다. 이 흐름은 WWDC 테크톡 Explore UI animation hitches and the render loop에서 Commit → Render Prepare → Render Execute 단계로 정의한다. 핵심 함의: 앱이 커밋 뒤 잠깐 멈춰도 이미 넘어간 애니메이션은 Render Server가 계속 진행할 수 있다.

실험 · 도구

Instruments의 Animation Hitches / Core Animation 템플릿으로 hitch(예상보다 늦게 표시된 프레임)를 시간(ms) 단위로 잡는다. 어느 프로세스가 늦었는지 — 앱의 커밋인지 Render Server인지 — 를 트랙별로 볼 수 있다. Xcode의 디버그 옵션 "Color Blended Layers", "Color Offscreen-Rendered"로 GPU 쪽 부담 원인을 눈으로 확인하고, os_signpost로 셀 구성처럼 앱 코드의 구간 시간을 직접 계측한다. 예상 결과: 앱이 프레임 예산을 넘기면 커밋 트랙이 길어지고 그 프레임이 드롭돼 화면 갱신 간격이 벌어진다.

프로젝트 적용

• 커밋은 메인 스레드에서 일어난다. 무거운 계산·파싱·디코드는 커밋 이전에 백그라운드에서 끝내라.
• 레이어 트리를 얕고 단순하게 유지하라. Commit 단계 비용은 트리 깊이·레이어 수에 비례한다.
• 애니메이션 진행 중에 레이아웃을 무효화(setNeedsLayout 남발)하지 마라. 매 프레임 재커밋을 유발한다.

꼬리 질문

• 암시적 애니메이션이 도는 도중 앱 메인 스레드가 200ms 블로킹되면 화면은 어떻게 보이는가?
• 더블 버퍼링에서 GPU가 렌더를 제때 못 끝내면 무슨 일이 벌어지고, 트리플 버퍼링은 이를 어떻게 완화하는가?
• SwiftUI는 이 파이프라인의 어느 지점에서 UIKit/Core Animation과 만나는가?

Q2. 60Hz와 120Hz에서 Frame budget은 각각 얼마인가?

CS 원리

budget = 1 / refresh rate. 이 시간 안에 렌더 파이프라인의 각 stage가 완료돼야 다음 VSync에 맞춰 새 프레임을 내보낼 수 있다. 넘기면 그 주기에는 이전 프레임이 한 번 더 표시되고(프레임 반복), 체감상 끊김으로 나타난다. 리프레시가 2배가 되면 예산은 정확히 절반이 된다.

iOS에서는

대부분의 iPhone은 60Hz, ProMotion iPhone은 10~120Hz 가변이다(iPad Pro는 하한이 더 높다). 주의할 함정: ProMotion iPhone에서도 앱 애니메이션은 기본적으로 60fps로 캡된다. 120Hz까지 쓰려면 Info.plist에 CADisableMinimumFrameDurationOnPhone을 true로 넣고, CADisplayLink의 preferredFrameRateRange로 원하는 프레임레이트 범위를 명시해야 한다. 또 하나: 16.67ms를 앱이 통째로 쓸 수 있는 건 아니다. Render Server·GPU 몫이 별도 주기로 필요하므로, 실무 목표치는 그보다 짧게(60Hz에서 커밋 8~10ms 이내 등) 잡는 게 안전하다. 참고로 ProMotion의 실제 리프레시 rate는 연속값이 아니라 최소 프레임 지속시간에 맞춰 양자화된 이산값(120·80·60·48·40·30·24·20·16·15·12·10Hz 등)으로 정해진다.

실험 · 도구

실제 프레임 간격은 CADisplayLink의 timestamp 차이로 직접 잴 수 있다. 정상이면 16.67 또는 8.33ms 근처, 드롭이 나면 그 배수(33.3ms 등)로 튄다.

final class FPSMonitor {
    private var link: CADisplayLink?
    private var last: CFTimeInterval = 0

    // CADisplayLink는 target(self)을 강하게 retain한다. self가 link를,
    // link가 self를 서로 잡아 순환 참조가 생기므로 반드시 stop()으로 끊어야 한다.
    func start() {
        let link = CADisplayLink(target: self, selector: #selector(tick(_:)))
        link.add(to: .main, forMode: .common)
        self.link = link
    }

    func stop() {
        link?.invalidate()   // 순환을 끊어 FPSMonitor(self)가 해제되게 한다
        link = nil
    }

    @objc private func tick(_ link: CADisplayLink) {
        guard last != 0 else { last = link.timestamp; return }  // 첫 프레임은 기준만 잡고 건너뜀
        let delta = link.timestamp - last            // 두 프레임 사이 실제 간격(초)
        last = link.timestamp
        print("frame interval: \(delta * 1000) ms")  // 16.67 / 8.33 근처여야 정상
    }
}

프로젝트 적용

• 120Hz를 타겟하면 예산이 반토막(8.33ms)이다. 스크롤 셀 구성처럼 매 프레임 반복되는 작업의 상한을 그 안으로 맞춰야 한다.
• "60fps 고정"을 코드에 하드코딩하지 마라(예: 애니메이션 스텝을 1/60로 가정). 가변 리프레시에서 깨진다. delta time 기반으로 계산하라.
• 고프레임이 필요 없는 정적 화면에서 굳이 120Hz를 강제하면 전력만 더 쓴다.

꼬리 질문

• 커밋은 8ms 안에 끝나는데 GPU 렌더가 12ms 걸리면, 60Hz와 120Hz에서 각각 무슨 일이 일어나는가?
• 가변 리프레시 환경에서 물리 기반 애니메이션을 프레임레이트와 무관하게 일정하게 만들려면 어떻게 계산해야 하는가?
• 스크롤 중에만 120Hz를 쓰고 정지하면 낮추는 전략을 CADisplayLink로 어떻게 구성하겠는가?

Q3. CPU와 GPU는 렌더링에서 각각 무엇을 담당하는가?

CS 원리

CPU는 소수의 강력한 코어로 분기 많은 순차 로직에 강하고, GPU는 수많은 작은 코어로 같은 연산을 대량 병렬(SIMD)로 처리하는 데 강하다. 래스터화(삼각형을 픽셀로)와 프래그먼트 셰이딩(픽셀별 색 계산)은 픽셀마다 독립적이라 병렬성이 높아 GPU에 적합하다. 반대로 "이 뷰가 어디에 얼마 크기로 놓이는가" 같은 준비·판단은 CPU가 맡는다.

iOS에서는

Core Graphics(Quartz 2D)는 CPU로 비트맵을 그린다. 이 비트맵이 백킹스토어가 되어 GPU 텍스처로 올라간다. Core Animation의 레이어 합성·트랜스폼·투명도 처리는 Metal을 통해 GPU가 한다. 여기서 비싼 패턴이 offscreen rendering이다 — 마스크와 그림자를 함께 쓰거나(예: cornerRadius+masksToBounds+shadow 조합), group opacity를 켜면 GPU가 별도 버퍼에 먼저 그린 뒤 합치는 추가 패스를 강제한다. shouldRasterize는 그 결과를 캐시해 재사용하되, 매 프레임 내용이 바뀌면 캐시가 계속 무효화돼 오히려 손해다.

실험 · 도구

Instruments의 GPU/Metal System Trace로 GPU 시간을, Time Profiler로 CPU 시간을 각각 확인한다. Xcode 디버그 옵션으로 눈으로 판별할 수도 있다 — "Color Offscreen-Rendered"(오프스크린 패스가 노란색으로 표시), "Color Blended Layers"(빨간 영역이 블렌딩 부담), "Color Hits Green and Misses Red"(rasterization 캐시 적중/실패). GPU가 붉게 도배되면 합성·블렌딩·오프스크린이 병목, 반대로 메인 스레드 Time Profiler가 무거우면 CPU 쪽(레이아웃·디코드·drawRect)이 병목이다.

프로젝트 적용

• 오프스크린 렌더를 유발하는 조합(둥근 모서리 + 마스크 + 그림자)을 피하고, 그림자는 shadowPath를 지정해 GPU가 경로를 다시 계산하지 않게 하라.
• 반투명 레이어를 겹겹이 쌓아 블렌딩을 늘리지 마라. 불투명(isOpaque = true)으로 둘 수 있으면 두라.
• drawRect는 정말 커스텀 드로잉이 필요할 때만. 색·모서리·그림자는 레이어 속성으로 GPU에 맡기는 편이 싸다.

꼬리 질문

• 같은 화면이 저사양 기기에서만 끊긴다면, CPU 병목인지 GPU 병목인지 어떻게 좁혀 들어가겠는가?
• shouldRasterize = true가 성능을 오히려 악화시키는 구체적 상황은?
• 그림자에 shadowPath를 주는 것이 왜 GPU 비용을 줄이는가?

Q4. 이미지 Decode가 스크롤을 끊기게 만드는 이유는 무엇인가?

CS 원리

압축 이미지 디코드는 엔트로피 디코딩·역변환(JPEG의 IDCT 등)을 포함한 CPU 집약 작업이다. 결과 비트맵은 폭×높이×픽셀당바이트만큼의 메모리를 차지한다(8비트 RGBA면 픽셀당 4바이트). 예로 12MP 사진(4032×3024)은 디코드하면 약 48MB다. 이 무거운 작업이 메인 스레드(=UI 런루프)에서 돌면 그 시간만큼 화면 갱신이 멈춘다.

iOS에서는

디코드는 이미지가 실제로 화면에 붙어 렌더될 때 lazy하게 일어난다 — imageView.image = ... 시점이 아니라 그 레이어가 커밋/Prepare될 때다. 이걸 앞당겨 백그라운드에서 끝내는 공식 API가 iOS 15+의 byPreparingForDisplay()(비동기) / preparingForDisplay()다. 예전에는 이미지를 CGContext에 한 번 그려 강제 디코드하는 트릭을 썼다. 이미지 처리 모범 사례는 WWDC 2018 Image and Graphics Best Practices에 정리돼 있다.

let raw = UIImage(contentsOfFile: path)!

Task.detached(priority: .utility) {
    let ready = await raw.byPreparingForDisplay()   // 백그라운드에서 디코드 완료
    await MainActor.run {
        if let ready { cell.imageView.image = ready } // 메인 스레드는 표시만
    }
}

실험 · 도구

Time Profiler로 스크롤 중 메인 스레드 스택을 보면 ImageIO/CGImageSource 계열 디코드 프레임이 잡힌다 — 이게 병목의 증거다. Core Animation FPS gauge로 셀이 등장하는 순간 드롭이 몰리는지 확인하고, os_signpost로 셀 구성 시간을 구간 계측한다. 백그라운드 디코드로 바꾸면 메인 스레드에서 디코드 스택이 사라지고 드롭이 줄어드는 걸 확인할 수 있다.

프로젝트 적용

• 리스트·그리드 이미지는 반드시 백그라운드에서 디코드·다운샘플 후 메인에 넘겨라. SDWebImage·Kingfisher 같은 라이브러리는 기본적으로 이걸 해 준다.
• UICollectionViewDataSourcePrefetching으로 곧 보일 셀의 이미지를 미리 디코드해 두라.
• 셀 재사용 시 이전 비동기 디코드 결과가 엉뚱한 셀에 꽂히지 않도록, 완료 시점에 대상 index/식별자를 검증하라.

꼬리 질문

• 같은 파일 크기라도 PNG보다 JPEG 디코드가 더 무겁거나 가벼울 수 있는 이유는?
• 비동기 디코드를 넣었는데도 빠르게 스크롤하면 여전히 끊긴다면, 다음으로 무엇을 의심하겠는가?
• 애니메이션 GIF/APNG처럼 여러 프레임 이미지는 디코드 전략이 어떻게 달라져야 하는가?

Q5. 이미지 Downsampling은 무엇이며 왜 필요한가?

CS 원리

디코드된 비트맵의 메모리는 파일 용량이 아니라 픽셀 수에 비례한다. 표시 크기보다 큰 해상도를 들고 있는 만큼은 순수 낭비다. 목표 크기로 리샘플(다운스케일)해 두면 메모리 점유, 메모리 대역폭, 그리고 GPU가 샘플링할 텍스처 크기가 모두 줄어든다.

iOS에서는

핵심은 CGImageSourceCreateThumbnailAtIndex에 kCGImageSourceThumbnailMaxPixelSize로 최대 픽셀 크기를 지정하고 kCGImageSourceShouldCacheImmediately로 그 시점에 디코드까지 끝내는 것이다. 이렇게 하면 full-resolution 이미지를 거치지 않고 곧장 축소된 비트맵을 얻는다. UIGraphicsImageRenderer로 다시 그려 축소할 수도 있지만, 그 방식은 원본을 먼저 full-decode해야 하는 경우가 많아 메모리 피크를 줄이는 목적에는 ImageIO가 유리하다. (WWDC 2018 Image and Graphics Best Practices)

func downsample(at url: URL, to pointSize: CGSize, scale: CGFloat) -> UIImage? {
    let srcOpt = [kCGImageSourceShouldCache: false] as CFDictionary
    guard let src = CGImageSourceCreateWithURL(url as CFURL, srcOpt) else { return nil }

    let maxPixel = max(pointSize.width, pointSize.height) * scale
    let opt = [
        kCGImageSourceCreateThumbnailFromImageAlways: true,
        kCGImageSourceShouldCacheImmediately: true,       // 이 시점에 디코드까지 완료
        kCGImageSourceCreateThumbnailWithTransform: true, // EXIF 회전 반영
        kCGImageSourceThumbnailMaxPixelSize: maxPixel
    ] as CFDictionary

    guard let cg = CGImageSourceCreateThumbnailAtIndex(src, 0, opt) else { return nil }
    return UIImage(cgImage: cg)
}

실험 · 도구

Instruments Allocations / VM Tracker(또는 Memory graph)로 이미지가 차지하는 메모리를 다운샘플 전후로 비교한다. 예상 결과: 원본 그대로 로드하면 이미지 하나가 수십 MB를 잡지만, 목표 크기(스케일 포함)로 다운샘플하면 그 크기 제곱에 비례해 수십~수백 KB 수준으로 떨어진다. 스크롤 중 메모리 증가 곡선과 디코드 시간이 함께 줄어드는 걸 볼 수 있다.

프로젝트 적용

• 목표는 뷰의 point 크기가 아니라 픽셀 크기다. Retina를 고려해 screen.scale(2x/3x)을 곱해라. 너무 작게 다운샘플하면 화면에서 뭉개진다.
• 서버가 썸네일 URL을 준다면 그걸 먼저 써라. 클라이언트 다운샘플은 원본만 있을 때의 차선책이다.
• 원본 해상도는 확대·상세 화면에서만 로드하고, 리스트에서는 항상 다운샘플본을 캐시해 재사용하라.

꼬리 질문

• 같은 이미지를 여러 크기로 반복 표시한다면 다운샘플 결과를 어떻게 캐시하고 키를 무엇으로 잡겠는가?
• kCGImageSourceShouldCacheImmediately를 켜고 끄는 것이 디코드 타이밍과 메모리에 각각 어떤 영향을 주는가?
• 다운샘플과 Q4의 백그라운드 디코드는 어떻게 한 파이프라인으로 합칠 수 있는가?

Q6. Layout, Display, Commit 단계의 병목은 어떻게 다른가?

CS 원리

파이프라인의 각 stage는 병목의 성격이 다르다 — 어떤 단계는 순수 계산량, 어떤 단계는 픽셀 생성과 메모리, 어떤 단계는 직렬화와 프로세스 간 전송이 지배한다. 그래서 "느리다"는 관찰만으로는 부족하고 어느 stage가 예산을 먹는지 특정해야 올바른 처방이 나온다.

iOS에서는

커밋 트랜잭션은 Layout → Display → Prepare → Commit 4단계다. Layout에서 오토레이아웃은 제약 기반 solver(Cassowary 계열)로 제약 수가 늘수록 비용이 초선형으로 뛴다. Display는 drawRect(_:)를 오버라이드한 뷰에서만 실제로 실행되며 백킹스토어 비트맵을 만든다 — 오버라이드가 없으면 이 단계는 대부분 건너뛴다. Prepare는 이미지 디코드·GPU가 못 쓰는 포맷 변환을 처리한다(그래서 Q4·Q5가 여기 연결된다). Commit은 레이어 트리를 재귀적으로 인코딩해 IPC로 넘기므로 트리가 깊고 넓을수록 비싸다.

실험 · 도구

Time Profiler에서 메인 스레드 스택을 보면 어느 단계가 무거운지 이름으로 드러난다 — layoutSubviews/오토레이아웃 엔진(Layout), -[CALayer display]·Core Graphics(Display), CA::Transaction::commit(Commit). Core Animation 템플릿의 FPS와 병행해 보고, os_signpost로 의심 구간을 감싸 구간별 시간을 직접 잰다. 뷰 계층이 병목이면 Xcode View Debugger로 실제 계층 깊이를 확인하라.

프로젝트 적용

• Layout: 뷰 계층을 얕게, 셀 높이는 미리 계산해 캐시하고, 애니메이션 중 불필요한 setNeedsLayout을 막아라.
• Display: 색·모서리·그림자·그라디언트는 drawRect가 아니라 레이어 속성으로. 반복되는 텍스트/드로잉 결과는 이미지로 캐시하라.
• Commit: 화면당 레이어 수를 줄이고, 거대한 백킹스토어(전체 화면 크기의 비트맵)를 매 프레임 새로 만들어 전송하지 마라.

꼬리 질문

• Time Profiler에서 CA::Transaction::commit이 유난히 길다면, Layout·Display·Commit 중 무엇을 먼저 의심하고 어떻게 구분하겠는가?
• drawRect를 오버라이드하지 않은 순수 오토레이아웃 화면에서도 Display 단계가 비용을 낼 수 있는가?
• 같은 UI를 셀 하나에 30개 서브뷰 vs 3개 레이어로 구성했을 때, 세 단계 각각의 비용은 어떻게 달라지는가?

출처 · 참고자료