뷰 레이아웃 전체 과정 심화 — update → layout → display

둘 다 일어난다. 역할이 다르다.

• 뷰: 그 뷰에 "제약 갱신 필요" 더티 플래그 ON → 어떤 뷰를 처리할지
• 윈도우(트리 루트)/런루프: "이번 런루프 끝(commit)에 레이아웃 패스를 한 번 돌려라" 예약 → 언제 트리거할지

윈도우 등록 = 그 뷰 대신 윈도우를 처리한다는 뜻이 아니라 레이아웃 패스를 깨우는 스케줄. 패스가 돌 때 시스템은 윈도우(루트)부터 트리를 순회하며 더티 뷰를 찾아 처리. → 진입점=윈도우, 대상=더티 뷰.

순회 방향은 맞고, "무조건 연쇄 호출"은 아니다.

• update 패스는 더티로 마킹된 뷰의 updateConstraints()를 bottom-up(자식→부모→윈도우) 순서로 호출
• 부모의 updateConstraints()는 그 부모도 더티일 때 호출. 모든 부모가 매번 자동으로 불리는 건 아님 — "bottom-up"은 호출 순서가 자식→부모 방향이라는 뜻
• ✅ VC는 루트뷰 레벨에서 updateViewConstraints() 호출 (super는 맨 마지막)

레이아웃 패스(②) = frame(위치·크기) 확정 단계. 그리기 아님.

• 더티 표시(setNeedsLayout)된 뷰에 layoutSubviews() 호출
• 방향: top-down(부모→자식). 부모가 bounds 안에서 자식 frame을 정하고, 그 다음 자식이 자기 자식 배치
• Auto Layout 사용 시: layoutSubviews() 기본 구현이 엔진(NSISEngine, Cassowary)이 푼 제약 해를 각 서브뷰 frame에 적용
• 커스텀: layoutSubviews() 오버라이드해 직접 frame 세팅(super 호출 후)
• VC 훅: viewWillLayoutSubviews() → (루트뷰 layoutSubviews) → viewDidLayoutSubviews()
• frame 의존 작업(cornerRadius·그림자 path)은 여기서. 강제=layoutIfNeeded() / 예약=setNeedsLayout()
• ①과의 관계: ①에서 제약 갱신·수집 → 엔진 solve → ②에서 결과 frame 적용

GPU가 합성을 끝낸 "화면 한 장"(픽셀 배열)이 저장되는 메모리 영역.

• 한 프레임 전체의 픽셀 색 데이터(RGBA per pixel)
• 디스플레이 컨트롤러가 이걸 읽어 패널에 출력
• 더블/트리플 버퍼링: GPU가 한 버퍼에 그리는 동안 디스플레이는 다른 버퍼를 읽음 → 테어링 방지, VSync에 버퍼 swap

❌ 그리기는 layout 패스(②)가 아니라 display 패스(③)다.

• ② layout = frame(숫자) 확정, 그리기 아님
• ③ display = draw(_:) 시점에 CPU가 Core Graphics로 backing store(비트맵 = layer.contents)에 그림
• draw(_:)를 오버라이드한 뷰만 CPU 비트맵 그리기. backgroundColor·UIImageView.image 등은 draw 없이 GPU 직접/layer.contents로 처리

→ 주인님 문장의 "layout 패스에서" → "display 패스에서"로 고치면 정확.

디스플레이가 다음 프레임을 화면에 표시하기 시작하는 경계 신호(수직동기).

• 주사율대로 갱신: 60Hz=16.7ms, 120Hz(ProMotion)=8.3ms마다
• 이 경계에 맞춰 GPU 프레임버퍼 swap → 화면 중간에 두 프레임 섞임(테어링) 방지
• iOS: render server가 VSync에 맞춰 합성·표시. CADisplayLink도 VSync에 콜백 동기화(애니 타이밍 정석)
• 한 프레임 작업이 간격(16.7ms) 안에 못 끝나면 프레임 드롭 = 버벅임(jank)

거의 맞고 두 가지만 보강. 계층: VC.view(루트) → v1 → v2

(1) 그 전에 ① update constraints 패스가 먼저 (bottom-up, 더티인 것만):

(2) 그 다음 ② layout 패스 (top-down) — 빠진 건 루트뷰(VC.view) 자신의 layoutSubviews가 v1보다 먼저:

viewWillLayoutSubviews/viewDidLayoutSubviews는 루트뷰 레이아웃을 감싸는 알림이고, v1·v2의 layoutSubviews는 will~did 사이에 일어난다. top-down이라 부모(v1)가 자식(v2)보다 먼저 — 이 부분은 정확.

해당 뷰만이 아니다. layoutIfNeeded()는 receiver에서 조상 체인을 따라 올라가 가장 위의 더티 조상부터 그 아래 서브트리 전체의 pending 레이아웃을 즉시 수행(보통 윈도우 트리 단위).

• layout을 하려면 제약이 최신이어야 하므로 pending update constraints도 함께 풀린다 → 그 트리의 더티 뷰들 updateConstraints()가 같이 호출
• "receiver 한 뷰만" ❌ / "그 뷰가 속한 트리의 더티한 것 전부" ✅
• 딱 그 뷰 서브트리 제약만 즉시 풀려면 updateConstraintsIfNeeded()

"이 뷰의 제약 집합을 최신 상태로 만드는 것" — 그게 전부.

• 제약 생성 / activate·deactivate / constant·priority 변경 / 동적 제약 갱신
• super.updateConstraints()를 맨 마지막 호출
• ⚠️ 여기서 frame을 계산하지 않는다. 제약을 푸는(solve) 건 Auto Layout 엔진, 실제 frame 배치는 ② layout 패스. updateConstraints는 그 입력(제약)을 준비하는 자리

아니다. backgroundColor는 layer.contents(비트맵)에 그리는 게 아니다.

• 배경색은 layer.backgroundColor(CGColor) 속성으로 저장 → render server/GPU가 합성 때 그 사각형을 단색으로 채운다(fill)
• 비트맵(contents) 생성이 없다 → CPU draw 없음, 메모리 거의 안 씀(제일 쌈)
• layer.contents에 실제 비트맵이 들어가는 건: draw(_:) 오버라이드(CPU가 그린 결과), UIImageView(이미지를 contents에 꽂음), 텍스트 렌더 등
• 정리: 색 변경 = "그리기" 아니라 속성 변경 → GPU가 합성 때 칠함

핵심은 "코드 줄 수"가 아니라 "메인 스레드가 한 프레임 예산(16.7ms)을 넘기느냐".

• viewDidLoad는 메인 스레드에서 동기 1회 실행. 무거운 동기 작업(큰 이미지 디코딩, 동기 디스크/네트워크, 대량 Auto Layout)을 하면 → 첫 프레임/화면 전환이 마감을 못 맞춰 끊김(hitch)
• 이건 진입 시 일시적 hitch. 지속 버벅임은 스크롤·애니 중 매 프레임 layout/draw가 무거울 때
• 예산은 두 군데가 따로: CPU(메인) 이벤트+layout+draw+commit이 16.7ms 초과 → 드롭 / GPU 합성이 무거우면(오프스크린 렌더·과한 블러·그림자·마스크) → 드롭
• 해법: 무거운 작업을 백그라운드/지연(lazy)/사전 디코딩·다운샘플로 빼고 viewDidLoad는 가볍게

직관이 맞다 — 대부분 필요 없다. 핵심은 "제약"과 "frame"이 다른 일이라는 것.

layout 패스는 제약을 만들지 않는다. 이미 있는 제약을 풀어서(solve) frame을 낼 뿐. 제약은 보통 viewDidLoad에서 미리 만들어둔다.

그럼 언제 쓰나? 제약 자체가 동적으로 통째로 바뀌고(가로/세로·확장/축소로 제약 세트 교체) 그 재구성이 비쌀 때만. 이유 둘:

• 배칭 — 한 런루프에 상태가 5번 바뀌어 setNeedsUpdateConstraints가 5번 불려도 실제 재구성은 update 패스에서 딱 1번. 매번 즉시 activate/deactivate하면 같은 일 5번=낭비
• 제약 추가/제거는 비싸다 — .constant 변경보다 무거움(엔진이 제약 그래프 재구성). 자주 토글되면 모아서가 이득

→ 제약 고정이면 updateConstraints 불필요. 자주 재구성 + 비쌀 때만 "모아서 처리하는 최적화 자리".

맞다. 메인 스레드는 매 프레임 런루프 한 바퀴를 동기로 돈다:

이 전부가 16.7ms(60Hz) 안에 안 끝나면 다음 VSync에 새 프레임을 못 줘서 프레임 드롭=버벅임. 그래서 이 동기 비용을 줄이자는 게 맞다.

정밀화 2가지:

• "그리는 작업"만이 아니다 — draw뿐 아니라 네 일반 코드·제약 solve·layout 계산 전부가 메인 스레드 동기 비용 (draw=CPU Core Graphics도 메인)
• GPU 렌더는 메인 스레드가 아니다 — 합성은 render server/GPU에서 별도로 돈다. 예산이 두 군데 따로:
  • CPU(메인): 네 코드+update/layout/draw+commit이 16.7ms 초과 → 드롭
  • GPU: 합성이 무거우면(오프스크린·블러·그림자) VSync 못 맞춰 → 드롭
  • 둘 중 하나라도 늦으면 버벅

→ 주로 줄이려는 건 메인 스레드(CPU) 동기 비용이고 그게 핵심 맞음. GPU 쪽도 따로 예산이 있다는 것만 추가.

보통은 아니다. 흔한 오해. 핸들러에서 제약을 직접 바꾸면 UIKit이 자동으로 더티 표시한다 — setNeedsUpdateConstraints()를 직접 부를 필요 없음.

constant = / isActive = / activate·deactivate → 전부 자동 더티 → 다음 layout 패스에서 반영. 실무 99%는 그냥 바꾸고 끝.

setNeedsUpdateConstraints를 직접 부르는 건 — updateConstraints()를 오버라이드한 경우에만:

→ 버튼 → a 제약 변경은 보통 직접 바꾸면 되고 setNeedsUpdateConstraints는 안 부른다. 그건 Q13의 "제약을 updateConstraints에 모아 처리하는 특수 패턴"일 때만 등장.

모순 아니다. 더티 플래그가 2개라서 그렇다 — Q15에서 내가 "자동 더티"라고만 써서 어느 더티인지 모호했던 게 원인.

이 둘은 별개 플래그·별개 패스·별개 메서드. "setNeedsUpdateConstraints가 있어야 updateConstraints가 불린다"는 ✅ 맞다(①을 깨우는 조건). 그런데 constant 변경은 ① 경로를 안 탄다.

왜 ①을 안 거쳐도 되나? updateConstraints()는 "제약을 새로 만들/추가·제거·재구성"하는 자리. constant=는 기존 제약의 값만 바꾼 것(재구성 아님) → 엔진이 ② layout 패스에서 다시 풀어 frame만 내면 끝.

시나리오: VC.view에 a1·a3, a1 안에 a2. a2.setNeedsLayout() 호출 시 전체 흐름.

✅ 맞은 것

• 레이아웃 패스 순서 viewWillLayoutSubviews → VC.view → a1 → a2 → viewDidLayoutSubviews (top-down)
• a3는 호출 안 됨(더티 아님) · layoutSubviews=frame set · draw는 top-down·override한 곳만·CPU가 비트맵에

🔧 교정 4가지

1. "부모뷰에 setNeedsLayout이 호출된다" ❌ (가장 중요) — 전파되는 건 setNeeds… 호출이 아니다. a2.setNeedsLayout()은 a2만 더티 + 윈도우에 패스 예약. 조상의 setNeedsLayout을 줄줄이 부르지 않음. (오타: "부모뷰인 a2"→a2의 부모는 a1)
2. 조상 layoutSubviews는 "조상도 더티일 때만" — a2.setNeedsLayout()은 a2.layoutSubviews()만 보장. VC.view·a1의 layoutSubviews(및 viewWillLayoutSubviews)는 그들도 무효화됐을 때만. 제약 변경이 상위에 영향 주면 윈도우 레벨로 무효화돼 조상도 도는 경우가 많을 뿐
3. layout 다음 draw가 "항상" 오는 건 아니다 — setNeedsLayout은 frame만 무효화. draw(③)는 needsDisplay가 따로 켜졌을 때만. 위치·크기만 바뀌면 비트맵 그대로 두고 render server가 기존 텍스처를 새 위치에 재합성만(draw 불필요). layout ≠ display (예외: contentMode = .redraw)
4. "GPU의 render server" → 용어 2개: render server는 GPU 일부가 아니라 별도 프로세스("GPU를 써서" 합성). 빠진 단계 = CATransaction commit으로 레이어 트리를 IPC로 render server에 전달 → GPU로 합성(compositing) → 프레임버퍼 → VSync 출력. "그린다"보다 "합성"

시나리오: VC.view ▸ [a1 ▸ a2] + a3. a2.setNeedsLayout() 호출 시.

Q1. "a2의 frame까지 바뀌어야 하는 변경" = Auto Layout도 뜻하나?

✅ 그렇다. Auto Layout에서 a2 frame 변경은 보통 제약 변경(constant·isActive)이나 intrinsic content size 변화(라벨 글자 증가 등)로 일어남. 이게 부모(a1)·VC.view 레이아웃에도 영향 → 위쪽도 무효화.

Q2. "런루프가 대기로 들어가기 직전"이 무슨 말? 런루프가 대기해?

런루프=메인 스레드 무한 루프. 이벤트 처리하다 처리할 게 없으면 잠들어(sleep/대기) CPU를 안 쓰고 다음 입력 대기. Core Animation은 런루프 옵저버로 "잘 거야(BeforeWaiting)" 직전에 commit 실행 → 그때 레이아웃 패스가 돔.

Q3. updateConstraints 관련 4가지

• (a) layout 전? 후? → 전. 레이아웃 패스 = ① update constraints → ② layout → ③ display. ①이 ②보다 먼저
• (b) 오버라이드 안 하면 호출 안 됨? → 시스템 기본 구현은 호출됨(특별한 일 없을 뿐). 내 코드가 돌 일이 없는 것
• (c) setNeeds는 예약, updateConstraints는 바로 실행? → 둘 다 즉시 아님. setNeedsUpdateConstraints()=예약 → 다음 commit ① 패스에서 시스템이 updateConstraints() 호출(내가 부르는 게 아님). 즉시 강제는 updateConstraintsIfNeeded()
• (d) 방향? → ✅ ① update=bottom-up(자식→부모), ② layout=top-down(부모→자식)

Q4. layoutSubviews는 frame set까지? draw/render까지?

frame set(배치)까지만. draw(③ display)·GPU render는 그 이후 별도 단계. layoutSubviews는 서브뷰 frame 숫자 계산·할당만.

Q5. ⭐ a1.layoutSubviews()는 a1의 frame? a2의 layoutSubviews 호출?

이름대로 "subviews를 layout" — a1이 자기 서브뷰(a2)의 frame을 정함. a1 자신 frame 아님.

X.layoutSubviews() = X의 자식들 frame을 정함. X 자신 frame은 X의 부모가 정함. a2의 layoutSubviews는 a1이 직접 부르는 게 아니라 시스템이 top-down 순회로 이어서 호출.

Q6. a2만 layoutSubviews 호출되면 viewDidLayoutSubviews가 안 불릴 수 있어?

✅ 가능. viewWillLayoutSubviews/viewDidLayoutSubviews는 VC.view(루트뷰)의 layoutSubviews가 돌 때만 불림. a2 frame은 그대로고 a2 내부 서브뷰 배치만 무효화되면 a2.layoutSubviews만 돌고 VC 콜백은 안 불림. a2 frame이 바뀌어 상위까지 무효화되면 불림.

Q7. setNeedsUpdateConstraints도 setNeedsLayout처럼 런루프 때 호출돼?

✅ 그렇다. 둘 다 예약이고 실제 메서드는 다음 런루프 끝(commit)에 호출. 같은 commit 안에서 순서가 정해짐 — 예약하는 패스만 다름(① vs ②).

Q8. setNeedsUpdateConstraints는 bottom→top? updateConstraints도?

• updateConstraints() 호출은 bottom-up(자식→부모) ✅
• 하지만 setNeedsUpdateConstraints() 자체는 방향이 없다 — 특정 뷰 하나를 더티로 찍는 예약일 뿐, 트리 순회가 아님. 방향은 실제 호출(① 패스)에만 있음

Q9. setNeedsUpdateConstraints·setNeedsLayout·setNeedsDisplay 모두, 자식이 했을 때 부모도 필요시 될 수 있어?

공통 원칙: 셋 다 setNeeds… 호출 자체는 부모로 전파 안 함(receiver만 더티). 단 "부모도 무효화되냐"는 셋이 다름:

왜 display(③)만 부모와 무관? 그리기는 각 레이어가 자기 비트맵(layer.contents)에 독립적으로 함. 자식이 다시 그려도 부모 비트맵 그대로 → render server가 합성 때 겹쳐 갱신, 부모는 draw 다시 안 함. 반면 레이아웃(①②)은 본질적으로 트리 의존(자식 크기 ↔ 부모 배치)이라 위로 번질 수 있음.

Q10. 더티 후 그 런루프 끝? 다음 런루프 끝? 패스 3개가 각각 끝나야 다음으로? render server 합성이 패스마다 끝나야 다음 패스?

• 그 (현재) 런루프 끝 — 다음 런루프 아님. 더티 찍은 이벤트 처리 끝 → 현재 런루프가 idle 직전(BeforeWaiting) commit에서 레이아웃 패스 시작. ("next update cycle"=다음 런루프가 아니라 이 사이클 끝의 그리기 단계)
• 패스 3개 ✅ ① update constraints → ② layout → ③ display. render server 합성은 여기 포함 X(3패스 뒤 별도)
• 패스 단위 순차 ✅ ①을 트리 전체(bottom-up) 끝 → ② 전체(top-down) → ③. 뷰 하나가 ①②③ 다 돌고 다음 뷰로 가는 게 아니라 패스별 전체 처리(②는 ①결과에 의존)
• render server 합성이 패스마다? ❌ ①②③ 전부 앱(메인 스레드)에서 끝남. render server는 3패스 끝난 뒤 commit에서 1회만 관여, 게다가 비동기(앱은 합성 완료 안 기다리고 다음 런루프로)

Q11. "backgroundColor만 있는 뷰 → draw 안 함, ②에서 GPU가 색 사각형 칠함" — 이때 render server가 하는 거지?

✅ render server가 맞다. 단 "②에서"는 틀림 — 색칠은 패스 ①②③ 중 어디도 아니고, 그 뒤 commit → render server 합성 단계에서 GPU가 한다.

• ②(layout)는 frame 숫자만 정함 — 픽셀/색 칠하는 일 없음
• backgroundColor는 비트맵(contents) 아니라 layer 속성 → CPU draw도 비트맵도 불필요 → render server가 합성 때 직접 fill(제일 쌈)

✅ 호출된다. ① update constraints와 ② layout은 같은 commit 안에서 ①→② 순서로 이어짐.

• "필요에 따라"가 정확 — ①에서 제약이 실제 frame에 영향 주는 변경일 때만 ②가 돔. frame 결과가 같으면 생략 가능
• 별개 더티 플래그(needsUpdateConstraints ① / needsLayout ②)인데, 제약 변경이 needsLayout을 자동으로 켜줘서 둘이 연결됨
• 방향 주의: ①→② 자동만. 역방향 X — layoutSubviews가 updateConstraints를 부르지 않음

같은 "크기"가 아니다. 하나는 희망(입력), 하나는 확정(출력).

자식이 희망 크기를 아니까 위로 모으고(① bottom-up), 부모 크기가 정해져야 자식 자리가 나오니 아래로 내린다(② top-down).

✅ 맞다. "더티 표시"와 "레이아웃 패스"는 다른 시점. 패스(④~⑦)는 런루프 끝 commit. setNeeds…(더티 표시)는 그보다 먼저, 네 코드가 뷰/제약을 바꾸는 그 순간(동기) 자동으로 켜진다.

게다가 최초 화면 표시 전엔 레이아웃 패스가 한 번 보장되므로, viewDidLoad에서 제약만 걸어두면 알아서 첫 레이아웃이 돈다.

그럼 setNeeds…를 직접(수동) 부르는 건 언제? 거의 안 부른다. UIKit이 모르는 "내 커스텀 상태"가 레이아웃에 영향 줄 때만 — 보통 manual layout(직접 frame 계산):

• setNeedsLayout() 수동 → layoutSubviews 오버라이드해 수동 배치할 때
• setNeedsUpdateConstraints() 수동 → updateConstraints 오버라이드해 제약 로직 둘 때
• Auto Layout 쓰면 대부분 자동 → 수동 setNeeds는 manual layout 쪽에서 주로 등장

주로 "여러 런루프 사이클에 걸쳐 반복"이라는 뜻. 기본은 한 런루프 사이클당 패스 1회(쌓인 더티 모아서).

• 회전 → 그 사이클에 1회 / 스크롤 → 거의 매 프레임(매 런루프) 1회 / 제약 변경 → 그때마다 1회
• "한 번 그리고 끝"이 아니라 앱이 도는 동안 이 사이클이 수없이 반복 → 그래서 layoutSubviews에 무거운 작업 넣으면 스크롤 중 매 프레임 비용 → 버벅
• 한 런루프 안 여러 번도 가능(부차적): layoutIfNeeded() 명시적 여러 번 호출, layout 중 재무효화. 하지만 정상 흐름 기본은 사이클당 1회

주인님 말이 더 정확하다. (Q14 표의 "→ needsLayout"은 단순화로 덜 정확 — 교정)

핵심: intrinsic content size는 Auto Layout 엔진 안에서 "content size constraint"라는 제약(입력)으로 표현된다. 그게 바뀌면 제약을 갱신해야 하니 ① update constraints 경로로 들어간다.

• 주인님 직관(intrinsic=제약 입력 → update constraints 쪽)이 옳다
• 다만 결국 ②(layout)도 따라온다 — 제약 바뀌면 frame을 다시 풀어야 하니까. 그래서 "needsLayout도 켜진다"가 완전 틀린 건 아니지만 일차 경로는 ① update constraints

✅ 맞다. 단 정확한 기준은 "위치라서"가 아니라 "제약 값(constant)만 바꿔서(재구성 아니라서)".

크기를 바꿔도 constant면 ① 안 거치고 ②만. 반대로 위치가 아니어도 제약 add/remove나 intrinsic(text) 변화면 ① 거침. → 결정 요인은 위치/크기가 아니라 "기존 제약 값만 손댔나 vs 제약 구조/입력이 바뀌었나".

핵심: UIView.animate가 보간하는 건 frame이지 constant가 아니다.

• constraint.constant = 200은 frame을 즉시 안 바꿈 — needsLayout 더티만, 실제 frame은 다음 layout 패스에서
• 게다가 constant는 애니메이션 대상 속성이 아님. animate가 잡는 건 frame
• 그래서 frame이 "블록 실행 중에" 옛→새로 변해야 animate가 캡처 → 그 변화를 강제하는 게 블록 안 layoutIfNeeded()

왜 중요?

• Auto Layout에선 frame 직접 애니 불가 — view.frame=로 애니해도 다음 layout 패스가 제약대로 덮어써서 충돌. 제약 뷰는 반드시 이 패턴
• 모르면 "왜 애니 안 되지/왜 툭 튀지" 대표 삽질 버그
• 견고하게: 시작 상태도 layoutIfNeeded()로 확정(pending layout이 시작점 튀게 하는 것 방지)

큰 갈래 4개: ① Manual(frame) · ② Autoresizing mask · ③ Auto Layout · ④ SwiftUI. 오토레이아웃은 ③(표준).

③ Auto Layout 작성법:

보조 — 레이아웃 가이드(제약 기준점): safeAreaLayoutGuide(노치·홈 인디케이터 피함) · layoutMarginsGuide(기본 여백) · readableContentGuide(가독 폭) · UILayoutGuide(보이지 않는 가상 사각형, 더미뷰 대체).

✅ 맞다. UIView는 CALayer 위에 얹힌 래퍼라, 레이아웃은 레이어가 하고 UIView는 그 layer의 delegate로서 콜백을 받는다.

체인:

관찰 예시:

트리(VC.view ▸ a1 ▸ a2) — 레이어 트리 기준 top-down:

• UIView=CALayer 래퍼. 위치·크기·렌더·애니는 전부 layer가 처리, UIView는 delegate로 저수준 콜백을 UIKit 메서드로 변환
• 그래서 layoutSubviews/draw(_:)는 우리가 부르는 진입점이 아니라 레이어 메커니즘에 얹힌 콜백
• 순수 CALayer(delegate 없음)는 layoutSublayers에서 layoutSubviews로 안 감 — UIView가 layer.delegate일 때만의 동작

Auto Layout 이전의 레이아웃 방식 (iOS 6 이전, 지금도 존재). 부모 크기가 바뀔 때 자식이 어떻게 반응할지 "스프링 & 스트럿"으로 지정.

한계: 비율 지정, 뷰 간 관계(A 옆에 B) 등 복잡한 건 못함 → Auto Layout으로 대체됨.

회전(transform) 있을 때:

자식을 배치하는 건 "내 좌표계 안"에서 하는 일. 내 좌표계 = bounds.

• frame.width를 쓰면? 보통은 같지만, 회전(transform) 있으면 달라짐 → 자식이 삐져나감
• 회전 없어도 bounds 쓰는 게 개념적으로 맞는 습관

아니다. super.layoutSubviews()는 자식 frame만 설정하고, 자식의 layoutSubviews()는 안 부른다. 시스템이 top-down으로 순회하며 각 뷰의 layoutSubviews()를 순차적으로 호출한다.

왜 이렇게 설계?

실제론: 내 코드가 frame을 바꾼 후에 시스템이 childView.layoutSubviews()를 부름 → grandchild가 새 frame(200x100) 기준으로 배치됨.

아니다. frame = ... 직접 대입은 setNeedsLayout()을 호출하지 않는다.

layoutSubviews 안에서 frame 직접 설정 = "지금 이 pass 안에서" frame을 확정하는 것. 새 pass를 예약하는 게 아님.