huobengluantiao8

浏览: 1029103 次

最近访客更多访客>>

u012363178

wangyy

lsmh2000

shlpyy

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (1470)

社区版块

存档分类

android Application Component研究之BroadcastReceiver

本文为原创文章，欢迎转载！转载时请注明出处：http://blog.csdn.net/windskier

这篇文章开始从framework的角度来研究一下android四大控件最后一个控件BroadcastReceiver的机制与原理，BroadcastReceiver 字面意思就是广播接收器，它能接收来自于系统的以及其他appliaction的广播消息，是android中非常重要的一个component。

1.BroadcastReceiver注册

BroadcastReceiver的注册有两种方式，一种是通过Context.registerReceiver()方法来进行动态注册，或者通过在AndroidManifest.xml中进行静态注册。AMS对两种不同注册方式的Receiver有不同的管理方式。静态注册就不用说了，静态注册的receiver的管理是有PMS负责的，而AMS则需要对动态注册的receiver注册和管理。下面就研究一下AMS对receiver的动态管理过程。

1.1ReceiverDispatcher

同Service一样，LoadedApk为receiver提供了一个ReceiverDispatcher类型，类似于Service管理时的ServiceDispatcher类型，对于每个要注册的receiver，LoadedApk会为其创建一个ReceiverDispatcher。从其名称来看，ReceiverDispatcher就是向receiver dispatch广播信息，下面简单介绍一下这个类型存在的价值，广播信息是经由AMS进行分发管理的，因此需要为AMS向receive分发广播消息设计一个接口，通过这个接口可以实现receiver与AMS的IPC通信，BroadcastReceiver 本身并不是一个IBinder接口，因此需要单独设计一个，这个接口就是InnerReceiver，InnerReceiver一方面与AMS进行IPC通信，另一方面还需要与receiver进行交互，为了区分IPC的接口方法和与receiver的交互接口，这里需要定义了另外一个类型ReceiverDispatcher，这就是ReceiverDispatcher产生的原因。

@ContextImpl.java

    private Intent registerReceiverInternal(BroadcastReceiver receiver,
            IntentFilter filter, String broadcastPermission,
            Handler scheduler, Context context) {
        IIntentReceiver rd = null;
        if (receiver != null) {
            if (mPackageInfo != null && context != null) {
                if (scheduler == null) {
                    scheduler = mMainThread.getHandler();
                }
                rd = mPackageInfo.getReceiverDispatcher(
                    receiver, context, scheduler,
                    mMainThread.getInstrumentation(), true);
            } else {
                if (scheduler == null) {
                    scheduler = mMainThread.getHandler();
                }
                rd = new LoadedApk.ReceiverDispatcher(
                        receiver, context, scheduler, null, true).getIIntentReceiver();
            }
        }
        try {
            return ActivityManagerNative.getDefault().registerReceiver(
                    mMainThread.getApplicationThread(), mBasePackageName,
                    rd, filter, broadcastPermission);
        } catch (RemoteException e) {
            return null;
        }
    }

1.2InnerReceiver

上面一节已经介绍了InnerReceiver存在的意义，它其实是一个IInterface，用于AMS和Receiver之间的IPC通信，InnerReceiver实现了接口IIntentReceiver。

@IIntentReceiver.aidl

oneway interface IIntentReceiver {
    void performReceive(in Intent intent, int resultCode,
            String data, in Bundle extras, boolean ordered, boolean sticky);
}

1.3sticky broadcast

有这么一种broadcast，在发送并经过AMS分发给对应的receiver后，这个broadcast并不会被丢弃，而是保存在AMS中，当有新的需要动态注册的receiver请求AMS注册时，如果这个receiver能够接收这个broadcast，那么AMS会将在receiver注册成功之后，马上向receiver发送这个broadcast。这种broadcast我们称之为stickybroadcast。

当receiver注册成功后，AMS会将合适的stickybroadcast作为方法registerReceiver()返回给Component，以便通知Component当前是否有stickybroadcast存在。

public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter)

如果有多个符合receiver条件的stickybroadcast的话，那么AMS将会只返回一个时间较早的stickybroadcast，并且会将这些所有满足要求的stickybroadcast均发送给reciever，交由receiver去处理。stickybroadcast的发送于取消通过方法sendStickyBroadcast()/sendStickyOrderedBroadcast() 以及removeStickyBroadcast()来控制。

registerReceiver()@ActivityManagerService.java

            // Enqueue broadcasts for all existing stickies that match
            // this filter.
            if (allSticky != null) {
                ArrayList receivers = new ArrayList();
                receivers.add(bf);

                int N = allSticky.size();
                for (int i=0; i<N; i++) {
                    Intent intent = (Intent)allSticky.get(i);
                    BroadcastRecord r = new BroadcastRecord(intent, null,
                            null, -1, -1, null, receivers, null, 0, null, null,
                            false, true, true);
                    if (mParallelBroadcasts.size() == 0) {
                        scheduleBroadcastsLocked();
                    }
                    mParallelBroadcasts.add(r);
                }
            }

1.4 动态注册receiver的注册管理

receiver的动态注册过程就需要掌握以上几个知识点就可以了，真正的注册名其曰注册，其实质就是将其交由AMS去管理，因此下面我们来分析研究一下AMS是通过哪些数据结构来管理receiver的。掌握了这些数据结构的含义以及它们之间的相互关系之后，我们就明白了整个需注册receiver的注册过程了。

1.4.1 BroadcastFilter

对于每个注册过程，由两部分组成，一部分是是BroadcastReceiver，另一部分是IntentFilter，BroadcastReceiver通过IntentFilter来指定要接收的Intent BroadCast。而BroadcastFilter则是继承自IntentFilter，它记录了当前需注册的Receiver的IntentFilter信息。因此每一组BroadcastReceiver和IntentFilter对应一次注册过程，每个注册过程即是一个BroadcastReceiver向AMS指示一个Intent Broadcast的需求，如果有多个Intent Broadcast需求，BroadcastReceiver需要向AMS进行多次注册。

1.4.2 ReceiverList

ReceiverList继承自Arraylist，并且该Arraylist是以BroadcastFilter为元素，同时我们知道BroadcastReceiver的注册过程的二要素是BroadcastReceiver和IntentFilter，对于同一个BroadcastReceiver可能会接收多个Intent Broadcast，因此每个IIntentReceiver可能会对应多个BroadcastFilter，这也是设计ReceiverList这个Arraylist的主要目的。

1.4.3 mReceiverResolver

mReceiverResolver的定义如下：

    final IntentResolver<BroadcastFilter, BroadcastFilter> mReceiverResolver
            = new IntentResolver<BroadcastFilter, BroadcastFilter>()

mReceiverResolver是一个IntentResolver类型的对象，通过它AMS可以将BroadcastFilter按照不同的元素，如action、data、category，进行管理，这样的话在AMS收到broadcast之后，会根据这个broadcast的Intent的元素去query mReceiverResolver，获取对应的BroadcastFilter。

既然mReceiverResolver实现了对BroadcastFilter的管理，那么前面的ReceiverList类型存在的意义是什么呢？ mReceiverResolver和ReceiverList的关系其实并不冲突，AMS可以通过mReceiverResolver来获得可以接收发来的Broadcast的所有的BroadcastFilter。通过上面的类型关系图，我们可以看出BroadcastFilter中反向链接到自己所处的ReceiverList，看见两者之间的关系并不是对立的，而是适用于AMS接收分发过程的不同阶段。

1.4.4 BroadcastRecord

就向前面介绍的android中的其他几大component一样，BroadReceiver在被处理时同样是通过一个BroadcastRecord的Record类型来进行管理的，BroadcastRecord只有在AMS在处理分发Broadcast时才去创建，它记录着每个Broadcast的信息，在Receiver的过程并不涉及Broadcast。

2. Broadcast的发送过程

上面第一节介绍了Receiver的动态注册过程，那么接下来我们分析一下Broadcast的发送处理。

2.1 Broadcast的发送方式

Broadcast根据不同的需求有多种不同的发送方式，下面来分析一下具体有几种发送方式。下面的表格列出了application几种不同的发送方式以及不同方式对应的方法。

不同的发送方式	对应的方法
普通模式	sendBroadcast(Intent intent)
Broadcast sender 指定了receiver的permission，只有符合这个permission的receiver才能接收这个Broadcast	sendBroadcast(Intent intent, String receiverPermission)
要求符合要求的所有receiver (包括动态注册和静态注册的receiver)按照优先级顺序来接收这个Broadcast	sendOrderedBroadcast(Intent intent, String receiverPermission)
某些情况下，Broadcast sender在发出Broadcast之后，向AMS指定一个resultReceiver，期望所有的receiver接收并处理完Broadcast之后，将在各个receiver间传递的resultExtras返回给resultReceiver。这个resultExtras既可以由sender指定，也可以由某一个receiver指定，一般情况下只要receiver需要向sender返回数据，则可以通过这个resultExtras	sendOrderedBroadcast(Intent intent,String receiverPermission, BroadcastReceiver resultReceiver,Handler scheduler, int initialCode, String initialData,Bundle initialExtras)
Sticky Broadcast。前面已描述	sendStickyBroadcast(Intent intent); endStickyOrderedBroadcast(Intent intent,BroadcastReceiver resultReceiver,Handler scheduler, int initialCode, String initialData,Bundle initialExtras)

2.2 Package manager Broadcast

AMS在处理收到的Broadcast时，需要对一些特殊的Broadcast做特殊处理，比如Package manager发来的关于Package移除、增加、修改等操作的，由于android系统允许user在package内部component在运行的情况下进行如上所述的操作，因此每当发生这些操作时，PM则会通过发送Broadcast的方式通知AMS进行属于AMS范畴的一些操作，如当PM移除某个Package的时候，要求AMS停止这个Package相关的所有Component等。

同样的，关于timezone的一些事件也是通过Broadcast的方式通知AMS，这里就不再分析。

2.3 Protected Broadcast

2.3.1 Protected Broadcast作用

从其名称看即是受保护的Broadcast，它声明在AndroidManifest.xml的一级节点中，对应的节点名称为<protected-broadcast>，一般情况下，protected broadcast定义的是系统级别的broadcast，通常只能被系统服务或者appliaction发送，下面我们分析那些情况下才能发送protected broadcast。

首先看一下protectedbroadcast的定义，它的主要元素就是一个action name，这些action只能被系统发送，我们可以想象一下，系统级别的broadcast可以不受限制的被所有的应用发送的后果，那将是非常严重的，不可想象的。因此从安全性的角度出发，android为了保证这些系统级别的broadcast不被第三方的应用滥发，提出了这个protected broadcast的概念。

<protected-broadcast 
android:name=[action String] />

Android规定了一些可以发送protected broadcast的进程，

● android:sharedUserId="android.uid.system"

● android:sharedUserId="android.uid.phone"

● android:sharedUserId="android.uid.shell"

● 设置android:persistent的appliaction。

对于其他不符合上述四条的进程发送broadcast时，AMS回去检查该是否是protected broadcast规定的action，如果是，那么将不允许这个broadcast发送。具体代码如下:

broadcastIntentLocked()@ActivityManagerService.java

        if (callingUid == Process.SYSTEM_UID || callingUid == Process.PHONE_UID
                || callingUid == Process.SHELL_UID || callingUid == 0) {
            // Always okay.
        } else if (callerApp == null || !callerApp.persistent) {
            try {
                if (AppGlobals.getPackageManager().isProtectedBroadcast(
                        intent.getAction())) {
                    String msg = "Permission Denial: not allowed to send broadcast "
                            + intent.getAction() + " from pid="
                            + callingPid + ", uid=" + callingUid;
                    Slog.w(TAG, msg);
                    throw new SecurityException(msg);
                }
            } catch (RemoteException e) {
                Slog.w(TAG, "Remote exception", e);
                return BROADCAST_SUCCESS;
            }
        }

2.3.2 Protected Broadcast定义

上面介绍了Protected Broadcast的作用，知道这类Broadcast一般是系统发送的，那么我们再来分析一下哪些AndroidManifest.xml中可以定义Protected Broadcast。我们可容易的想到，Protected Broadcast也不是随随便便定义在一个application的AndroidManifest.xml。

只有系统appliaction才能在其AndroidManifest.xml中定义Protected Broadcast，系统appliaction包括/system/framework、/system/app、vendor/app下的package，因此设备中安装的第三方apk中如果定义了Protected Broadcast，那么这个Protected Broadcast将不生效。下面代码是对<protected-broadcast>属性的解析，可以看出解析之后会检查当前的package是否为系统package，如果是则提取这个ProtectedBroadcast。

parsePackage ()@PackageParser.java

          } else if (tagName.equals("protected-broadcast")) {
                sa = res.obtainAttributes(attrs,
                        com.android.internal.R.styleable.AndroidManifestProtectedBroadcast);

                // Note: don't allow this value to be a reference to a resource
                // that may change.
                String name = sa.getNonResourceString(
                       com.android.internal.R.styleable.AndroidManifestProtectedBroadcast_name);

                sa.recycle();

                if (name != null && (flags&PARSE_IS_SYSTEM) != 0) {
                    if (pkg.protectedBroadcasts == null) {
                        pkg.protectedBroadcasts = new ArrayList<String>();
                    }
                    if (!pkg.protectedBroadcasts.contains(name)) {
                        pkg.protectedBroadcasts.add(name.intern());
                    }
                }

                XmlUtils.skipCurrentTag(parser);
                
            }

2.4 查找receiver

这一节来分析一下AMS在收到Broadcast之后，查找匹配的receiver来向其分发这个Broadcast。前面说过receiver有两种，一种是动态注册的，另一种则是预先定义静态注册的。不同类型的receiver有不同的管理方式，动态注册的receiver从上面章节中介绍的IntentResolver mReceiverResolver中获取；静态注册的receiver则是从PM中获取。

2.5 Broadcast分发模式

2.1中介绍了几种android中常用的Broadcast发送方式，sticky模式上面的文章中已经做了介绍，下面主要介绍一些ordered模式和非ordered模式下，不同的分发模式。

2.5.1 非ordered模式

默认情况下，Broadcast发送方式是非order模式的，这里所说的ordered和非ordered模式是针对动态注册的receiver来说的，而对于静态注册的receiver则一律是ordered模式。非ordered模式下，AMS对Broadcast的分发是一种非同步的模式，也就是说，不待一个receiver处理完Broadcast，就会将Broadcast分发给下一个receiver。

2.5.2 ordered模式

ordered模式下，动态注册的receiver将会采取和静态注册的receiver相同的处理模式，类似于一种同步模式，AMS会等待一个reciever处理完这个Broadcast，才会将Broadcast分发给下一个receiver。这种模式下，receiver的处理有了先后顺序，因此必须考虑如何布置这个先后顺序，这里按照优先级的顺序来给receiver的处理顺序进行排序。

对于动态注册的receiver，可以在其IntentFilter类型中定义它的优先级；而对于静态注册的receiver，同样的我们可以在其<intent-filter>属性中定义它的优先级。根据receiver优先级从高到低进行排序，如果动态的注册的和静态注册的receive处在相同的优先级，那么将优先处理动态注册的receiver。

broadcastIntentLocked()@ActivityManagerService.java

           int NT = receivers != null ? receivers.size() : 0;
            int it = 0;
            ResolveInfo curt = null;
            BroadcastFilter curr = null;
            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);
                    ir++;
                    curr = null;
                    it++;
                    NT++;
                } else {
                    // Skip to the next ResolveInfo in the final list.
                    it++;
                    curt = null;
                }
            }
        }
        while (ir < NR) {
            if (receivers == null) {
                receivers = new ArrayList();
            }
            receivers.add(registeredReceivers.get(ir));
            ir++;
        }

2.6 Broadcast分发过程

Broadcast分发过程是一个异步过程，AMS在收到Broadcast之后，会根据不同类型的receiver，按照Broadcast发送发指定的发送模式进行分发，现在我们来分析一下Broadcast分发过程。

AMS向自己的消息队列发送消息BROADCAST_INTENT_MSG对所有的receiver进行分发操作，所有的分发操作由方法processNextBroadcast()来实现，因此这一部分我们着重分析一下这个方法中的实现过程。

2.6.1 非ordered分发

上面已经对ordered模式和非ordered模式进行了简单介绍，这里不再多介绍了。对于非ordered模式的分发过程，AMS则会将Broadcast直接分发给符合要求的receiver的进程的消息队列，这种分发的方式可以视作一种异步方式，也可以看作是将该Broadcast同时分发给符合要求的动态注册的receiver，上面章节中我们分析过只有动态注册的receiver才会有ordered和非ordered模式之分，而静态注册的reciever则无此之分，一概视为ordered模式。

2.6.2 ordered分发

满足ordered模式的receiver，AMS对其进行Broadcast分发时是一种同步的过程，只有前一个receiver处理完该Broadcast之后，并且receiver通知AMS该Broadcast已经处理结束，此时AMS才能将Broadcast分发给下一个receiver去处理，如下图所示：

我们知道需要ordered分发的receiver既包括动态注册的receiver，又包括静态注册的receiver，但是AMS向两种不同的注册方式的receiver分发Broadcast的方式有不尽相同，但是最基本的发送及处理过程是按照上面的图示进行的，两种注册方式具体的分发和处理内容如下图所示:

2.7 Broadcast处理超时

AMS向各个BroadcastReceiver分发Broadcast过程以及BroadcastReceiver处理Broadcast的过程并不是无限期的，为了保证系统的响应性和稳定性，android给这个过程设置了固定期限，有Broadcast相关的有两种固定期限，这两种期限均是针对Ordered模式的Receiver，而对于非Ordered模式的Receiver则不需要考虑这个时限，下面来一一介绍一下。

2.7.1 BroadcastRecord处理总时长

针对每个BroadcastRecord的处理，均会设置一个总时长，这个总时长是指所有符合BroadcastRecord条件的receiver处理完这个Broadcast的总时长的上限。也就是说如果满足条件的所有的Receiver均已经接收并处理完了这个Broadcast的时刻，不能超过规定的总时长，总时长跟满足条件的Receiver总个数有关系，如下面代码所示：

processNextBroadcast ()@ActivityManagerService.java

int numReceivers = (r.receivers != null) ? r.receivers.size() : 0;
if (mProcessesReady && r.dispatchTime > 0) {
    long now = SystemClock.uptimeMillis();
    if ((numReceivers > 0) &&
            (now > r.dispatchTime + (2*BROADCAST_TIMEOUT*numReceivers))) {
        Slog.w(TAG, "Hung broadcast discarded after timeout failure:"
                + " now=" + now
                + " dispatchTime=" + r.dispatchTime
                + " startTime=" + r.receiverTime
                + " intent=" + r.intent
                + " numReceivers=" + numReceivers
                + " nextReceiver=" + r.nextReceiver
                + " state=" + r.state);
        broadcastTimeoutLocked(false); // forcibly finish this broadcast
        forceReceive = true;
        r.state = BroadcastRecord.IDLE;
    }
}

2.7.2 BroadcastReceiver处理时长

除了设置针对一个BroadcastRecord的处理的总时长外，android针对每个Receiver的处理时长也做了一个时限设定，保证每一个的Receiver的处理时长不超过规定时长，具体如下面代码所示：

processNextBroadcast ()@ActivityManagerService.java

if (! mPendingBroadcastTimeoutMessage) {
    long timeoutTime = r.receiverTime + BROADCAST_TIMEOUT;
    if (DEBUG_BROADCAST) Slog.v(TAG,
            "Submitting BROADCAST_TIMEOUT_MSG for " + r + " at " + timeoutTime);
    setBroadcastTimeoutLocked(timeoutTime);
}

如果上述2种时长存在超时的话，AMS将会抛出ANR, 向user报告当前的Receiver在处理Broadcast时存在无响应状况或者响应时间过长等状况。

broadcastTimeoutLocked()@ActivityManagerService.java

if (anrMessage != null) {
    // Post the ANR to the handler since we do not want to process ANRs while
    // potentially holding our lock.
    mHandler.post(new AppNotResponding(app, anrMessage));
}

分享到：

【每日听力活动训练】第十二期 0405 | 具有跨浏览器兼容的事件处理javascript脚本

2012-04-05 22:34
浏览 769
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

android Application Component研究之BroadcastReceiver

1.BroadcastReceiver注册

1.1ReceiverDispatcher

1.2InnerReceiver

1.3sticky broadcast

1.4 动态注册receiver的注册管理

1.4.1 BroadcastFilter

1.4.2 ReceiverList

1.4.3 mReceiverResolver

1.4.4 BroadcastRecord

2. Broadcast的发送过程

2.1 Broadcast的发送方式

2.2 Package manager Broadcast

2.3 Protected Broadcast

2.3.1 Protected Broadcast作用

2.3.2 Protected Broadcast定义

2.4 查找receiver

2.5 Broadcast分发模式

2.5.1 非ordered模式

2.5.2 ordered模式

2.6 Broadcast分发过程

2.6.1 非ordered分发

2.6.2 ordered分发

2.7 Broadcast处理超时

2.7.1 BroadcastRecord处理总时长

2.7.2 BroadcastReceiver处理时长

评论

发表评论

相关推荐

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

android Application Component研究之BroadcastReceiver

1.BroadcastReceiver注册

1.1ReceiverDispatcher

1.2InnerReceiver

1.3sticky broadcast

1.4 动态注册receiver的注册管理

1.4.1 BroadcastFilter

1.4.2 ReceiverList

1.4.3 mReceiverResolver

1.4.4 BroadcastRecord

2. Broadcast的发送过程

2.1 Broadcast的发送方式

2.2 Package manager Broadcast

2.3 Protected Broadcast

2.3.1 Protected Broadcast作用

2.3.2 Protected Broadcast定义

2.4 查找receiver

2.5 Broadcast分发模式

2.5.1 非ordered模式

2.5.2 ordered模式

2.6 Broadcast分发过程

2.6.1 非ordered分发

2.6.2 ordered分发

2.7 Broadcast处理超时

2.7.1 BroadcastRecord处理总时长

2.7.2 BroadcastReceiver处理时长

评论

发表评论

相关推荐

最近访客更多访客>>