데브허브 | DEVHUB | Why 99% Are Using Coroutine Dispatchers WRONG!Why 99% Are Using Coroutine Dispatchers WRONG!
suspend 함수를 withContext(Dispatchers.IO)로 감싸는 것은 대부분 불필요하며, 이미 내부적으로 올바른 디스패처로 전환되기 때문에 성능 향상 없이 코드만 복잡하게 만듭니다. 🚫
- 코루틴은 단일 스레드 내에서 여러 개가 독립적으로 실행될 수 있으며, 스레드와 달리 블로킹 없이 비동기 작업을 처리하여 효율성을 높입니다. 🧵
- 코루틴 디스패처는 코루틴이 실행될 특정 스레드를 결정하는 역할을 하며, 작업 유형에 따라 최적의 스레드 풀을 제공합니다. 🚦
- 메인 디스패처는 앱의 UI 스레드에서만 코루틴을 실행하며, UI 업데이트와 같은 메인 스레드 작업에 사용됩니다. 🏠
- IO 디스패처는 최소 64개의 스레드를 가진 큰 스레드 풀을 사용하여 네트워크 요청, 파일 읽기/쓰기와 같은 I/O 바운드 작업에 적합하며, 대기 시간 동안 다른 작업을 병렬로 처리할 수 있습니다. 🌐
- 기본 디스패처는 CPU 코어 수만큼의 스레드를 가지며, 대규모 데이터 매핑이나 복잡한 계산과 같은 CPU 집약적인 작업에 최적화되어 CPU 활용을 극대화합니다. 🧠
- 메인 안전성 원칙은 모든
suspend 함수가 메인 스레드에서 안전하게 호출될 수 있어야 함을 의미하며, 블로킹 호출에 대한 디스패처 전환 책임은 해당 suspend 함수 내부에 있습니다. 🛡️
withContext는 오직 블로킹(suspending이 아닌) 코드를 실행하여 현재 스레드를 차단할 수 있는 경우에만 사용해야 하며, 이는 해당 블로킹 작업을 별도의 스레드에서 안전하게 실행하기 위함입니다. ✅
- 파일에 직접 쓰는 것과 같이 실제 블로킹 I/O 작업을 수행하는 경우,
withContext(Dispatchers.IO)를 사용하여 메인 스레드 차단을 방지하는 것이 올바른 사용 예시입니다. 💾
- 복잡한 Flow 체인(필터링, 매핑 등)에
flowOn(Dispatchers.Default)를 적용하면, 해당 체인 전체가 메인 스레드가 아닌 다른 스레드에서 실행되어 UI 지연을 방지할 수 있습니다. 🌊