安卓全局廣播形式是什麼形式

Ⅰ 安卓開發本地廣播和全局廣播有什麼差別

引用網友bupthxh 在 問題 http://..com/question/1433916311990487339.html 中的回答：

BroadcastReceiver是針對應用間、應用與系統間、應用內部進行通信的一種方式

LocalBroadcastReceiver僅在自己的應用內發送接收廣播，也就是只有自己的應用能收到

Ⅱ 安卓里的系統廣播是什麼有什麼作用

比如，開關機，聯網，來電，這些廣播主要為了上層開發app方便比如來電視頻app就自動暫停等等功能，或者開機自啟動等等

Ⅲ android中的廣播是什麼意思

android的廣播概念和我們日常生活中的電台有相通之處，空氣中有不同頻段，不同電台的廣播，而android系統中就有對應的電池的電量，來電，簡訊還有例如sd卡拔插等等這些廣播的消息發出，這些消息就對應著用收音機調頻時，不同電台的節目。而我們注冊的廣播就類似於我收聽某個電台的節目，比如一個注冊廣播收聽交通廣播，另一個注冊的廣播收聽音樂廣播，那麼怎麼區分是交通廣播還是音樂廣播呢，這就要通過前一章提到的Intent的action來判斷。

Ⅳ 安卓編程里的系統廣播是什麼有什麼作用

android通過廣播來實現不同進程間的通信 對應於廣播（broadcat）還有一個廣播接收器（broadcast receiver）每個廣播指定了對應的action 、 type等信息，每個接收器根據這些信息來過濾是否自己要接收的廣播

Ⅳ android 本地廣播和全局廣播有什麼差別

本地廣播發送的廣播只有該應用程序內才可以接收的到，而全局廣播發送出來的廣播，可以被其他app接收到

Ⅵ Android注冊廣播有幾種方式，分別是什麼

注冊方式有兩種：
1、靜態注冊，就是在manifest文件里配置一下，這種方式注冊的廣播屬於系統級廣播。你的應用沒打開也能收到廣播。比如你要做一個收到某廣播就啟動你的應用的功能可以這樣搞。
2、動態注冊，在代碼里執行一個rigisterBroadcastReciver（可能拼寫有誤）的方法。這種你要自己作好反注冊。這種廣播可以做成你的應用啟動後才監聽，關閉後就不監聽的效果。

Ⅶ android的localbroadcastmanager其他app廣播能到達嗎

廣播接收器是運行在UI線程。

下面介紹來自於android學習手冊，android學習手冊包含9個章節，108個例子，源碼文檔隨便看，例子都是可交互，可運行，源碼採用android studio目錄結構，高亮顯示代碼，文檔都採用文檔結構圖顯示，可以快速定位。360手機助手中下載,圖標上有貝殼
1.Android廣播機制概述
Android廣播分為兩個方面：廣播發送者和廣播接收者，通常情況下，BroadcastReceiver指的就是廣播接收者（廣播接收器）。廣播作為Android組件間的通信方式，可以使用的場景如下：
1.同一app內部的同一組件內的消息通信（單個或多個線程之間）；
2.同一app內部的不同組件之間的消息通信（單個進程）；
3.同一app具有多個進程的不同組件之間的消息通信；
4.不同app之間的組件之間消息通信；
5.Android系統在特定情況下與App之間的消息通信。
從實現原理看上，Android中的廣播使用了觀察者模式，基於消息的發布/訂閱事件模型。因此，從實現的角度來看，Android中的廣播將廣播的發送者和接受者極大程度上解耦，使得系統能夠方便集成，更易擴展。具體實現流程要點粗略概括如下：
1.廣播接收者BroadcastReceiver通過Binder機制向AMS(Activity Manager Service)進行注冊；
2.廣播發送者通過binder機制向AMS發送廣播；
3.AMS查找符合相應條件（IntentFilter/Permission等）的BroadcastReceiver，將廣播發送到BroadcastReceiver（一般情況下是Activity）相應的消息循環隊列中；
4.消息循環執行拿到此廣播，回調BroadcastReceiver中的onReceive()方法。
對於不同的廣播類型，以及不同的BroadcastReceiver注冊方式，具體實現上會有不同。但總體流程大致如上。
由此看來，廣播發送者和廣播接收者分別屬於觀察者模式中的消息發布和訂閱兩端，AMS屬於中間的處理中心。廣播發送者和廣播接收者的執行是非同步的，發出去的廣播不會關心有無接收者接收，也不確定接收者到底是何時才能接收到。顯然，整體流程與EventBus非常類似。
在上文說列舉的廣播機制具體可以使用的場景中，現分析實際應用中的適用性：
第一種情形：同一app內部的同一組件內的消息通信（單個或多個線程之間），實際應用中肯定是不會用到廣播機制的（雖然可以用），無論是使用擴展變數作用域、基於介面的回調還是Handler-post/Handler-Message等方式，都可以直接處理此類問題，若適用廣播機制，顯然有些逗殺雞牛刀地的感覺，會顯太逗重地；
第二種情形：同一app內部的不同組件之間的消息通信（單個進程），對於此類需求，在有些教復雜的情況下單純的依靠基於介面的回調等方式不好處理，此時可以直接使用EventBus等，相對而言，EventBus由於是針對統一進程，用於處理此類需求非常適合，且輕松解耦。可以參見文件《Android各組件/控制項間通信利器之EventBus》。
第三、四、五情形：由於涉及不同進程間的消息通信，此時根據實際業務使用廣播機制會顯得非常適宜。下面主要針對Android廣播中的具體知識點進行總結。

2.BroadcastReceiver
自定義BroadcastReceiver
自定義廣播接收器需要繼承基類BroadcastReceivre，並實現抽象方法onReceive(context, intent)方法。廣播接收器接收到相應廣播後，會自動回到onReceive(..)方法。默認情況下，廣播接收器也是運行在UI線程，因此，onReceive方法中不能執行太耗時的操作。否則將因此ANR。一般情況下，根據實際業務需求，onReceive方法中都會涉及到與其他組件之間的交互，如發送Notification、啟動service等。
下面代碼片段是一個簡單的廣播接收器的自定義：

1 public class MyBroadcastReceiver extends BroadcastReceiver {
2 public static final String TAG = "MyBroadcastReceiver";
3 public static int m = 1;
4
5 @Override
6 public void onReceive(Context context, Intent intent) {
7 Log.w(TAG, "intent:" + intent);
8 String name = intent.getStringExtra("name");
9 Log.w(TAG, "name:" + name + " m=" + m);
10 m++;
11
12 Bundle bundle = intent.getExtras();
13
14 }
15 }



BroadcastReceiver注冊類型
BroadcastReceiver總體上可以分為兩種注冊類型：靜態注冊和動態注冊。
1).靜態注冊：
直接在AndroidManifest.xml文件中進行注冊。規則如下：

<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 ——此broadcastReceiver能否接收其他App的發出的廣播，這個屬性默認值有點意思，其默認值是由receiver中有無intent-filter決定的，如果有intent-filter，默認值為true，否則為false。（同樣的，activity/service中的此屬性默認值一樣遵循此規則）同時，需要注意的是，這個值的設定是以application或者application user id為界的，而非進程為界（一個應用中可能含有多個進程）；
android:name —— 此broadcastReceiver類名；
android:permission ——如果設置，具有相應許可權的廣播發送方發送的廣播才能被此broadcastReceiver所接收；
android:process ——broadcastReceiver運行所處的進程。默認為app的進程。可以指定獨立的進程（Android四大基本組件都可以通過此屬性指定自己的獨立進程）
常見的注冊形式有：

<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>


其中，intent-filter由於指定此廣播接收器將用於接收特定的廣播類型。本示例中給出的是用於接收網路狀態改變或開啟啟動時系統自身所發出的廣播。當此App首次啟動時，系統會自動實例化MyBroadcastReceiver，並注冊到系統中。
之前常說：靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立，具體分析詳見本文後面部分。

2).動態注冊：
動態注冊時，無須在AndroidManifest中注冊<receiver/>組件。直接在代碼中通過調用Context的registerReceiver函數，可以在程序中動態注冊BroadcastReceiver。registerReceiver的定義形式如下：
1 registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
2 registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheler)
典型的寫法示例如下：

1 public class MainActivity extends Activity {
2 public static final String BROADCAST_ACTION = "com.example.corn";
3 private BroadcastReceiver mBroadcastReceiver;
4
5 @Override
6 protected void onCreate(Bundle savedInstanceState) {
7 super.onCreate(savedInstanceState);
8 setContentView(R.layout.activity_main);
9
10 mBroadcastReceiver = new MyBroadcastReceiver();
11 IntentFilter intentFilter = new IntentFilter();
12 intentFilter.addAction(BROADCAST_ACTION);
13 registerReceiver(mBroadcastReceiver, intentFilter);
14 }
15
16 @Override
17 protected void onDestroy() {
18 super.onDestroy();
19 unregisterReceiver(mBroadcastReceiver);
20 }
21
22 }


註：Android中所有與觀察者模式有關的設計中，一旦涉及到register，必定在相應的時機需要unregister。因此，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)。
當此Activity實例化時，會動態將MyBroadcastReceiver注冊到系統中。當此Activity銷毀時，動態注冊的MyBroadcastReceiver將不再接收到相應的廣播。

3.廣播發送及廣播類型
經常說地發送廣播逗和地接收逗，表面上看廣播作為Android廣播機制中的實體，實際上這一實體本身是並不是以所謂的地廣播逗對象存在的，而是以地意圖逗（Intent）去表示。定義廣播的定義過程，實際就是相應廣播地意圖逗的定義過程，然後通過廣播發送者將此地意圖逗發送出去。被相應的BroadcastReceiver接收後將會回調onReceive()函數。
下段代碼片段顯示的是一個普通廣播的定義過程，並發送出去。其中setAction(..)對應於BroadcastReceiver中的intentFilter中的action。
1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.putExtra("name", "yumidi");
4 sendBroadcast(intent);

根據廣播的發送方式，可以將其分為以下幾種類型：
1.Normal Broadcast：普通廣播
2.System Broadcast: 系統廣播
3.Ordered broadcast：有序廣播
4.Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)
5.Local Broadcast：App應用內廣播
下面分別總結下各種類型的發送方式及其特點。
1).Normal Broadcast：普通廣播
此處將普通廣播界定為：開發者自己定義的intent，以context.sendBroadcast_"AsUser"(intent, ...)形式。具體可以使用的方法有：
sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)。
普通廣播會被注冊了的相應的感興趣（intent-filter匹配）接收，且順序是無序的。如果發送廣播時有相應的許可權要求，BroadCastReceiver如果想要接收此廣播，也需要有相應的許可權。
2).System Broadcast: 系統廣播
Android系統中內置了多個系統廣播，只要涉及到手機的基本操作，基本上都會發出相應的系統廣播。如：開啟啟動，網路狀態改變，拍照，屏幕關閉與開啟，點亮不足等等。每個系統廣播都具有特定的intent-filter，其中主要包括具體的action，系統廣播發出後，將被相應的BroadcastReceiver接收。系統廣播在系統內部當特定事件發生時，有系統自動發出。
3)Ordered broadcast：有序廣播
有序廣播的有序廣播中的逗有序地是針對廣播接收者而言的，指的是發送出去的廣播被BroadcastReceiver按照先後循序接收。有序廣播的定義過程與普通廣播無異，只是其的主要發送方式變為：sendOrderedBroadcast(intent, receiverPermission, ...)。
對於有序廣播，其主要特點總結如下：
1>多個具當前已經注冊且有效的BroadcastReceiver接收有序廣播時，是按照先後順序接收的，先後順序判定標准遵循為：將當前系統中所有有效的動態注冊和靜態注冊的BroadcastReceiver按照priority屬性值從大到小排序，對於具有相同的priority的動態廣播和靜態廣播，動態廣播會排在前面。
2>先接收的BroadcastReceiver可以對此有序廣播進行截斷，使後面的BroadcastReceiver不再接收到此廣播，也可以對廣播進行修改，使後面的BroadcastReceiver接收到廣播後解析得到錯誤的參數值。當然，一般情況下，不建議對有序廣播進行此類操作，尤其是針對系統中的有序廣播。
4)Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)。
既然已經deprecated，此處不再多做總結。
5)Local Broadcast：App應用內廣播（此處的App應用以App應用進程為界）
由前文闡述可知，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的單一實例。
代碼片段如下：

1 //registerReceiver(mBroadcastReceiver, intentFilter);
2 //注冊應用內廣播接收器
3 localBroadcastManager = LocalBroadcastManager.getInstance(this);
4 localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
5
6 //unregisterReceiver(mBroadcastReceiver);
7 //取消注冊應用內廣播接收器
8 localBroadcastManager.unregisterReceiver(mBroadcastReceiver);
9
10 Intent intent = new Intent();
11 intent.setAction(BROADCAST_ACTION);
12 intent.putExtra("name", "yumidi");
13 //sendBroadcast(intent);
14 //發送應用內廣播
15 localBroadcastManager.sendBroadcast(intent);



4.不同注冊方式的廣播接收器回調onReceive(context, intent)中的context具體類型
1).對於靜態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext；
2).對於全局廣播的動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Activity Context；
3).對於通過LocalBroadcastManager動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Application Context。
註：對於LocalBroadcastManager方式發送的應用內廣播，只能通過LocalBroadcastManager動態注冊的ContextReceiver才有可能接收到（靜態注冊或其他方式動態注冊的ContextReceiver是接收不到的）。

5.不同Android API版本中廣播機制相關API重要變遷
1).Android5.0/API level 21開始粘滯廣播和有序粘滯廣播過期，以後不再建議使用；
2).地靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立逗
Android 3.1開始系統在Intent與廣播相關的flag增加了參數，分別是FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES。
FLAG_INCLUDE_STOPPED_PACKAGES：包含已經停止的包（停止：即包所在的進程已經退出）
FLAG_EXCLUDE_STOPPED_PACKAGES：不包含已經停止的包
主要原因如下：
自Android3.1開始，系統本身則增加了對所有app當前是否處於運行狀態的跟蹤。在發送廣播時，不管是什麼廣播類型，系統默認直接增加了值為FLAG_EXCLUDE_STOPPED_PACKAGES的flag，導致即使是靜態注冊的廣播接收器，對於其所在進程已經退出的app，同樣無法接收到廣播。
詳情參加Android官方文檔：
由此，對於系統廣播，由於是系統內部直接發出，無法更改此intent flag值，因此，3.1開始對於靜態注冊的接收系統廣播的BroadcastReceiver，如果App進程已經退出，將不能接收到廣播。
但是對於自定義的廣播，可以通過復寫此flag為FLAG_INCLUDE_STOPPED_PACKAGES，使得靜態注冊的BroadcastReceiver，即使所在App進程已經退出，也能能接收到廣播，並會啟動應用進程，但此時的BroadcastReceiver是重新新建的。
1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES);
4 intent.putExtra("name", "yumidi");
5 sendBroadcast(intent);

注1：對於動態注冊類型的BroadcastReceiver，由於此注冊和取消注冊實在其他組件（如Activity）中進行，因此，不受此改變影響。
注2：在3.1以前，相信不少app可能通過靜態注冊方式監聽各種系統廣播，以此進行一些業務上的處理（如即時app已經退出，仍然能接收到，可以啟動service等..）,3.1後，靜態注冊接受廣播方式的改變，將直接導致此類方案不再可行。於是，通過將Service與App本身設置成不同的進程已經成為實現此類需求的可行替代方案。

Ⅷ android中注冊廣播有幾種方式，這些方式的優缺點，談談android引入廣播的用意

2種方式
1.在androidmainfest.xml中注冊
2.<receiver>
3. <intent-filter>
4. <action android:name = "android.intent.action.PICK"/>
5. </intent-filter>
6.</receiver>
7.缺點：常駐型，占資源比較大
8.
9.registerReceiver(receiver,filter); BroadcastReceiver更新UI一般用這種方法

Ⅸ android 注冊廣播有幾種方式，這些方式有何優缺點

一般來說，一種是動態注冊，即 用java代碼直接注冊，
如oncreate(){
this.registerreceiver(new yourbroadcast, Intenfilter i);

}
當然你也在其他如onstart里注冊，看你的業務是什麼要求了。取消注冊在對應的方法里。
一般是對應的，oncreate-onDestroy onstart-onstop

另一種就是xml文件注冊了。

Ⅹ android 的廣播有幾種類型分別如何使用

我剛才幫你查詢了這個，一共分為六類的，直接打開就行了。