Andorid 애플리케이션 개발 BroadcastReceiver

5539 단어 androidStringapifilterSecurityservice
BroadcastReceiver 개요:
BroadcastReceiver는sendBroadcast()에서 보내는 intent를 받는 기본 클래스입니다.너는 Context를 통과할 수 있다.registerReceiver () 방법은 코드에 BroadcastReceiver의 실례를 동적으로 등록하거나 안드로이드 Manifest를 통해 다시 등록할 수 있습니다.xml 파일에서 탭으로 정적 설명을 합니다.
주의: 만약 당신이Activity라면.onResume () 방법에 등록된receiver입니다.Activity에 있어야 합니다.onPause () 방법에서 로그아웃합니다.(activity가 일시 정지 상태일 때 intents를 받지 않을 뿐만 아니라, 이렇게 하면 시스템의 불필요한 비용을 줄일 수 있다.Activity에 있지 마세요.onSaveInstanceState () 방법에서receiver를 취소합니다. 왜냐하면 activity가 창고에서 복구될 때 이 방법을 사용하지 않기 때문입니다.
브로드캐스트에 가입:
<receiver android:name="MySMSListener">
   <intent-filter>
       <action 
android:name="android.provider.Telephony.SMS_RECEIVED"/>
   </intent-filter>
</receiver>
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
IncomingSMSReceiver receiver = new IncomingSMSReceiver();
registerReceiver(receiver, filter);

수신 가능한broadcast는 주로 두 가지 유형으로 나뉘는데 그것이 바로 일반적인broadcasts(Context.sendBroadcast를 통해 발송)는 완전히 비동기적이다.이broadcast의receiver는 무질서한 상태로 실행되며 항상 같은 시간에 실행됩니다.이런 방법은 매우 효율적이지만,receiver는 서로 처리된 결과를 이용하거나 종료된 API를 호출해서 종료할 수 없다는 것을 의미한다. (어떤receiver가 intent를 먼저 받았는지 모르기 때문이다.)질서정연한broadcasts(Context.sendOrderedBroadcast를 통해 발송)는 한 번에 하나의receiver에게만 발송됩니다.모든receiver는 이 int를 질서정연하게 처리한다. 앞의receiver는 다음receiver에게 결과를 전달할 수 있거나 임의의receiver가 완전히 퇴출될 수 있다. 그러면 intent는 다른receivers에게 전달되지 않는다.receiver의 실행 순서는 일치하는 intent-filter의android:priority 속성을 통해 제어할 수 있습니다.만약 여러 개의receivers가 같은 우선순위에 있다면, 이 몇 개의receivers는 임의의 순서로 실행될 것입니다.일반적인broadcasts를 방송하는 상황에서도 시스템은 한 번에 하나의broadcast를receriver에 보내는 것으로 전환될 수 있다.특히receivers가 프로세스를 만들어야 할 때, 같은 시간에 하나의receiver만 실행할 수 있으며, 시스템이 새로 만든 프로세스로 인해 과부하되지 않도록 합니다.주의: Intent 클래스는 이러한broadcasts를 보내고 받아들이는 데 사용되지만, 이곳의 Intentbroadcast 메커니즘과Context를 통해startActivity () 방법으로 activity를 시작하는 intent는 완전히 독립적입니다.BroadcastReceiver는activity를 시작하는 intent를 관찰하고 포착할 수 없습니다.마찬가지로, int를 통해broadcast를 보낼 때, 이 int를 통해activity를 찾거나 시작할 수 없습니다.이 두 가지 조작은 완전히 다르다. 하나의 int를 통해 하나의activity를 시작하는 것은 프론트 데스크톱 조작이고 사용자의 현재 상호작용 대상을 바꿀 수 있다.intent를 통해broadcast를 보내는 것은 백엔드 작업으로 사용자가 자주 눈치채지 못한다.BroadcastReceiver 클래스 (manfest의 탭을 통해 구성 요소로 시작) 는 프로그램의 전역 성명 주기의 중요한 부분입니다.토론의 주제 1, Receiver의 생명주기 2, 권한 3, 프로세스의 생명주기에서 수신할 수 있는broadcast는 주로 두 가지 유형으로 나뉜다. 일반적인broadcasts(Context.sendBroadcast를 통해 발송)는 완전히 다른 것이다.이broadcast의receiver는 무질서한 상태로 실행되며 항상 같은 시간에 실행됩니다.이런 방법은 매우 효율적이지만,receiver는 서로 처리된 결과를 이용하거나 종료된 API를 호출해서 종료할 수 없다는 것을 의미한다. (어떤receiver가 intent를 먼저 받았는지 모르기 때문이다.)
질서정연한broadcasts(Context.sendOrderedBroadcast를 통해 발송)는 한 번에 하나의receiver에게만 발송됩니다.모든receiver는 이 int를 질서정연하게 처리한다. 앞의receiver는 다음receiver에게 결과를 전달할 수 있거나 임의의receiver가 완전히 퇴출될 수 있다. 그러면 intent는 다른receivers에게 전달되지 않는다.receiver의 실행 순서는 일치하는 intent-filter의android:priority 속성을 통해 제어할 수 있습니다.만약 여러 개의receivers가 같은 우선순위에 있다면, 이 몇 개의receivers는 임의의 순서로 실행될 것입니다.
일반적인broadcasts를 방송하는 상황에서도 시스템은 한 번에 하나의broadcast를receriver에 보내는 것으로 전환될 수 있다.특히receivers가 프로세스를 만들어야 할 때, 같은 시간에 하나의receiver만 실행할 수 있으며, 시스템이 새로 만든 프로세스로 인해 과부하되지 않도록 합니다.
 
참고:
비록 Intent 클래스는 이러한broadcasts를 보내고 받아들이는 데 사용되지만, 이곳의 Intentbroadcast 메커니즘과Context를 통해startActivity () 방법으로 activity를 시작하는 intent는 완전히 독립적입니다.BroadcastReceiver는activity를 시작하는 intent를 관찰하고 포착할 수 없습니다.마찬가지로, int를 통해broadcast를 보낼 때, 이 int를 통해activity를 찾거나 시작할 수 없습니다.이 두 가지 조작은 완전히 다르다. 하나의 int를 통해 하나의activity를 시작하는 것은 프론트 데스크톱 조작이고 사용자의 현재 상호작용 대상을 바꿀 수 있다.intent를 통해broadcast를 보내는 것은 백엔드 작업으로 사용자가 자주 눈치채지 못한다.
BroadcastReceiver 클래스 (manfest의 탭을 통해 구성 요소로 시작) 는 프로그램의 전역 성명 주기의 중요한 부분입니다.토론 주제 1, Receiver의 라이프 사이클 2, 권한 3, 프로세스의 라이프 사이클
Receiver의 라이프 사이클
BroadcastReceiver의 대상은 온Receiver(CONtext, Intent)를 호출하는 시간에만 유효합니다.일단 당신의 코드가 이 함수에서 되돌아오면 시스템은 이 대상이 끝났고 다시 활성화될 수 없다고 생각할 것이다.onReceive (Context, Intent) 에서의 실현은 매우 중요한 영향을 미친다. 비동기적인 작업에 대한 요청은 허용되지 않는다. 이 함수에서 비동기적인 작업을 처리해야 할 수도 있지만, 그런 상황에서 BroadcastReceiver는 다시 활성화되지 않기 때문에 시스템은 비동기적인 작업을 하기 전에 이 프로세스를 죽일 것이다.
특히, 더 이상 BroadcastReceiver에 대화상자를 표시하거나 서비스를 연결해서는 안 됩니다.전자는 Notification Manager API로 대체해야 하고, 후자는 Context로 대체할 수 있다.startService () 는 그 서비스에 명령을 보내서 귀속 효과를 실현합니다.
 
사용 권한
액세스 권한은 송신자의 Intent 또는 수신자의 Intent에서 강제로 지정할 수 있습니다.
브로드캐스트를 보낼 때 권한을 강제로 지정하려면 빈 peemission 파라미터가sendBroadcast(Intent, String)나sendOrderedBroadcast(Intent, String, BroadcastReceiver,android.os.Handel, int, String, Bundle)에 제공되어야 합니다.Android Manifest.xml 파일에 해당하는 설명 탭을 통해receiver만 이것들의broadcast를 받을 수 있습니다.
broadcast를 받을 때 권한을 강제로 지정하려면receiver를 등록할 때 비어 있지 않은permission 파라미터를 제공해야 합니다. 리지스터 리시버 (Broadcast Receiver, IntentFilter, String, android. os.Handler) 를 호출하거나 Android Manifest를 통과해야 합니다.xml 파일에서 정적 탭을 통해 설명합니다.이 권한을 가진 발송자만 이 Receiver에 Intent를 보낼 수 있습니다.
보안 및 권한에 대한 자세한 내용은 Security and Permission 설명서를 참조하십시오.
 
프로세스의 라이프 사이클
BroadcastReceiver (즉, onReceive (CONtext, Intent) 방법을 실행하고 있는 프로세스는 프론트 데스크톱의 프로세스로 여겨지며, 시스템이 메모리가 극도로 낮은 상황에서 실행되지 않는 한 계속 실행될 것입니다.
OnReceive () 방법에서 돌아오면 이 BroadcastReceiver는 다시 활성화되지 않습니다. 이 프로그램의 주 프로세스는 이 프로그램에서 실행되는 다른 구성 요소와 같은 우선 순위를 가집니다.이 점은 매우 중요하다. 만약 프로세스가 단지 Broad Receiver만 가지고 있다면 (일반적인 상황은 사용자가 최근에 그것과 상호작용을 하지 않았거나 하지 않았거나), 이 프로세스가 onReceive () 방법에서 되돌아오면 시스템은 프로세스가 비어 있고 주동적으로 그것을 죽여서 다른 중요한 프로세스에 이용될 수 있도록 한다.이는 시간이 걸리는 작업에 대해 서비스와 BroadcastReceiver를 결합하여 이 작업을 수행하는 프로세스가 전체 실행 과정에서 활성 상태를 유지하도록 할 수 있음을 의미한다.
OC3 - 부모 포인터 가 하위 클래스 대상 을 가리 키 고 있 습 니 다.
IE 브 라 우 저가 파일 을 업로드 할 때 로 컬 경로 가 "C: \ fakepath \" 로 변 하 는 문제

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage