안드로이드 개발 질문/답변
(글 수 45,052)
Service, Broadcast, AIDL 의 차이점이 궁금합니다.
지금 백그라운드쪽을 공부하고 사용해 보고 있는데요.
Service를 쓰나 Broadcast를 쓰나 사용하는 방식에서 약간의 차이만 느껴질 뿐
실제로 사용되어지는 것에서 별 차이를 느낄 수 없더라고요.
가지고 있는 책들이나 여러곳을 찾아봐도 확실히 구분되는 부분을 못찾겠더라고요.
찾아본 책에는 Broadcast에 대한 언급은 별로없고 Service 위주로 설명이 되있기도 하고요.
그리고 AIDL도 Service에서 더 나아간(?) 방법 같은데
OS 수준 어쩌고저쩌고... 이런 설명들은 있지만 확실히 와닿지가 않네요. (언제 무슨 경우에 사용해야 하는건지)
지금 일단 가장 상위기법(? 책에서 제일 뒷부분에 나와있어서^^;)인 AIDL을 적용해나가고는 있는데
아무래도 제대로 알고 써야지 무작정 쓰는건 아닌것 같아서요.
Service, Broadcast, AIDL 의 차이점과 각각의 사용목적( 언제 무얼 사용해야 하는 것인지)이 궁금합니다!
지금 백그라운드쪽을 공부하고 사용해 보고 있는데요.
Service를 쓰나 Broadcast를 쓰나 사용하는 방식에서 약간의 차이만 느껴질 뿐
실제로 사용되어지는 것에서 별 차이를 느낄 수 없더라고요.
가지고 있는 책들이나 여러곳을 찾아봐도 확실히 구분되는 부분을 못찾겠더라고요.
찾아본 책에는 Broadcast에 대한 언급은 별로없고 Service 위주로 설명이 되있기도 하고요.
그리고 AIDL도 Service에서 더 나아간(?) 방법 같은데
OS 수준 어쩌고저쩌고... 이런 설명들은 있지만 확실히 와닿지가 않네요. (언제 무슨 경우에 사용해야 하는건지)
지금 일단 가장 상위기법(? 책에서 제일 뒷부분에 나와있어서^^;)인 AIDL을 적용해나가고는 있는데
아무래도 제대로 알고 써야지 무작정 쓰는건 아닌것 같아서요.
Service, Broadcast, AIDL 의 차이점과 각각의 사용목적( 언제 무얼 사용해야 하는 것인지)이 궁금합니다!
2010.07.08 10:10:27
답변하기엔 시간이 오래 지났지만, 나중에 보실분도 계실거 같아서 늦게나마 답변을 답니다~~^^
아래 내용은 저도 웹서핑하다가 찾은거네요~
Explicitly running in the background
명시적으로 백그라운드에서 작업하기
어플리케이션 프로세스가 안드로이드 시스템에 의해 강제로 종료되지 않는 한, 해당 암시적으로 백그라운드 작업을 수행할 수 있습니다. 하지만, 이런 기능이 웹페이지를 로딩하는 등의 일을 하기에는 충분할지 모르지만, 예를 들어 백그라운드에서 음악을 재생, 데이타를 동기화, 위치 정보를 기록, 알람 등과 같이보다 엄밀한 요구사항이 필요한 경우에는 적절하지 못합니다.
이러한 작업들을 위해서, 어플리케이션은 안드로이드 시스템에게 명시적으로 백그라운드 상에서 작업이 수행되어야 함을 알릴 필요가 있습니다. 어플리케이션은 메니페스트 상에 'Broadcast Receiver' 혹은 'Service' 요소를 선언할 수 있으며, 이 두가지 요소를 통해 명시적으로 백그라운드 작업을 수행 할 수 있습니다.
Broadcast Receivers
Broadcast Receiver 는 어플리케이션이 특정한 이벤트가 발생하는 경우에, 아주 짧은 시간동안 백그라운드에서 작업할 수 있도록 해주며, 다양한 방식으로 보다 상위에 기능을 구현하는데 사용 될 수 있습니다. 예를 들어 AlarmManager 는 어플리케이션이 미래의 특정 시점에 Broadcast 를 전송 할 수 있도록 해주며, LocationManager 는 위치 정보가 변경될 때마다 Broadcast 를 전송할 수 있습니다. BroadcastReceiver 에 관한 정보는 어플리케이션 메니페스트에 포함되기 때문에, 안드로이드 시스템은 현재 작동 하지 않는 어플리케이션의 BroadcastReceiver 를 찾아서 실행 시켜 줄 수 있으며, 물론, 어플리케이션이 현재 작동 중이라면, 그 어플리케이션에 속하는 BroadcastReceiver 는 매우 효율적으로 실행 됩니다.
Broadcast 를 처리하기 위해 어플리케이션은 최대 10초의 시간만을 사용할 수 있있습니다. 만일 해당 시간내에 작업을 완료하지 못하면, 그 어플리케이션은 오작동하는 것으로 간주되고, 그 즉시 해당 어플리케이션 프로세스는 메모리 확보를 위해 필요한 경우 언제든지 종료될 수 있는 상태(backgroud state - 가장 낮은 중요도를 갖는 프로세스)로 전환됩니다.
BroadcastReceiver 는 GPS 위치 정보가 변경되었음을 사용자에게 알리는 일과 같이 외부의 자극에 대해 반응하는 아주 간단한 일을 수행하는데 매우 훌륭하며, Broadcast 를 실재로 수신하는 동안에만 어플리케이션 프로세스가 작동하기 때문에 매우 가볍습니다. 또한, 정해진 시간 동안만 활성화 되기 때문에 실재로 작동하는 10초간은 해당 프로세스가 죽지 않을 것이라는 것을 매우 강력하게 보장해 줍니다. (주>따라서 갑작스런 프로세스 종료에 대한 예외사항을 고려하지 않아도 된다.) 그러나 네트워크 관련 일과 같은 비교적 긴 시간이 필요한 작업을 수행하는데는 적합하지 않습니다.
Services
Service는 어플리케이션이 보다 긴 백그라운드 작업을 수행할 수 있도록 해줍니다. Service 는 여러가지 기능이 있지만, 근본적인 역할은, 어플리케이션이 안드로이드 시스템에게 "헤이~ 나는 내가 종료되었다고 하기 전까지 백그라운드에서 계속해서 작동했으면 좋겠어!" 라고 알려주는 것입니다. 어플리케이션은 명시적으로 Service 를 시작 하거나 종료 시킬 수 있습니다.
Service 는 풍부한 클라이언트-서버 모델에 관련된 기능을 제공해 주지만, 어디까지나 옵션에 불과하다. 어플리케이션에 속한 Service 를 시작하는데 있어서, 안드로이드 시스템은 단순히 해당 Context 를 갖는 어플리케이션 요소 하나를 생성할 뿐입니다. 이 후에 Service 와 어떻게 상호작용 할 것인지는 전적으로 어플리케이션에 달린 문제입니다. Service 내부에 필요한 모든 코드를 작성한 후 어플리케이션의 다른 요소들과는 전혀 별개로 작동해도 좋고, 어플리케이션 내에 모든 요소들이 공유하는 Singleton 객체를 생성한 후 해당 Singleton 객체의 메서드를 호출해도 좋습니다. 혹은 어플리케이션의 다른 쪽에서 생성된 Service 객체를 직접 참조하여 사용해도 좋고(Local Service), Service 를 별도의 프로세스에서 작동하게 한 후에 작RPC 프로토콜을 통해 어플리케이션의 나머지 요소들과 상호작용 할 수도 있습니다(Remote Service).
작동중인 Service 의 수와 각각의 Service 가 작업을 완료하는데 걸리는 시간에는 정해진 한계가 없기 때문에, Service 가 작동 중인 프로세스를 관리하는 것은 BroadcastReceiver 의 경우와는 차이점이 있습니다. 요청된 모든 Service 들을 동시에 작동하는데는 메모리가 부족할 수 있으며, 때문에 Service 들이 항상 작동한다는 것을 확실히 보장할 수는 없습니다.
만일 메모리가 부족해 진다면, Service 가 작동중인 프로세스 또한 강제로 종료되어야 합니다. 하지만, 만일 강제로 종료된 Service 들이 계속해서 작동하고자 한다면, 안드로이드 시스템은 이후에 메모리에 여유가 생길 때, 종료된 프로세스를 다시 시작하여 Service 를 재실행 시켜줍니다. 예를 들어 사용자가 굉장히 큰 메모리 용량을 요구하는 웹페이지에 갔다면, 안드로이드 시스템은 브라우저가 필요로 하는 메모리 공간을 확보하기 위해, 데이타 싱크 작업을 수행하는 프로세스를 종료할 수 있습니다.
Service 는 안드로이드 시스템에 미리 자신을 'Foreground' 상태로 간주해 달라고 이야기할 수도 있습니다. 이것은, "나를 죽이지 마세요" 라는 뜻인데, 이 경우 해당 Service 는 사용자에게 자신이 현재 작동중임을 Notification (안드로이드 화면 상단의 상태바) 을 통해 표시해 주어야 합니다. 백그라운드 음악 플레이 혹은 자동차 네비게이션등과 같은 Service 에 유용한데, 사용자들은 웹브라우징을 할 때, 상태바의 음악 재생 아이콘을 보고, 현재 음악이 재생 중임을 알 수 있습니다. 안드로이드 시스템은 'Foreground' 로 간주되길 원하는 Service 들을 최대한 종료시키지 않도록 노력하며, 그와 동시에, 사용자들이 해당 Service 들이 현재 작동중임을 알 수 있고, 필요한 경우 명시적으로 종료 할 수 있도록 보장합니다.
The value of generic components
기본구성 요소(Service 와 BroadcastReceiver)의 가치
개발자들은 안드로이드의 BroadcastReceiver 와 Service 를 이용하여, 다양한 형태의 백그라운드 작업을 효율적으로 수행할 수 있습니다. 안드로이드 1.0 에서 구글 어플리케이션의 거의 모든 백그라운드 작업을 구현하는데 이 요소들이 사용되었습니다.
- Service 에서 음악을 재생하는 것은 사용자가 음악 어플리케이션을 떠난 후에도 음악이 계속 재생되도록 한다.
- 알람시계는 Alarm Manager 를 이용하여, 다음 정해신 알람 시간까지는 작동하지 않는 BroadcastReceiver 로 구현되어 있다.
- 달력 어플리케이션도 유사하게, 다음 정의된 이벤트때 알림내용을 표시하거나 갱신하기 위해 AlaramManager 를 통해 알람을 설정한다.
- 백그라운드 파일 다운로드 기능은 진행중인 다운로드가 있는 경우 작동하는 Service 로 구현되었다.
- E-Mail 어플리케이션은 정해진 시간마다 새로운 메일을 확인하기 위한 Service 를 작동시키도록 알람을 설정한다.
- 구글 어플리케이션들은 네트워크를 통한 Push 이벤트 수신을 위한 Service 를 유지하며, 특정 Push 이벤트에 의해 주소록 동기화 같은 작업을 수행할 필요가 있을 경우, 각 어플리케이션에 Broadcast 를 전달한다.
플랫폼이 진화함에 따라, 이 기본 요소들은 다양한 추가적인 중요 기능을 구현하는데 사용되었습니다.
- Input Method 는 안드로이드 시스템이 관리하며, 현재 IME 설정에 따라 화면에 Input Method 를 보여 주도록 Service 로 개발되었다.
- 어플리케이션 위젯들은 BroadcastReceiver 이고, 안드로이드 시스템이 위젯과 상호작용하고자 할 경우 Broadcast 를 전달해야 한다. 따라서 어플리케이션 웨젯들 해당 프로세스가 항상 작동중이 아니어도 되기 때문에 꽤 가볍다.
- 접근성 기능 (TTS 와 같은)들은 작동중에 안드로이드 시스템이 유지하고 적절한 사용자 인터렉션 정보를 전달하는 Service 로 구현되어 있다.
- 안드로이드 2.0 에서 소개된 Sync Adapter 는 특정한 데이타 싱크 작업이 수행되어야 할 경우 백그라운드에서 작동하는 Service 이다.
- Live Wallpaper 는 사용자 선택에 의해 안드로이드 시스템이 시작하는 Service 이다.