[iOS 오토레이아웃 가이드] Debugging Auto Layout - Unsatisfiable Layouts

[iOS 오토레이아웃 가이드] Debugging Auto Layout - Unsatisfiable Layouts

auto layout 엔진이 유효한 해결책을 찾을 수 없을 때 Unsatisfiable layouts이 생긴다. 두 개 이상의 제약조건이 충돌했을 때 생긴다. 

Identifying Unsatisfiable Constraints

storyboard에서 작업할 때 아래 사진에서 나온 것과 같이 빨간색원에 화살표를 본 적이 있을거에요. 저게 unsatisfiable constraints(이하 에러)를 알려주는 신호입니다. 저걸 누르면 에러 리스트가 나옵니다. 그리고 각각에 맞게 해결책을 제시해 줍니다. 하지만 모든 에러를 잡아주지는 못합니다. 현재 캔버스 사이즈에 대해서만 에러를 감지합니다. 루트뷰가 늘어나거나 줄어들거나 또는 뷰의 내용이 늘어나거나 줄어들거나 할 때는 에러를 잡지 못합니다. 또한 맞게 했는데 스토리보드상에서 이상하게 나올 때가 있습니다. 그래서 실행시켜서 시뮬레이터나 실기기에서 확인하고 스크린사이즈나 방향, 크기, 언어등을 바꿔가면서 테스트 해야 합니다.

iOS auto break points

UIViewAlertForUnsatisfiableConstraints를 이용하면 좋습니다.

Preventing Unsatisfiable Constraints

unsaisfiable constraints는 xcode가 알려주기 때문에 고치기 쉽습니다. 그리고 대부분 삭제하거나 optional constraints으로 바꾸면 해결할 있습니다. 

하지만 자세히 봐야할 상황들이 있습니다.

- 코드로 뷰를 구성할 때 뷰의 translatesAutoresizingMaskIntoConstraints는 true입니다 이것도 하나의 요인으로 false로 해야합니다.

- 공간이 없을 때도 잘 발생합니다. 특히 국제화나 다이나믹 타입 text때문에 많이 발생합니다. 

- required constriants는 optional constratins(999)로 하는 걸 고려. 그러면 중돌이 일어날 때 layout이 깨지는 지점을 제어 할 수 있게 됩니다.

예를 들어 레이아웃이 깨지는 지점에 999를 주면 대부분 상황에서는 rrequired처럼 되지만, 충돌이 일어나면 999를 가진 제약조건은 깨지고 나머지 레이아웃을 보호합니다

-  뷰 사이즈는 에러를 찾기 좋으니 CHCR priority가 1000인 intrinsic content size는 주지마세요 

- initrinsic content size를 꼭 사용해야 될 때가 있다. 그런 상황에서도 위와 같이 주면 예기치 못하게 레이아웃이 깨질 수 있으니 예측가능한 몇몇 지점을 만들어 사용하는 게 좋다