一、廣播

1、廣播的定義

BroadcastReceiver，中文直譯為“廣播接收者”，在Android 系統(tǒng)中，廣播主要用在組件與組件之間進行消息傳遞。組件與組件之間可以是同一個進程，也可以是不同進程。既然是可以跨進程的，那么可以想像底層應(yīng)該是基于Binder來實現(xiàn)的，事實也正是如此。

2、廣播的使用場景

3、廣播的種類

? ? ? 4) 有序廣播? Ordered Broadcast

攔截可以使用abortBroadCast來攔截。

數(shù)據(jù)的設(shè)置如果是原始廣播發(fā)送過來的，可以使用intent.getStringExtra("msg")獲得原始數(shù)據(jù)，你可以將新的數(shù)據(jù)使用setResultExtras()封裝傳遞到下一級去(下一級接收getResultExtras(true)),

也可以使用setResultData()封裝數(shù)據(jù)發(fā)送到下一級(下一級使用getResultData()接收)

? ? ? ? 5)? 粘性廣播 Stick Broadcast

粘性消息在發(fā)送后就一直存在于系統(tǒng)的消息容器里面，等待對應(yīng)的處理器去處理，如果暫時沒有處理器處理這個消息則一直在消息容器里面處于等待狀態(tài)，粘性廣播的Receiver如果被銷毀，那么下次重建時會自動接收到消息數(shù)據(jù)。

從上面的日志信息可以看出sendStickyBroadcast只保留最后一條廣播，并且一直保留下去，這樣即使已經(jīng)處理了這條廣播但當再一次注冊這條廣播后依然可以收到它。

二、實現(xiàn)廣播-receiver

1、靜態(tài)注冊：注冊完成就一直運行

2、動態(tài)注冊：跟隨activity的生命周期

三、廣播實現(xiàn)機制

四、LocalBroadcastManager詳解

BroadcastReceiver安全問題

BroadcastReceiver設(shè)計的初衷是從全局考慮可以方便應(yīng)用程序和系統(tǒng)、應(yīng)用程序之間、應(yīng)用程序內(nèi)的通信，所以對單個應(yīng)用程序而言BroadcastReceiver是存在安全性問題的(惡意程序腳本不斷的去發(fā)送你所接收的廣播)。為了解決這個問題LocalBroadcastManager就應(yīng)運而生了。

LocalBroadcastManager是Android Support包提供了一個工具，用于在同一個應(yīng)用內(nèi)的不同組件間發(fā)送Broadcast。LocalBroadcastManager也稱為局部通知管理器，這種通知的好處是安全性高，效率也高，適合局部通信，可以用來代替Handler更新UI

好處：

1、因廣播數(shù)據(jù)在本應(yīng)用范圍內(nèi)傳播，你不用擔心隱私數(shù)據(jù)泄露的問題。

2、不用擔心別的應(yīng)用偽造廣播，造成安全隱患。

3、相比在系統(tǒng)內(nèi)發(fā)送全局廣播，它更高效。

五、Android Broadcast 和 BroadcastReceiver的權(quán)限限制

在Android應(yīng)用開發(fā)中，有時會遇到以下兩種情況，

1. 一些敏感的廣播并不想讓第三方的應(yīng)用收到 ；

2. 要限制自己的Receiver接收某廣播來源，避免被惡意的同樣的ACTION的廣播所干擾。

第一種場景： 誰有權(quán)收我的廣播？

首先在send app中的Androidmanifest.xml添加

然后，在Sender app發(fā)送廣播時將此權(quán)限作為參數(shù)傳入，如下：

這樣做之后就使得只有具有RECV_XXX權(quán)限的Receiver APP才能接收此廣播要接收該廣播，在Receiver應(yīng)用的AndroidManifest.xml中要添加對應(yīng)的RECV_XXX權(quán)限。

Receiver APP 廣播注冊的時候也要添加此權(quán)限，否則接受不到消息

第二種場景： 誰有權(quán)給我發(fā)廣播？

備注：Android 8.0取消大部分靜態(tài)注冊的廣播

六、BroadcastReceiver之源碼分析

Context--ContextImpl-AMS