Kotlin Coroutines – Retrofit2 + Coroutines 동시에 다루기

Android의 스레딩 모델은 UI 스레드라고 불리는 싱글 스레드가 사용자의 인터페이스 렌더링, 이벤트 캡쳐 및 기타 여러 측면을 담당하는데 이는 모든 UI 프레임워크와 동일합니다. 네트워크 요청, DB 쿼리, 많은 연산과 같은 긴 작업을 수행하면 UI가 멈추어 ANR 오류가 발생합니다.

우리는 이런 문제를 해결 하기위해서 아래와 같은 몇가지 방식을 사용합니다.
1. AsyncTask – 순서대로 짧은 연산 실행, 동시에 수행 할 수 있음
2. Executors – 고정된 스레드 풀과 동시에 작업 실행
3. Intent Service – 순서대로 긴 연산을 실행, 큐잉 처리함
4. RxJava – 가장 인기 있으며, 안드로이드 프레임워크에서 지원하지 않음
5. Raw Threads

위의 방식은 훌륭하지만 올바르게 사용하기 위해선 미묘한 차이를 보입니다. 또, 디버깅과 취소처리가 간단하지 않습니다.
 

Kotlin Coroutines

코틀린 코루틴는 순차적으로 일어나는 일을 비동기 처리하기위한 방법입니다. 코루틴을 생성하는 것은 스레드를 만드는 것에 비해 비용이 적게듭니다. 그 이유는

코루틴은 컴파일 기술을 통해 완벽하게 구현됩니다. (VM 또는 OS측면에서 지원이 필요없습니다). Suspend는 코드 변환을 통해 작동합니다.

코루틴은 여전히 실험단계에 있으며, 이는 API가 앞으로 변화될 가능성을 의미합니다. 하지만 JetBrains은 이전 버전과 같은 호환성을 제공할것 이라고 약속했습니다. (여기를 통해 확인 해보세요.)
 

Code

코루틴을 사용하기위해서 함수를 suspend로 표시해야 모든 정상기능을 사용할 수 있습니다. 이러한 기능을 사용하기위해 실행및 비동기화(Launch & Async)하는 코루틴 빌더가 필요합니다.
 

Launch & Async

Launch – 현재 스레드를 차단하지 않고 새로운 코루틴을 싱행하고 코루틴을 제거하는데 사용 할 수 있는 작업으로 코루틴에 대한 참조를 반환합니다.

Async – 새로운 코루틴을 실행하고 지연후 결과를 반환합니다.

CoroutineContext – 코루틴 빌더가 실행되는 스레드를 정의합니다.

DefaultDispatcherCommonPool을 사용합니다. 개발자는 실행해야하는 스레드를 지정할 수있는 모든 권한을가집니다. 다른 옵션은 UI 스레드에서 실행되는 UI입니다.

CoroutineStart – 시작 방법 정의

  • DEFAULT – 즉시 실행을 시작
  • LAZY – 코루틴을 느리게 시작
  • ATOMIC – 자동으로 최적화된 방법으로 시작
  • UNDISPATCHED – 분산 처리방법으로 시작
  •  

    예제

    연속적으로 처리하는 작업

    UI (Main Thread)는 Context를 사용하여 새로운  코루틴 Launch를 만듭니다. 이 과정에서 백그라운드에서 무거운 작업을 수행하고 UI 스레드에서 두 개의 다른 코루틴을 실행합니다. Async는 새로운 코루틴을 생성하고 지연된것을 리턴하여 기다릴 수 있게 됩니다.

    간단히 말해 코드는 work1과 work2가 실행될 때 순차적으로 실행되고 result1은 work1이 완료 될 때까지 기다린 다음 result2는 work2가 완료 될 때까지 기다립니다. result1과 result2는 기본 스레드인 CommonPool을 Context로 사용했기 때문에 백그라운드 스레드에서 가져옵니다. 모든 예외는 해당 try catch 블록에서 발견됩니다.
     
    동시에 처리 하는 작업

    위의 변수의 결과는 동시에 work1과 work2가 완료 될때만 이용할 수 있습니다.  이를 위해 await() 호출시 지연된 모든 객체가 호출됩니다.

    코루틴 취소는 Job에서 cancel()을 통해 간단히 호출할 수 있습니다.

    Retrofit2 + Coroutines

    코루틴을 Retrofit2와 함께 사용하기 위해서는 Retrofit2 Kotlin Coroutines Adapter 라이브러리를 이용하여 Service 메소드의 반환 유형으로 Deferred 타입을 사용할 수 있습니다.

    apiService 인터페이스가 기존 Call대신 Deferred를 반환하기 때문에 이를 통해 이전에 다룬 코루틴을 그대로 사용할 수 있습니다.

    결론

    코루틴을 사용하면 코드를 쉽게 읽을 수 있는 비동기 코드 작성이 가능하며, 오류및 유지 보수를 줄 일 수 있습니다. 또한 코드의 경량화는 말할것도 없습니다.

    Dagger 2 소개, 안드로이드에서 Dependency Injection 사용하기전에

    이 글은 Janishar Ali가 작성한 Introduction to Dagger 2, Using Dependency Injection in Android: Part 1을 번역하였습니다.

    Android에서 Dagger2 사용법을 이해하려면 왜 필요한지를 먼저 알아야 합니다. 중요한 질문은 다음과 같습니다.

    왜 의존성 주입(Dependency Injection)이 필요한가?
    의존성 주입은 Inversion of Control 개념을 바탕으로합니다. 클래스가 외부로부터 의존성을 가져야합니다. 간단히 말해 클래스는 다른 클래스를 인스턴스화해야하지만 구성 클래스에서 인스턴스를 가져와야합니다.
    Java 클래스가 new 연산자를 통해 다른 클래스의 인스턴스를 생성하면 해당 클래스와 독립적으로 테스트하고 사용할 수 없으며 이를 하드종속성이라고합니다.

    그렇다면 클래스 외부에서 종속성을 제공하면 어떤 이점이 있을까요?
    가장 중요한 장점은 클래스를 재사용 할 가능성을 높이고 다른 클래스와 독립적으로 클래스를 테스트 할 수 있다는 것입니다.
    이것은 비즈니스 로직의 특정 구현이 아닌 클래스를 생성하는데 매우 효과적입니다.
    이제 조금은 이해 했으므로 종속성 삽입 탐색을 진행할 수 있습니다.

    큰 문제는 바로 DI(Dependency Injection)를 어떻게 할 것인가입니다.
    이 질문에 답하기 위해 우리는 과거를 되돌아 봐야합니다.
    종속성 컨테이너라는 프레임워크 클래스는 클래스의 종속성을 분석하는데 사용되었습니다. 이 분석을 통해 Java Reflection을 통해 클래스의 인스턴스를 만들고 정의 된 종속성에 객체를 삽입 할 수있었습니다. 이로 인해 어려운 의존성이 제거되었습니다. 그런 식으로 클래스를 독립적으로 테스트 할 수 있습니다. mock 객체를 사용합니다. 이것은 Dagger 1이었습니다.

    이 과정의 주요 단점은 두 가지입니다.
    첫째, Reflection 자체가 느림.
    번째로, 런타임에 종속성 해결을 수행하여 예기치 않은 충돌 발생.

    이것은 Dagger2의 탄생으로 이어졌습니다. Dagger2는 Google의 Square Dagger1에서 분기되었습니다.

    Dagger2에서 가져온 큰 변화는 주석 처리기(Annotation Processor)를 사용하여 종속성 그래프를 생성하는 것이 었습니다. 의존성을 제공하는 클래스는 이제 javax injection 패키지를 사용하여 빌드시 생성됩니다. 이것은 응용 프로그램이 실행되기 전에 가능한 오류 검사를 용이하게합니다. 생성된 코드는 직접 작성한것 처럼 보기 쉽습니다.

    참고: 주석 처리기는 프로젝트에서 사용할 소스코드 파일을 생성하기 위해 컴파일하는 동안 컴파일 된 파일을 읽는 방법입니다.
    그래도 잘 이해 되지 않는다면 다음 파트2의 예제를 보기위해 기다리면 됩니다.

    DI작동 방식에 대한 몇가지 정보를 드리겠습니다.
    클래스의 종속성을 설명하기위한 표준 Java 주석은 Java Specification Request 330(JSR 330)에 정의되어 있습니다.

    Injection 모드 :
    1. Constructor Injection: 생성자 삽입.
    2. Field Injection: 멤버 변수 삽입 (비공개이면 안됨).
    3. Method Injection: 메소드 매개 변수 삽입.

    JSR330에 따른 종속성 주입 순서
    1. Constructor
    2. Field
    3. Method

    @Inject로 주석처리된 메소드나 필드가 호출되는 순서는 JSR330에 의해 정의되지 않습니다. 메서드나 필드가 클래스에서 선언 된 순서대로 호출된다고 가정 할 수 없습니다.
    생성자가 호출 된 후에 필드 및 메서드 매개 변수가 삽입되므로 생성자에서 삽입 된 멤버 변수를 사용할 수 없습니다.

    Dagger2를 사용하여 종속성 주입 프로세스를 시각화하는 경향이 있습니다.

    종속성 소비자는 커넥터를 통해 종속성 공급자의 종속성(Object)을 필요로합니다.

    1. Dependency provider: @Module로 주석 된 클래스는 삽입 할 수있는 객체를 제공합니다. 이러한 클래스는 @Provides로 주석 된 메소드를 정의합니다. 이 메소드의 리턴 된 오브젝트는 종속성 삽입에 사용 가능합니다.
    2. Dependency consumer: @Inject 어노테이션은 의존성을 정의하는데 사용된다.
    3. Connecting consumer and producer: @Component 주석이 달린 인터페이스는 객체 제공자(모듈)와 의존 관계를 표현하는 객체 사이의 연결을 정의합니다. 이 연결에 대한 클래스는 Dagger에 의해 생성됩니다.

    Dagger2의 한계 :
    1. Dagger2는 필드를 자동으로 주입하지 않습니다.
    2. 비공개 필드를 주입 할 수 없습니다.
    3. 필드 주입을 사용하려면 @Component 주석이 달린 인터페이스에서 멤버 변수를 삽입 할 클래스의 인스턴스를 취하는 메소드를 정의해야합니다.