Android 방송 수신기 대 서비스
이 질문에 이미 답변이 있습니다.
Android에서 브로드 캐스트 수신기와 서비스의 차이점을 명확히하려고합니다.
활동 startService
이 인 텐트 로 호출하여 서비스를 시작할 수 있음을 이해합니다 .
브로드 캐스트 수신기는 코드 또는 매니페스트에 등록 할 수 있으며 sendBroadcast
.
언제 하나를 사용합니까?
여러 브로드 캐스트 리시버가 동일한 인 텐트를 수신 할 수 있으며 이는 서비스의 경우가 아님을 이해합니다.
서비스 는 사용자가 포 그라운드에서 수행하는 작업에 관계없이 일정 시간 동안 백그라운드에서 작업을 수행하도록되어 있습니다 (사용자가 활동간에 전환 할 수 있음). 좋은 예는 음악 플레이어 서비스입니다. 사용자는 음악 플레이어 앱을 통해 음악 재생을 시작하지만 앱을 종료하면 음악이 계속 재생됩니다.
서비스는 또한 여러 응용 프로그램에서 리소스에 대한 공통 액세스를 제공 / 관리하는 데 유용합니다. 센서와 같은 시스템 리소스에 자주 사용됩니다.
브로드 캐스트 수신기 는 인 텐트 (일반적으로 서비스 또는 시스템 이벤트에 의해 전송 된 인 텐트)에 응답하고, 무언가를 수행하고, 수행하기위한 것입니다. 예를 들어 사용자가 NFC 지원 전화를 태그에 터치하고 시스템에서 인 텐트를 생성하고 등록 된 수신기가이를 처리하여 일부 설정 (볼륨 변경, 블루투스 켜기 등)을 변경할 수 있습니다.
인 텐트가 sendBroadcast를 통해 브로드 캐스트되면 일치하는 인 텐트 필터가있는 모든 수신자 에게 전송됩니다 . 그러나 API26 +에서는 매니페스트에 등록 된 대부분의 수신자가 더 이상 이러한 상황에서 호출되지 않습니다 . 자세한 내용은 Google 문서를 참조하세요 .
예 1 : Kevin Bacon과의 분리 정도를 계산하도록 웹 사이트에 요청하는 함수 (사용하려는 모든 응용 프로그램에서 사용 가능)를 노출한다고 가정합니다.
이 예제는 장기 실행 백그라운드 작업을 수행하는 것과는 반대로 "무엇을 수행하고 반환"하는 것입니다.
이를 여러 가지 방법으로 구현할 수 있습니다.
모든 사용자가 자신의 애플리케이션으로 컴파일하는 라이브러리 프로젝트를 만듭니다.
- 이제 코드의 여러 사본이 있으며 모두 다른 버전이 될 수 있습니다.
- 각 요청이 독립적으로 처리되므로 요청을 일괄 처리하거나 캐시 할 수 없습니다.
각 요청을 처리 할 브로드 캐스트 수신기를 만듭니다.
- 응용 프로그램은 베이컨 질문을 묻는 인 텐트를 수락하기 위해 브로드 캐스트 수신기를 등록합니다.
- 각 응용 프로그램은 질문을하는 인 텐트를 보냅니다.
- 브로드 캐스트 수신기는 의도를 수락하고
- 요청을 서비스에 전달하여 처리를 수행하고 결과와 함께 요청자에게 Intent를 보냅니다.
- 완료되면 Google 클라우드 메시징을 사용하여 응답 할 서버에 요청을 보냅니다.
- 모든 요청이 하나의 애플리케이션을 거치기 때문에 결과를 일괄 처리 / 캐시 할 수 있습니다.
- 이것은 항상 비동기입니다.
- API는 "인 텐트"-기능을 노출하는 가장 친숙한 방법이 아닙니다.
각 요청을 처리 할 서비스 만들기
- 애플리케이션은 요청을 처리하는 서비스를 생성하고 바인더 또는 AIDL을 통해 API를 노출합니다.
- API는 동기 (직접 호출 및 반환) 또는 비동기 (리스너 등록 허용 및 결과가 준비되면 리스너 호출) 일 수 있습니다. 처리가 매우 빠를 것으로 예상되는 경우에만 동기식을 선택해야합니다. 서버 호출은 더 자주 비동기 적으로 처리되어야합니다.
- API는 "메서드 호출"입니다. 기능을 노출하는 훨씬 더 친근한 방법
예 2 : 데이터에서 일부 패턴을 찾기 위해 데이터 분석을 수행하려고합니다.
백그라운드 스레드 사용자가 동일한 애플리케이션과 동일한 활동에있는 동안 모든 처리가 수행되어야하는 경우 백그라운드 스레드 (또는 백그라운드 스레드를 관리하는 AsyncTask)가 좋은 접근 방법이 될 것입니다.
서비스 처리가 수행되는 동안 사용자가 응용 프로그램을 종료하도록 허용하거나 (나중에 결과를 통지) 처리가 수행되는 동안 동일한 응용 프로그램에서 여러 활동을 진행할 수 있도록하려면 서비스가 제공됩니다. 더 나은 접근
방송 수신기
Android 개발자 블로그에서 Dianne Hackborn 인용 :
브로드 캐스트를 처리 할 때 응용 프로그램에는 작업을 수행하는 고정 된 시간 (현재 10 초)이 제공됩니다. 해당 시간 내에 완료되지 않으면 응용 프로그램이 오작동하는 것으로 간주되고 해당 프로세스가 즉시 백그라운드 상태로 던져져 필요한 경우 메모리를 위해 종료됩니다.
방송 수신기는 최대 시간 (일반적으로 10 초)으로 제한되며 완료해야합니다.
서비스
작업에 시간이 더 오래 걸리는 경우 (인터넷에 연결하는 데 약간의 시간이 걸릴 수 있음) 백그라운드에서 실행하는 것이 더 좋습니다. 이 목적을 위해 수신자 또는 활동에서 서비스를 호출해야합니다. 그들은 안드로이드 운영 체제에 의해 마지막으로 죽습니다.
결론:
Generally speaking all the work (fetching, parsing, caching, updating database) which is important to your application should be moved to
Service
as they are long lived on Android. As you've almost considered that all the social networking sites have thereSTICKY_SERVICES
which does all troublesome work.BroadcastReceiver
are mostly used to start the service. It generally depends upon application. Most of the application usesConnectivityManager
to broadcast whenever network is UP OR DOWN. With the help of theseService
are started byBroadcastReceiver
.
First, read the documentation for both Broadcast Receiver and Services.
You can find useful tutorials here and here.
at last, to make the long story short:
Service starts upon your request (startService(intent)). You can think of The Broadcast receiver as an intent listener.
참고URL : https://stackoverflow.com/questions/14548927/android-broadcast-receiver-vs-service
'programing tip' 카테고리의 다른 글
다음 아티팩트를 해결할 수 없습니다. javax.jms : jms : jar : 1.1 (0) | 2020.10.16 |
---|---|
scikit-learn을 사용하여 여러 범주로 분류 (0) | 2020.10.16 |
Go 언어의 할당 연산자 (0) | 2020.10.16 |
긴 함수 이름을 여러 줄로 나눌 수 있습니까? (0) | 2020.10.16 |
Python의 교차 플랫폼 / dev / null (0) | 2020.10.16 |