Android Broadcast
Broadcast使用場景
Android廣播分為兩個方面:廣播發送者和廣播接受者.通常情況下,BroadcastRecevier指廣播接受者,廣播作為Android組件之間的通訊方式,使用場景有:
- 同一個APP內部的同一個組件類的消息通訊(單線程或者多個線程)
- 同一個APP內部不同的組件之間的消息通訊(單個進程)
- 同一個APP具有多個進程不同組件之間的消息通訊
- 不同APP之間的組件之間的通訊
- Android系統在特定情況下與APP之間的通訊.
Broadcast實現的基本流程為:
- 廣播接受者BroadcastRecevier通過Binder機制向AMS(Activity manager Service)進行注冊
- 廣播發送者通過Binder機制向AMS發送廣播
- AMS查找符合條件(intentFilter/permission)的BroadcastRecevier,將廣播發送給ReceiverDispatcher,Dispatcher將廣播發送到BroadcastReceiver(一般情況是Activity)的消息循環隊列中;
- 消息循環執行此廣播,回調到BoradcastReceiver中的onReceiver()方法中.
廣播注冊方式
- 靜態注冊:
<receiver
android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permission="string"
android:process="string" >
</receiver>
其中屬性:
- android:exported: 此廣播能否接受其他APP發出的廣播,這個屬性默認值由intent-filter決定,如果有intent-filter,默認值為true,否則為false(Activity/Service中同樣適用).
- android:name: 廣播接受者名
- android:permission: 如果設置,具有相同權限的廣播發送的廣播才能被此接受者接受.
- android:process: 廣播接受者所處在的進程,默認為app.
<receiver android:name=".MyBroadcastReceiver" >
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
-
動態注冊:
動態注冊廣播對使用的Context要注意,因為廣播接受者的存在取決于注冊的context,如果是Activity,廣播在當前Activity中有效,如果是Application context則與App應用生命周期相同.
registerReceiver(BroadcastReceiver receiver, IntentFilter filter) registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheduler)
廣播發送及其廣播類型
-
廣播的類型:
- Normal Broadcast 普通廣播
- Ordered Broadcast 有序廣播
- Sticky Broadcast 粘性廣播(api21中廢棄)
- System Broadcat 系統廣播
- Local Broadcast APP內部廣播
-
廣播發送的方式:
-
sendOrderedBroadcast(Intent, String)
發送有序廣播 -
sendBroadcast(Intent)
發送普通廣播 -
LocalBroadcastManager.sendBroadcast
發送應用內廣播
-
不同注冊方式的廣播接收器回調onReceive(context, intent)中的context具體類型
對于靜態注冊的ContextReceiver,回調onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext;
對于全局廣播的動態注冊的ContextReceiver,回調onReceive(context, intent)中的context具體指的是Activity Context;
對于通過LocalBroadcastManager動態注冊的ContextReceiver,回調onReceive(context, intent)中的context具體指的是Application Context。
注:對于LocalBroadcastManager方式發送的應用內廣播,只能通過LocalBroadcastManager動態注冊的ContextReceiver才有可能接收到(靜態注冊或其他方式動態注冊的ContextReceiver是接收不到的)。
如何在廣播接收者onReceiver中進行耗時操作
廣播接收者有生命周期,但是很短,當onReceiver()執行完畢,他生命周期就結束了.這次BroadcastRece已經不處于active狀態,被系統殺掉的幾率很高.如果此時去開線程進行異步超過或者打開Dialog都還沒達到相應的效果就被系統殺掉,因為這個Receiver組件在運行,但是只是一個執行完畢的空進程.這情況下可以使用下面方法,來保持Receiver處于active狀態,即便系統想要快速結束receive,也可以把操作移動其他線程防止主線程卡頓.
- goAsync()
- JobService()
public class MyBroadcastReceiver extends BroadcastReceiver {
private static final String TAG = "MyBroadcastReceiver";
@Override
public void onReceive(final Context context, final Intent intent) {
final PendingResult pendingResult = goAsync();
AsyncTask<String, Integer, String> asyncTask = new AsyncTask<String, Integer, String>() {
@Override
protected String doInBackground(String... params) {
StringBuilder sb = new StringBuilder();
sb.append("Action: " + intent.getAction() + "\n");
sb.append("URI: " + intent.toUri(Intent.URI_INTENT_SCHEME).toString() + "\n");
Log.d(TAG, log);
// Must call finish() so the BroadcastReceiver can be recycled.
pendingResult.finish();
return data;
}
};
asyncTask.execute();
}
}
廣播的安全隱患以及相應的措施
Android中的廣播可以跨進程甚至跨App直接通信,且注冊是exported對于有intent-filter的情況下默認值是true,由此將可能出現安全隱患如下:
1.其他App可能會針對性的發出與當前App intent-filter相匹配的廣播,由此導致當前App不斷接收到廣播并處理;
2.其他App可以注冊與當前App一致的intent-filter用于接收廣播,獲取廣播具體信息。
無論哪種情形,這些安全隱患都確實是存在的。由此,最常見的增加安全性的方案是:
1.對于同一App內部發送和接收廣播,將exported屬性人為設置成false,使得非本App內部發出的此廣播不被接收;
2.在廣播發送和接收時,都增加上相應的permission,用于權限驗證;
3.發送廣播時,指定特定廣播接收器所在的包名,具體是通過intent.setPackage(packageName)指定在,這樣此廣播將只會發送到此包中的App內與之相匹配的有效廣播接收器中。
App應用內廣播可以理解成一種局部廣播的形式,廣播的發送者和接收者都同屬于一個App。實際的業務需求中,App應用內廣播確實可能需要用到。同時,之所以使用應用內廣播時,而不是使用全局廣播的形式,更多的考慮到的是Android廣播機制中的安全性問題。
相比于全局廣播,App應用內廣播優勢體現在:1.安全性更高;2.更加高效。
為此,Android v4兼容包中給出了封裝好的LocalBroadcastManager類,用于統一處理App應用內的廣播問題,使用方式上與通常的全局廣播幾乎相同,只是注冊/取消注冊廣播接收器和發送廣播時將主調context變成了LocalBroadcastManager的單一實例。
//registerReceiver(mBroadcastReceiver, intentFilter);
//注冊應用內廣播接收器
localBroadcastManager = LocalBroadcastManager.getInstance(this);
localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
//unregisterReceiver(mBroadcastReceiver);
//取消注冊應用內廣播接收器
localBroadcastManager.unregisterReceiver(mBroadcastReceiver);
Intent intent = new Intent();
intent.setAction(BROADCAST_ACTION);
intent.putExtra("name", "qqyumidi");
//sendBroadcast(intent);
//發送應用內廣播
localBroadcastManager.sendBroadcast(intent);
面試題:
-
廣播中如何進行耗時操作?(Service/Notification)
- goAsync()
- JobService
-
廣播是否可以開啟Activity?
廣播啟動activity很可能影響用戶體驗,何況有時接受者還不止一個,可以考慮使用Notification.
-
廣播來更新界面是否合適?
如果不是頻繁更新刷新,可以是廣播來達到效果.對于頻繁地刷新動作,不要使用廣播,廣播發送和接收使用具有一定的代價,他的傳輸是通過Binder機制實現,那么系統會為廣播做進程之間通訊做準備很好性能,另外,廣播的接收具有一定的延時性,可能導致卡頓(Binder傳輸).
-
有時候基于數據安全考慮,我們想發送廣播只有自己(本進程)能接收到,那么該如何去做呢?如果不使用LocalBroadcastManger,該怎么實現?
可能使用Handler,往主線程的消息池(Message Queue)發送消息,只有主線程的Handler可以分發處理它,廣播發送的內容是一個Intent對象,我們可以直接用Message封裝一下,留一個和sendBroadcast一樣的接口。在handleMessage時把Intent對象傳遞給已注冊的Receiver。