Intrinsic Content Size 🍎

1️⃣ 설명

• 일부 뷰는 현재 포함하고 있는 콘텐츠에 따라 자연스러운 크기를 가지고 있음
• 뷰의 크기를 제약으로 정의하지 않아도 Intrinsic Content Size로 자연스러운 크기를 가지는 뷰들이 있음
• Intrinsic Content Size를 가지는 뷰는 뷰의 높이, 너비 또는 둘 다를 정의할 수 있음
• Intrinsic Content Size를 활용하여 뷰를 적절한 크기로 표현할 수 있음

2️⃣ 콘텐츠 크기

• Intrinsic Content Size는 뷰의 현재 콘텐츠에 기반함
• Label이나 Button의 Intrinsic Content Size는 표시된 텍스트 양과 사용된 글꼴에 따라 결정됨
• 비어있는 이미지 뷰는 Intrinsic Content Size를 갖지 않지만, 이미지를 추가하면 즉시 이미지의 크기로 Intrinsic Content Size가 설정됨
• Text View의 Intrinsic Content Size는 콘텐츠의 내용에 따라 다양함
• Text View가 스크롤링이 가능한 경우에는 Intrinsic Content Size가 없음
• Text View의 스크롤링이 비활성화된 경우에는 기본적으로 Intrinsic Content Size가 텍스트의 크기를 줄 바꿈 없이 한 줄의 텍스트로 표시하기 위해 필요한 높이와 너비로 계산됨
• Text View의 텍스트에 줄 바꿈이 없다면 Intrinsic Content Size는 텍스트를 한 줄의 글로 레이아웃하는 데 필요한 높이와 너비를 계산함
• Text View의 너비를 지정하는 Constraints을 추가하면, Intrinsic Content Size는 해당 너비에서 텍스트를 표시하는 데 필요한 높이를 정의함

3️⃣ CHCR

• Content Hugging, Compression Resistance
• Auto Layout은 각 차원에 대해 뷰의 Intrinsic Content Size를 나타내기 위해 두 개의 제약(Content Hugging, Compression Resistance)을 사용함
• Content Hugging은 뷰를 내부로 당겨서 콘텐츠에 딱 맞게 둘러싸도록 함
• Compression Resistance은 뷰를 바깥쪽으로 밀어서 콘텐츠가 잘릴 수 없도록 함
  
• 아래 그림에서는 IntrinsicHeight 와 IntrinsicWidth상수는 뷰의 Intrinsic Content Size로부터 높이와 너비 값을 나타냄
  
• 각각의 이러한 제약은 자체적으로 우선순위를 가질 수 있음
• 기본적으로, 뷰들은 컨텐츠 Content Hugging에 250 우선순위를 사용하고, Compression Resistance에 750 우선순위를 사용함
• 따라서 뷰를 늘리는 것은 뷰를 줄이는 것보다 쉬움
• 대부분의 컨트롤들에 대해서는 이러한 동작이 바람직함
• 예를 들어, 버튼을 Intrinsic Content Size보다 크게 늘리는 것은 안전하지만, 버튼을 줄이면 콘텐츠가 잘려 보일 수 있음
• Interface Builder는 때로는 이러한 우선순위를 조정하여 꼬임을 방지하는 데 도움을 줄 수 있습니다.

4️⃣ CHCR 가이드라인

• 가능하다면, 뷰의 내재적 콘텐츠 크기를 레이아웃에 활용해야함
• 이는 뷰의 콘텐츠가 변경됨에 따라 레이아웃이 동적으로 적응할 수 있도록 해줌
• 또한, 모호하지 않고 충돌하지 않는 레이아웃을 생성하기 위해 생성해야 하는 Constraints의 수를 줄여줌
• 그러나 뷰의 CHCR 우선순위를 관리해야 할 필요가 있음

여러 개의 뷰를 한 공간에 늘리려고 할 때

• 여러 개의 뷰를 한 공간에 늘리려고 할 때, 모든 뷰들이 동일한 content-hugging priority를 가진 경우에는 레이아웃이 모호해지고 오토 레이아웃은 어떤 뷰를 늘려야 할 지 알 수 없음
• 일반적으로 이러한 상황은 Label과 Text Field 쌍으로 나타남
• 보통 Text Field를 추가 공간을 채우기 위해 늘리고, 라벨은 Intrinsic Content Size를 유지하고 싶은 경우가 많음
• 이를 보장하기 위해서는 Text Field의 가로 content-hugging priority를 Label의 우선순위보다 낮게 설정해야 함
• 실제로 이 예는 매우 흔해서 Interface Builder에서는 라벨의 content-hugging priority를 자동으로 251로 설정해줌
• 만약 코드로 레이아웃을 만드는 경우에는 컨텐츠 허김 우선순위를 직접 수정해야 함

의도치 않게 Intrinsic Content Size보다 크게 늘려 질때

• 가끔 뷰들이 투명한 배경(예: 버튼이나 라벨)을 가질 때, 의도치 않게 Intrinsic Content Size보다 크게 늘려질 수 있어 이상하고 예상치 못한 레이아웃이 발생할 수 있음
• 실제 문제가 무엇인지 명확하지 않을 수 있으며, 텍스트가 잘못된 위치에 표시될 수 있음
• 이러한 늘림을 방지하려면 컨텐츠 허김 우선순위를 높여주면 됨

intrinsic content height가 있을 때

• Baseline Constraints은 뷰가 intrinsic content height에 있을 때만 작동함
• 만약 뷰가 세로로 늘어나거나 압축된다면, Baseline Constraints가 올바르게 정렬되지 않음

Switch, Segment Control, Stepper

• 위와 같은 일부 뷰들은 항상 Intrinsic Content Size로 표시되어야 함
• 늘리거나 압축되지 않도록 CHCR 우선순위를 필요에 따라 높여줘야 함

뷰에 필수적인 CHCR 우선순위를 지정하는 것 ❌

• 뷰에 필수적인 CHCR 우선순위를 지정하는 것(priority = 1000)은 피하는 것이 좋음
• 뷰가 올바른 크기보다는 예기치 않게 충돌을 일으키는 것이 더 나쁠 수 있기 때문임
• 뷰가 항상 Intrinsic Content Size를 가져야 한다면, 대신 매우 높은 우선순위(999)를 사용하는 것이 좋음
• 이 방법은 일반적으로 뷰가 늘리거나 압축되지 않도록 유지하지만, 예상보다 크거나 작은 환경에서 뷰가 표시되는 경우를 대비하여 비상용 압력 밸브로 사용될 수 있음

5️⃣ Intrinsic Content Size ⁉️ Fitting Size ⁉️

Intrinsic Content Size

• Intrinsic Content Size는 Auto Layout의 입력으로 작용
• 뷰에 Intrinsic Content Size가 있으면, 시스템은 해당 크기를 나타내는 제약 조건을 생성하고, 이러한 제약 조건을 사용하여 레이아웃을 계산함

Fitting Size

• 반면에 Fitting Size는 Auto Layout엔진의 출력임
• 이는 뷰의 제약 조건에 따라 계산된 크기로, 뷰의 내용에 따라 동적으로 결정됨
• 뷰가 Auto Layout을 사용하여 하위 뷰를 배치한다면, 시스템은 뷰의 내용에 기반하여 Fitting Size를 계산할 수 있음

Stack View

• Stack View는 좋은 예시임
• 다른 제약 조건이 없는 경우, 시스템은 스택 뷰의 크기를 내용과 속성에 기반하여 계산함
• 여러 측면에서, 스택 뷰는 Intrinsic Content Size가 있는 것처럼 작동함
• 스택 뷰의 위치를 정의하는 데 하나의 수직 및 수평 제약 조건만으로도 유효한 레이아웃을 생성할 수 있음
• 그러나 스택 뷰의 크기는 Auto Layout에 의해 계산되며, Auto Layout의 입력으로 사용되지 않음
• 스택 뷰의 Content Hugging, Compression Resistance 우선순위를 설정해도 영향을 미치지 않음
• 이는 스택 뷰에 Intrinsic Content Size가 없기 때문
• 스택 뷰의 Fitting Size를 스택 뷰 바깥의 항목과 관련하여 조정해야 하는 경우, 해당 관계를 지정하는 명시적인 제약 조건을 생성하거나 스택 뷰의 컨텐츠와 스택뷰 바깥의 항목과의 CHCR 우선순위를 수정해야 함

---

출처📚

🍎Apple Docs: Intrinsic Content Size