- Auto Layout recap: 뷰의 절대적 위치가 아니라 뷰 사이의 제약을 통해서 다양한 화면을 대응하는 것
- iOS 12 에서의 성능개선 → 자동으로 얻을 수 있다.
- 어떻게 했는가?
- updateConstraints 메소드 레벨에서
- 일단 super는 반드시 호출한다.(UIKit 레벨에서 하는 일이 있다.)
- 리프에서 루트 방향으로 호출된다.(레이아웃과 디스플레이의 반대)
- 레이아웃과 대응되는 메소드들을 가진다.(setNeedsUpdateConstraints, updateConstraintsIfNeeded) → 있는 이유도 같고, 권장도 setNeeds
- updateConstraint에서 제약을 비활성화하고 다시 활성화하는 건, layoutSubViews에서 remove하고 add하는 것과 같다.
- 즉, 기존 제약이 있으면 이를 최대한 살려야 한다.
- 렌더 루프의 위험성
- 렌더 루프는 일을 몰아서 하기 때문에 낭비되는 일을 줄일 수 있다.
- 다만 매우 자주 실행되기 때문에 조금만 느려도 성능에 치명적이다.
- 제약의 활성화와 비활성화가 의미하는 것(내부 구조)
- 윈도우는 레이아웃 엔진을 가지고 있다.(private)
- 뷰는 자신이 속한 윈도우를 통해서 엔진에 접근한다.
- 제약이 추가되면, 방정식(Equation)이 엔진에 추가된다.
- 등식의 변수는 View가 된다.
- 내부에서는 선형 대수를 풀어낸다.
- 엔진에서의 값이 바뀌게 되면, 뷰에 신호를 준다.
- 뷰는 슈퍼뷰의 setNeedsLayout을 호출한다.
- layoutSubviews에서는 엔진에서 값을 가져와서 세팅한다.
- 이후 서브뷰의 setBounds()와 setCenter를 설정한다.
- 제약을 해제하고 다시 넣으면, 이전 계산 결과를 활용할 수 없기 때문에, 불필요한 연산이 늘어난다.
- 로컬 vs 글로벌
- 서로 연관성이 없는 뷰와 제약을 넣지 말라
- 로컬 기준으로 해야만, 복잡도가 선형으로 증가한다.
- 그래서 엔진이 뭔데?
- 레이아웃 캐시 & 의존성 추적
- 문제를 최대한 간략하고 자연스럽게 표현할 수 있어야 한다.
- 다른 문제들은?
- 부등식: 방정식과 거의 동일하다.
- 상수 설정: 상수 설정은 단순 대치기 때문에 빠르게 일어난다.
- 우선순위: 할일이 늘어난다. 에러를 최소화 하는 방향으로 동작하도록 되어 있기 때문이다.
- 비직관의 영역 → 측정으로 해결해야 한다.
- 근데 여기서 나온 instrument는 안나왔다.
- 뷰를 제거하기 보다는 hidden으로 처리할 것
- 필요한 제약만 배열로 가지고 있다가 토글하는 식으로 하자
- intrinsic size
- 특정 뷰에서 사용중인 피쳐
- 만약 시스템보다 많은 정보를 가지고 있어서 빠르게 텍스트 크기를 알 수 있다던지 하면 오버라이드 하는게 좋다.
- 오토레이아웃에 완전히 맡길꺼면 UIView.noIntrinsicMetric을 사용하자
- systemLayoutsizeFitting: 프레임과 함께 레이아웃을 동작시켜야 할 때 사용
- 이 메소드는 생각보다 무겁다.
- 엔진 인스턴스 생성
- 제약 추가
- 레이아웃 계산
- 뷰 크기 반환
- 엔진 인스턴스 폐기
- 보통 셀프 사이징 셀에서 쓰는데, 성능 문제가 있다면 그 부분도 고려해보라