[번역] [Androd] Intelligent Job-Scheduling

Intelligent Job-Scheduling

최근의 앱들은 사용자 인터렉션의 직접적인 흐름외에, 비동기로 많은 작업들을 수행할 수 있다. 비동기 작업의 몇가지 예는 다음과 같다:
  • 네트워크 리소스의 업데이트
  • 정보의 다운로드
  • 백그라운드 작업의 업데이트
  • 시스템 서비스 호출의 스케쥴링
이 작업들을 현명하게 스케쥴링 하면, 배터리 수명과 같은 시스템 상태와 함께 앱 성능을 개선시킬 수 있다. JobScheduler가 이 스케쥴링 작업을 수행한다.
앱이 백그라운드 작업을 스케쥴 할 수 있게 해주는 몇개의 API가 있다 .이 옵션들 중 가장 중요한 것은 JobScheduler이다. 이 JobScheduler API를 사용하면 최적의 시스템 상태를 위해 단말에서 중앙집중형 작업 스케쥴링과 함께 작업실행에 강력한 조건을 지정할 수 있다.JobScheduler는 또한 확장성이 뒤어난 기능을 제공한다. 캐시지우기 같은 작은 작업에 적합할 뿐 아니라 DB를 클라우드에 동기화 시키는 것과 같은 대규모 작업에도 적합하다.
In addition to JobScheduler, there are several other facilities available to help your app schedule work. JobScheduler외에도, 앱의 스케쥴링을 돕는 아래와 같은 몇가지 기능이 있다.
이 페이지는 JobScheduler 및 앱의 성능과 시스템 상태를 최대로 하기 위해 작업 스케쥴링을 도와주는 다른 API들에 대해 간략히 소개한다.

Android Framework JobScheduler

JobScheduler는 작업을 스케쥴링하기 위한 Android 프레임워크 API이다. 이것은 Android 5.0 부터 사용가능했었고, 현재도 활발히 개발중이다. 특히 Android 7.0에서는 작업 기반 트리거 기능을 추가했다.
JobScheduler는 플랫폼에 구현되어 모든 앱에서 실행해야하는 작업에 대한 정보를 수집할 수 있다. 이 정보는 작업이 거의 유사한 시각에 실행하기 위한 스케쥴링에 사용된다. 이러한 방식으로 작업실행을 일괄처리 하게되면, 장치가 절전모드로 들어가서 좀 더 오래 있을 수 있으므로, 배터리 수명이 유지된다.
네트워크와 타이밍에 대한 요구사항을 지정해서 작업을 등록하여 JobScheduler를 사용한다. 그 후 적절한 시간에 작업이 정상적으로 실행되도록 일정을 계획한다. Doze 모드 및 앱 대기시간 제한을 준수하기 위해 동시에 필요에 따라 작업실행을 연기한다. JobScheduler는 작업실행 조건을 정의하기 위한 많은 Method를 제공한다.
만약 앱의 Target이 Android 5.0이라면, JobScheduler를 이용해 백그라운드 작업을 실행할 것을 권장한다. JobScheduler에 대한 좀 더 많은 정보는 API-reference documentation를 참고하라.

AlarmManager

AlarmManager API는 작업 스케쥴링을 위해 프레임 워크에서 제공하는 또 다른 옵션이다. 이 API는 앱이 특정 시간에 노티피케이션을 Post하거나, 알람을 설정하는 경우에 유용하다.
특정시간에 반드시 실행되어야 하는 작업의 경우에 대해서만 이 API를 사용해야 한다. 그러나 디바이스의 idle 혹은 충전중을 감지하는 것과 같은 JobScheduler에서 지정이 허용되는 실행 조건(execution conditions)에 대해서는 필요하지 않다.

Firebase JobDispatcher

Firebase JobDispatcher는 Android 플랫폼에서의 JobScheduler 와 유사한 기능을 제공하는 Open source library이다. Firebase JobDispatcher는 Android 5.0이하 버전(API level 21)을 대상으로 하는 앱의 JobScheduler 호환성 레이어 같은 역할을 한다. 
Firebase JobDispatcher는 작업의 dispatching (running)을 위한 구현으로 구글 플레이 서비스의 사용을 지원하지만, 라이브러리를 사용하면 다른 구현을 정의하고 사용할 수 있다. 예를들어 JobScheduler를 사용하거나, 당신의 커스텀 Code를 작성할 수 있다. 이러한 융통성으로 인해, 만약 앱의 Target Version이5.0보다 낮다면, Firebase JobDispatcher의 사용을 추천한다.
Firebase JobDispatcher에 관한 좀더 많은 정보는 문서와 소스코드를 참고하자.

Additional Facilities

위에서 설명된 API와 라이브러리들 외에도, 특정 조건에서 앱을 보다 강력하고 효과적으로 수행할 수 있는 Sync Adapter와 Service들이 있다.

SyncAdapter

프레임워크는 디바이스와 서버 사이의 데이터 싱크 작업을 관리하기 위한 SyncAdapter 클래스를 제공해 왔다. Sync adapter는 디바이스와 클라우드 사이의 데이터 싱크를 위해 특별히 디자인 되었다. Sync adapter들은 좀 더 복잡하다 구현하기가 위에 언급된 라이브러리나 API들보다는 구현하기가 좀 더 복잡하다. 왜냐하면 최소한의 Fake 인증(authenticator)과 content provider의 구현이 필요하기 때문이다. 이러한 이유로 일반적으로 백그라운드에서 오로지 클라우드와의 데이터 싱크를 위해 sync adapter를 생성하지 않아야 한다. 가능한 경우, JobScheduler, Firebase JobDispatcher, 또는 GCM Network Manager를 대신 사용해야 한다. 
Android N (API level 24)에서 SyncManager는 JobScheduler위에 위치한다. 만약 SyncManager가 제공하는 추가적인 기능이 필요한 경우에만 SyncAdapter를 사용해야 한다. 

Services

Services 프레임워크는 오래 실행되는 작업이 백그라운드에서 작동하도록 해준다. 음악재생같이 사용자를 위해 머물러 있어야 하는 작업을 수행하기 위해서 foreground Service를 사용하는 것을 권장한다. Bound service 또한 다양한 경우에 여전히 유용하다. 예를 들면, 사용자가 fragment나 activity를 볼 때만 실행될 필요가 있는 service등이 있다.
당신은 작업을 끊임없이 혹은 주기적으로 실행하기 위해 서비스를 시작하는 것을 회피해야 한다. 그런 작업들은 유용한 작업을 하고 있지 않더라도, 끊임없이 단말의 자원을 사용하기 때문이다. 대신에,  이 페이지에 기술된것이나 Native lifecycle 관리를 제공하는 다른 솔루션을 사용해야 한다. 서비스를 시작하는 것은 최후의 수단으로만 사용해라. Android 플랫폼은 앞으로 서비스를 시작하는 것을 지원하지 않을 수도 있다. 

Additional Points

Regardless of the solution you adopt, keep the following points in mind:
솔루션을 채택하는 것과 관계 없이, 아래 사항을 염두해야 한다. 
  • Captive Internet Portals, VPNs, 그리고 proxies는 인터넷 연결 문제를 일으킬 수 있다. 라이브러리나 API는 인터넷이 이용가능하다고 생각할 수 있다. 그러나 서비스는 접근 불가능할 수 있다. 정상적으로 실패하고, 가능한 적은 작업으로 다시 스케쥴링 하라.
  • 네트워크 가능여부 같이 작업을 실행하기 위해 지정한 상태에 따라, 태스크가 트리거 된 후 변경사항이 발생한다면 더이상 해당 컨디션이 충족되지 않는다. 이러한 경우 예기치 않게 반복적으로 작업이 실패할 수 있다. 이러한 이유로 당신은 백그라운드 작업로직을 코딩하여 작업이 지속적으로 실해할 경우 이를 알리고 실수로 리소스를 과도하게 사용하지 않도록 exponential back-off를 수행해야 한다.
  • 작업 스케쥴링을 할때(특히 AlarmManager를 사용 ) exponential backoff를 사용해야 한다. 만약 앱이 JobScheduler, Firebase JobDispatcher, 혹은 sync adapters를 사용한다면 exponential backoff는 자동으로 적용된다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Android] DataBinding의 동작방식 - 4. include Tag 혹은 ViewStub 사용시의 Binding

이미지
이번에는 <include>와 ViewStub 사용시의 Binding에 대해서 알아보려고 한다. 사실 include와 ViewStub까지 사용해서 앱을 만드는 경우는 그렇게 많지는 않다고 생각한다. 하지만 앱이 복잡해 지는경우, View의 재사용을 include를 통해 적용하게 되는 경우등에는 쓰는 경우들이 있는데, Binding을 사용하는 경우에는 Bind되는 Model을 재사용하거나 분리하려고 할 때도 쓸 수 있다. "[Android] DataBinding의 동작방식" 전체목록     1. Setter Method와의 연결     2. BindingAdapter의 기본 및 사용 시점     3. BindingAdapter의 사용시 팁     4. include Tag 혹은 ViewStub 사용시의 Binding     5. Listener, Callback     6. InverseBinding (InverseBindingAdapter) + Two way Binding 1. <include>에서의 Binding  우선은 제일 간단한 <include> Tag 사용시의 Binding에 대해서 알아본다. 가장 외곽  1) outer layout xml <? xml version = "1.0" encoding = "utf-8" ?> < layout xmlns: android = "http://schemas.android.com/apk/res/android" xmlns: app = "http://schemas.android.com/apk/res-auto" > < data > < variable name = "user" type = "com.example.User" /...
자세한 내용 보기

[Android] Retrofit2, OkHttpClient Method 정리

이미지
(이 Post는 Retrofit 2.2.0 기준으로 작성되었음) Retrofit을 적용하면서, 지원되는 기능들을 한번 정리를 해 둬야, 어떤 것을 쓸수 있는지 확실히 할 수 있을 것 같아서, 아래와 같이 정리한다. 1. Retrofit.Builder    baseUrl(String baseUrl) 을 제외하면, 대부분 DI의 형태를 띄고 있다. 각각 Injection 되는 Class들의 용도는 각 항목에서 설명한다. 분석을 하고 보니, Retrofit Class는 이 Builder를 통해 Injection 된 Instance들을 들고있는 Holder 역할을 하는 것으로 보인다. baseUrl(String baseUrl) : Base가 되는 URL을 설정한다. 많은 서비스들에서 사용하는 API들은 앞부분의 Host 정도는 동일하고, 뒷부분의 API Name들로 구분을 하는 경우가 많다. 그때 고정이 되는 앞부분을 여기서는 BaseURL이라고 이야기하고 있다. 만약 BaseUrl을 "https://apis.github.com"이라고 설정한 다음 실제 Retrofit Service Interface에서 @GET("/user/repos")라고 선언해서 사용한다면 실제 요청은 "https://apis.github.com/user/repos"로 나가게 된다. 중요한 부분이 있어서 Retrofit의 Document에서 일부를 가져온다. 올바른 사용: Base URL: http://example.com/api/ Endpoint: foo/bar/ Result: http://example.com/api/foo/bar/ 잘못된 사용: Base URL: http://example.com/api Endpoint: foo/bar/ Result: http://example.com/foo/bar/ 만약 Base URL을 설정하지 않으면 IllegalStateException이 발생하게 된다. baseUrl(HttpU...
자세한 내용 보기

[Android] EventBus보다 빠르고 간단한 MessageBus !!

Android에서 이벤트를 전달하는 방법은 다양합니다. 일반적인 Callback이나 Listener를 통해 전달하는 방법이 있고, Broadcast를 통해서 전달하거나 Intent를 통해 전달을 하는 등, 다양한 방법들이 있습니다. 하지만, 앱이 복잡해짐에 따라 Listener를 깊숙하게 전달해야하는 문제들이 있었습니다. Broadcast를 하기에는 너무 무거운 감이 있고, 기타 방법들도 마땅치 않은 경우들이 많습니다. 이러한 문제를 해결하기 위해서 다양한 개발자들이 여러 해법들을 제시해왔고, 그 중 인기를 얻고 있는 EventBus(https://github.com/greenrobot/EventBus) 가 있습니다. 저 역시 EventBus를 사용하기 위해 검토를 해봤는데, 제가 봤을 때 문제점과 우려되는 점 들이 있었습니다. EventBus의 문제 + 우려 1. 전달하는 Event의 형태는 항상 Object이다.   - instanceof 로 같은 Class를 등록해둔 Subscriber는 모두 받게 된다.   - 가볍게 이벤트의 발생만 알리고 싶어도 커스텀 클래스를 정의해야한다. 2. 정의된 Annotation을 통해 Subscriber로 등록하지만, Runtime에 Annotation이 리플렉션으로 처리되기 때문에, 약간의 속도저하를 예상할 수 있다.   - 한두개 정도의 Subscriber의 등록은 큰 문제 없겠지만, 동시에 Subscriber로 등록하는 컴포넌트들이 많다면(40~60개 수준?), 약간은 걱정되는 부분이다. 이 두가지 문제를 해결하기 위해 MessageBus 를 만들게 되었습니다. ( Github :  https://github.com/UnsignedUSB/MessageBus ) 1. MessageBus에서는 Event를 integer형으로 던질 수 있습니다. 2. MessageBus는 Annotation Processor로 돌아가기 때문에, Build tim...
자세한 내용 보기