25 · 렌더링 심화

P0 08장이 "프레임이 어떤 단계를 거쳐 표시되는가"와 "60/120Hz 프레임 예산"까지였다면, 이 챕터는 그 아래를 판다. 렌더링을 하는 주체가 우리 앱이 아니라는 사실, 다섯 단계가 동시에 서로 다른 프레임을 처리한다는 사실, 그리고 20장에서 미뤄둔 render hitch가 왜 별도 문제인지를 다룬다. 여기서 나오는 수치는 대부분 Apple 문서에 명시된 값이다.

Q1. 렌더 서버는 왜 별도 프로세스인가?

CS 원리

이건 신뢰할 수 없는 클라이언트로부터 공유 자원을 보호하는 고전적 설계다. 디스플레이는 시스템 전체가 공유하는 자원이고, 앱 하나가 그것을 직접 제어하게 두면 그 앱이 멈출 때 화면 전체가 멈춘다.

그래서 대부분의 현대 OS가 컴포지터(compositor)를 별도 프로세스로 둔다 — 각 앱은 "내 화면은 이렇게 생겼다"는 서술만 제출하고, 컴포지터가 그것들을 합성해 최종 화면을 만든다.

iOS에서 그 서술이 레이어 트리다. 앱이 보내는 것은 픽셀이 아니라 "이 위치에 이 크기로 이 콘텐츠를 이 변환으로 놓아라"라는 구조다. 그래서 앱이 커밋을 한 번만 하면, 렌더 서버가 이후 수백 프레임을 앱 없이 진행할 수 있다.

애니메이션이 여기서 특별한 의미를 갖는다. CABasicAnimation을 커밋하는 것은 "0.3초 동안 이 값을 여기서 저기로 바꿔라"라는 명령을 한 번 보내는 것이지, 매 프레임 값을 계산해 보내는 것이 아니다. 그래서 앱이 그 사이에 블로킹돼도 애니메이션은 계속 돈다.

이 구조의 대가는 책임 분산이다. 화면이 끊겼을 때 원인이 두 곳일 수 있고, 어느 쪽인지 구분하지 않으면 엉뚱한 곳을 최적화하게 된다. 20장 Q1에서 본 commit hitch와 render hitch의 구분이 여기서 나온다.

iOS에서는

렌더 서버는 backboardd 안의 서브시스템으로 동작한다고 알려져 있다 (구현 세부 — Apple 미문서화, WWDC 세션과 커뮤니티 관측 기반). 우리가 의존해야 할 것은 프로세스 이름이 아니라 "별도 프로세스가 그린다"는 사실이다. 앱과의 관계에서 실무적으로 중요한 사실이 넷이다.

(1) 커밋은 런루프 틱에 암묵적으로 일어난다. 우리가 view.frame = …을 바꾸면 즉시 전송되는 것이 아니라, 트랜잭션에 모였다가 런루프가 한 바퀴 돌 때 플러시된다. 20장 Q2에서 본 런루프가 여기서도 중심이다. 명시적으로 보내려면 CATransaction.flush()를 쓸 수 있지만, 일반적인 코드에서는 필요 없다.

(2) 애니메이션은 앱 없이 진행된다. Core Animation 애니메이션을 걸어두면 렌더 서버가 매 프레임 보간해 그린다. 그래서 메인스레드가 200ms 막혀도 스피너는 계속 돈다. 반대로 말하면 "스피너가 도니까 앱이 살아 있다"는 판단은 틀렸다 — 20장의 행이 진행 중일 수 있다.

(3) 레이어의 실제 상태는 두 벌이다. 앱 쪽의 모델 레이어(layer)와 렌더 서버 쪽의 표시 상태가 있고, 애니메이션 중에는 둘이 다르다. layer.presentation()이 "지금 화면에 보이는 값"을 근사해 알려준다.

(4) 렌더 서버가 하는 일의 양은 앱이 정한다. 20장 Q1 꼬리질문에서 본 대로 — 별개 프로세스지만 앱을 대신해서 일하고, 그 작업이 너무 복잡하면 제때 못 끝낸다. 레이어 개수, 투명도, 마스크, 그림자, 블러가 전부 렌더 서버의 부하다.

실험 · 도구

"앱이 멈춰도 애니메이션은 돈다"를 직접 확인하면 구조가 손에 잡힌다.

import UIKit

final class RenderServerDemoViewController: UIViewController {
    private let spinner = UIActivityIndicatorView(style: .large)
    private let box = UIView()

    override func viewDidLoad() {
        super.viewDidLoad()
        spinner.startAnimating()                 // Core Animation 애니메이션

        // 레이어에 직접 애니메이션을 건다 — 커밋 후 렌더 서버가 스스로 진행시킨다
        let rotate = CABasicAnimation(keyPath: "transform.rotation.z")
        rotate.fromValue = 0
        rotate.toValue = Double.pi * 2
        rotate.duration = 2
        rotate.repeatCount = .infinity
        box.layer.add(rotate, forKey: "spin")
    }

    @IBAction func blockMainThread() {
        // 메인스레드를 3초 완전히 막는다
        let deadline = ContinuousClock.now + .seconds(3)
        var x = 0
        while ContinuousClock.now < deadline { x &+= 1 }
        _ = x

        // 관찰 결과:
        //   ✅ 스피너와 회전 애니메이션은 계속 돈다 (렌더 서버가 진행)
        //   ❌ 터치·스크롤은 전혀 반응하지 않는다 (메인 런루프가 막힘)
        //   → "애니메이션이 도니 앱이 살아 있다"는 판단이 왜 틀리는지 보인다
    }

    /// 모델 레이어와 표시 상태의 차이
    func inspectLayerState() {
        print("모델 값:", box.layer.transform)                    // 최종 목표 값
        print("표시 값:", box.layer.presentation()?.transform)    // 지금 화면에 보이는 값
        // 애니메이션 중에는 둘이 다르다.
        // 히트 테스트는 모델 값 기준이라 "보이는 곳"을 눌러도 안 먹는 이유가 이것이다.
    }
}

# 렌더 서버 쪽 작업을 관찰한다 — Instruments
#   Animation Hitches 템플릿을 열면 commit / render 단계가 분리되어 보인다
#   앱 트랙과 렌더 서버 트랙이 따로 표시되므로 어느 쪽이 늦는지 바로 안다

# 레이어 구성을 실시간으로 진단한다 — 시뮬레이터 Debug 메뉴
#   Color Blended Layers        : 반투명 합성이 겹친 곳 (빨강일수록 비쌈)
#   Color Offscreen-Rendered    : 오프스크린 렌더링 발생 지점 (Q4)
#   Color Misaligned Images     : 픽셀 정렬이 어긋나 재샘플링되는 이미지
#   Color Copied Images         : GPU가 못 쓰는 포맷이라 CPU가 변환한 이미지

프로젝트 적용

이 구조를 알면 판단이 바뀌는 지점 넷.

• 진단의 첫 질문을 "어느 프로세스인가"로 둔다. 스크롤이 끊길 때 메인스레드부터 보는 것이 습관인데, Animation Hitches로 commit/render를 먼저 구분하면 헛수고를 피한다. 20장 Q1 꼬리질문에서 본 대로 render hitch는 최적화 방향이 완전히 다르다.
• 애니메이션 존재를 앱 생존 신호로 쓰지 않는다. 사용자 제보 중 "화면은 움직이는데 아무것도 안 눌려요"가 정확히 이 상황이다 — 행이다(20장).
• Core Animation에 맡길 수 있는 것은 맡긴다. 타이머로 매 프레임 값을 바꾸는 대신 애니메이션을 걸면, 메인스레드 부하가 사라지고 앱이 잠깐 막혀도 부드럽게 유지된다.
• 레이어 복잡도를 예산으로 관리한다. 렌더 서버의 부하는 우리가 정한다. 특히 셀 하나의 레이어 수는 스크롤 성능에 직접 반영된다.

꼬리 질문

Q2. 렌더 루프 다섯 단계는 어떻게 겹쳐서 돌아가는가?

CS 원리

이건 파이프라이닝이다. CPU 명령어 파이프라인과 원리가 같다 — 한 작업을 여러 단계로 쪼개고, 각 단계가 서로 다른 작업을 동시에 처리하게 한다.

파이프라이닝이 주는 것과 뺏는 것이 명확하다.

세 번째 행이 실무적으로 가장 중요하다. 단계마다 프레임 하나 분량의 시간을 받는다는 뜻이므로, "메인스레드에서 8.3ms를 쓰면 렌더링할 시간이 없다"가 아니라 "메인스레드가 8.3ms를 쓰는 것 자체는 정상 예산 안"이다. 다만 그 예산을 넘기면 문제가 된다.

네 번째 행이 히치의 구조다. 조립 라인에서 한 공정이 늦으면 그 뒤 공정들이 전부 밀린다. 그래서 한 프레임의 지연이 여러 프레임의 지연으로 번진다 — Apple 문서가 "늦은 프레임 하나가 이후 프레임들을 건너뛰게 만드는 경우가 많다"고 설명하는 이유다.

iOS에서는

각 단계에서 무슨 일이 일어나고 누가 책임지는지를 정리하면 이렇다.

앞의 두 단계가 우리 코드이고, 뒤의 두 단계가 렌더 서버·GPU다. 20장 Q1에서 본 commit/render 구분이 정확히 이 경계다.

리프레시 레이트가 가변이라는 점도 중요하다. Apple 문서가 명시하듯 사용자 상호작용 중에는 기기가 지원하는 최대 리프레시 레이트로 갱신하고, 표시할 새 내용이 없으면 일부 디스플레이는 레이트를 낮춘다. 그래서 다음이 따라온다.

• 예산이 상황마다 다르다. 스크롤 중에는 120Hz라 8.3ms이지만, 정지 상태에서는 더 여유가 있을 수 있다. 가장 빡빡한 순간(상호작용 중)을 기준으로 설계해야 한다.
• 측정 시 리프레시 레이트를 함께 봐야 한다. 유휴 구간이 섞이면 평균 프레임 시간이 왜곡된다(20장 Q1 꼬리질문).

그리고 렌더 서버도 앱을 대신해 일한다는 점을 다시 짚어야 한다 — Apple 문서 표현대로 별개 프로세스여도 앱을 위해 작업하며, 그 작업이 너무 복잡하면 제때 못 끝낸다. 그래서 히치를 찾고 이해하려면 메인스레드의 작업과 렌더 서버의 작업을 둘 다 봐야 한다.

실험 · 도구

프레임 간격은 CADisplayLink로 직접 관찰할 수 있다. 단계별 분해는 Instruments가 필요하다 — 아래 코드가 재는 것은 프레임 간격이지 각 단계의 소요 시간이 아니다.

import UIKit
import QuartzCore
import OSLog

/// 커밋 구간과 실제 표시 시점을 각각 관찰한다
final class RenderLoopProbe {
    private let log = Logger(subsystem: "com.example.shop", category: "render")
    private var link: CADisplayLink?
    private var lastTimestamp: CFTimeInterval = 0

    /// (1) 프레임 간격 관찰 — Display 단계의 실제 주기
    func startFrameProbe() {
        let link = CADisplayLink(target: self, selector: #selector(tick(_:)))
        link.add(to: .main, forMode: .common)     // 스크롤 중에도 돌게 (20장 Q2)
        self.link = link
    }

    @objc private func tick(_ link: CADisplayLink) {
        defer { lastTimestamp = link.timestamp }
        guard lastTimestamp != 0 else { return }

        let delta = (link.timestamp - lastTimestamp) * 1000     // ms
        // targetTimestamp - timestamp 가 이번 프레임에 허용된 예산이다
        let budget = (link.targetTimestamp - link.timestamp) * 1000

        if delta > budget * 1.5 {
            log.notice("프레임 지연: \(delta, privacy: .public)ms (예산 \(budget, privacy: .public)ms)")
        }
    }

    /// (2) 커밋에 건 애니메이션이 끝나는 시점 관찰
    ///
    /// ⚠️ CATransaction.setCompletionBlock 은 "이 트랜잭션에 추가된 애니메이션이
    ///    모두 끝났을 때" 불린다. 애니메이션이 없으면 **즉시** 실행되며,
    ///    렌더 서버 도착이나 화면 표시 시점과는 무관하다.
    ///    커밋 구간 자체의 소요 시간은 Instruments 의 Commit 트랙으로 봐야 한다.
    func measureAnimationCompletion(_ work: () -> Void) {
        let start = CACurrentMediaTime()
        CATransaction.begin()
        CATransaction.setCompletionBlock {
            let elapsed = (CACurrentMediaTime() - start) * 1000
            self.log.notice("애니메이션 완료까지 \(elapsed, privacy: .public)ms")
        }
        work()
        CATransaction.commit()
    }
}

CADisplayLink의 targetTimestamp - timestamp가 이번 프레임의 실제 예산이라는 점이 유용하다. 리프레시 레이트가 가변이므로 하드코딩한 16.67ms나 8.3ms 대신 이 값을 쓰면 상황에 맞는 판정이 된다.

# 단계별 분해는 Instruments가 가장 정확하다
#   Animation Hitches 계측기:
#     - Commit 트랙 (앱 메인스레드)
#     - Render 트랙 (렌더 서버 + GPU)
#     - 히치가 발생한 프레임과 그 원인 단계가 색으로 구분된다
#
#   함께 켜면 좋은 것:
#     - Time Profiler  : commit이 늦을 때 메인스레드의 어느 코드가 원인인지
#     - Core Animation : 레이어 수, 오프스크린 렌더링 (Q4)
#     - Metal/GPU      : render execute가 늦을 때 GPU 부하

# 기기에서 실시간 프레임률 확인 (개발 중)
#   설정 › 개발자 › (그래픽 관련 항목) 또는
#   시뮬레이터 Debug › Color Blended Layers 등으로 간접 확인

프로젝트 적용

파이프라인 구조를 알면 달라지는 판단 넷.

• 예산을 단계별로 잡는다. "프레임당 8.3ms"가 아니라 "커밋에 8.3ms, 렌더에 8.3ms"다. 커밋이 6ms 걸린다고 즉시 문제인 것은 아니지만, 예산의 70%를 쓰고 있으므로 여유가 없다.
• 가장 빡빡한 순간을 기준으로 한다. 상호작용 중에는 최대 리프레시 레이트로 돌므로 예산이 가장 작다. 스크롤 중 실행되는 코드가 언제나 1순위 최적화 대상이다(20장 Q1).
• 지연을 프레임 단위로 생각한다. "몇 ms 늦었나"보다 "몇 프레임 밀렸나"가 사용자 체감에 가깝다. 한 프레임 지연도 연속 상호작용에서는 보인다.
• 단계를 구분해 측정한다. 구분 없이 "느리다"만 알면 최적화 방향을 못 정한다. Animation Hitches의 commit/render 분리가 첫 단계다.

꼬리 질문

@objc func tick(_ link: CADisplayLink) {
    // ✅ 표시될 시점 기준으로 계산해야 정확하다
    let t = link.targetTimestamp - startTime
    layer.position.x = interpolate(at: t)

    // 남은 예산을 보고 작업량을 조절할 수도 있다
    let remaining = link.targetTimestamp - CACurrentMediaTime()
    if remaining < 0.002 { skipExpensiveDetail() }
}

let link = CADisplayLink(target: self, selector: #selector(tick(_:)))
// 30~60fps면 충분한 애니메이션이라면 굳이 120fps를 쓰지 않는다
link.preferredFrameRateRange = CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60)
link.add(to: .main, forMode: .common)

Q3. CA commit의 네 단계에서 무엇이 일어나는가?

CS 원리

커밋이 여러 단계로 나뉘는 이유는 의존 관계 때문이다. 각 단계의 결과가 다음 단계의 입력이라 순서를 지켜야 한다.

1. 크기와 위치가 정해져야 무엇을 그릴지 안다 → Layout이 먼저.
2. 그려질 내용이 정해져야 GPU에 올릴 것을 준비할 수 있다 → Display가 그다음.
3. 모든 준비가 끝나야 일관된 상태로 전송할 수 있다 → Commit이 마지막.

여기서 트랜잭션이라는 이름의 의미가 나온다 — 여러 변경을 모아 원자적으로 적용한다. 뷰 열 개의 위치를 바꾸면 열 번 전송되는 것이 아니라 한 번에 간다. 그래서 화면에 중간 상태가 보이지 않는다.

P0 09장에서 본 데이터베이스 트랜잭션과 성질이 비슷하다 — 일관성을 위해 변경을 묶고, 커밋 시점에 한꺼번에 반영한다.

비용 구조에서 중요한 비대칭이 하나 있다. Layout과 Display는 CPU 작업이고 앱 프로세스에서 일어난다. 즉 메인스레드 예산을 직접 먹는다. 반면 실제 렌더링은 렌더 서버와 GPU가 하므로 우리 예산 밖이다. 그래서 커밋 비용을 줄이는 것과 렌더 비용을 줄이는 것은 다른 작업이다.

iOS에서는

단계별로 우리 코드가 개입하는 지점과 비용 요인을 정리하면 이렇다.

Display 단계의 draw(_:)가 특히 오해가 많다. draw(_:)를 오버라이드하면 시스템이 백킹 스토어(비트맵)를 할당하고 CPU로 그린다. 이건 두 가지 비용이다 — 메모리(뷰 크기 × 4바이트)와 CPU 시간. 같은 결과를 layer.cornerRadius나 이미지로 얻을 수 있다면 그쪽이 압도적으로 싸다.

Prepare 단계의 이미지 디코딩이 P0 08장 Q4에서 본 "이미지 디코드가 스크롤을 끊는" 현상의 정확한 자리다. UIImage(named:)는 파일을 읽을 뿐 디코딩을 하지 않고, 실제로 화면에 그려질 때 디코딩이 일어난다 — 그게 이 단계다. 그래서 "이미지를 미리 로드했는데 왜 스크롤이 끊기나"의 답이 여기 있다.

해법은 백그라운드에서 미리 디코딩하는 것이다.

import UIKit
import ImageIO

/// 백그라운드에서 디코딩까지 끝낸 이미지를 만든다 — Prepare 단계 비용을 옮긴다
func decodedImage(at url: URL, maxPixel: Int) async -> UIImage? {
    await Task.detached(priority: .userInitiated) {
        let options = [
            kCGImageSourceCreateThumbnailFromImageAlways: true,
            kCGImageSourceShouldCacheImmediately: true,      // ← 여기서 디코딩까지 끝낸다
            kCGImageSourceCreateThumbnailWithTransform: true,
            kCGImageSourceThumbnailMaxPixelSize: maxPixel,
        ] as CFDictionary

        guard let src = CGImageSourceCreateWithURL(url as CFURL, nil),
              let cg = CGImageSourceCreateThumbnailAtIndex(src, 0, options) else { return nil }
        return UIImage(cgImage: cg)
    }.value
}

// 셀에서는 이미 디코딩된 이미지를 붙이기만 한다
cell.imageView.image = await decodedImage(at: url, maxPixel: 600)
//   → Prepare 단계에서 할 일이 없어 커밋이 가벼워진다

kCGImageSourceShouldCacheImmediately: true가 핵심이다 — 이 옵션이 썸네일 생성 시점에 디코딩까지 완료시키므로, 메인스레드의 Prepare 단계에서 할 일이 사라진다.

실험 · 도구

각 단계의 비용은 layoutSubviews·draw(_:)를 직접 감싸 재고, 나머지는 계측기로 본다.

import UIKit
import OSLog

/// Layout / Display 단계에 우리가 얼마나 쓰는지 직접 계측한다
final class InstrumentedView: UIView {
    private static let log = Logger(subsystem: "com.example.shop", category: "commit")

    override func layoutSubviews() {
        let t0 = CACurrentMediaTime()
        super.layoutSubviews()
        let ms = (CACurrentMediaTime() - t0) * 1000
        if ms > 2 {                       // 프레임 예산의 1/4 이상이면 경고
            Self.log.notice("layoutSubviews \(ms, privacy: .public)ms — \(String(describing: type(of: self)), privacy: .public)")
        }
    }

    override func draw(_ rect: CGRect) {
        let t0 = CACurrentMediaTime()
        super.draw(rect)
        // 여기서 CPU가 픽셀을 그린다. 백킹 스토어도 할당돼 있다.
        Self.log.notice("draw \((CACurrentMediaTime() - t0) * 1000, privacy: .public)ms size=\(NSCoder.string(for: rect.size), privacy: .public)")
    }
}

# Instruments — Core Animation / Animation Hitches 계측기
#   Commit 트랙을 열면 Layout / Display 하위 구간이 분리되어 보인다
#   어느 뷰의 layoutSubviews가 오래 걸리는지까지 추적된다

# 시뮬레이터 Debug 메뉴 — 시각적 진단
#   Color Copied Images   : GPU가 직접 못 쓰는 포맷이라 CPU가 변환한 이미지
#                           → Prepare 단계 비용. 포맷을 맞추면 사라진다
#   Color Misaligned Images : 픽셀 정렬이 어긋나 재샘플링되는 이미지
#                           → frame을 정수 픽셀에 맞추면 사라진다
#   Color Offscreen-Rendered : 오프스크린 렌더링 (Q4)

# 백킹 스토어 메모리 확인 — draw(_:) 오버라이드가 많으면 여기서 드러난다
#   Instruments › Allocations › VM Tracker 에서 IOSurface / CoreAnimation 항목

Color Copied Images가 특히 유용한 진단이다. 서버에서 받은 이미지의 색 공간이나 비트 포맷이 GPU가 직접 쓸 수 없는 형태면, CPU가 매번 변환한다. 이 비용이 Prepare 단계에 그대로 얹힌다. 사전 디코딩 시 표준 포맷으로 정규화하면 사라진다.

프로젝트 적용

커밋 비용을 줄이는 실무 규칙 다섯.

• draw(_:) 오버라이드를 기본적으로 피한다. 둥근 모서리·테두리·그림자는 레이어 속성으로, 복잡한 도형은 CAShapeLayer로, 그라디언트는 CAGradientLayer로 처리한다. 이들은 렌더 서버가 그리므로 메인스레드 예산을 안 먹는다.
• 이미지는 백그라운드에서 디코딩까지 끝낸다. 셀에 붙이는 시점에는 준비된 비트맵이어야 한다.
• 셀 높이를 캐시한다. 오토레이아웃으로 매번 높이를 계산하면 Layout 단계가 무거워진다. 특히 스크롤 중에는 프레임 예산을 직접 잡아먹는다.
• 레이어 수를 예산으로 관리한다. 셀 하나에 레이어 30개면 Commit 단계의 직렬화 비용이 는다. 배경·구분선 같은 것은 그리기보다 레이어가 낫지만, 레이어 수가 과하면 반대가 된다.
• 구조 변경을 최소화한다. 매 프레임 뷰를 추가·제거하면 레이어 트리 구조가 바뀌어 커밋이 무거워진다. 재사용하고 속성만 바꾸는 편이 훨씬 싸다.

꼬리 질문

/// GPU가 바로 쓸 수 있는 포맷으로 정규화한다
func normalized(_ image: UIImage) -> UIImage {
    let format = UIGraphicsImageRendererFormat.default()
    format.opaque = true          // 알파가 필요 없으면 불투명으로 — 합성 비용도 준다
    format.scale = image.scale
    return UIGraphicsImageRenderer(size: image.size, format: format).image { _ in
        image.draw(at: .zero)     // 표준 포맷으로 다시 그린다
    }
}

Q4. 오프스크린 렌더링은 왜 비싼가?

CS 원리

GPU는 렌더 타깃(그릴 대상 버퍼)을 정해두고 그린다. 정상 경로에서는 화면 버퍼 하나에 레이어들을 순서대로 합성하며 그린다 — 한 번의 패스로 끝난다.

그런데 어떤 효과는 "먼저 완성된 결과가 있어야 적용할 수 있다". 마스크가 대표적이다 — 마스크를 적용하려면 마스크 대상 전체가 그려져 있어야 하고, 그러려면 별도 버퍼에 먼저 그려야 한다.

그래서 흐름이 이렇게 된다.

1. GPU가 렌더 타깃을 임시 버퍼로 전환한다.
2. 대상 레이어들을 그 버퍼에 그린다.
3. 효과(마스크·블러 등)를 적용한다.
4. 렌더 타깃을 화면 버퍼로 되돌린다.
5. 결과를 화면에 합성한다.

비싼 이유는 1번과 4번의 전환이다. GPU는 파이프라인 구조라 렌더 타깃 전환이 파이프라인 플러시를 유발할 수 있다 — 진행 중인 작업을 마무리하고 상태를 바꿔야 한다. 이건 CPU의 분기 예측 실패나 캐시 미스와 비슷한 성격의 비용이다(P0 12장).

여기에 메모리 대역폭 비용이 더해진다. 임시 버퍼를 쓰고 다시 읽는 것은 메모리를 왕복하는 것이고, 모바일 GPU는 대역폭이 성능을 좌우하는 경우가 많다.

그래서 오프스크린 렌더링은 개수보다 전환 횟수가 문제다. 한 화면에 오프스크린 유발 요소가 20개면 프레임마다 20번 전환이 일어난다.

iOS에서는

유발 요인과 대안을 정리하면 이렇다.

shadowPath가 가장 효과가 큰 최적화다. 그림자를 그리려면 GPU가 레이어의 알파 채널을 분석해 모양을 알아내야 하는데, 우리가 모양을 미리 알려주면 그 분석이 통째로 사라진다.

// ❌ 오프스크린 렌더링 — GPU가 알파 채널을 분석해 그림자 모양을 계산한다
view.layer.shadowColor = UIColor.black.cgColor
view.layer.shadowOpacity = 0.2
view.layer.shadowRadius = 8
view.layer.shadowOffset = CGSize(width: 0, height: 4)

// ✅ 모양을 미리 알려주면 분석이 필요 없다
view.layer.shadowPath = UIBezierPath(
    roundedRect: view.bounds, cornerRadius: 12
).cgPath

// ⚠️ 주의: bounds가 바뀌면 shadowPath도 갱신해야 한다.
//    안 하면 그림자 모양이 어긋난 채 남는다.
override func layoutSubviews() {
    super.layoutSubviews()
    layer.shadowPath = UIBezierPath(roundedRect: bounds, cornerRadius: 12).cgPath
}

shouldRasterize는 양날의 검이다. 레이어를 일부러 오프스크린에 그려 비트맵으로 캐시하는 기능이라, 내용이 자주 안 바뀌면 이후 프레임에서 재사용되어 이득이다. 그런데 내용이 매 프레임 바뀌면 매번 다시 그리므로 순손실이다.

// shouldRasterize는 "정적이고 그리기 비싼" 경우에만
if isStaticComplexView {
    layer.shouldRasterize = true
    layer.rasterizationScale = UIScreen.main.scale   // ⚠️ 안 하면 흐려진다
}
// 애니메이션 중이거나 내용이 자주 바뀌면 켜지 않는다 — 캐시 적중률이 0에 가깝다

rasterizationScale을 안 맞추면 Retina에서 흐릿하게 보인다 — 매우 흔한 실수다.

실험 · 도구

오프스크린 렌더링은 눈으로 보는 것이 가장 빠르다.

# 시뮬레이터 Debug 메뉴 (또는 Xcode › Debug › View Debugging)
#   ☑︎ Color Offscreen-Rendered
#     → 오프스크린 렌더링이 일어나는 영역이 노란색으로 표시된다
#     → 스크롤하면서 노란 영역이 얼마나 많은지 본다
#
#   ☑︎ Color Blended Layers
#     → 반투명 합성이 겹친 곳이 빨갛게 표시된다 (겹칠수록 진해짐)
#     → 불투명하게 만들 수 있는 곳을 찾는다
#
#   ☑︎ Color Hits Green and Misses Red
#     → shouldRasterize 캐시 적중(초록)/실패(빨강)
#     → 빨간색이면 rasterize가 손해를 보고 있다는 뜻이다

# 실기기 GPU 부하 측정
#   Instruments › Metal System Trace 또는 Animation Hitches
#   render 트랙에서 GPU 시간이 예산을 넘는지 확인

Color Hits Green and Misses Red가 shouldRasterize 판단의 결정적 근거다. 빨간색이 보이면 캐시가 매번 무효화되고 있다는 뜻이므로 즉시 꺼야 한다.

비용 차이를 직접 재보는 것도 유용하다.

/// 그림자 방식별 비용을 비교하는 실험 뷰
final class ShadowBenchmarkView: UIView {
    enum Mode { case noPath, withPath, plain }   // 'none' 은 Optional.none 과 충돌해 피한다

    func makeCards(mode: Mode, count: Int) {
        subviews.forEach { $0.removeFromSuperview() }
        for i in 0..<count {
            let card = UIView(frame: CGRect(x: 16, y: 16 + i * 80, width: 300, height: 64))
            card.backgroundColor = .systemBackground
            card.layer.cornerRadius = 12

            switch mode {
            case .noPath:
                card.layer.shadowColor = UIColor.black.cgColor
                card.layer.shadowOpacity = 0.2
                card.layer.shadowRadius = 8
                // shadowPath 없음 → 카드마다 오프스크린 렌더링

            case .withPath:
                card.layer.shadowColor = UIColor.black.cgColor
                card.layer.shadowOpacity = 0.2
                card.layer.shadowRadius = 8
                card.layer.shadowPath = UIBezierPath(
                    roundedRect: card.bounds, cornerRadius: 12).cgPath
                // → 오프스크린 없음

            case .plain:
                break
            }
            addSubview(card)
        }
    }
}

// 각 모드로 100개를 만들어 스크롤하며 Animation Hitches의 render 트랙을 비교한다.
// Color Offscreen-Rendered를 켜면 .noPath 에서만 노란 영역이 뜬다.

프로젝트 적용

실무 규칙 다섯.

• 그림자에는 항상 shadowPath를 준다. 비용 대비 효과가 가장 크고 부작용이 없다. 단 layoutSubviews에서 갱신하는 것을 잊지 않는다.
• 리스트 셀에서 마스크를 피한다. 셀 하나의 오프스크린 비용이 화면에 보이는 셀 수만큼 곱해진다. 프로필 이미지를 둥글게 하려면 미리 둥글게 처리한 이미지를 쓰거나, 배경에 cornerRadius를 주는 방식으로 우회한다.
• shouldRasterize는 측정 후에만. Color Hits Green and Misses Red로 확인하고, 빨간색이면 끈다.
• 불투명하게 만들 수 있으면 만든다. isOpaque = true와 불투명 배경색은 블렌딩 비용을 없앤다(Q3 꼬리질문).
• render hitch를 별도 지표로 본다. commit만 보면 이 영역이 통째로 안 보인다(20장 Q1). Animation Hitches에서 render 트랙을 항상 함께 확인한다.

꼬리 질문

func circularImage(from image: UIImage, size: CGSize) -> UIImage {
    let format = UIGraphicsImageRendererFormat.default()
    format.opaque = false
    return UIGraphicsImageRenderer(size: size, format: format).image { ctx in
        UIBezierPath(ovalIn: CGRect(origin: .zero, size: size)).addClip()
        image.draw(in: CGRect(origin: .zero, size: size))
    }
}
// 백그라운드에서 만들어 캐시하고, 셀에는 결과만 붙인다

Q5. 벡터 애니메이션은 무엇을 맞바꾸는가?

CS 원리

이건 시간-공간 트레이드오프의 전형이다. 미리 계산해두면(프리렌더) 공간을 쓰고 시간을 아끼고, 런타임에 계산하면(벡터) 시간을 쓰고 공간을 아낀다.

마지막 행이 실무에서 자주 사고를 만든다. 프리렌더는 비용이 예측 가능하다 — 해상도와 프레임 수를 알면 대략 안다. 반면 벡터는 디자이너가 만든 내용에 따라 비용이 수십 배 달라진다. 도형 500개에 마스크가 겹친 애니메이션은 겉보기에 단순해도 렌더 비용이 폭발한다.

그리고 비용이 지불되는 위치도 다르다. 프리렌더 디코딩은 Q3에서 본 Prepare 단계 비용이고 백그라운드로 옮길 수 있다. 벡터 렌더링은 매 프레임 일어나므로 옮길 수 없다 — 프레임 예산 안에서 끝나야 한다.

iOS에서는

iOS에서 벡터 애니메이션을 다루는 방식은 크게 셋이다.

• Core Animation 기본 요소 — CAShapeLayer + CABasicAnimation. 단순한 도형 애니메이션은 이걸로 충분하고, 렌더 서버가 그리므로 메인스레드 비용이 없다(Q1).
• SF Symbols 애니메이션 — 시스템이 최적화한 벡터 심볼. 아이콘 수준의 애니메이션이면 가장 싸다.
• 서드파티 벡터 애니메이션 라이브러리 — 디자인 도구에서 내보낸 JSON을 런타임에 해석해 그린다. 복잡한 일러스트 애니메이션에 쓴다.

세 번째 계열에서 중요한 사실이 하나 있다 — 렌더 엔진이 둘로 나뉘는 구현이 흔하다. 대표적으로 Lottie는 Core Animation 엔진과 메인스레드 엔진 두 가지를 갖는다.

마지막 행이 실무의 함정이다. 같은 애니메이션 파일인데 엔진에 따라 다르게 보일 수 있다. 성능을 위해 Core Animation 엔진으로 바꿨더니 일부 효과가 사라지거나 다르게 렌더되는 상황이 생긴다.

이건 추상화 뒤에 성능 특성과 동작이 함께 숨는 전형적 사례다 — P0 17장의 추상화 논의가 여기서 실물로 나타난다. "애니메이션 파일을 넣으면 돌아간다"는 인터페이스 뒤에 완전히 다른 두 구현이 있고, 어느 쪽인지가 성능과 결과를 모두 바꾼다.

실험 · 도구

벡터 애니메이션의 비용은 반드시 실측해야 한다. 내용에 따라 편차가 크기 때문이다.

import UIKit
import QuartzCore
import OSLog

/// 애니메이션이 도는 동안 프레임 지연과 CPU 시간을 측정한다
final class AnimationCostProbe {
    private let log = Logger(subsystem: "com.example.shop", category: "anim")
    private var link: CADisplayLink?
    private var last: CFTimeInterval = 0
    private var dropped = 0
    private var total = 0

    func start() {
        last = 0; dropped = 0; total = 0
        let l = CADisplayLink(target: self, selector: #selector(tick(_:)))
        l.add(to: .main, forMode: .common)
        link = l
    }

    @objc private func tick(_ l: CADisplayLink) {
        defer { last = l.timestamp }
        guard last != 0 else { return }
        total += 1
        let budget = l.targetTimestamp - l.timestamp
        if (l.timestamp - last) > budget * 1.5 { dropped += 1 }
    }

    func stop(_ label: String) {
        link?.invalidate(); link = nil       // ⚠️ 반드시 무효화 (20장 Q2)
        let rate = total > 0 ? Double(dropped) / Double(total) * 100 : 0
        log.notice("[\(label, privacy: .public)] 지연 프레임 \(dropped, privacy: .public)/\(total, privacy: .public) (\(rate, privacy: .public)%)")
    }
}

// 사용: 같은 화면에서 애니메이션 개수를 늘려가며 측정한다
// [벡터 1개]  지연 프레임 0/300 (0.0%)
// [벡터 5개]  지연 프레임 12/300 (4.0%)
// [벡터 20개] 지연 프레임 148/300 (49.3%)   ← 개수에 비선형으로 악화

# 비용 위치 확인 — 어느 프로세스가 바쁜지
#   Instruments › Animation Hitches
#     commit 트랙이 바쁘다 → 메인스레드 엔진일 가능성. 엔진을 바꿔본다.
#     render 트랙이 바쁘다 → 렌더 서버 부하. 도형 복잡도를 줄인다.
#
#   Instruments › Time Profiler
#     메인스레드 엔진이면 렌더 관련 스택이 크게 잡힌다.
#     Core Animation 엔진이면 여기에 거의 안 잡힌다 (Q1의 렌더 서버 분리 때문).

# 파일 자체의 복잡도를 미리 본다 — 도형·레이어 수가 비용의 대리 지표다
python3 - <<'PY'
import json, sys
d = json.load(open("animation.json"))
layers = d.get("layers", [])
print("레이어 수:", len(layers))
print("총 프레임:", d.get("op", 0) - d.get("ip", 0))
print("크기:", d.get("w"), "x", d.get("h"))
# 레이어가 수백 개면 런타임 비용을 의심하고 실측한다
PY

프로젝트 적용

선택 기준과 운영 규칙 다섯.

• 용도로 고른다. 크기가 작고 개수가 많으면(리스트 셀의 작은 아이콘) 프리렌더나 SF Symbols가 유리하다. 크고 하나뿐이며 색을 런타임에 바꿔야 하면 벡터가 유리하다.
• 단순한 것은 Core Animation으로 직접 만든다. 로딩 스피너나 체크 표시 정도는 CAShapeLayer + CABasicAnimation이면 되고, 렌더 서버가 그리므로 메인스레드 비용이 0이다. 라이브러리를 쓸 이유가 없다.
• 엔진 설정을 명시적으로 정하고 기록한다. 기본값에 맡기지 말고 어느 엔진을 쓰는지 코드에 남긴다. 성능과 렌더 결과가 둘 다 달라지므로 바꿀 때는 시각 검증도 함께 한다.
• 디자이너와 복잡도 예산을 합의한다. "레이어 100개 이하", "마스크 중첩 2단계 이하" 같은 기준을 정하면 만들고 나서 못 쓰는 상황을 막는다. 디자인 단계에서 정하는 것이 훨씬 싸다.
• 느린 기기에서 검증한다. 최신 기기에서 매끄러운 애니메이션이 구형에서 render hitch를 만든다. 20장 Q7의 원칙이 그대로 적용된다.

꼬리 질문

// Core Animation — 커밋 한 번, 이후 메인스레드 비용 0
let spinner = CAShapeLayer()
spinner.path = UIBezierPath(arcCenter: center, radius: 16,
                            startAngle: 0, endAngle: .pi * 1.5,
                            clockwise: true).cgPath
spinner.strokeColor = UIColor.systemBlue.cgColor
spinner.fillColor = nil
spinner.lineWidth = 3
spinner.lineCap = .round

let rotate = CABasicAnimation(keyPath: "transform.rotation.z")
rotate.toValue = Double.pi * 2
rotate.duration = 1
rotate.repeatCount = .infinity
spinner.add(rotate, forKey: "spin")     // 이후 앱이 막혀도 계속 돈다

// 보이는 셀만 재생 — 화면 밖 애니메이션은 정지시킨다
func collectionView(_ cv: UICollectionView, didEndDisplaying cell: UICollectionViewCell,
                    forItemAt indexPath: IndexPath) {
    (cell as? AnimatedCell)?.pauseAnimation()
}

Q6. 렌더 히치는 어떻게 진단하는가?

CS 원리

진단의 본질은 탐색 공간 축소다(20장 Q7). 렌더링은 두 프로세스와 GPU가 얽혀 있어 후보가 많으므로, 가장 큰 부분집합을 먼저 배제하는 질문부터 던져야 한다.

가장 강력한 첫 질문이 "commit인가 render인가"다. 이 하나로 후보가 절반으로 줄고, 이후 사용할 도구와 최적화 방향이 완전히 갈린다.

마지막 행이 중요하다. 20장 Q1에서 본 Apple의 지침 — 행을 다 고치면 히치도 상당수 사라진다 — 는 commit hitch에만 해당한다. render hitch는 행 도구로 잡히지 않으므로 남는다. 그래서 "행을 다 고쳤는데 여전히 끊긴다"면 render 쪽을 봐야 한다.

두 번째 원리는 시각 진단의 효율이다. GPU 작업은 프로파일러로 함수 단위 분해가 어렵지만, "화면의 어느 영역이 비싼가"는 색으로 즉시 보인다. 공간적 문제에는 공간적 도구가 맞다.

iOS에서는

시각 진단 도구별로 무엇을 알려주는지 정리하면 이렇다.

Flash Updated Regions가 의외로 유용하다. 작은 값 하나가 바뀌었는데 화면 전체가 깜빡인다면 갱신 범위가 과도한 것이고, 이건 대개 뷰 계층 구조 문제다. 셀 하나만 바뀌어야 하는데 리스트 전체를 reloadData하는 경우가 전형이다.

그리고 Color Misaligned Images는 원인이 단순하다 — 뷰의 frame이 정수 픽셀 경계에 안 맞으면 GPU가 재샘플링해야 한다. 오토레이아웃 계산 결과가 10.333… 같은 값이 되면 발생한다. 대응은 반올림이다.

extension CGRect {
    /// 화면 픽셀 경계에 맞춘다 — 재샘플링을 없앤다
    func pixelAligned(scale: CGFloat = UIScreen.main.scale) -> CGRect {
        CGRect(x: (origin.x * scale).rounded() / scale,
               y: (origin.y * scale).rounded() / scale,
               width:  (size.width  * scale).rounded() / scale,
               height: (size.height * scale).rounded() / scale)
    }
}

override func layoutSubviews() {
    super.layoutSubviews()
    imageView.frame = computedFrame.pixelAligned()
}

실험 · 도구

진단 절차를 순서대로 실행하는 체크리스트다.

# ── 1단계: commit인가 render인가 ──
# Instruments › Animation Hitches 템플릿
#   - Commit 트랙이 길다  → 2A로
#   - Render 트랙이 길다  → 2B로
#   - 둘 다               → 큰 쪽부터

# ── 2A: commit hitch ──
# Time Profiler를 함께 켠다 (릴리스 구성, 실기기)
#   - layoutSubviews 가 오래? → 오토레이아웃 단순화, 셀 높이 캐시 (Q3)
#   - draw(_:) 가 오래?       → 레이어 속성으로 대체 (Q3)
#   - 이미지 관련 스택?       → 백그라운드 디코딩 (Q3)

# ── 2B: render hitch ──
# 시뮬레이터 Debug 메뉴를 순서대로 켜본다
#   ① Color Offscreen-Rendered  → 노란 영역이 있나? (Q4)
#   ② Color Blended Layers      → 빨간 영역이 넓나?
#   ③ Color Copied Images       → 청록 영역이 있나? (Q3)
#   ④ Color Misaligned Images   → 어긋난 이미지가 있나?
#   ⑤ Flash Updated Regions     → 갱신 범위가 과도한가?
# 실기기 GPU 시간은 Metal System Trace로 확인

# ── 3단계: 수정 후 재측정 ──
# 같은 시나리오, 같은 기기로 Animation Hitches를 다시 돌려 비교

# ── 4단계: 느린 기기에서 검증 ──
# 지원 목록 중 가장 느린 모델에서 히치율 확인

프로덕션 회귀 감시는 Organizer 히치율이 담당한다(20장 Q4). 현행 기준을 다시 정리하면 ≤10 ms/s 좋음, ≤25 경고, ≤50 심각, >50 즉시 조치다.

// 자체 계측 — commit 측 프레임 지연을 화면 정보와 함께 남긴다
final class HitchReporter {
    private var link: CADisplayLink?
    private var hitchMs: Double = 0
    private var windowStart = CACurrentMediaTime()

    func start() {
        let l = CADisplayLink(target: self, selector: #selector(tick(_:)))
        l.add(to: .main, forMode: .common)
        link = l
    }

    private var last: CFTimeInterval = 0

    @objc private func tick(_ l: CADisplayLink) {
        defer { last = l.timestamp }
        guard last != 0 else { return }
        // Q2 와 같은 식 — 프레임 간격이 예산을 넘긴 만큼을 누적한다
        let budget = l.targetTimestamp - l.timestamp
        let gap = l.timestamp - last
        if gap > budget { hitchMs += (gap - budget) * 1000 }

        // 1초 창마다 히치율(ms/s)을 계산해 보고한다 — Apple 지표와 같은 단위
        let elapsed = CACurrentMediaTime() - windowStart
        if elapsed >= 1.0 {
            let rate = hitchMs / elapsed
            if rate > 25 {          // Apple 기준 "경고" 이상만 보고
                Observability.capture(event: "hitch", fields: [
                    "rate_ms_per_s": Int(rate),
                    "screen": CurrentScreen.name,      // 어느 화면인지가 핵심 단서
                ])
            }
            hitchMs = 0; windowStart = CACurrentMediaTime()
        }
    }

    func stop() { link?.invalidate(); link = nil }   // 20장 Q2 — 반드시 무효화
}

화면 이름을 함께 남기는 것이 핵심이다. 히치율 숫자만으로는 어디를 봐야 할지 모르지만, "결제 화면에서만 히치율이 40"이면 조사 범위가 즉시 좁혀진다 — 18장 Q1의 "차원을 살려 보내기"가 여기서 실제 이득을 준다.

프로젝트 적용

운영 규칙 다섯.

• commit/render 구분을 조사 1단계로 못 박는다. 팀 위키에 절차를 적어두면 매번 처음부터 헤매지 않는다.
• 시각 진단을 정기 점검에 넣는다. 주요 화면을 대상으로 분기마다 Color 도구들을 훑는다. 새 기능이 오프스크린을 들여오는 것을 조기에 잡는다.
• 히치율을 화면별로 수집한다. 전체 값만 보면 어느 화면이 문제인지 모른다.
• 느린 기기 기준을 별도 지표로 둔다. 20장 Q4에서 본 대로 90퍼센타일이 나쁘면 특정 기기 문제일 가능성이 높다.
• 디자인 리뷰에 성능 관점을 넣는다. 그림자·블러·마스크가 많은 시안은 만들기 전에 비용을 논의한다. Q5의 복잡도 예산과 같은 발상이다.

꼬리 질문

출처 · 참고자료