왜 UI는 메인 스레드에서 다룰까?
1. UIKit의 대부분 구성요소는 non-atomic하게 구성되어있는데, 이는 곧 Thread-safe하지 않다는 것을 의미한다. 모든 속성을 Thread-safe하게 설계하기엔 UIKit이 너무 방대한 프레임워크이다. 이를 억지로 보장하도록하는 것은 오히려 성능상으로 좋지 않다는 애플의 발표도 있다.
예를 들어 생각해보자. UITableView의 셀이 백그라운드 스레드에서 제거되었는데 다른 백그라운드 스레드가 해당 셀에 접근하려고하면 어떻게될까? 크래시가 발생할 것이다. 또 백그라운드 스레드의 Runloop에 특정 뷰에 대한 제거가 진행중에 있는데, 사용자가 해당 뷰를 탭하면 그 응답을 어떻게 처리해야할까? 어떤 스레드에서 해당 응답을 처리해야할지조차 애매하다.
2. View Drawing Cycle을 생각해보면 하나의 Runloop에서 이를 확인하고 관리하게 된다. 하지만 만약 각 스레드의 Runloop에서 View의 life cycle을 관리하게 되면 화면의 UI가 변경되었을 때 모든 변경사항을 화면에 존재하는 여러 View들이 확인할 수 없게 된다. 따라서 View가 깨질 것이다.
3. iOS는 그림을 표현할 때 특정한 랜더링 프로세스(코어애니메이션 -> 렌더서버 -> GPU -> 표시)를 거치는데, 여러 스레드에서 각 뷰의 변경사항을 GPU로 보내면 각 정보를 해석하기 위해 많은 오버헤드가 발생할 수 있다.
4. 페이스북에서 비동기적으로 UI를 업데이트하는 프레임워크(AsyncDisplayKit(Texture), ComponentKit)을 개발했지만, 이 역시 결과적으로는 메인 스레드에서 변경사항이 적용되도록하고 있다.
참고
'🍎 Apple > Question' 카테고리의 다른 글
| [iOS] Remote data를 가져올 때 Data(contentsOf:)를 사용하면 안되는 이유 (1) | 2022.05.17 |
|---|---|
| [UIKit] dequeueReusableCell (withIdentifier:for:) vs (withIdentifier:) (2) | 2022.04.18 |
| [iOS] #selector는 무엇이며 왜 필요할까? (0) | 2022.02.07 |
| [iOS] 왜 오토 레이아웃을 사용할 때는 translatesAutoresizingMaskIntoConstraints = false를 할까? (0) | 2022.01.21 |