頻道欄目
首頁 > 程序開發 > 移動開發 > Android > 正文
Android開發之廣播的基本使用說明
2018-07-30 14:14:25         來源:cccdehaoma的博客  
收藏   我要投稿

1、Android廣播發送及廣播類型

廣播發送的基本代碼:

Intent intent =  new Intent();
intent.setAction(Constant.WAIT_BROADCAST_ACTION);
context.sendBroadcast(intent);

根據廣播的發送方式,可以將其分為以下幾種類型:

1)普通廣播 Normal Broadcast

2)系統廣播 System Broadcast

3) 有序廣播 Ordered Broadcast

4)粘性廣播 Sticky Broadcast (在Android 5.0/Api 21中不推薦使用,有序粘性廣播也已經不推薦使用)

5)應用內廣播 Local Broadcast(使用LocalBroadcastManager,只能在應用內使用,不能跨進程使用。)

1)普通廣播 Normal Broadcast

開發者自己定義的intent,以context.sendBroadcast(...)或者context.sendBroadcastAsUser(...)形式發送。

具體可以使用的方法有:

sendBroadcast(...):

①sendBroadcast(@RequiresPermission Intent intent);

②sendBroadcast(@RequiresPermission Intent intent, @Nullable String receiverPermission);

③sendBroadcast(Intent intent, @Nullable String receiverPermission, @Nullable Bundle options);

④sendBroadcast(Intent intent, String receiverPermission, int appOp);

sendBoadcastAsUser(...)

①sendBroadcastAsUser(@RequiresPermission Intent intent, UserHandle user);

②sendBroadcastAsUser(@RequiresPermission Intent intent, UserHandle user, @Nullable String receiverPermission);

③sendBroadcastAsUser(@RequiresPermission Intent intent, UserHandle user, @Nullable String receiverPermission, int appOp);

2)系統廣播 System Broadcast

Android系統內置了多個廣播,涉及到手機的基本操作,基本上都會發出相應的系統廣播。

系統廣播在系統內部當特定事件發生時,由系統發出。

3)有序廣播 Ordered Broadcast

有序廣播是針對廣播接收者(BroadcastReceiver)而言,按照先后順序接收的。

先后順序判斷標準為:按照Priority由大到小排序;有相同priority的動態廣播和靜態廣播,動態廣播會排在前面。

4)粘性廣播(Sticky Broadcast)

已經在Android 5.0/Api 21中不推薦使用

5)應用內廣播(Local Broadcast)

用LocalBroadcastManager統一處理APP應用內的廣播問題。

Android廣播可以跨進程甚至跨APP發送,會造成一下問題:

①其他應用可能會針對當前APP,發送與當前APP intent-filter一致的廣播,導致APP不斷的接收和處理;

②其他應用可以注冊與當前APP intent-filter一致的廣播,用于接收廣播信息。

以上兩種情況都存在安全隱患,常見的增加安全性的方案是:

①本地APP內部發送和接收的廣播,將exported屬性設為false。

②在發送和接收廣播時,增加上相應的permission,用于權限驗證。

③發送廣播時,指定廣播接收器所在的包名

2、廣播發送和接收的原理

除應用內廣播,其他廣播發送和接收原理

①繼承BroadcastReceiver,重寫onReceive()方法;

②通過Binder機制向ActivityManagerService注冊廣播

③通過Binder機制向ActivityManagerService發送廣播

④AMS查找符合條件(IntentFilter/Permission)的BroadcastReceiver,將廣播發送到BroadcastReceiver所在的消息隊列中。

⑤BroadcastReceiver所在的隊列收到此廣播后,回調onReceive()方法。

應用內廣播,發送和接收原理與普通廣播基本一致,將ActivityManagerService換為LocalManagerService控制廣播的接收和發送等流程。

3、廣播數據的限制(未驗證,待驗證)

廣播傳輸數據大小應該盡可能的小。不能太大。圖片或者太長的字符串應該以別的方式傳遞。

進程內,可以用EventBus,文件緩存,磁盤緩存。

官網上對TransationTooLargeException有如下說明:

TransactionTooLargeException

The Binder transaction failed because it was too large.

During a remote procedure call, the arguments and the return value of the call are transferred asParcelobjects stored in the Binder transaction buffer. If the arguments or the return value are too large to fit in the transaction buffer, then the call will fail andTransactionTooLargeExceptionwill be thrown.

The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process. Consequently this exception can be thrown when there are many transactions in progress even when most of the inpidual transactions are of moderate size.

There are two possible outcomes when a remote procedure call throwsTransactionTooLargeException. Either the client was unable to send its request to the service (most likely if the arguments were too large to fit in the transaction buffer), or the service was unable to send its response back to the client (most likely if the return value was too large to fit in the transaction buffer). It is not possible to tell which of these outcomes actually occurred. The client should assume that a partial failure occurred.

The key to avoidingTransactionTooLargeExceptionis to keep all transactions relatively small. Try to minimize the amount of memory needed to create aParcelfor the arguments and the return value of the remote procedure call. Avoid transferring huge arrays of strings or large bitmaps. If possible, try to break up big requests into smaller pieces.

意思大概是說

通過Binder緩沖區中的Parcel對象進行傳輸。Binder事務緩沖區具有有限的固定大小,當前為1Mb。

由當前進程正在進行的所有事務共享。因此,即使大多數單個事務的大小適中,當有許多事務正在進行時,也會拋出此異常。

當拋出TransactionTooLargeException時,有兩種可能得原因?蛻舳藷o法將其請求發送到服務(可能因為參數太大而無法保存到事務緩沖區中),或者服務無法將其響應發送回客戶端(可能因為返回值為太大而無法保存到事務緩沖區中)。

避免TransactionTooLargeException的關鍵是保持所有事務相對較小。

避免傳輸大量字符串或大位圖。如果可能的話,嘗試將大量請求分解成更小的部分。

點擊復制鏈接 與好友分享!回本站首頁
上一篇:win10下的Android、Eclipse-8.0.2和PhoneGap-8.0.0環境配置教程
下一篇:Android 插件化,qihoo360插件方案配置教程
相關文章
圖文推薦
文章
推薦
點擊排行

關于我們 | 聯系我們 | 廣告服務 | 投資合作 | 版權申明 | 在線幫助 | 網站地圖 | 作品發布 | Vip技術培訓 | 舉報中心

版權所有: 紅黑聯盟--致力于做實用的IT技術學習網站

重庆快乐十分开奖记录