<블로그 원문은 이곳에서 확인하실 수 있습니다>
이 블로그 게시물은 WorkManager에 관한 새로운 블로그 시리즈 중 첫 게시물입니다. WorkManager의 기초, WorkManager의 사용 방법과 시점, 막후에서 실제로 벌어지는 일에 대해 탐구해보겠습니다. 그런 다음 더 복잡한 사용 사례를 살펴보겠습니다.
WorkManager란?
WorkManager는 제약 조건 이 충족될 때 뒤로 미룰 수 있는 백그라운드 작업을 실행하는 Android 라이브러리입니다.WorkManager는 앱을 종료하더라도 시스템이 실행할 것이라는 보장 이 필요한 작업을 위한라이브러리입니다.
다시 말해, WorkManager는 Android의 백그라운드 동작 제한이 거쳐온 수년간의 발전 과정을 집약한 배터리 친화적인 API를 제공합니다. WorkManager는 백그라운드 작업을 실행해야 하는 Android 애플리케이션에 매우 중요합니다!
WorkManager의 사용 시점
WorkManager는 애플리케이션 프로세스의 활성화 여부에 상관없이 다양한 제약 조건 충족 시 실행해야 하는 백그라운드 작업을 처리합니다. 앱이 백그라운드에 있거나 포그라운드에 있거나 포그라운드에서 시작하지만 백그라운드로 이동할 때 백그라운드 작업이 시작될 수 있습니다. 백그라운드 작업은 애플리케이션이 수행하는 작업과는 상관없이 계속 실행하거나 Android가 그 작업의 프로세스를 종료할 경우에는 다시 시작해야 합니다.
WorkManager에 대해 흔히 혼동하는 점은 WorkManager가 '백그라운드' 스레드에서 실행해야 하지만 프로세스가 종료되면 계속 실행할 필요가 없는 작업을 위한 것이라 생각하는 점입니다. 하지만 이것은 사실이 아닙니다. Kotlin의 코루틴, ThreadPool 또는 RxJava와 같은 라이브러리 등, 이 사용 사례를 위한 다른 솔루션이 있습니다. 백그라운드 처리에 대한 가이드에서 이 사용 사례에 대해 더 자세히 알아보실 수 있습니다.
백그라운드 작업을 실행해야 하는 다양한 상황, 그에 따라 백그라운드 작업을 실행하기 위한 다양한 솔루션이 많이 있습니다. 백그라운드 처리에 관한 이 블로그 게시물에서는 WorkManager의 사용 시점에 관한 많은 유용한 정보를 제공합니다. 블로그에서 발췌한 아래 다이어그램을 살펴보세요.
WorkManager의 경우 완료해야 하고 연기할 수 있는 백그라운드 작업에 가장 적합합니다.
먼저 다음과 같이 자문해보는 것으로 시작해봅시다.
- 이 작업을 꼭 완료해야 할까요? 사용자가 애플리케이션을 닫을 경우에도 반드시 작업을 완료해야 하는 걸까요? 원격 동기화 기능이 있는 메모 기록 애플리케이션을 예로 들 수 있습니다. 사용자는 메모 작성을 마치면 앱이 당연히 메모를 백엔드 서버와 동기화할 것이라 기대합니다. 이 작업은 사용자가 다른 앱으로 전환하여 OS가 메모리 회수를 위해 원래 사용하던 앱을 닫아야 하는 경우에도 이루어집니다. 기기를 다시 시작하는 경우에도 이 작업은 꼭 이루어져야 합니다. WorkManager는 작업이 완료되도록 보장해 줍니다.
- 뒤로 미룰 수 있는 작업일까요? 이 작업을 이후에 실행할 수 있을까요? 아니면 지금 바로 실행해야만 쓸모 있는 작업일까요? 이후에 실행할 수 있는 작업이라면 뒤로 미룰 수 있습니다. 이전의 예로 돌아가서, 메모한 내용을 즉시 업로드하면 좋겠지만 지금 바로 업로드할 수는 없고 이후에 동기화가 이루어지더라도 큰 문제는 아닙니다. WorkManager는 OS 백그라운드 제한을 고려하여 배터리를 효율적으로 이용할 수 있는 방식으로 작업을 실행하려 합니다.
그래서 WorkManager는 일종의 가이드라인으로서 앱이 종료하더라도 시스템이 실행할 것이라는 보장이 필요한 작업을 위한 라이브러리입니다. 즉시 실행해야 하거나 정확한 시간에 실행해야 하는 백그라운드 작업에는 적합하지 않습니다. (알람 시계나 이벤트 리마인더처럼) 정확한 시간에 작업을 실행해야 하는 경우에는 AlarmManager를 사용하세요. 즉시 실행해야 하지만 오래 계속되는 작업의 경우, 실행을 포그라운드로 제한하든(작업이 더는 실제 백그라운드 작업이 아닌 경우) Foreground Service를 사용하든, 포그라운드에 있을 때 작업이 실행되도록 해야 할 때가 종종 있을 것입니다.
WorkManager는 다음과 같이 더 복잡한 시나리오에서 백그라운드 작업을 트리거해야 할 때 다른 API와 페어링할 수 있고 페어링해야 합니다.
- 서버가 작업을 트리거하는 경우 WorkManager가 Firebase 클라우드 메시징과 페어링될 수 있습니다.
- Broadcast receiver를 사용하여 브로드캐스트를 청취한 다음에 오래 계속되는 작업을 트리거해야 하는 경우 WorkManager를 사용할 수 있습니다. WorkManager는 보통은 브로드캐스트로 들어오는 다수의 공통적인 Constraints를 위한 지원을 제공하는데, 이러한 경우 자체적인 broadcast receiver를 등록하지 않아도 됩니다.
WorkManager를 사용하는 이유는?
WorkManager는 백그라운드 작업을 실행하면서 배터리 및 시스템 상태에 대한 모범 사례와 호환성 문제를 자동으로 처리합니다.
더욱이 WorkManager를 사용하여 주기적인 작업과 복잡하고 종속적인 작업 체인을 모두 예약할 수 있습니다. 백그라운드 작업을 병렬 또는 순차 실행할 수 있으며, 이때 실행 순서를 지정할 수 있습니다. WorkManager는 작업 간의 입력과 출력을 따른 전달을 완벽히 처리합니다.
백그라운드 작업의 실행 시점에 대한 조건을 설정할 수도 있습니다. 예를 들어 기기가 네트워크에 연결되지 않은 경우에는 원격 서버에 HTTP 요청을 할 필요가 없습니다. 따라서 네트워크 연결이 있을 때만 작업을 실행할 수 있도록 하는 Constraint를 설정할 수 있습니다.
WorkManager는 실행 보장의 일환으로 기기를 다시 시작할 때, 그리고 프로세스가 강제로 중지되는 경우에 작업 유지를 처리합니다. 또한 작업이 중지되어 이후에 재시도하고 싶은 경우 재시도 전략을 손쉽게 정의할 수도 있습니다.
마지막으로, WorkManager를 사용하여 UI를 업데이트할 수 있도록 작업 요청 상태를 관찰할 수 있습니다.
요약하자면, WorkManager는 다음과 같은 이점을 제공합니다.
- 다양한 OS 버전과의 호환성 처리
- 시스템 상태 모범 사례 준수
- 비동기 일회적 작업과 주기적 작업 지원
- 입력/출력과 함께 체인으로 연결된 작업 지원
- 작업 실행 시점에 관한 제약 조건 설정 가능
- 앱이나 기기가 다시 시작하더라도 작업 실행 보장
이미지에 필터를 적용하는 동시 작업의 파이프라인을 빌드하는 구체적인 예를 살펴봅시다. 결과는 압축 작업으로 전송된 다음 업로드 작업으로 전송됩니다.
다음과 같이 이러한 작업에 대한 제약 조건 집합을 정의하고 작업을 실행할 수 있는 시점을 지정할 수 있습니다.
제약 조건이 있는 작업 체인 샘플
이러한 모든 워커는 정밀한 시퀀스를 정의합니다. 예를 들어 우리는 이미지가 어떤 순서로 필터링될지 모르지만 Filter 워커가 전부 완료한 후에만 Compress 워커가 시작될 것이라는 점을 알고 있습니다.
WorkManager 스케줄러의 작동 방식
API 레벨 14로 이전 버전과의 호환성을 보장하기 위해, WorkManager는 기기 API 레벨에 따라 백그라운드 작업을 예약할 알맞은 방법을 선택합니다. WorkManager는 JobScheduler 또는 BroadcastReceiver와 AlarmManager의 조합을 사용할 수 있습니다.
WorkManager가 어떤 스케줄러를 사용할지 판별하는 방법
WorkManager는 프로덕션 사용 준비가 되어 있을까요?
WorkManager는 현재 베타 버전으로 나와 있습니다. 즉, 이 주요 수정 버전에서 급격한 API 변경 사항은 없을 것이라는 뜻입니다.
WorkManager가 안정적인 버전으로 출시되면 백그라운드 작업을 실행하기 위해 우선적으로 선택되는 수단이 될 것입니다. 이런 이유로, 지금이 바로 WorkManager를 사용하기 시작하고 WorkManager의 개선에 도움을 주시기에 정말 좋은 시점입니다!
WorkManager 관련 참고 자료
