RunLoop: 잠들고 깨는 메인 스레드

Day 2) 메인 스레드와 런루프

• 메인 스레드의 책임: 이벤트 처리, 레이아웃/렌더링 준비, UI 업데이트
• RunLoop: 입력 이벤트/타이머/소스 처리의 반복 구조
• 동기 작업이 UI를 멈추게 하는 이유: 메인 스레드가 루프를 못 돌아 입력/그리기 처리 지연

정리 질문

• 메인 스레드에서 하면 안 되는 작업은 무엇이며, 어디로 보내야 하는가?

---

Thread

스레드(Thread)는 “코드”가 아니라 코드를 실행하기 위한 실행 흐름(실행 컨텍스트)에 가깝다.
OS는 프로세스 안에 스레드를 만들고, 스레드 단위로 CPU 시간을 배분한다.

• 스레드가 가진 것(감각적으로)
  • 호출 스택(Stack)
  • 레지스터 상태(PC, SP 등)
  • 스케줄링 메타 데이터

---

Main Thread

메인 스레드는 iOS에서 “UI 반응성”을 책임지는 핵심 스레드다.

• 이벤트 처리: 터치/제스처/스크롤
• UI 업데이트: 상태 변경 반영
• 레이아웃/렌더링 준비: 다음 프레임에 반영될 변경을 정리하고 제출(커밋) 가능한 상태로 만들기

사용자는 CPU나 OS를 직접 보지 못하고 화면의 반응만 본다.

그래서 메인 스레드가 막히면 사용자는 곧바로 “앱이 멈췄다”로 체감한다.

---

RunLoop

RunLoop는 스레드에서 이벤트를 처리하는 반복 구조다.

• 할 일 있으면 깨어서 처리
• 할 일 없으면 잠들어(sleep) CPU를 쉬게 함

비유

• Main Thread = 경비 아저씨 (실제로 일하는 주체)
• RunLoop = 경비 아저씨의 업무 루틴(일과표)

경비 아저씨는 아래를 반복한다.

• 할 일 없으면 의자에서 잠든다
• 초인종이 울리면(이벤트/소스) 깬다
• 알람시계가 울리면(타이머) 깬다

 

Main vs Background

• 메인 스레드의 RunLoop는 시스템/프레임워크가 자동으로 구성하고 실행한다.
• 백그라운드 스레드는 필요할 때만 RunLoop를 직접 돌린다.
  
  예를 들어, 포트 기반 메시지(Port-based input source)를 받아야 해서 스레드가 계속 살아 있어야 한다면,
  그 스레드에 RunLoop를 붙여서 이벤트를 기다리게 만든다.

(+) RunLoop에서 실행된다는 말
RunLoop는 별도의 엔진이 아니라, 그 스레드(대부분 메인 스레드)가 이벤트를 처리하는 반복 루틴이다.
그래서 “RunLoop에서 실행된다”는 말은 보통 “메인 스레드가 RunLoop 턴 중에 그 코드를 실행한다”는 뜻이다.

---

RunLoop 정리 (Deep Dive)

- Timer

타이머를 등록하면 “1초마다 이벤트가 큐에 쌓인다”기보다는,

• RunLoop가 다음에 깨어나야 할 시각(next fire time)을 계산해두고
• 그 시각까지는 보통 잠든 뒤
• 시간이 되면 깨어나 “지금 실행할 타이머가 있나?”를 확인하고 fire 한다

- Source

RunLoop를 깨우는 건 타이머만이 아니다.

• 입력 이벤트(터치/제스처)
• 메인 큐 작업(DispatchQueue.main)
• 포트 기반 메시지(Mach port, socket 등)

즉, RunLoop는 시간 기반(알람) / 이벤트 기반(초인종) 두 축으로 깨어난다고 보면 이해가 쉽다.

Port-based / Custom Source (아주 쉽게)

• Port-based source: “전화선/초인종” 같은 통로로 메시지가 들어오면 깨서 처리
• Custom source: 내가 직접 만든 규격(콜백)으로 깨우는 사용자 소스

Run Loops— Threading Programming Guide (Apple Archive)

RunLoop (Foundation)

CFRunLoop.c (CoreFoundation 오픈소스)

---

RunLoopTracer (Self Check)

RunLoop가 “실제로 잠들었다가 깨는지” 확인하려고, 메인 RunLoop에 Observer를 붙여 activity를 찍어봤다.

코드(핵심)

final class RunLoopTracer {
    private var observer: CFRunLoopObserver?

    func start() {
        stop()

        let activities: CFRunLoopActivity = [
            .entry,
            .beforeTimers,
            .beforeSources,
            .beforeWaiting,
            .afterWaiting,
            .exit
        ]

        observer = CFRunLoopObserverCreateWithHandler(
            kCFAllocatorDefault,
            activities.rawValue,
            true,
            0
        ) { _, activity in
            switch activity {
            case .beforeTimers:  print("RunLoop: beforeTimers")
            case .beforeSources: print("RunLoop: beforeSources")
            case .beforeWaiting: print("RunLoop: beforeWaiting (going to sleep)")
            case .afterWaiting:  print("RunLoop: afterWaiting (woke up)")
            default: break
            }
        }

        if let observer {
            CFRunLoopAddObserver(CFRunLoopGetMain(), observer, .commonModes)
        }
    }

    func stop() {
        if let observer {
            CFRunLoopRemoveObserver(CFRunLoopGetMain(), observer, .commonModes)
        }
        observer = nil
    }
}

로그(요약)

RunLoop: beforeTimers
RunLoop: beforeSources
RunLoop: beforeWaiting (going to sleep)
RunLoop: afterWaiting (woke up)
...

여기서 인상적이었던 건 두 가지다.

1. RunLoop는 “계속 바쁘게 도는 while” 느낌이 아니라,
   잠들기 직전(beforeWaiting)과 깨어난 직후(afterWaiting)가 반복되는, 진짜 “sleep ↔ wake” 구조로 보였다.
2. 내가 화면을 터치하지 않았는데도 afterWaiting이 찍혔는데, 이건 정상이다.
   사용자 입력이 없어도 시스템 내부 작업/메인 큐 작업/타이머 등으로 RunLoop는 깨어날 수 있다.

---

Problem

앱을 사용할 때 화면이 버벅이거나 멈추는 현상을 한 번쯤은 경험해봤을 것이다. 대부분은 아래처럼 체감된다.

• 버튼을 눌렀는데 반응이 늦다
• 스크롤이 툭 끊긴다
• 애니메이션이 멈춘 것처럼 보인다

이 현상들을 RunLoop 관점에서 한 문장으로 바꾸면 이렇게 된다.

메인 스레드가 동기 작업에 묶여 RunLoop 턴이 진행되지 못했다.

---

원인 

대표적인 케이스는 다음처럼 정리된다.

1. 긴 CPU 작업
   - 대용량 JSON 디코딩, 이미지 디코딩/리사이즈, 복잡 계산, 큰 레이아웃 작업
2. I/O 블로킹
   - 파일/DB/네트워크 같은 “기다림이 본질”인 작업을 UI 흐름에서 동기로 수행
3. 동기화 대기
   - 락 경합, 세마포어로 메인이 기다리는 구조
   - “다른 스레드 끝날 때까지 메인이 멈춘다”가 그대로 UI 멈춤으로 이어짐

---

해결

결론은 단순하지만, 이 단순함을 지키는 게 어렵다.

• 메인 스레드에는 UI 관련만 남긴다.
• 무거운 작업은 백그라운드로 보내고, 결과만 메인으로 복귀해 UI에 반영한다.

다만 “무조건 백그라운드”가 정답은 아니다.
작업을 분리하면 스케줄링/큐잉/메인 복귀/동기화 비용이 생기고, 작업이 작다면 오히려 그 비용이 더 클 수 있다.

 

그래도 I/O, 디코딩, 큰 연산처럼 실행 시간이 흔들리는 작업은 최악 케이스에서

메인 RunLoop를 막을 수 있기 때문에 분리하는 편이 안전하다.

 

예)

• CPU/IO 작업 → 백그라운드
• UI 업데이트 → MainActor / DispatchQueue.main

---

(+) UI  Update (Commit과 Frame)

UI 갱신을 이해할 때 중요한 포인트는 이거다.

메인 스레드는 “픽셀을 직접 그린다”기보다는,
변경사항을 모아 커밋(제출)할 수 있게 만들고, 제때 제출되게 하는 쪽에 가깝다.

 

CATransaction

변경사항을 “묶는 단위”로 이해하면 편하다.

• 비유: 장바구니/서류 묶음
• 이 변경도, 저 변경도 모아서 한 번에 제출

CADisplayLink

디스플레이 리프레시에 맞춰 콜백을 받는 “프레임 박자 소스”다.

• 비유: 메트로놈
• “지금 프레임 타이밍이야”를 알려줌

Explore UI animation hitches and the render loop

Understanding hitches in your app

---

정리 질문

- 메인 스레드에서 하면 안 되는 작업은 무엇인가?

• 대용량 디코딩/파싱, 이미지 디코딩/리사이즈 같은 무거운 CPU 작업
• 파일/DB/네트워크 같은 블로킹 I/O
• 락/세마포어 등으로 메인이 “기다리는” 구조

- 어디로 보내야 하는가?

• 백그라운드 스레드(Concurrency/GCD/OperationQueue)로 보내고
• UI 반영만 메인에서 처리한다

결론

• RunLoop는 “계속 도는 while”이 아니라, 대부분 잠들어 있다가 필요할 때 깨어나는 구조로 보는 게 이해가 쉽다.
• UI가 멈춘다는 건 대개 메인 스레드가 동기 작업에 묶여 RunLoop 턴이 밀린 결과다.
• 그래서 메인 스레드 성능 최적화는 결국,
  “메인을 가볍게 유지하고, 무거운 작업은 분리하는 설계”로 귀결된다.

---

아래는 내가 해당 내용을 학습하기 위해 GPT와 열심히 씨름한 내용이다. 

Chat GPT