에러
> Task :composeApp:compileKotlinWasmJs FAILED
e: composeApp/src/commonMain/kotlin/viewmodel/MainViewModel.kt:8:27 Unresolved reference: IO
e: composeApp/src/commonMain/kotlin/viewmodel/MainViewModel.kt:18:36 Unresolved reference: IO
상황
잘 빌드 되다가 갑자기 위와 같은 에러메시지가 뜨면서, 빌드가 되지 않았습니다.
안드로이드에서는 당연하게 사용되었지만, Unresolved reference: IO 가 발생을 했습니다. 해결방안을 ChatGPT를 통해서 검색을 했습니다.
ChatGPT 대답
Dispatchers.IO와 Dispatchers.Default의 주요 차이는 그들이 최적화된 작업 유형에 있습니다. Dispatchers.IO는 입출력(I/O) 작업, 예를 들어 파일 읽기/쓰기, 네트워크 통신 등에 최적화되어 있으며, 이러한 작업을 처리할 때 사용하는 것이 권장됩니다. 반면, Dispatchers.Default는 CPU 집약적인 작업, 예를 들어 큰 데이터 처리나 복잡한 계산에 최적화되어 있습니다.
성능상의 차이
- Dispatchers.IO:
- I/O 작업은 일반적으로 CPU를 많이 사용하지 않지만, 대기 시간(예: 네트워크 응답 대기, 파일 시스템 접근)이 발생할 수 있습니다.
- Dispatchers.IO는 이러한 대기 시간 동안 다른 작업을 수행할 수 있도록 추가적인 스레드를 할당할 수 있어, I/O 작업을 효율적으로 관리합니다.
- 네트워크 통신과 같은 작업에 사용할 경우, 이 디스패처는 I/O 대기 시간에 다른 작업을 수행할 수 있도록 스레드 풀을 관리함으로써 리소스 사용을 최적화합니다.
- Dispatchers.Default:
- CPU를 집중적으로 사용하는 작업에 최적화되어 있으며, 스레드 풀의 크기가 CPU 코어 수에 기반하여 결정됩니다.
- 네트워크 요청과 같은 I/O 작업을 Dispatchers.Default에서 실행하면, 이론적으로는 I/O 작업의 대기 시간에도 스레드가 대기 상태에 머물러 있을 수 있으므로, 다른 CPU 집중적 작업을 실행하는 데 사용할 수 있는 스레드 수가 줄어들 수 있습니다.
- 그러나, 실제 애플리케이션에서 이러한 차이가 성능에 미치는 영향은 작업의 종류와 양, 애플리케이션의 구조에 따라 달라질 수 있습니다.
실제 영향
- 대부분의 경우, 네트워크 통신과 같은 I/O 작업을 Dispatchers.Default로 실행해도 애플리케이션 성능에 큰 영향을 미치지 않을 수 있습니다. 특히, 비동기 작업이 잘 관리되고 있고, 애플리케이션에서 동시에 실행되는 CPU 집중적 작업의 양이 많지 않은 경우에는 더욱 그렇습니다.
- 그러나, 애플리케이션에서 동시에 많은 네트워크 요청 또는 파일 I/O 작업과 CPU 집중적 작업을 실행하는 경우, 각 디스패처를 작업에 맞게 적절히 선택하는 것이 성능 최적화 측면에서 중요할 수 있습니다.
Dispatchers.IO를 Dispatchers.Default로 변경하는 것이 항상 성능 문제를 일으키지는 않지만, 작업 유형에 따라 가장 적합한 디스패처를 선택하는 것이 권장되는 베스트 프랙티스입니다.
멀티플랫폼 고려사항
- 플랫폼별 스레딩 모델: JVM 기반의 안드로이드 애플리케이션은 Dispatchers.IO와 같은 여러 종류의 코루틴 디스패처를 지원하지만, Kotlin/Native (iOS를 포함한 모든 네이티브 타겟)는 다중 스레딩 모델이 다르며, 기본적으로 메인 스레드와 백그라운드 스레드 간의 자유로운 데이터 공유에 제한이 있습니다. 이러한 차이는 Dispatchers.IO와 같은 특정 디스패처를 멀티플랫폼 코드에서 직접적으로 사용하기 어렵게 만듭니다.
- 공통 API 제공의 어려움: KMM은 가능한 한 모든 플랫폼에서 공통적으로 사용할 수 있는 API를 제공하는 것을 목표로 합니다. 그러나 모든 플랫폼에서 동일하게 동작하는 Dispatchers.IO와 같은 특화된 디스패처를 제공하는 것은 플랫폼별 실행 환경과 스레딩 모델의 차이로 인해 어려울 수 있습니다.
INSIGHT
- Dispachers.IO의 입출력 쓰레드를 사용하는 것또한 안드로이드에 종속적인 개발 방법이라는 것을 알았다.
- 성능을 중심으로 생각하지 않는다면, Dispachers.Default를 사용하더라도 생각보다 크게 이슈가 없어보인다.
'Android 공부 > KMM' 카테고리의 다른 글
코틀린 밖에 못하는 바보 ... - Compose multiplatform & Kotlin multiplatform 경험기 (1) (4) | 2024.09.08 |
---|---|
2024년의 NEW 감자튀김의 프로젝트 (0) | 2024.01.31 |
KMM (2) sqldelight (1) | 2022.04.16 |
KMM (1) 시작 (1) | 2022.04.16 |