앨런 iOS Concurrency(동시성) - 디스패치큐와 오퍼레이션큐의 이해

안녕하세요. 오랜만에 새소식으로 인사드리네요.

다름이 아니오라,

왜 UI를 메인쓰레드에서 업데이트 해야할까? 라는 질문에 대한 좋은 글이 있어, 해석본을 만들게 되었고 공유해 드리려고 합니다.

혹시나 좋은 참고 자료가 되었으면 합니다.

(글의 원본 출처)

https://medium.com/@duwei199714/ios-why-the-ui-need-to-be-updated-on-main-thread-fd0fef070e7f

(해석본 pdf자료)

https://drive.google.com/file/d/1dFw6sJsxV-huK3BoHXgDq-7rXy9yBq9l/view?usp=sharing

간단하게 요약해 드리자면,

1) UIKit의 모든 속성을 Thread-safe하게 설계하면, 느려짐과 같은 성능저하가 발생할 수 있기 때문에 그렇게 설계할 수 없다. (Thread-safe하지 않게 설계한 것은 애플의 의도다.)

2) 메인 런루프(Runloop)가 뷰의 업데이트를 관리하는 View Drawing Cycle을 통해 뷰를 동시에 업데이트 하는 그런 설계를 통해 동작하고 있는데, (메인쓰레드가 아닌)백그라운드 쓰레드가 각자의 런루프로 그런 동작을 하게되었을때, 뷰가 제멋대로 동작할 수있다. (예를  들어, 기기를 회전 했을때, 동시에 뷰의 레이아웃이 재배치되는 그런 동작을 못하게 될 수도 있다.)

3) iOS가 그림의 그리는 렌더링 프로세스(코어애니메이션 -> 렌더서버 -> GPU -> 표시)가 있는데, 여러 쓰레드에서 각자의 뷰의 변경사항 GPU로 보내면 GPU는 각각의 정보를 다 해석해야하니 느려지거나, 비효율적이 될 수 있다.

4) Texture나 ComponentKit이라는 페이스북에서 개발한 비동기적 UI 프레임워크가 있긴 하지만, View Drawing Cycle가 유사한 방식으로 적절한 타이밍에 메인 쓰레드에서 동시에 업데이트 하도록 하고 있다.

이정도  내용입니다. 사실, iOS뿐만 아니라 윈도우나 다른 OS에서도 마찬가지로 이런 위의 유사한 여러가지 이유때문에 구조적으로 메인쓰레드에서만 UI업데이트를 할 수 있도록 하고 있는 것이 아닐까, 다시 생각해보게 하는 글이었습니다.

그냥 한번쯤 생각해 볼 수 있는 주제라.. 조금의 도움이 되시길 바랍니다 ^^

감사합니다.