어려워 지고 있는 백그라운드 작업

초기 안드로이드의 백그라운드 작업은 쉬웠습니다.

서비스 하나를 쉽게 만들어 사용자 모르게 뒤에서 돌리는것도 가능했습니다. 브로드캐스트 리시버를 사용해서 개발자가 원하는 시점에 앱을 깨워서 작업을 해도 됐습니다.

이 모든게 가능했습니다. 이것이 ios 와의 큰 차이기도 했고, 이러한 기능을 이용해서 만들어진 많은 앱들은 안드로이드만의 장점이기도 했습니다.

그런데 이러한 편리함은 큰 단점을 만들게 됩니다. 많은 앱들이 각자의 작업을 백그라운드에서 수행 하면서 AP, 메모리 와 배터리등 하드웨어 자원을 많이 소모하기 시작했습니다.

그래서 구글은 안드로이드 M 부터 백그라운드 작업에 제한을 걸기 시작합니다. 도즈 모드, 앱 스탠바이, 브로드캐스트 제한, 강제 웨이크락(Wakelock) 해제, 백그라운드 서비스 제한 그리고 최신의 안드로이드 P 에서도 또 새로운 기능들이 추가가 됩니다.

사용자가 현재 사용하고 있는 앱 (활성화된 앱)은 시스템 상에서 우선순위가 높기 때문에 백그라운드 작업을 하는것은 몇가지의 제약사항만 지킨다면 여전히 어렵지 않게 작업을 처리할수 있습니다.

하지만 사용자가 앱을 사용하지 않을때도 수행해야 하는 작업들이 있는 경우는 매우 까다롭습니다.

지금까지의 백그라운드 작업 방법

안드로이드는 앱의 실행 및 종료 여부에 상관없이 수행되는 백그라운드 작업을 다음과 같이 처리해왔습니다.

기본은 AlarmManager 와 브로드캐스트 리시버를 사용하는 것입니다.

AlarmManager 의 명세대로 우리가 지정한 타이밍에 딱 시스템에서는 알람이 오고, 이 알람에 맞춰서 백그라운드 작업을 수행하면 됐습니다만, 안드로이드 K (킷켓, API 19) 부터는 알람이 한없이 미뤄지거나 한번에 몰아서 처리되는 등 정확한 실행을 보장하지 않게 되었습니다.

안드로이드는 브로드캐스트 리시버 를 등록하여 기기의 부팅시나 네트워크 연결 등의 상황에 시스템으로부터 전파되는 알림을 받을수 있습니다.

앱은 자신이 원하는 상황의 브로드캐스트 리시버를 통해 해당 타이밍에 작업을 수행해 왔지만, 안드로이드 N (누가, API 24) 에서 특정 인텐트에 대한 동작이 제한이 되고, 안드로이드 O (오레오, API 26) 에서는 암시적 브로드캐스트 리시버의 등록을 차단하는 등 점점 사용 방법에 제한이 추가되고 있습니다.

안드로이드 L (롤리팝, API 21) 에서 JobScheduler 를 제공합니다. 부정확해진 AlarmManger 의 대안이기도 했고, 결국 백그라운드 작업을 아예 배제시킬수는 없었기 때문입니다. 하지만, 이로서 안드로이드 L 이전 버전에서도 동작해야 하는 앱 의 개발자는 버전에 따라 AlarmManager 와 JobScheduler 를 각각 사용하도록 구현해야 하는 이중고를 겪어야 했습니다.

이후 구글은 Firebase JobDispatcher 를 제공합니다. Firebase JobDispatcher 는 안드로이드 G(진저브레드, API 9) 이상을 지원하고 내부적으로 현재 시스템의 안드로이드 버전에 따라 AlarmManager 와 JobScheduler 를 알아서 선택합니다.

개발자의 일은 한가지로 줄었으나, JobDispatcher 는 구글 플레이 서비스 에 의존성을 가집니다. 그러므로 구글 플레이 서비스를 사용할수 없는 앱 들은 결국 AlarmManager 또는 JobScheduler 를 직접 구현하는 수 밖에 없습니다. 또한 두가지 방식을 모두 호환하는 방식으로 api 를 제공하다보니 할수 있는 작업이 매우 제한적이었습니다.

이제 WorkManager 입니다.

2018년 구글 I/O 에서는 안드로이드의 백그라운드 작업을 도와줄 WorkManager 가 공개 되었습니다.

WorkManager 는 Android Jetpack 의 아키텍처의 구성 요소 입니다.

WorkManager 는 다음과 같은 특징을 가집니다.

• WorkManager 는 실행이 보장 됩니다. 또한 제약조건을 가지고 실행할수 있습니다. 예를 들어 네트워크 연결시에만 처리되는 작업을 추가하면 네트워크가 연결되면 반드시 실행됩니다.
• WorkManager 는 장치의 상태를 존중합니다. 가령 도즈 모드에 진입하면 일을 처리하기 위해 기기를 깨우거나 하지 않습니다.
• WorkManager 는 구글서비스의 유무에 상관 없이 동작합니다.
• WorkManager 는 실행중인가, 대기중인가, 완료 되었는가 등의 상태 조회 가 가능합니다.
• WorkManager 는 작업 A 의 결과에 따라 B 또는 C 를 선택하여 처리하고 D 를 이어서 처리하는 등의 작업 연결 처리가 가능합니다.
• WorkManager 는 기회주의적 입니다. 즉, 어떤 제한조건이 충족 되었을때 즉시 실행이 됩니다.

WorkManager 는 내부적으로 다음의 그림과 같이 동작합니다.

API 의버전에 맞게 AlarmManager 또는 JobScheduler 를 사용하며, 만약 개발자가 앱에 Firebase JobDispatcher 의 의존성을 추가 해두었다면 이를 적극 이용합니다.

그러므로 개발자는 WorkManager 를 사용함으로써 상황에 따른 고민이나 별도의 구현 없이 앱의 종료나 기기의 재부팅 된 경우에도 항상 장치에 맞는 가장 적합한 방법을 사용하여 백그라운드 작업을 처리할수 있게 됩니다.

그러나 WorkManager 가 항상 최선은 아닙니다.

다시 처음으로 돌아가서, 안드로이드는 백그라운드 작업을 처리하는 많은 방법이 있습니다.

그리고 WorkManager 는 그중 하나의 방법입니다.

이 작업이 앱의 종료 여부와 상관없이 수행되어야 하는 작업, 즉 앱의 프로세스 수명과 별도로 살아남기 위한 작업에 사용하는것을 추천합니다.

예를 들어 이미지를 서버에 업로드 해야 하거나, 데이터를 분석하고 이를 데이터베이스에 저장해야 하는 작업에는 WorkManager 를 사용하는것이 좋습니다.

그러나 사용자가 현재 보고있는 UI 를 빠르게 변경해야 하는 작업이나 물건 구입 과정에서의 결제 진행 등 즉시 처리해야 하는 작업은 WorkManager 를 사용하지 않는것이 좋습니다.

WorkManager 의 작업은 반드시 실행되지만 그 처리가 상황에 따라 지연 되거나 도중에 중단될 경우 다시 실행 될수 있다는 것을 꼭 기억해야 합니다.

적절한 상황에서, WorkManager 는 AlarmManager 나 JobScheduler, JobDispather 를 대체하는 훌륭한 백그라운드 작업 처리 방법입니다.

WorkManager 는 18년 8월 10일을 기준으로 현재 최신 버전은 1.0.0-alpha6 입니다.

개인적으로 사용해 본 결과 문제는 발생하지 않았습니다만 곧 안정화된 버전이 출시될 예정이라고 하니 그때까지 기다리거나 알파 버전을 미리 사용해 볼수도 있습니다.

다음은 WorkManager 를 소개한 2018 구글 I/O 의 세션 동영상 입니다.

마치며

이 포스트에서는 안드로이드에서의 백그라운드 처리 방법의 변천사 와 혼란했던 모든것을 정리한 WorkManager 의 특징에 대해 알아보았습니다.

이제 2회에 걸쳐 WorkManager 의 사용 방법을 예제와 함께 설명합니다.

감사합니다.