Workmanager 이전의 안드로이드 백그라운드작업

Workmanager 이전의 안드로이드 백그라운드작업

 

Jetpack의 workmanager에대하여 알아보기 전에
이전의 안드로이드 백그라운드작업을 어떻게 처리했었는지 알아보도록 하겠습니다 .

 

 

 

 

1.android K (킷켓,API 19)이전

킷케버전 이전에서는  실행 및 종료 여부에 상관없이 수행되는 백그라운드 작업을 다음과 같이 처리해왔습니다.

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

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

 

 

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

 

 

2.android L (롤리팝, API 21)

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

 

 

3.andorid N (누가, API 24)

안드로이드 N (누가, API 24) 에서 특정 인텐트에 대한 동작이 제한이 됩니다.

 

4.andorid O (오레오, API 26)

안드로이드 O (오레오, API 26) 에서는 암시적 브로드캐스트 리시버의 등록을 차단하는 등 점점 사용 방법에 제한이 추가되었습니다

그리고 Background Service 제약 - App 이 background 일 때 foreground service 가 아니면 background service 를 쓸 수 없게되었고 ,

Broadcast 제약 - 매니페스트에 등록한 암시적 broadcast 를 받을 수 없게 되었습니다.

 

 

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

개발자의 일은 줄었지만 구글플레이 서비스에 의존성을 가질 수 밖에 없게됩니다. 그리고 두 방식을 모두 호환하려다보니 작업이 제한적이 되었습니다.

 

 

안드로이드 버전과 구글플레이서비스 여부에따라 백그라운드 서비스를 지원하기가 까다로운문제가 발생하게 되었습니다.

그래서 Google I/O에서 WorkManager라는 해결책을 제공해주었습니다.

 

다음으로 Workmanager에대하여 알아보도록 하겠습니다.