일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Kotlin
- FLUTTER
- kodility
- android architecture component
- NDK
- Java
- dart
- Python
- mfc
- Android
- Flutter TextField
- Django REST Android
- RxAndroid
- C
- 안드로이드
- UWP
- 코틀린
- C/C++
- android push
- Android P
- C++
- RxJava
- 프로그래머스
- Django REST framework
- 알고리즘
- Rxjava2
- 안드로이드 구글맵
- livedata
- flutter firestore
- Django REST
- Today
- Total
개발하는 두더지
WorkManager로 안드로이드 하위 버전부터 오레오 버전까지 백그라운드 작업 통합 본문
안드로이드 디바이스에서 백그라운드로 진입했을 때 작업을 수행하려면 서비스를 사용해야합니다.
하지만 서비스를 사용할때 고려해야될 사항들이 있습니다.
1. 서비스는 프로세스가 계속 실행되고 있으므로 배터리 소모가 상당합니다.
2. 마시멜로우 버전부터 잠자기 모드( doze mode )가 생겼습니다.
3. 잠자기 모드는 누가버전에서 발전시키고 오레오 버전에서 더욱 강화되었습니다.
잠자기 모드는 유저가 디바이스 스크린을 끄고나면 네트워크, Sync, GPS, 알람, 와이파이 스캔 등을 비활성화 시켜버립니다.
스크린을 켜거나 충전기에 연결할때 까지 이 상태가 유지되버립니다. 그리고 중요하지 않은 작업/앱을 종료시켜버림으로써 디바이스의 배터리를 절약하는 전략을 사용합니다.
그리고 오레오 버전으로 타겟팅된 앱이 백그라운드에서 startService() 메서드 호출하면 백그라운드 서비스 제한이 있어서 exception이 발생합니다.
구글의 앞으로의 정책내용을 보자면
2018/8 새로 출시되는 앱은 api 26을 반드시 Target 적용
2018/11 기존 앱도 api 26 이상을 반드시 적용
정리하면,
백그라운드 작업을 위해 더 이상 서비스를 사용하지 않게 변경될 것입니다.
그럼 어떻게 백그라운드에서 작업을 해야할까요?
AlarmManager와 BroadcastReceiver 사용
지정한 타이밍에 시스템에서 알람이 오고 여기에 맞춰 백그라운드 작업을 수행할 수 있었지만 킷켓 버전에서는 알람이 미뤄지거나 한번에 몰아서 오는 등 정확한 실행을 보장하지 않게 됩니다.
BroadcastReceiver 를 통해서 기기의 부팅, 네트워크 연결 등의 디바이스 이벤트를 시스템으로부터 전파받아서 특정 작업을 수행해왔는데
누가 버전에서 특정 인텐트에 대해 동작이 제한되고, 오레오 버전에서 암시적 브로드캐스트리시버 등록을 차단하는 등 제한이 추가되고 있습니다.
그래서 대안책이 Job을 사용하는 것 입니다.
JobScheduler 사용
최소 api 21 이상에서만 사용할 수 있다는 제약, AlarmManager와 JobScheduler를 각각 사용해서 구현해야 합니다.
JobDispatcher(GCM Nerwork Manager) 사용
API 9 이상 지원가능. 내부적으로 AlarmManager와 JobScheduler를 선택해줍니다. 하지만 구글 플레이 서비스에 의존하게되어 아마존/중국제조사 디바이스에서는 기능을 사용할 수 없습니다. 구글 플레이 서비스가 없는 디바이스에서는 AlarmManager와 JobScheduler를 각각 사용해서 구현해야 합니다.
JobIntentService 사용
정확한 시간에 작업이 수행되지 않기 때문에 오레오에서 Job을 빨리 수행하는데는 도움이 되지 않습니다.
Android-Job (Evernote) 라이브러리(Third party library) 사용
자동으로 안드로이드 버전에 따라 AlarmManager, JobScheduler, JobDispatcher들 중 어떤것을 사용할지 결정해주는 라이브러리입니다.
아직 써보지는 않았지만 WorkManager가 안정되기 전까지는 가장 좋은 라이브러리라고 평가 받고 있습니다.
하지만 Evernote에서 새로운 가이드 안을 발표했습니다. Android-Job ( Evernote) 의 가이드
안드로이드 버전에 따라 백그라운드 API가 수시로 변경되어서 버전별로 분기가 필요하고 복잡한 API를 사용이 힘들었을 텐데 앞으로 Evernote는 Android Job 라이브러리를 배포하여 개발자들에게 편의를 제공해왔지만 더 이상 지원하지 않고 WorkManager사용을 권장한다는 내용입니다.
결국,
현재 실행중인 안드로이드 버전에 따라서 백그라운드 서비스 API를 다르게 호출시키고 관리해야 합니다.
디바이스의 안드로이드 버전과 구글플레이서비스 여부에따라 백그라운드 서비스를 지원하기가 까다롭습니다. 그래서 Google I/O에서 WorkManager라는 해결책을 제공해주었습니다.
WorkManager 사용
WorkManager는 시스템 기반의 백그라운드 프로세싱 API를 제공해줍니다. 앱이 포그라운드에 없어도 백그라운드 Job을 수행시켜줍니다.
내부적으로 API 버전에 맞게 AlarmManager와 JobScheduler를 사용하고 구글플레이서비스 사용이 가능하다면 JobDispatcher를 적극 사용합니다.
WorkManager를 사용해서 클라이언트 개발자가 백그라운드 작업을 위해 이전까지 해왔던 불편하고 분기가 많아지는 작업을 안해도 백그라운드 WorkManager처리할 수 있게됩니다. 앱의 종료나 기기의 재부팅이 되도 항상 장치에 맞는 적합한 방법을 사용하여 백그라운드 작업을 처리할 수 있게 되었습니다. 아마 오레오 이후 버전에서 다시 분기가 생기는 문제가 발생하지는 않을듯 싶습니다.
하지만 WorkManager가 만능은 아닙니다.
앱의 종료 여부와 관계없이 수행되어야되는 작업의 경우에는 사용을 추천하지만 아닌 케이스도 있습니다.
예를들어 이미지를 서버에 업로드하거나 데이터베이스에 저장하는 작업에는 WorkManager가 좋습니다.
사용자가 현재 보고있는 UI를 빠르게 변경하는 작업이나 결제 진행 작업 같은 경우에는 WorkManager보다 ForegroundService로 구현하는 것이 좋습니다.
아직 알파버전이지만 곧 안정화된 버전이 출시될 예정입니다.
2018/8/27 WorkManager 1.0.0-alpha08 버전이 릴리즈됨.
최종적으로 정리해보자면
현재 앱 개발시에 오레오 버전을 타겟팅해야하고
WorkManager를 사용하면 디바이스 안드로이드 버전, 구글플레이서비스 지원여부에 따라 자동으로 백그라운드 API를 결정해줍니다.
하지만 상황에 맞게 WorkManager를 사용해야합니다..
참고
Services. The life with/without. And WorkManager
[Jetpack] Android Background는 WorkManager에게 맡기세요
Android Scheduling Background Services(A developer's nightmare)
WorkManager 설명 및 사용예시 ( Let's Work manager do all the Background processing)
'Java,Android' 카테고리의 다른 글
[Effective Java 규칙20] 태그 기반 클래스 대신 클래스 상속을 활용하라 (0) | 2018.09.26 |
---|---|
[Effective Java 규칙19] 인터페이스는 자료형을 정의할 때만 사용하라 (0) | 2018.09.26 |
[Effective Java 규칙18] 추상 클래스 대신 인터페이스를 사용하라 (0) | 2018.09.17 |
[Effective Java 규칙17] 상속을 위한 설계와 문서가 없다면 상속하지 마라 (0) | 2018.09.17 |
[Effective Java 규칙16] 상속(extends)하는 대신 구현(implements)하라 (0) | 2018.09.17 |