Thread 는 프로그램에서 노동자 역할을 한다. Thread는 우리가 요청하는 모든 일을 수행한다.그러면 Thread을 알아야하는 이유는 뭘까? 어쩌피 지금도 몰랐던 상태였어도 충분히 일을 알아서 다 잘하고 있는거 아닌가? 결과만 두고보면 작동을 하기 때문에 맞다고 할 수 있지만, 최선은 아니다.
우선 Main Thread 부터 알아보자. Main Thread는 이름에서부터 알 수 있듯이, 메인으로 작업을 하는 Thread 이다. 그러면 무엇을 Main 으로 하는것일까?
Swift 에서는 UI 관련 작업들은 Main Thread에서 하게끔 되어 있다. 만약 이를 어길경우는 Runtime Error를 볼 수 있다.
그러면 왜 Thread가 많은데도 불구하고 단 Main Thread 에서만 UI 관련 작업들을 수행할 수 있게끔 하는것일까?
위 문제의 해답을 찾기 위해선 우선 iOS 랜더림 프로세스를 한번 살펴보자. 아래 그림은 iOS Renering Framework이다.
1. UIKit : 모든 종류의 구성 요소를 포함하고, 사용자의 이벤트를 처리, 랜더링 코드를 포함하지 않고 있다.
2. Core Animation : 모든 뷰를 그리거나, 디스플레이하고, 애니메이션을 책임 지고 있다. 사용자가 실제로 보는 화면은 전부 Core Animation에서 관리하고 있다.
3. OpenGL ES : 2D 및 3D 랜더링 서버 제공
4. CoreGraphics : 2D 랜더링 서버 제공
5. Graphics HardWare : GPU
화면에 표시되는 모든 것들은 Core Animation FrameWork에서 관리 된다고 하는데, Core Animation pipeline도 같이 살펴보자.
1. Commit Transaction : view를 배치하고, 이미지 디코딩 및 포맥 변환 작업처리를 한다. 뷰 레이어를 pack up 해서 render server로 보낸다.
2. Render Server : 전 단계에서 보낸 package 를 deserialzation 과정을 거쳐 rendering tree 로 변환한다. 그리고 레이어 지침을 보고 드로임 지침 새성, Vsync signal을 기다린후 openGl 을 호출한다.
3. GPU : Vsync Signal에 맞춰 openGL 사용해 렌더링을 시작한다. 렌더링이 끝난 면 Buffer에 저장.
4. Display : Buffer에 있는 정보를 Screen에 보내서 Display 한다.
위 4단계로 구성되어 있는 파이프라인은 1초에 60번 실행된다고 한다. 만약 Main Thread가 아닌 다른 Thread 에서도 동시다발적으로 View 변경을 요청하는 경우, 해당 작업은 매우 무거운 작업이기에 성능에 직접적인 영향을 끼칠수 있다고 한다. 또한 GPU 병목현상 발생 가능성이 높아 질 수 있기 때문에, Swift에서는 Main Thread 하나만 UI 작업을 담당하고 있다.
정리를 해보자면 성능 감소의 위험부담성 떄문에 Main Thread 에서는 UI 작업을 담당한다. 그러면 다른 작업들은 어떻게 분배가 되고, 다른 Thread도 놀지 않고 작업을 돌릴 수 있는것일까? 다음 포스트는 GCD에 관해서 올릴 예정이다.
개발자 (진)