로고

[번역] Ambiguous Layouts - Debugging Auto Layout

작성일 :

개요

해당 문서는 학습 목적으로 Apple 공식 문서인 🔗 Auto Layout Guide을 번역한 글입니다. 다소 오역이 있을 수 있어 잘못된 내용이 있을 수 있습니다. 문제가 되거나 오류가 있다면 댓글 부탁드립니다.

Ambiguous Layouts

Ambiguous Layouts은 제약 시스템에 두 개 이상의 유효한 솔루션이 있을 때 발생합니다. 두 가지 주요 원인이 있습니다.

  • 레이아웃에는 모든 뷰의 위치와 위치를 고유하게 지정하기 위한 추가 제약 조건이 필요합니다. 어떤 뷰가 모호한지 확인한 후 뷰의 위치와 크기를 고유하게 지정하는 제약 조건을 추가하기만 하면 됩니다.
  • 레이아웃에 동일한 우선 순위를 가진 충돌하는 선택적 제약 조건이 있으며 시스템은 어떤 제약 조건을 중단해야 하는지 알지 못합니다. 여기에서 더 이상 동일하지 않도록 우선 순위를 변경하여 중단해야 하는 제약 조건을 시스템에 알려야 합니다. 시스템은 우선 순위가 가장 낮은 제약 조건을 먼저 해제합니다.

Detecting Ambiguous Layouts

unsatisfiable layouts과 마찬가지로 Interface Builder는 종종 디자인 타임에 ambiguous layouts을 감지하고 수정할 수 있는 제안을 제공할 수 있습니다. 이러한 모호성은 이슈 탐색기의 경고, 문서 개요의 오류 및 캔버스의 빨간색 선으로 나타납니다. 자세한 내용은 충족할 수 없는 “Identifying Unsatisfiable Constraints” 파트를 참조하십시오.

unsatisfiable layouts과 마찬가지로 Interface Builder는 가능한 모든 모호성을 감지할 수 없습니다. 많은 오류는 테스트를 통해서만 찾을 수 있습니다.

런타임에 모호한 레이아웃이 발생하면 오토 레이아웃은 사용할 수 있는 솔루션 중 하나를 선택합니다. 이는 레이아웃이 예상대로 표시될 수도 있고 표시되지 않을 수도 있음을 의미합니다. 또한 콘솔에 기록된 경고가 없으며 모호한 레이아웃에 대한 중단점을 설정할 방법이 없습니다.

결과적으로 모호한 레이아웃은 종종 unsatisfiable layouts보다 탐지하고 식별하기 어렵습니다. 모호성이 분명하고 눈에 띄는 효과가 있더라도 오류가 모호성 때문인지 레이아웃 로직의 오류 때문인지 판단하기 어려울 수 있습니다.

다행히 모호한 레이아웃을 식별하는 데 도움이 되도록 호출할 수 있는 몇 가지 메서드가 있습니다. 이러한 모든 메서드는 디버깅에만 사용해야 합니다. 뷰 계층 구조에 액세스할 수 있는 위치에 중단점을 설정한 다음 콘솔에서 다음 메서드 중 하나를 호출합니다.

  • 🔗 hasAmbiguousLayout: iOS 및 OS X 모두에서 사용할 수 있습니다. 잘못 배치된 뷰에서 이 메서드를 호출합니다. 뷰의 프레임이 모호하면 YES를 반환합니다. 그렇지 않으면 NO를 반환합니다.
  • 🔗 exerciseAmbiguityInLayout: iOS 및 OS X 모두에서 사용할 수 있습니다. 모호한 레이아웃이 있는 보기에서 이 메서드를 호출합니다. 이렇게 하면 가능한 유효한 솔루션 간에 시스템이 전환됩니다.
  • 🔗 constraintsAffectingLayoutForAxis: iOS에서 사용할 수 있습니다. 뷰에서 이 메소드를 호출하십시오. 지정된 축을 따라 해당 뷰에 영향을 미치는 모든 제약 조건의 배열을 반환합니다.
  • 🔗 constraintsAffectingLayoutForOrientation:. OS X에서 사용할 수 있습니다. 뷰에서 이 메서드를 호출합니다. 지정된 방향을 따라 해당 뷰에 영향을 미치는 모든 제약 조건의 배열을 반환합니다.
  • _autolayoutTrace: iOS에서 비공개 방법으로 사용할 수 있습니다. 보기에서 이 메소드를 호출하십시오. 해당 뷰를 포함하는 전체 뷰 계층 구조에 대한 진단 정보가 있는 문자열을 반환합니다. 모호한 보기에는 레이블이 지정되며 🔗 translatesAutoresizingMaskIntoConstraints가 YES로 설정된 보기에도 레이블이 지정됩니다.

콘솔에서 이러한 명령을 실행할 때 Objective-C 구문을 사용해야 할 수도 있습니다. 예를 들어, 중단점이 실행을 중지한 후 콘솔 창에 call [self.myView exerciseAmbiguityInLayout]을 입력하여 myView 개체에서 exerciseAmbiguityInLayout 메서드를 호출합니다. 마찬가지로 po [self.myView autolayoutTrace]를 입력하여 myView를 포함하는 뷰 계층 구조에 대한 진단 정보를 출력합니다.

Detecting Ambiguous Layouts

Logical Errors는 단순히 버그입니다. 어딘가에 잘못된 가정이 있습니다. 아마도 오토 레이아웃이 뷰의 프레임을 계산하는 방법에 대한 가정일 것입니다. 아마도 생성한 제약 조건 세트 또는 설정한 뷰 속성에 대한 가정일 수 있습니다. 아마도 복잡한 동작을 생성하기 위해 제약 조건이 상호 작용하는 방식에 대한 가정일 것입니다. 그럼에도 불구하고 어딘가에 당신의 정신 모델과 완전히 일치하지 않는 것이 있습니다.

Logical Errors는 찾기가 가장 어렵습니다. 다른 모든 가능성을 제거한 후에 남아 있는 것은 아무리 가능성이 희박하더라도 논리적 오류임에 틀림없습니다. 그러나 버그가 있다고 판단한 후에도 잘못된 가정이 정확히 어디에 있는지 알아내야 합니다.

여기에는 도구나 단계별 지침이 없습니다. Logical Errors 수정에는 일반적으로 문제를 식별하고 수정 방법을 파악하기 위한 실험 및 반복 테스트가 포함됩니다. 그러나 도움이 될 수 있는 몇 가지 제안이 있습니다.

  • 기존 제약 조건을 검토합니다. 제약 조건을 놓치거나 원치 않는 제약 조건을 실수로 추가하지 않았는지 확인하십시오. 모든 제약 조건이 올바른 항목 및 속성에 연결되어 있는지 확인하십시오.
  • 뷰 프레임을 다시 확인하십시오. 예기치 않게 늘어나거나 줄어들지 않는지 확인합니다.
  • 이는 레이블이나 버튼과 같이 보이지 않는 배경이 있는 보기에서 특히 중요합니다. 이러한 항목의 크기가 예기치 않게 조정되면 명확하지 않을 수 있습니다.
  • 크기 조정의 한 가지 증상은 기준선 정렬 뷰가 더 이상 제대로 정렬되지 않는다는 것입니다. 기준선 정렬은 보기가 고유 콘텐츠 높이에 표시될 때만 작동하기 때문입니다. 뷰를 세로로 늘이거나 축소하면 텍스트가 잘못된 위치에 이상하게 나타납니다.
  • 컨트롤이 항상 고유한 콘텐츠 크기와 일치해야 하는 경우 매우 높은 콘텐츠 허깅 및 컴프레셔 레지스턴스 우선 순위를 지정합니다(예: 999).
  • 레이아웃에 대한 가정을 찾고 이러한 가정이 사실인지 확인하기 위해 명시적 제약 조건을 추가합니다.
  • 만족스럽지 못한 레이아웃은 일반적으로 찾고 수정하기 가장 쉬운 문제라는 점을 기억하십시오. 충돌이 발생할 때까지 추가 제약 조건을 추가한 다음 충돌을 검사하고 수정합니다.
  • 주어진 제약 조건이 표시되는 결과를 생성하는 이유를 이해하려고 노력하십시오. 당신이 그것을 이해한다면, 당신은 그것을 고치는 길에 있습니다.
  • 대체 제약 조건을 실험해 보십시오. 자동 레이아웃은 일반적으로 동일한 문제에 대해 다양한 솔루션을 제공합니다. 다른 접근 방식을 시도하면 문제가 해결되거나 적어도 실수를 더 쉽게 발견할 수 있습니다.