만약 당신이 그런 느낌을 받은 적이 있다면 안드로이드 어플리케이션 데이터 로딩 중에 멈춘다면 메인 스레드에 문제가 있을 가능성이 매우 높습니다. 코틀린 코루틴은 많은 개발자들에게 구세주와 같은 존재로, 비동기 코드를 작성할 수 있게 해줍니다. 순차적이고 선형적인 것처럼 보입니다.코드가 마치 사다리처럼 보이게 만들었던 무한 콜백을 제거했습니다.
이 강력한 기능을 활용하려면 단순히 단어를 입력하는 것만으로는 충분하지 않습니다. suspend 공연 전에. 정말 중요한 건 아는 거죠. 실행되는 곳 각 코드 조각마다 담당 스레드가 다르며, 바로 이 부분에서 디스패처가 오케스트라 지휘자처럼 각 작업에 어떤 스레드가 배정될지 결정하는 역할을 합니다.
디스패처가 도대체 뭐야?
기본적으로 디스패처는 코루틴을 특정 사용자에게 할당하는 역할을 담당합니다. 실 또는 실들의 묶음 세부 사항. 코루틴은 가볍고 비동기적이지만, 백그라운드에서 코루틴을 지원하는 스레드가 실행되고 있다는 점을 기억해야 합니다. 적절한 디스패처를 구성하면 앱 충돌이나 성능 저하를 방지할 수 있습니다.
코루틴을 실행할 때 launch일반적으로 객체는 생성된 컨텍스트를 상속받습니다. 하지만 특정 로직 부분을 다른 스레드로 옮겨야 하는 경우 명시적으로 지정할 수 있습니다. 현재 어떤 스레드에서 실행 중인지 확인하는 유용한 방법은 다음과 같이 출력하는 것입니다. 스레드.currentThread().name이를 통해 우리는 마법이 일어나는 순간을 실시간으로 볼 수 있습니다.
역동적인 삼인조: 메인, IO, 그리고 기본
Kotlin은 여러 옵션을 제공하지만, 그중 99%는 세 가지를 사용하게 될 것입니다. 첫 번째는 다음과 같습니다. 디스패처.메인이 스레드는 사용자 인터페이스 스레드입니다. 화면의 텍스트를 업데이트하거나 UI 구성 요소와 상호 작용하는 것과 같은 매우 빠른 작업에만 사용해야 합니다. 여기서 계산 작업을 시작하면 앱이 충돌하고 사용자가 불편을 겪게 됩니다.
그런 다음 우리는 디스패처스.IO이는 모든 데이터 입력 및 출력의 핵심 역할을 합니다. 다음과 같은 용도에 이상적입니다. 파일을 읽고 API에 요청을 보냅니다. 또는 Room을 사용하여 데이터베이스를 쿼리할 수 있습니다. 이 디스패처는 I/O 작업이 CPU를 소모하지 않고 외부 응답을 기다리는 데 많은 시간을 소비하는 경우가 많기 때문에 훨씬 더 큰 스레드 풀을 사용합니다.
마지막으로 우리는 디스패처.기본값이는 프로세서 집약적인 작업에 최적화되어 있습니다. 즉, CPU 사용량이 많은 작업대용량 JSON 파일을 파싱하거나, 방대한 목록을 정렬하거나, 복잡한 수학 계산을 수행해야 하는 경우라면 바로 이곳이 적합합니다. 시스템 과부하를 방지하기 위해 일반적으로 CPU 코어 수에 맞춰 스레드가 할당됩니다.
또한 거기에 Dispatchers.Unconfined,하지만 진실은 잘 사용하지 않는 실제 프로젝트에서는 호출되는 위치에서 시작되고 어떤 스레드에서든 재개될 수 있기 때문에 대부분의 경우 예측하기가 매우 어렵습니다.
withContext를 사용하여 스레드를 전환하는 기술
바로 이곳에서 마법이 일어납니다. 메인 스레드 보안 (주요 안전 장치). 기능 withContext 이 기능을 사용하면 현재 코루틴을 일시 중단하고, 다른 디스패처로 이동하여 코드 블록을 실행한 다음, 완료되면 자동으로 원래 디스패처로 돌아갈 수 있습니다.
이 패턴의 가장 큰 장점은 함수를 보내는 쪽에서 어떤 스레드에서 호출해야 할지 걱정할 필요가 없다는 것입니다. 좋은 방법은 일시 중단된 함수 자체를... 컨텍스트를 직접 관리하세요예를 들어 함수 getDatos() 내부적으로 호출해야 합니다 withContext(Dispatchers.IO)이렇게 하면 뷰모델은 화면을 차단할 염려 없이 메인 스레드에서 해당 함수를 호출할 수 있습니다.
성능면에서 withContext 매우 효율적입니다. 콜백과 비교했을 때 추가적인 부하가 발생하지 않으며, 때로는 Kotlin이 다음과 같은 이점을 제공하기도 합니다. 스레드 스와핑 최적화 원하는 디스패처에 이미 진입했음을 감지하면 불필요한 이동을 방지합니다.
라이프사이클 관리: 범위 및 작업
코루틴을 무작위로 실행하는 것은 재앙과 메모리 누수를 초래할 수 있습니다. 이를 방지하기 위해 우리는 다음을 사용합니다. 코루틴스코프이는 작업의 수명을 정의합니다. 안드로이드에서는 다음과 같습니다. viewModelScope 뷰모델의 경우 및 lifecycleScope 액티비티 또는 프래그먼트의 경우, 컴포넌트가 종료되면 코루틴도 자동으로 취소됩니다.
우리가 사용할 때마다 launch o async, a가 생성됩니다 작업 객체이 작업은 코루틴을 제어할 수 있게 해주는 티켓과 같습니다. 우리는 이를 사용할 수 있습니다. job.join() 끝나기를 기다리거나 job.cancel() 결과가 더 이상 우리에게 중요하지 않게 되면 중단하는 것입니다. 이것이 바로 그 기본 원칙입니다. 구조화된 동시성아이들은 아버지와 연결되어 있으며, 고아에 대한 기억은 전혀 남아 있지 않습니다.
병렬 실행과 launch 및 async의 차이점
때로는 시간을 절약하기 위해 여러 가지 일을 동시에 처리하고 싶을 때가 있습니다. 이를 위해 우리는 다음을 사용합니다. async객체를 반환합니다. Deferred. 같지 않은 launch (기본적으로는) 찍고 잊어버리세요.), async 이 함수를 사용하면 값을 가져올 수 있습니다. await().
여기서 주의하세요: 당신이 사용하는 것 async 그렇다고 해서 자동으로 병렬 처리가 되는 것은 아닙니다. 두 개의 프로세스를 실행하면 병렬 처리가 이루어집니다. async en Dispatchers.Main이 작업들은 동일한 스레드에서 순차적으로 실행됩니다. 이를 달성하기 위해 실제 병렬성당신은 그것들을 지정해야 합니다. Dispatchers.Default o IO이를 통해 여러 CPU 코어에 데이터를 분산시킬 수 있습니다.
병렬 작업 그룹을 관리하기 위해 빌더는 coroutineScope 이는 매우 중요합니다. 이를 통해 모든 자식 코루틴이 작업을 완료할 때까지 함수가 종료되지 않도록 보장하고, 도중에 발생할 수 있는 예외를 포착하여 처리되지 않고 방치되지 않도록 합니다.
결론적으로, 과도하게 사용하지 않는 것이 중요합니다. GlobalScope 테스트 및 취소가 매우 어렵기 때문입니다. 이상적으로는 항상 다음을 신뢰해야 합니다. Android 범위 계층 구조 그리고 작업량에 따라 적절한 배차 담당자를 사용합니다. 이를 결합함으로써 viewModelScope, withContext 고강도 작업에 적합하며 async 동시성 처리를 통해, 백그라운드에서 데이터를 처리하는 동안에도 매끄러운 인터페이스를 유지하는 견고한 애플리케이션을 구현할 수 있습니다.