UI관련 작업은 “Main Queue”에서 처리해야 한다.
여러 프로젝트를 통해 main에서 UI작업을 해야한다는 것은 체득되었다.
다시 말하자면,
- UI를 그리는 등 UI와 관련된 작업은
main스레드에서 작업해야한다. - 심지어 UI 작업을
main스레드에 할당하지 않으면 에러가 발생한다.
📌 그런데 왜 Main에서 UI작업을 처리할까?
일단 생각을 해본 결과 아래의 내용처럼 길어졌다.
UIKit은 Thread Safe 하지 않다.
UIKit은 UI를 구성하는 구성 요소들의 집합이다.
즉, 화면에 즉각적으로 표현이 되는 요소들이다.
그러나 이 UIKit 대부분의 요소들은 Thread Unsafe한 성질을 가지고 있다.
여러 스레드에서 접근이 가능한 것이다.
만약 Main Thread말고 다른 Thread에서도 UI작업이 가능하다면?
Race Condiotion 이 발생할 수 있다.
우리가 보는 화면을 여러 스레드에서 막 접근하여 바꿀 수 있게 된다.
예를 들어, 버튼의 모양을 바꾸는 일, 버튼의 색을 바꾸는 일이 충돌하여 의도대로 동작하게 된다.
즉, Thread Unsafe한 UIKit 작업을 Serial Queue인 Main Thread로 가져와서 작업을 하는 것!
📌 꼭 Main Thread 여야하는 이유는? 다른 Serial 큐에 넣으면 안되는 것인가?
UI 작업을 꼭 Main 스레드에서 작업해야하는 이유는 메인 스레드에는 Main RunLoop가 동작하고 있기 때문이다.
Main 스레드에서는 RunLoop가 일정한 주기를 유지하며 계속 동작하고 있고, 이 주기에 맞춰서 사용자의 입력을 받아 UI를 그리게 된다. (이러한 주기를 View Drawing Cycle이라고 한다.)
하지만 모든 스레드는 각자의 RunLoop를 가질 수 있다.
위에서 말한대로 모든 스레드의 RunLoop에 따라 각자가 UI를 그리게 된다면 UI그리는 시점이 모두 제각각이게 된다.
Race Condition도 발생하고 비효율적이고 관리가 되지 않기 때문에 Main RunLoop로 고정을 한 것이 아닐까 싶다.
결론 : Main Run Loop는 Main에 있다.
📌 애초에 UIKit을 왜 Thread Unsafe하게 만들었을까?
결론 : "UIKit이 ThreadSafe하게 설계한다면, 이는 추가적인 오버헤드와 복잡성을 야기할 수 있고, 성능을 떨어뜨릴 수 있다. 또한 코드의 복잡성을 증가시킬 수 있기 때문이다" 라고 구글검색에서 나왔다.
📌 그러면 어떤 문제에서 오버헤드와 복잡성이 증가할까?
일단 ThreadSafe하게 만들기 위해서는 공유자원 접근에 대한 Locking이 필요하다.
(Locking을 사용하면 동시적으로 공유자원에 접근하는 코드 영역인 크리티컬섹션에 접근하는 스레드의 수를 제한 할 수 있게 된다.)
여기까지 대략 알고있는 내용이고,
하지만 Locking을 사용하는 것 자체가 추가적인 오버헤드가 발생하고 또 다른 레이스 컨디션이 발생할수 있다고한다..(Locking을 쓰면 레이스 컨디션은 발생을 안하지 않나..)
물론 DeadLock이나 Starvation 같은 상황은 일어날 것 같다.
쨋든 개발자가 개발을 할때 있어서 공수비용도 많이들어가고 설계도 힘들어지고, DeadLock, Starvation같은 상황 때문에 Unsafe하게 설계를 하지 않았을까 생각이든다..
