導航:首頁 > 操作系統 > android發送接收廣播

android發送接收廣播

發布時間:2023-01-20 22:58:43

android系統廣播(Broadcast)注冊,發送,接收流程解析

以下廣播簡稱Broadcast

   是Android四大組件之一,在四大組件的另外兩個組件 和 擁有發送和接收廣播的能力。Android 是在 進程間通信機制的基礎上實現的,內部基於消息發布和訂閱的事件驅動模型,廣播發送者負責發送消息,廣播接收者需要先訂閱消息,然後才能收到消息。 進程間通信與 的區別在於:

   有三種類型

   存在一個注冊中心,也可以說是一個調度中心,即 。廣播接收者將自己注冊到 中,並指定要接收的廣播類型;廣播發送者發送廣播時,發送的廣播首先會發送到 , 根據廣播的類型找到對應的 ,找到後邊將廣播發送給其處理。

   這里以普通廣播為例子, 接收者有兩種注冊方式,一種是 ,一種是 :

(廣播的發送分為 兩種,這里針對有序的廣播) 中的android:priority=""和 中的IntentFilter.setPriority(int)可以用來設置廣播接收者的優先順序,默認都是0 , 范圍是[-1000, 1000],值越大優先順序越高,優先順序越高越早收到。

   在相同優先順序接收同個類型廣播時, 的廣播接收器比 的廣播接收者更快的接收到對應的廣播,這個之後會進行分析。

   註:以下源碼基於rk3399_instry Android7.1.2

   的流程可分為 , 和 三個部分,這里依次分析下

   在Android系統的 機制中,前面提到, 作為一個注冊和調度中心負責注冊和轉發 。所以 的注冊過程就是把它注冊到 的過程。

   這里我們分析 廣播的過程, 和 有一個共同的父類 ,所以它們對應的注冊過程其實是調用 ,接下來我們按照流程逐步分析調用流程的源碼。

frameworks/base/core/java/android/content/ContextWrapper.java

   在之前的 Android應用程序啟動入口ActivityThread.main流程分析 分析過,在我們啟動 Activity 時會創建一個 對象,然後通過 傳給我們啟動的 ,其內部就會將該對象賦值給 ; 的 方法也是類似的賦值流程,這里放個簡易的源碼應該更好理解

   可以看到最後都會將生成的 對象賦值給對應的
對象。接下來繼續分析 , 即 函數。

/frameworks/base/core/java/android/app/ContextImpl.java

   這里我們首先看下如何將廣播接收者 封裝成一個 介面的 本地對象
/frameworks/base/core/java/android/app/LoadedApk.java

   每一個注冊過廣播接收者的 或 組件在<font color='Crimson'> LoadedApk </font>類中都有個對應的 對象,該對象負責將 與 組件關聯起來。這些對象,以關聯的 作為關鍵字保存在一個 中。之後對應的 又以 的 作為關鍵字保存在 的成員變數 對象中。最後通過 對應的 方法獲得其 介面的 本地對象。之後再回到 注冊方法內,將 對象發給 進行注冊。

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

   在的 或 注冊一個 時,並不是將其注冊到<font color='OrangeRed'>AMS</font>中,而是將與它關聯的<font color='OrangeRed'>InnerReceiver</font>對象注冊到<font color='OrangeRed'>AMS</font>中,當<font color='OrangeRed'>AMS</font>接收到廣播時,會根據 在內部找到對應的<font color='OrangeRed'>InnerReceiver</font>對象,然後在通過這個對象將這個廣播發送給對應的 處理。

   注冊過程這邊畫了一個簡單的流程圖:

   <font color='OrangeRed'>Broadcast</font>的發送過程可簡單描述為以下幾個過程:

frameworks/base/core/java/android/content/ContextWrapper.java

/frameworks/base/core/java/android/app/ContextImpl.java

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

Ⅱ Android廣播阻塞、延遲問題

        最近項目中,多次碰到app研發人員反饋廣播從發送到接收器接收,間隔時間太長,要求系統進行優化,特別是開機階段。對此,專門閱讀了一下廣播從發送到接收這個流程的源碼,以徹底搞明白怎樣讓自己發送的廣播盡快到達接收器。

涉及到的源碼類不多,主要就是ActivityManagerService.java 和 BroadcastQueue.java。發送廣播進程調用發送介面,通過IPC到達AMS,AMS根據Intent是否配置Intent.FLAG_RECEIVER_FOREGROUND,選擇當前廣播加入前台廣播隊列還是後台廣播隊列。根據當前廣播是否有序,將廣播加入廣播隊列的串列列表還是並行列表。廣播隊列和廣播隊列中的廣播列表是影響廣播接收時間的主要因素。

BroadcastQueue廣播隊列,負責將廣播發送給廣播接收器。AMS中有兩個成員變數, 

BroadcastQueue mFgBroadcastQueue;//前台廣播隊列

BroadcastQueue mBgBroadcastQueue;//後台廣播隊列

前台廣播隊列和後台廣播隊列的區別有兩處:1 超時時間,前台10s,後台60s. 2 是否延遲廣播等待前一個廣播進程完成。這兩個區別已經說明前台廣播對廣播接收器要求更高,響應時間更短,如果廣播要排隊,時間上前台廣播更短。同時系統默認使用後台廣播隊列,所以前台廣播隊列處理的廣播要少,避免了可能的大量廣播排隊情況。

廣播隊列中的列表

//存放無序並發送給動態廣播接收器的廣播任務

final ArrayList<BroadcastRecord> mParallelBroadcasts = new ArrayList<BroadcastRecord>();

//存放無序發送給靜態廣播接收器的廣播任務或者存放有序廣播任務

final ArrayList<BroadcastRecord> mOrderedBroadcasts = new ArrayList<BroadcastRecord>();

mParallelBroadcasts 此列表中存放的是無序廣播動態廣播接收器任務,廣播隊列會在處理任務時通過嵌套循環,把每個廣播通過ipc發送到關注它的所有進程。所有無序廣播+動態廣播接收器,廣播不需要排隊。這種情況是最快能讓廣播到達目標進程的方式。

mOrderedBroadcasts存放的廣播任務特點:廣播有序,或者廣播接收器是靜態注冊的。此種類型的廣播全部要在mOrderedBroadcasts中排隊,廣播之間按時間先後,同一個廣播不同廣播接收器按優先順序。mOrderedBroadcasts存放的廣播必須等一個廣播任務處理完畢才能處理下一個,中間可能包含進程的啟動等。

由此可見,廣播最快的情況是前台廣播、無序廣播、動態注冊廣播接收器。最糟糕的情況是:後台廣播、有序或靜態注冊廣播接收器、廣播接收器優先順序低。如果一個應用只是簡單的靠注冊一個靜態廣播接收器拉起進程,對應的正是最糟糕的情況。如果又發生在開機階段,自然延遲嚴重。

如果必須注冊靜態廣播接收器,縮短時間的辦法為:配置Intent.FLAG_RECEIVER_FOREGROUND,加入前台廣播隊列,設置廣播優先順序

源碼:

廣播發送:Context .sendBroadcast ->ActivityManagerNative.broadcastIntent->ActivityManagerService.broadcastIntent->ActivityManagerService.broadcastIntentLocked.到此階段,跟發送廣播的進程通信結束。此階段AMS完成的工作主要是根據Intent查找該廣播對應的動態廣播接收器、靜態廣播接收器、以此發送該廣播使用的廣播隊列。

private final int broadcastIntentLocked(

......//許可權檢查

......//特殊系統廣播進行必要處理

if (sticky) {//粘性廣播處理

......

//查找靜態注冊的接收器

receivers = collectReceiverComponents(intent, resolvedType, users);

if (intent.getComponent() == null) {

    // 查找動態廣播接收器

            registeredReceivers = mReceiverResolver.queryIntent(intent,

                    resolvedType, false, userId);

        }

//動態廣播接收器

        int NR = registeredReceivers != null ? registeredReceivers.size() : 0;

        if (!ordered && NR > 0) { 

//確定隊列

            final BroadcastQueue queue = broadcastQueueForIntent(intent);

//創建廣播任務BroadcastRecord

            BroadcastRecord r = new BroadcastRecord(queue, intent, callerApp,

                    callerPackage, callingPid, callingUid, resolvedType, requiredPermission,

                    appOp, registeredReceivers, resultTo, resultCode, resultData, map,

                    ordered, sticky, false, userId);

......

//廣播任務加入並行列表中

                queue.(r);

//啟動非同步發送廣播任務

                queue.scheleBroadcastsLocked();

registeredReceivers = null;

            NR = 0;

......

while (it < NT && ir < NR) {

......

//根據優先順序排序

          if (curt == null) {

                    curt = (ResolveInfo)receivers.get(it);

                }

                if (curr == null) {

                    curr = registeredReceivers.get(ir);

                }

                if (curr.getPriority() >= curt.priority) {

                    // Insert this broadcast record into the final list.

                    receivers.add(it, curr);

//獲取廣播隊列

            BroadcastQueue queue = broadcastQueueForIntent(intent);

//創建廣播任務

            BroadcastRecord r = new BroadcastRecord(queue, intent, callerApp,

                    callerPackage, callingPid, callingUid, resolvedType,

                    requiredPermission, appOp, receivers, resultTo, resultCode,

                    resultData, map, ordered, sticky, false, userId);

//加入到廣播隊列串列列表中

                queue.enqueueOrderedBroadcastLocked(r);

//啟動非同步發送任務

                queue.scheleBroadcastsLocked();

廣播隊列處理廣播:

final void processNextBroadcast(boolean fromMsg) {

......

//並行列表,遍歷廣播任務

            while (mParallelBroadcasts.size() > 0) {

final int N = r.receivers.size();

//遍歷接收器

                for (int i=0; i<N; i++) {

//IPC調用發送給目標進程

(r, (BroadcastFilter)target, false);

}

}

//有串列廣播任務正在執行

if (mPendingBroadcast != null) {

             //接收廣播的目標進程正常

                if (!isDead) {

                    // It's still alive, so keep waiting 繼續等待目前進程反饋

                    return;

                }

}

             //取出第一個廣播

                r = mOrderedBroadcasts.get(0);//判斷是否超時,

                    if ((numReceivers > 0) && 

                            (now > r.dispatchTime + (2*mTimeoutPeriod*numReceivers))) {

                         //廣播超時

                          broadcastTimeoutLocked(false);//超時處理,終止當前廣播,啟動下一個任務。

                          }

                if (r.receivers == null || r.nextReceiver >= numReceivers

                        || r.resultAbort || forceReceive) {

                 //所有廣播任務執行完畢

}

int recIdx = r.nextReceiver++;//下一個廣播接收器

r.dispatchTime = r.receiverTime;//設置派發時間

setBroadcastTimeoutLocked(timeoutTime);//啟動超時計時

if (nextReceiver instanceof BroadcastFilter){//動態廣播接收器

(r, filter, r.ordered);//發送

return;

}

.//靜態廣播

            ResolveInfo info =

                (ResolveInfo)nextReceiver;

......

//檢查進程是否已啟動

            ProcessRecord app = mService.getProcessRecordLocked(targetProcess,

                    info.activityInfo.applicationInfo.uid, false);

            if (app != null && app.thread != null) { /進程啟動

               processCurBroadcastLocked(r, app);//發送靜態廣播

               return;

            }

     if ((r.curApp=mService.startProcessLocked(targetProcess,//啟動進程

                    info.activityInfo.applicationInfo, true,

                    r.intent.getFlags() | Intent.FLAG_FROM_BACKGROUND,

                    "broadcast", r.curComponent,

                    (r.intent.getFlags()&Intent.FLAG_RECEIVER_BOOT_UPGRADE) != 0, false, false))

                            == null) {

                      //進程啟動失敗

                  }

             //標志正在發送的串列廣播

            mPendingBroadcast = r;

            mPendingBroadcastRecvIndex = recIdx;//正在發送的廣播任務對應的接收器索引

}

Ⅲ 簡述在android中如何發送廣播消息

1.發送廣播
Intent intent = new Intent(BroadcastAction);
Bundle bundle = new Bundle();
bundle.putString("***", SUCCESS);
bundle.putString("FullPathName", mFullPathName);
intent.putExtras(bundle);
sendBroadcast(intent);
2.在Activity中創建一個內部類MyBroadcastReceiver擴展BroadcastReceiver,並在其中實現onReceive方法。
3.在Activity中聲明一個MyBroadcastReceiver類型的成員變數,並注冊:
private MyBroadcastReceiver myBroadcastReceiver;
...
myBroadcastReceiver = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter();
filter.addAction(BroadcastAction);
registerReceiver(receiver, filter);
4.使用完後要記得釋放
unregisterReceiver(receiver);

註:1和2中的 BroadcastAction要是同一個Action

Ⅳ Android本地廣播的使用

為了解決廣播的安全性問題,Android引入了本地廣播機制,使用該機制發出的廣播只能在應用程序的內部進行傳遞,並且廣播接收器也只能接收來自本應用程序發出的廣播。

本地廣播是無法通過靜態注冊的方式來接收的。我們知道靜態注冊主要是為了在程序未啟動的情況下能接收廣播,而當我們發送本地廣播的時候,程序肯定是已經啟動的了,所以我們需要動態注冊方式創建接收器。
在這里我們創建一個繼承於BroadcastReceiver的類LocalReceiver。onReceive()處理你接收到的廣播內容,在這里我用Toast來創建一個提示接收到消息的彈窗

在activity_main.xml文件創建一個用於發送廣播的按鈕

首先通過本地廣播管理器LocalBroadcastManager的getInstance()方法獲取一個實例,並分別創建過濾器IntentFilter和自定義接收器LocalReceiver的實例。給IntentFilter的實例添加一個action:localbroadcast(接收的廣播的名稱),然後調用LocalBroadcastManager的registerReceiver()方法進行注冊,並將LocalReceiver的實例和IntentFilter的實例都傳進去。這樣本地監聽器就創建完成了。
調用LocalBroadcastManager的sendBroadcast()發送本地廣播。運行程序,點擊Send Button按鈕,我們可以看到彈窗顯示「This is in LocalReceiver」,說明本地廣播發送和接收成功了。

當然,我們最後一定不要忘了取消注冊。我們可以通過調用unregisterReceiver()方法來實現。至此,Android的標准廣播發送就完成了。

1.發送的廣播只能在本程序內傳遞,不必擔心數據泄露
2.其它程序廣播無法發送到本程序的內部,不必擔心安全漏洞隱患
3.本地廣播比系統全局廣播更加高效

Ⅳ 22 AndroidBroadcast廣播機制

廣播(Broadcast)機制用於進程/線程間通信,廣播分為廣播發送和廣播接收兩個過程,其中廣播接收者BroadcastReceiver便是Android四大組件之一。

BroadcastReceiver分為兩類:

從廣播發送方式可分為三類:

廣播在系統中以BroadcastRecord對象來記錄, 該對象有幾個時間相關的成員變數.

廣播注冊,對於應用開發來說,往往是在Activity/Service中調用 registerReceiver() 方法,而Activity或Service都間接繼承於Context抽象類,真正幹活是交給ContextImpl類。另外調用getOuterContext()可獲取最外層的調用者Activity或Service。

[ContextImpl.java]

其中broadcastPermission擁有廣播的許可權控制,scheler用於指定接收到廣播時onRecive執行線程,當scheler=null則默認代表在主線程中執行,這也是最常見的用法

[ContextImpl.java]

ActivityManagerNative.getDefault()返回的是ActivityManagerProxy對象,簡稱AMP.
該方法中參數有mMainThread.getApplicationThread()返回的是ApplicationThread,這是Binder的Bn端,用於system_server進程與該進程的通信。

[-> LoadedApk.java]

不妨令 以BroadcastReceiver(廣播接收者)為key,LoadedApk.ReceiverDispatcher(分發者)為value的ArrayMap 記為 A 。此處 mReceivers 是一個以 Context 為key,以 A 為value的ArrayMap。對於ReceiverDispatcher(廣播分發者),當不存在時則創建一個。

此處mActivityThread便是前面傳遞過來的當前主線程的Handler.

ReceiverDispatcher(廣播分發者)有一個內部類 InnerReceiver ,該類繼承於 IIntentReceiver.Stub 。顯然,這是一個Binder服務端,廣播分發者通過rd.getIIntentReceiver()可獲取該Binder服務端對象 InnerReceiver ,用於Binder IPC通信。

[-> ActivityManagerNative.java]

這里有兩個Binder服務端對象 caller 和 receiver ,都代表執行注冊廣播動作所在的進程. AMP通過Binder驅動將這些信息發送給system_server進程中的AMS對象,接下來進入AMS.registerReceiver。

[-> ActivityManagerService.java]

其中 mRegisteredReceivers 記錄著所有已注冊的廣播,以receiver IBinder為key, ReceiverList為value為HashMap。

在BroadcastQueue中有兩個廣播隊列mParallelBroadcasts,mOrderedBroadcasts,數據類型都為ArrayList<broadcastrecord style="box-sizing: border-box;">:</broadcastrecord>

mLruProcesses數據類型為 ArrayList<ProcessRecord> ,而ProcessRecord對象有一個IApplicationThread欄位,根據該欄位查找出滿足條件的ProcessRecord對象。

該方法用於匹配發起的Intent數據是否匹配成功,匹配項共有4項action, type, data, category,任何一項匹配不成功都會失敗。

broadcastQueueForIntent(Intent intent)通過判斷intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 來決定是前台或後台廣播,進而返回相應的廣播隊列mFgBroadcastQueue或者mBgBroadcastQueue。

注冊廣播:

另外,當注冊的是Sticky廣播:

廣播注冊完, 另一個操作便是在廣播發送過程.

發送廣播是在Activity或Service中調用 sendBroadcast() 方法,而Activity或Service都間接繼承於Context抽象類,真正幹活是交給ContextImpl類。

[ContextImpl.java]

[-> ActivityManagerNative.java]

[-> ActivityManagerService.java]

broadcastIntent()方法有兩個布爾參數serialized和sticky來共同決定是普通廣播,有序廣播,還是Sticky廣播,參數如下:

broadcastIntentLocked方法比較長,這里劃分為8個部分來分別說明。

這個過程最重要的工作是:

BroadcastReceiver還有其他flag,位於Intent.java常量:

主要功能:

這個過主要處於系統相關的10類廣播,這里不就展開講解了.

這個過程主要是將sticky廣播增加到list,並放入mStickyBroadcasts裡面。

其他說明:

AMS.collectReceiverComponents

廣播隊列中有一個成員變數 mParallelBroadcasts ,類型為ArrayList<broadcastrecord style="box-sizing: border-box;">,記錄著所有的並行廣播。</broadcastrecord>

動態注冊的registeredReceivers,全部合並都receivers,再統一按串列方式處理。

廣播隊列中有一個成員變數 mOrderedBroadcasts ,類型為ArrayList<broadcastrecord style="box-sizing: border-box;">,記錄著所有的有序廣播。</broadcastrecord>

發送廣播過程:

處理方式:

可見不管哪種廣播方式,都是通過broadcastQueueForIntent()來根據intent的flag來判斷前台隊列或者後台隊列,然後再調用對應廣播隊列的scheleBroadcastsLocked方法來處理廣播;

在發送廣播過程中會執行 scheleBroadcastsLocked 方法來處理相關的廣播

[-> BroadcastQueue.java]

在BroadcastQueue對象創建時,mHandler=new BroadcastHandler(handler.getLooper());那麼此處交由mHandler的handleMessage來處理:

由此可見BroadcastHandler採用的是」ActivityManager」線程的Looper

[-> BroadcastQueue.java]

此處mService為AMS,整個流程還是比較長的,全程持有AMS鎖,所以廣播效率低的情況下,直接會嚴重影響這個手機的性能與流暢度,這里應該考慮細化同步鎖的粒度。

Ⅵ Android 第六講 廣播接收器和服務

兩種方式:靜態注冊和動態注冊
動態注冊:

1)動態注冊:需要定義一個繼承自BroadcastReceiver類的子類,該接收器需要在Activity中的onDestroy中注銷
2)靜態注冊:通過在AndroidManifest.xml中配置

兩種廣播形式:有序廣播和無序廣播
1)無序廣播:接受標准廣播的接收器將同時收到廣播消息,非同步執行,沒有先後順序 sendBroadCast
2)有序廣播:sendOrderedBroadCast,按照一定順序先後被接受順序,由priority屬性決定,abortBroadCast中斷廣播

如果只想在本應用中發送和接受廣播,使用LocalBroadcastReceiver來對廣播進行管理
本地廣播不支持靜態注冊
優點 :安全高效

Service是Android中的一種組件,和Activity的級別一致,但不能自己運行,只能後台運行,和其他組件交互,服務必須注冊才能使用

本地服務:服務依附在主線程中,節約資源,主線程死掉服務終止
遠程服務:服務在獨立進程中,靈活性好 ,佔用資源高

兩種服務的啟動模式:
1)start方式:調用者和服務之間沒有關聯,調用者退出不會影響服務,startService啟動服務,如果服務不存在,調用onCreat方法,然後onStartCommand被調用。stopService關閉服務,onDestroy方法被調用
2)bind方式:調用者和服務綁定,調用者退出,服務終止bindService啟動服務,onCreate方法創建服務,onBind方法綁定服務,onUnbind方法解綁,onDestory在服務結束時調用

Ⅶ android 怎樣收到系統發送的廣播

要注冊接受廣播的處理程序, 有兩種方式

  1. 在AndroidManifest.xml重注冊, 比如監聽系統的開機廣播和屏幕解鎖廣播
    <receiver android:name="com.bestjoy.app.common.update.BootCompletedReceiver" >
    <intent-filter>
    <action android:name="android.intent.action.BOOT_COMPLETED" />
    <action android:name="android.intent.action.USER_PRESENT" />
    </intent-filter>
    </receiver>
    這樣, 一旦有定義的action發出來,BootCompletedReceiver的onReceive方法就會回調了,這樣的監聽,不需要你的app已經在運行。


2. 在程序中動態創建監聽器, 比如還是解鎖廣播,

在Activity的onCreate()中生成一個IntentFilter對象

IntentFilter filter=new IntentFilter();
//為IntentFilter添加一個Action
filter.addAction("android.intent.action.USER_PRESENT");
bootCompletedReceiver = newUserPresentReceiver();

registerReceiver(smsReceiver, filter);
在onDestroy的時候去注冊
unregisterReceiver(bootCompletedReceiver);
這樣的方式只有在Activity生命周期onCreate()-onDestroy()之間有效。

對於一些特俗的系統級別的廣播,即使你按照上面的任何一種方式做了, 也可能監聽不到, 這是android 系統做了保護了, 網上查一下就知道了。

Ⅷ Android 使用udp發送廣播

最近做項目時,遇到一個對新人我來說稍微有點麻煩的事情!

那就是使用udp協議發送廣播獲取伺服器地址

http都好說,github開源項目不知道有多少。

可是再難的問題也要去解決!

發送廣播需要許可權!

AndroidManifest.xml 中添加:

最少這三個是必須的,多的也忘了!
原因後面會講到

使用到RxJava:

udp發送與接受都需指定埠號
廣播地址是255.255.255.255

在之前添加許可權的時候CHANGE_WIFI_MULTICAST_STATE有添加這個
往下面看

接下來我們開啟接收udp信息

發送消息?

謝謝該作者的文章讓我學會udp發送
https://blog.csdn.net/tanghongchang123/article/details/53609237

Ⅸ android怎麼發送特定廣播的

起一個線程,每發一個廣播後就sleep一分鍾,如此循環。(或者接受系統的timechanged這個廣播,這個廣播好像一分鍾發一次)。

Android 在發送廣播時的方法 sendBroadcast(Intent)。

①:Intent myIntent = new Intent();——【創建Intent對象】

②:myIntent.setAction(String)——【設置一般的要執行的動作。參數:動作一個動作的名稱,如ACTION_VIEW。應用程序的具體行動,應與供應商的包名作為前綴。】

③:myIntent.putExtra(String,Object)——【廣播中額外發送的數據,String為自定義key,Object表示多種數據類型】

④:sendBroadcast(myIntent);——【發送廣播】

接收廣播

Android在接收廣播的方法是注冊一個廣播接收器 registerReceiver(MyReceiver,IntentFilter)。

①:首先創建MyReceiver類(類名自定義) 繼承 BroadcastReceiver類。——【創建廣播接收器】

②:在MyReceiver中重寫public void onReceive(Context context, Intent intent)方法。這個方法在接收到廣播後觸發。——【重寫處理方法】

③:在Activity或者Service啟動時 onCreate()、onStartCommand()等方法中實例化 MyReceiver類——【啟動時實例化廣播接收器】

④:IntentFilter filter = new IntentFilter();——【創建IntentFilter對象 意圖過濾器】

⑤:filter.addAction(String);——【在過濾器中加入過濾條件,說明接收什麼廣播】

⑥:registerReceiver(cmdReceiver, filter);——【注冊廣播,參數為(廣播接收器,意圖過濾器)】

Ⅹ android 廣播機制(2) 粘性廣播

android的粘性廣播,是指廣播接收器一注冊馬上就能接收到廣播的一種機制,當然首先系統要存在廣播。而普通廣播就是要先注冊廣播接收器,然後廣播被發送到系統,廣播接收器才能接收到廣播。
所以他們的區別是:
粘性廣播調用registerReceiver能馬上接受廣播,而普通廣播不行。

對於粘性廣播:
1.系統首先存在粘性廣播

2.注冊廣播接收器

3.處理廣播

下面用一個例子展示下他們的區別
主Acitivity

布局

布局有兩個按鈕,一個是注冊粘性廣播,一個是注冊普通廣播。點擊注冊粘性廣播按鈕會馬上返回結果。而點擊注冊普通廣播按鈕則沒有反應

閱讀全文

與android發送接收廣播相關的資料

熱點內容
長沙保衛戰薛岳下命令是哪一集 瀏覽:414
hp伺服器如何進iLO界面 瀏覽:141
固定ip伺服器如何加防火牆 瀏覽:235
vmp一機一碼加密軟體 瀏覽:790
跳繩解壓視頻教程 瀏覽:661
加密貨幣支付對虛擬幣的影響 瀏覽:741
國外3d解壓視頻 瀏覽:628
組態王app怎麼復制圖像 瀏覽:228
美國怡口凈水器壓縮活性炭 瀏覽:251
啟動選項命令 瀏覽:907
php在線下單系統源碼 瀏覽:684
windows視頻壓縮 瀏覽:391
螞蟻保護板藍牙app如何連接電池 瀏覽:295
迪哥的我的世界伺服器叫什麼 瀏覽:989
數據結構與演算法分析java習題答案 瀏覽:490
pdf伺服器 瀏覽:798
cef平衡演算法 瀏覽:437
安卓手機如何打開272文件 瀏覽:27
如何找到電腦里自己隱藏的文件夾 瀏覽:837
設置伺服器的無後綴地址訪問 瀏覽:408