12 · setNeedsLayout vs layoutIfNeeded

final class TraceView: UIView {
    private var layoutCount = 0
    override func layoutSubviews() {
        super.layoutSubviews()
        layoutCount += 1
        print("layoutSubviews 호출 #\(layoutCount)")
    }
}

let v = TraceView()

// ── 케이스 1: 무효화를 100번 ──
for _ in 0..<100 { v.setNeedsLayout() }
// 출력: (아직 아무것도 안 나옴 — 예약만 됨)
// 이번 RunLoop 사이클이 끝날 때 → "layoutSubviews 호출 #1"  ← 딱 한 번!

// ── 케이스 2: 무효화 + 즉시 실행을 100번 ──
for _ in 0..<100 {
    v.setNeedsLayout()
    v.layoutIfNeeded()
}
// 출력: #1 #2 #3 ... #100   ← 병합 이점을 전부 버렸다

// ── 케이스 3: 더티가 아닐 때 layoutIfNeeded ──
v.layoutIfNeeded()     // 아무 일도 안 일어난다 (이미 깨끗하므로)
v.layoutIfNeeded()     // 역시 아무 일도 없다
// → "IfNeeded"라는 이름 그대로, 필요할 때만 한다

// ❌ 시작 상태가 확정되지 않아 애니메이션이 튄다
UIView.animate(withDuration: 0.3) {
    self.heightConstraint.constant = 300
    self.view.setNeedsLayout()      // ← 제약 변경이 이미 무효화한다. 불필요.
    self.view.layoutIfNeeded()
}
// 문제: 이전에 밀려 있던 레이아웃까지 이 블록 안에서 함께 처리되어
//       "의도하지 않은 뷰들"이 같이 애니메이션된다.

// ✅ 정답 패턴 — 시작 확정 → 변경 → 블록 안에서 한 번
view.layoutIfNeeded()                 // (1) 밀린 레이아웃을 먼저 정리 = 시작 상태 확정
heightConstraint.constant = 300       // (2) 목표 값 (이 자체가 setNeedsLayout 유발)
UIView.animate(withDuration: 0.3) {
    self.view.layoutIfNeeded()        // (3) 종료 상태로 보간
}

// ✅ 더 싼 방법 — 레이아웃을 아예 안 건드린다
UIView.animate(withDuration: 0.3) {
    self.panel.transform = CGAffineTransform(translationX: 0, y: -120)
}
// transform · opacity · backgroundColor 는 레이아웃 무효화가 없다
// → 렌더 서버가 처리하고, 메인 스레드는 커밋 한 번으로 끝난다

// ① 계산 직전 — 프레임 값이 확정돼야 한다
containerView.layoutIfNeeded()
let contentHeight = stackView.frame.height   // 이제 신뢰 가능
scrollView.contentSize = CGSize(width: view.bounds.width, height: contentHeight)

// ② 스냅샷/이미지 렌더링 직전
view.layoutIfNeeded()
let image = UIGraphicsImageRenderer(bounds: view.bounds).image { ctx in
    view.layer.render(in: ctx.cgContext)
}

// ③ 셀 높이를 수동 계산할 때 (systemLayoutSizeFitting 사용이 더 낫지만)
cell.contentView.layoutIfNeeded()
let h = cell.contentView.systemLayoutSizeFitting(
    UIView.layoutFittingCompressedSize).height

// ④ "무효화 여부와 무관하게" 지금 확정하고 싶을 때 — 이때는 짝이 맞다
view.setNeedsLayout()      // 더티가 아니어도 강제로 더럽게 만들고
view.layoutIfNeeded()      // 지금 계산한다
// ⚠️ 다만 이 짝을 습관적으로 쓰면 병합 이점을 계속 버리게 된다.
//    "정말 지금 값이 필요한가?"를 먼저 물어야 한다.

[이벤트 처리]
   └ 터치 핸들러 · 타이머 · 네트워크 콜백에서 내 코드가 뷰를 더럽힌다
       setNeedsLayout() × N  →  더티 플래그 하나
       제약 변경           →  내부적으로 setNeedsLayout 유발
       텍스트/이미지 변경   →  intrinsicContentSize 변경 → 무효화
   ↓
[업데이트 사이클 — CATransaction 커밋 직전]
   ① updateConstraints  (더티인 것만, 아래→위)
   ② layoutSubviews     (더티인 것만, 위→아래)   ← 여기서 딱 한 번
   ③ display / draw     (더티인 것만)
   ↓
[커밋]
   레이어 트리를 인코딩해 렌더 서버로 전송
   ↓
[다시 잠듦]

// layoutIfNeeded() 는 이 순서를 기다리지 않고
// "지금 ②를 실행"하는 것이다.

// setNeedsLayout: 자기 자신을 더티로 표시
//   → 부모 방향으로도 전파될 수 있다 (내 크기가 바뀌면 부모 배치도 영향)

// layoutIfNeeded: 리시버와 그 하위 트리를 즉시 정리
//   ⚠️ 상위가 더티면 UIKit이 위쪽부터 정리할 수 있다
//      (내 프레임은 부모가 정해 주므로)

// 그래서 "이 뷰만 딱 계산"은 보장되지 않는다
someDeepView.layoutIfNeeded()
// → 실제로는 필요한 조상까지 함께 정리될 수 있다

// intrinsicContentSize를 바꾸는 커스텀 뷰라면 반드시
override var text: String {
    didSet {
        invalidateIntrinsicContentSize()   // ✅ 이걸 안 부르면 크기가 안 바뀐다
    }
}
// invalidateIntrinsicContentSize() 도 무효화 계열이다 —
// "내 고유 크기가 바뀌었으니 다시 물어봐 줘"

// ① 커스텀 뷰에 카운터
final class CountingView: UIView {
    static var layoutCount = 0
    override func layoutSubviews() {
        super.layoutSubviews()
        Self.layoutCount += 1
    }
}

// ② os_signpost로 구간 측정 (11번과 같은 방법)
let sp = OSSignposter(subsystem: "com.app.layout", category: "pass")
override func layoutSubviews() {
    let s = sp.beginInterval("layoutSubviews", id: sp.makeSignpostID())
    defer { sp.endInterval("layoutSubviews", s) }
    super.layoutSubviews()
}

// ③ Instruments → Time Profiler에서 찾을 이름
//    -[UIView layoutSubviews]
//    -[NSISEngine ...]              ← Auto Layout 해결기 내부
//    NSISEngine::optimize           ← 여기가 무거우면 제약이 너무 많다

// ④ Auto Layout 충돌·모호성 디버깅
//    실행 인자: -UIViewLayoutFeedbackLoopDebuggingThreshold 100
//    → 레이아웃 피드백 루프(무한 재계산)를 잡아 준다

final class ExpensiveValue {
    private var cached: Int?
    private var inputs: [Int] = []

    // 무효화 — setNeedsLayout 에 해당
    func setNeedsRecompute() {
        cached = nil                     // 플래그를 끄는 것만. 계산은 안 한다.
    }

    // 즉시 실행 — layoutIfNeeded 에 해당
    func recomputeIfNeeded() -> Int {
        if let cached { return cached }  // 깨끗하면 아무 일도 안 한다
        let result = expensiveWork(inputs)
        cached = result
        return result
    }

    func update(_ new: [Int]) {
        inputs = new
        setNeedsRecompute()              // 변경은 무효화만 유발
    }
}

// 이게 정확히 UIKit이 하는 일이다:
//   · 변경 → 플래그만 켠다 (싸다)
//   · 결과가 필요한 순간 → 그때 계산 (필요한 만큼만)
//   · 여러 번 변경 → 플래그는 하나 → 계산도 한 번  ← 병합
//
// 그리고 lazy var, Combine의 @Published, SwiftUI의 뷰 무효화,
// 빌드 시스템의 증분 빌드, 스프레드시트의 재계산이 전부 같은 구조다.

// 우리가 쓰는 것
label.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16)
label.trailingAnchor.constraint(lessThanOrEqualTo: view.trailingAnchor, constant: -16)
label.centerYAnchor.constraint(equalTo: view.centerYAnchor)

// 해결기가 푸는 것
//   label.left  =  view.left + 16
//   label.right ≤  view.right - 16
//   label.centerY = view.centerY
//   label.width  = label.right - label.left
//   ... (뷰마다 4개 변수 × 제약 개수)
//
// 여기에 우선순위(priority)가 붙으면 "가능한 만족시키되 안 되면 완화"가 되어
// 단순 연립방정식이 아니라 "최적화 문제"가 된다.

// Auto Layout은 Cassowary 계열의 증분 제약 해결기를 쓴다.
//   · Cassowary(Badros·Borning·Stuckey, 2001)는 증분 심플렉스 기반 알고리즘으로,
//     UI 레이아웃을 겨냥해 만들어진 것이 맞다.
//   · 다만 "Apple이 Cassowary를 그대로 쓴다"는 Apple 1차 문서로 확인되는 사실은 아니다.
//     널리 알려진 사실이지만, 면접에서는 "Cassowary 계열"이라고 말하는 편이 안전하다.
//
// 알고리즘 이름보다 중요한 성질은 이것이다:
//   "제약을 하나 추가/변경했을 때 처음부터 다시 풀지 않고
//    기존 해에서 증분적으로 갱신할 수 있다"

// 뷰 계층은 의존 그래프다
//   자식의 위치 ← 부모의 크기 에 의존
//   부모의 크기 ← 자식의 intrinsicContentSize 에 의존 (셀프사이징)
//
// 그래서 UIKit은 두 방향으로 나눠 처리한다:
//
//   updateConstraints : 아래(자식) → 위(부모)
//     "내 고유 크기가 이렇습니다"를 위로 올린다
//
//   layoutSubviews    : 위(부모) → 아래(자식)
//     확정된 크기를 아래로 내려보낸다
//
// 이 두 패스로 나누는 것이 의존 그래프의 위상 정렬에 해당한다.
// 사이클이 생기면? → 피드백 루프 = 무한 재계산

// ❌ 사이클을 만드는 전형
override func layoutSubviews() {
    super.layoutSubviews()
    // 자식 프레임을 보고 → 제약을 바꾼다 → 다시 레이아웃 필요 → 무한
    heightConstraint.constant = label.frame.height
}
// ✅ 제약으로 표현하면 해결기가 한 번에 푼다
label.bottomAnchor.constraint(equalTo: container.bottomAnchor)
// → "관계"를 선언하면 해결기가 순서를 알아서 정한다.
//    "값을 읽어서 값을 쓰는" 명령형 코드가 사이클을 만든다.

더티 플래그        (12번) — 레이아웃 계산을 사이클 끝까지 미룬다
Copy-on-Write      (04번) — 복사를 쓰기 시점까지 미룬다
이미지 지연 디코딩 (11번) — 압축 해제를 그릴 때까지 미룬다
lazy var                  — 초기화를 첫 접근까지 미룬다
Effect / async     (01·10번) — 부수효과를 실제 실행 시점까지 미룬다

// 관통하는 명제:
//   "비싼 일을 진짜 필요해질 때까지 미루면,
//    상당수는 아예 필요해지지 않는다."
//
// 그리고 미룬 일들은 자연스럽게 "모여서" 한 번에 처리된다 — 병합.
// 지연과 병합은 같은 전략의 앞뒤다.