博客源址:说说PendingIntent的内部机制
博客时间:2014-01-30 17:35
1 概述
在Android中,我们常常使用PendingIntent来表达一种“留待日后处理”的意思。从这个角度来说,PendingIntent可以被理解为一种特殊的异步处理机制。不过,单就命名而言,PendingIntent其实具有一定误导性,因为它既不继承于Intent,也不包含Intent,它的核心可以粗略地汇总成四个字——“异步激发”。
很明显,这种异步激发常常是要跨进程执行的。比如说A进程作为发起端,它可以从系统“获取”一个PendingIntent,然后A进程可以将PendingIntent对象通过binder机制“传递”给B进程,再由B进程在未来某个合适时机,“回调”PendingIntent对象的send()动作,完成激发。
在Android系统中,最适合做集中性管理的组件就是AMS(Activity Manager Service)啦,所以它义不容辞地承担起管理所有PendingIntent的职责。这样我们就可以画出如下示意图:
注意其中的第4步“递送相应的intent”。这一步递送的intent是从何而来的呢?简单地说,当发起端获取PendingIntent时,其实是需要同时提供若干intent的。这些intent和PendingIntent只是配套的关系,而不是聚合的关系,它们会被缓存在AMS中。日后,一旦处理端将PendingIntent的“激发”语义传递到AMS,AMS就会尝试找到与这个PendingIntent对应的若干intent,并递送出去。
当然,以上说的只是大概情况,实际的技术细节会更复杂一点儿。下面我们就来谈谈细节。
2 PendingIntent的技术细节
2.1 发起端获取PendingIntent
我们先要理解,所谓的“发起端获取PendingIntent”到底指的是什么。难道只是简单new一个PendingIntent对象吗?当然不是。此处的“获取”动作其实还含有向AMS“注册”intent的语义。
在PendingIntent.java文件中,我们可以看到有如下几个比较常见的静态函数:
- public static PendingIntent getActivity(Context context, int requestCode, Intent intent, int flags)
- public static PendingIntent getBroadcast(Context context, int requestCode, Intent intent, int flags)
- public static PendingIntent getService(Context context, int requestCode, Intent intent, int flags)
- public static PendingIntent getActivities(Context context, int requestCode, Intent[] intents, int flags)
- public static PendingIntent getActivities(Context context, int requestCode, Intent[] intents, int flags, Bundle options)
它们就是我们常用的获取PendingIntent的动作了。
坦白说,这几个函数的命名可真不怎么样,所以我们简单解释一下。上面的getActivity()的意思其实是,获取一个PendingIntent对象,而且该对象日后激发时所做的事情是启动一个新activity。也就是说,当它异步激发时,会执行类似Context.startActivity()那样的动作。相应地,getBroadcast()和getService()所获取的PendingIntent对象在激发时,会分别执行类似Context..sendBroadcast()和Context.startService()这样的动作。至于最后两个getActivities(),用得比较少,激发时可以启动几个activity。
我们以getActivity()的代码来说明问题:
public
static
PendingIntent getActivity(Context context,
int
requestCode,
Intent intent,
int
flags, Bundle options)
{
String packageName = context.getPackageName();
String resolvedType = intent !=
null
?
intent.resolveTypeIfNeeded(context.getContentResolver()) :
null
;
try
{
intent.setAllowFds(
false
);
IIntentSender target = ActivityManagerNative.getDefault().getIntentSender(
ActivityManager.INTENT_SENDER_ACTIVITY, packageName,
null
,
null
, requestCode,
new
Intent[] { intent },
resolvedType !=
null
?
new
String[] { resolvedType } :
null
,
flags, options);
return
target !=
null
?
new
PendingIntent(target) :
null
;
}
catch
(RemoteException e)
{}
return
null
;
}
其中那句new PendingIntent(target)创建了PendingIntent对象,其重要性自不待言。然而,这个对象的内部核心其实是由上面那个getIntentSender()函数得来的。而这个IIntentSender核心才是我们真正需要关心的东西。
说穿了,此处的IIntentSender对象是个binder代理,它对应的binder实体是AMS中的PendingIntentRecord对象。PendingIntent对象构造之时,IIntentSender代理作为参数传进来,并记录在PendingIntent的mTarget域。日后,当PendingIntent执行异步激发时,其内部就是靠这个mTarget域向AMS传递语义的。
我们前文说过,PendingIntent常常会经由binder机制,传递到另一个进程去。而binder机制可以保证,目标进程得到的PendingIntent的mTarget域也是合法的IIntentSender代理,而且和发起端的IIntentSender代理对应着同一个PendingIntentRecord实体。示意图如下:
2.2 AMS里的PendingIntentRecord
那么PendingIntentRecord里又有什么信息呢?它的定义截选如下:
class
PendingIntentRecord extends IIntentSender.Stub
{
final ActivityManagerService owner;
final Key key;
// 最关键的key域
final
int
uid;
final WeakReference<PendingIntentRecord>
ref
;
boolean sent =
false
;
boolean canceled =
false
;
String stringName;
. . . . . .
}
请注意其中那个key域。这里的Key是个PendingIntentRecord的内嵌类,其定义截选如下:
final
static
class
Key
{
final
int
type;
final String packageName;
final ActivityRecord activity;
final String who;
final
int
requestCode;
final Intent requestIntent;
// 注意!
final String requestResolvedType;
final Bundle options;
Intent[] allIntents;
// 注意!记录了当初获取PendingIntent时,用户所指定的所有intent
String[] allResolvedTypes;
final
int
flags;
final
int
hashCode;
. . . . . .
. . . . . .
}
请注意其中的allIntents[]数组域以及requestIntent域。前者记录了当初获取PendingIntent时,用户所指定的所有intent(虽然一般情况下只会指定一个intent,但类似getActivities()这样的函数还是可以指定多个intent的),而后者可以粗浅地理解为用户所指定的那个intent数组中的最后一个intent。现在大家应该清楚异步激发时用到的intent都存在哪里了吧。
Key的构造函数截选如下:
Key(
int
_t, String _p, ActivityRecord _a, String _w,
int
_r, Intent[] _i, String[] _it,
int
_f, Bundle _o)
{
type = _t;
packageName = _p;
activity = _a;
who = _w;
requestIntent = _i !=
null
? _i[_i.length-1] :
null
;
// intent数组中的最后一个
requestCode = _r;
requestResolvedType = _it != null ? _it[_it.length-1] : null;
allIntents = _i;
// 所有intent
allResolvedTypes = _it;
flags = _f;
. . . . . .
options = _o;
}
Key不光承担着记录信息的作用,它还承担“键值”的作用。
2.3 AMS中的PendingIntentRecord总表
在AMS中,管理着系统中所有的PendingIntentRecord节点,所以需要把这些节点组织成一张表:
final HashMap<PendingIntentRecord.Key, WeakReference<PendingIntentRecord>>
mIntentSenderRecords
这张哈希映射表的键值类型就是刚才所说的PendingIntentRecord.Key。
以后每当我们要获取PendingIntent对象时,PendingIntent里的mTarget是这样得到的:AMS会先查mIntentSenderRecords表,如果能找到符合的PendingIntentRecord节点,则返回之。如果找不到,就创建一个新的PendingIntentRecord节点。因为PendingIntentRecord是个binder实体,所以经过binder机制传递后,客户进程拿到的就是个合法的binder代理。如此一来,前文的示意图可以进一步修改成下图:
2.4 AMS里的getIntentSender()函数
现在,我们回过头继续说前文的getActivity(),以及其调用的getIntentSender()。我们先列一遍getActivity()的原型:
public
static
PendingIntent getActivity(Context context,
int
requestCode,
Intent intent,
int
flags, Bundle options)
- context参数是调用方的上下文。
- requestCode是个简单的整数,起区分作用。
- intent是异步激发时将发出的intent。
- flags可以包含一些既有的标识,比如FLAG_ONE_SHOT、FLAG_NO_CREATE、FLAG_CANCEL_CURRENT、FLAG_UPDATE_CURRENT等等。不少同学对这个域不是很清楚,我们后文会细说。
- options可以携带一些额外的数据。
getActivity()的代码很简单,其参数基本上都传给了getIntentSender()。
IIntentSender target = ActivityManagerNative.getDefault().getIntentSender(. . . . . .)
getIntentSender()的原型大体是这样的:
public
IIntentSender getIntentSender(
int
type,
String packageName, IBinder token, String resultWho,
int
requestCode, Intent[] intents, String[] resolvedTypes,
int
flags, Bundle options) throws RemoteException;
其参数比getActivity()要多一些,我们逐个说明。
type参数表明PendingIntent的类型。getActivity()和getActivities()动作里指定的类型值是INTENT_SENDER_ACTIVITY,getBroadcast()和getService()和动作里指定的类型值分别是INTENT_SENDER_BROADCAST和INTENT_SENDER_SERVICE。另外,在Activity.java文件中,我们还看到一个createPendingResult()函数,这个函数表达了发起方的activity日后希望得到result回馈的意思,所以其内部调用getIntentSender()时指定的类型值为INTENT_SENDER_ACTIVITY_RESULT。
packageName参数表示发起端所属的包名。
token参数是个指代回馈目标方的代理。这是什么意思呢?我们常用的getActivity()、getBroadcast()和getService()中,只是把这个参数简单地指定为null,表示这个PendingIntent激发时,是不需要发回什么回馈的。不过当我们希望获取类型为INTENT_SENDER_ACTIVITY_RESULT的PendingIntent时,就需要指定token参数了。具体可参考createPendingResult()的代码:
public
PendingIntent createPendingResult(
int
requestCode, Intent data,
int
flags)
{
String packageName = getPackageName();
try
{
data.setAllowFds(
false
);
IIntentSender target = ActivityManagerNative.getDefault().getIntentSender(
ActivityManager.INTENT_SENDER_ACTIVITY_RESULT,
packageName,
mParent ==
null
? mToken : mParent.mToken,
mEmbeddedID, requestCode,
new
Intent[] { data },
null
, flags,
null
);
return
target !=
null
?
new
PendingIntent(target) :
null
;
}
catch
(RemoteException e) {
// Empty
}
return
null
;
}
看到了吗?传入的token为Activity的mToken或者其mParent.mToken。说得简单点儿,AMS内部可以根据这个token找到其对应的ActivityRecord,日后当PendingIntent激发时,AMS可以根据这个ActivityRecord确定出该向哪个目标进程的哪个Activity发出result语义。
resultWho参数和token参数息息相关,一般也是null啦。在createPendingResult()中,其值为Activity的mEmbeddedID字符串。
requestCode参数是个简单的整数,可以在获取PendingIntent时由用户指定,它可以起区分的作用。
intents数组参数是异步激发时希望发出的intent。对于getActivity()、getBroadcast()和getService()来说,都只会指定一个intent而已。只有getActivities()会尝试一次传入若干intent。
resolvedTypes参数基本上和intent是相关的。一般是这样得到的:
String resolvedType = intent !=
null
? intent.resolveTypeIfNeeded(
context.getContentResolver()) :
null
;
这个值常常和intent内部的mData URI有关系,比如最终的值可能是URI对应的MIME类型。
flags参数可以指定PendingIntent的一些行为特点。它的取值是一些既有的比特标识的组合。目前可用的标识有:FLAG_ONE_SHOT、FLAG_NO_CREATE、FLAG_CANCEL_CURRENT、FLAG_UPDATE_CURRENT等等。有时候,flags中还可以附带若干FILL_IN_XXX标识。我们把常见的标识定义列举如下:
【PendingIntent中】
public
static
final
int
FLAG_ONE_SHOT = 1<<30;
public
static
final
int
FLAG_NO_CREATE = 1<<29;
public
static
final
int
FLAG_CANCEL_CURRENT = 1<<28;
public
static
final
int
FLAG_UPDATE_CURRENT = 1<<27;
【Intent中】
public
static
final
int
FILL_IN_ACTION = 1<<0;
public
static
final
int
FILL_IN_DATA = 1<<1;
public
static
final
int
FILL_IN_CATEGORIES = 1<<2;
public
static
final
int
FILL_IN_COMPONENT = 1<<3;
public
static
final
int
FILL_IN_PACKAGE = 1<<4;
public
static
final
int
FILL_IN_SOURCE_BOUNDS = 1<<5;
public
static
final
int
FILL_IN_SELECTOR = 1<<6;
public
static
final
int
FILL_IN_CLIP_DATA = 1<<7;
这些以FILL_IN_打头的标志位,主要是在intent对象的fillIn()函数里起作用:
public int fillIn(Intent other, int flags)
我们以FILL_IN_ACTION为例来说明,当我们执行类似srcIntent.fillIn(otherIntent, ...)的句子时,如果otherIntent的mAction域不是null值,那么fillIn()会在以下两种情况下,用otherIntent的mAction域值为srcIntent的mAction域赋值:
其他FILL_IN_标志位和FILL_IN_ACTION的处理方式类似,我们不再赘述。
options参数可以携带一些额外数据。
2.4.1 getIntentSender()函数
getIntentSender()函数摘录如下:
public
IIntentSender getIntentSender(
int
type, String packageName,
IBinder token, String resultWho,
int
requestCode, Intent[] intents,
String[] resolvedTypes,
int
flags, Bundle options)
{
. . . . . .
// 先判断intents数组,可以用伪代码checkIntents(intents)来表示
// checkIntents(intents);
. . . . . .
int
callingUid = Binder.getCallingUid();
. . . . . .
if
(callingUid != 0 && callingUid != Process.SYSTEM_UID)
{
int
uid = AppGlobals.getPackageManager().getPackageUid(packageName,
UserId.getUserId(callingUid));
if
(!UserId.isSameApp(callingUid, uid))
{
. . . . . .
throw
new
SecurityException(msg);
}
}
return
getIntentSenderLocked(type, packageName, Binder.getOrigCallingUid(),
. . . . . .
token, resultWho, requestCode, intents, resolvedTypes, flags, options);
}
. . . . . .
getIntentSender()函数中有一段逐条判断intents[]的代码,我用伪代码checkIntents(intents)来表示,这部分对应的实际代码如下:
for
(
int
i=0; i<intents.length; i++)
{
Intent intent = intents[i];
if
(intent !=
null
)
{
if
(intent.hasFileDescriptors())
{
throw
new
IllegalArgumentException(
"File descriptors passed in Intent"
);
}
if
(type == ActivityManager.INTENT_SENDER_BROADCAST &&
(intent.getFlags()&Intent.FLAG_RECEIVER_BOOT_UPGRADE) != 0)
{
throw
new
IllegalArgumentException(
"Can't use FLAG_RECEIVER_BOOT_UPGRADE here"
);
}
intents[i] =
new
Intent(intent);
}
}
这段代码说明在获取PendingIntent对象时,intent中是不能携带文件描述符的。而且如果这个PendingIntent是那种要发出广播的PendingIntent,那么intent中也不能携带FLAG_RECEIVER_BOOT_UPGRADE标识符。“BOOT_UPGRADE”应该是“启动并升级”的意思,它不能使用PendingIntent。
getIntentSender()中最核心的一句应该是调用getIntentSenderLocked()的那句。
2.4.2 getIntentSenderLocked()函数
getIntentSenderLocked()的代码截选如下:
【frameworks/base/services/java/com/android/server/am/ActivityManagerService.java】
IIntentSender getIntentSenderLocked(
int
type, String packageName,
int
callingUid,
IBinder token, String resultWho,
int
requestCode, Intent[] intents,
String[] resolvedTypes,
int
flags,
Bundle options)
{
. . . . . .
// 如果是INTENT_SENDER_ACTIVITY_RESULT类型,那么要判断token所
// 代表的activity是否还在activity栈中
. . . . . .
// 整理flags中的信息
. . . . . .
PendingIntentRecord.Key key =
new
PendingIntentRecord.Key(type, packageName,
activity, resultWho,
requestCode, intents,
resolvedTypes, flags, options);
// 尽力从哈希映射表中查找key对应的PendingIntentRecord,如果找不到就创建一个新的节点。
WeakReference<PendingIntentRecord>
ref
;
ref
= mIntentSenderRecords.get(key);
PendingIntentRecord rec =
ref
!=
null
?
ref
.get() :
null
;
if
(rec !=
null
)
{
// 找到了匹配的PendingIntent,现在考虑要不要更新它,或者取消它。
if
(!cancelCurrent)
{
if
(updateCurrent)
{
// 如果明确指定了FLAG_UPDATE_CURRENT,那么更新找到的节点
if
(rec.key.requestIntent !=
null
) {
rec.key.requestIntent.replaceExtras(intents !=
null
?
intents[intents.length - 1] :
null
);
}
if
(intents !=
null
) {
intents[intents.length-1] = rec.key.requestIntent;
rec.key.allIntents = intents;
}
else
{
rec.key.allResolvedTypes = resolvedTypes;
rec.key.allIntents = null;
rec.key.allResolvedTypes =
null
;
}
}
// 凡是能找到对应的节点,而且又不取消该节点的,那么就return这个节点
return
rec;
}
// 如果PendingIntent的标志中带有FLAG_CANCEL_CURRENT,则从哈希映射表中删除之
rec.canceled =
true
;
mIntentSenderRecords.remove(key);
}
if
(noCreate)
{
// 如果明确表示了不创建新节点,也就是说标志中带有FLAG_NO_CREATE,
// 那么不管是不是Cancel了PendingIntent,此时一概直接返回。
return
rec;
}
// 从哈希映射表中找不到,而且又没有写明FLAG_NO_CREATE,此时创建一个新节点
rec = new PendingIntentRecord(this, key, callingUid);
mIntentSenderRecords.put(key, rec.
ref
);
if
(type == ActivityManager.INTENT_SENDER_ACTIVITY_RESULT)
{
// 如果intent需要返回结果,那么修改token对应的ActivityRecord
// 的pendingResults域。
if
(activity.pendingResults ==
null
)
{
activity.pendingResults =
new
HashSet<WeakReference<PendingIntentRecord>>();
}
activity.pendingResults.add(rec.
ref
);
}
return
rec;
}
上面这段代码主要做的事情有:
2.4.3 说说flags
从getIntentSenderLocked()的代码中,我们终于搞明白了flags中那些特定比特值的意义了。我们现在总结一下。
应该说这些flags比特值基本上都是在围绕着mIntentSenderRecords总表说事的。其中,FLAG_CANCEL_CURRENT的意思是,当我们获取PendingIntent时,如果可以从总表中查到一个相符的已存在的PendingIntentRecord节点的话,那么需要把这个节点从总表中清理出去。而在没有指定FLAG_CANCEL_CURRENT的大前提下,如果用户指定了FLAG_UPDATE_CURRENT标识,那么会用新的intents参数替掉刚查到的PendingIntentRecord中的旧intents。
而不管是刚清理了已存在的PendingIntentRecord,还是压根儿就没有找到符合的PendingIntentRecord,只要用户没有明确指定FLAG_NO_CREATE标识,系统就会尽力创建一个新的PendingIntentRecord节点,并插入总表。
至于FLAG_ONE_SHOT标识嘛,它并没有在getIntentSenderLocked()中露脸儿。它的名字是“FLAG_ONE_SHOT”,也就是“只打一枪”的意思,那么很明显,这个标识起作用的地方应该是在“激发”函数里。在最终的激发函数(sendInner())里,我们可以看到下面的代码:
【frameworks/base/services/java/com/android/server/am/PendingIntentRecord.java】
int
sendInner(
int
code, Intent intent, String resolvedType,
IIntentReceiver finishedReceiver, String requiredPermission,
IBinder resultTo, String resultWho,
int
requestCode,
int
flagsMask,
int
flagsValues, Bundle options)
{
synchronized(owner) {
if
(!canceled)
{
sent =
true
;
if
((key.flags & PendingIntent.FLAG_ONE_SHOT) != 0) {
owner.cancelIntentSenderLocked(
this
,
true
);
canceled =
true
;
}
. . . . . .
. . . . . .
return
ActivityManager.START_CANCELED;
}
}
}
意思很简单,一进行激发就把相应的PendingIntentRecord节点从总表中清理出去,而且把PendingIntentRecord的canceled域设为true。这样,以后即便外界再调用send()动作都没用了,因为再也无法进入if (!canceled)判断了。
2.4.4 将PendingIntentRecord节点插入总表
接下来getIntentSenderLocked()函数new了一个PendingIntentRecord节点,并将之插入mIntentSenderRecords总表中。
2.5 PendingIntent的激发动作
下面我们来看PendingIntent的激发动作。在前文我们已经说过,当需要激发PendingIntent之时,主要是通过调用PendingIntent的send()函数来完成激发动作的。PendingIntent提供了多个形式的send()函数,然而这些函数的内部其实调用的是同一个send(),其函数原型如下:
public
void
send(Context context,
int
code, Intent intent,
OnFinished onFinished, Handler handler, String requiredPermission)
throws CanceledException
该函数内部最关键的一句是:
int
res = mTarget.send(code, intent, resolvedType,
onFinished !=
null
?
new
FinishedDispatcher(
this
, onFinished, handler) :
null
,
requiredPermission);
我们前文已经介绍过这个mTarget域了,它对应着AMS中的某个PendingIntentRecord。
所以我们要看一下PendingIntentRecord一侧的send()函数,其代码如下:
public
int
send(
int
code, Intent intent, String resolvedType,
IIntentReceiver finishedReceiver, String requiredPermission)
{
return
sendInner(code, intent, resolvedType, finishedReceiver,
requiredPermission,
null
,
null
, 0, 0, 0,
null
);
}
其中sendInner()才是真正做激发动作的函数。
sendInner()完成的主要逻辑动作有:
现在还有一个问题是,既然我们在当初获取PendingIntent时,已经指定了日后激发时需要递送的intent(或intent数组),那么为什么send()动作里还有一个intent参数呢?它们的关系又是什么呢?我猜想,PendingIntent机制的设计者是希望给激发端一个修改“待激发的intent”的机会。比如当初我们获取PendingIntent对象时,如果在flags里设置了FILL_IN_ACTION标志位,那么就说明我们允许日后在某个激发点,用新的intent的mAction域值,替换掉我们最初给的intent的mAction域值。如果一开始没有设置FILL_IN_ACTION标志位,而且在最初的intent里已经有了非空的mAction域值的话,那么即使在激发端又传入了新intent,它也不可能修改用新intent的mAction域值替换旧intent的mAction域值。
细心的读者一定记得,当初获取PendingIntent对象时,我们可是向AMS端传递了一个intent数组噢,虽然一般情况下这个数组里只有一个intent元素,但有时候我们也是有可能一次性传递多个intent的。比如getActivities()函数就可以一次传递多个intent。可是现在激发动作send()却只能传递一个intent参数,这该如何处理呢?答案很简单,所传入的intent只能影响已有的intent数组的最后一个intent元素。大家可以看看sendInner里allIntents[allIntents.length-1] = finalIntent;一句。
Ok,intent说完了,下面就该做具体的激发了。我们以简单的INTENT_SENDER_BROADCAST型PendingIntentRecord来说明,此时的激发动作就是发送一个广播:
owner.broadcastIntentInPackage(key.packageName, uid, finalIntent, resolvedType,
finishedReceiver, code,
null
,
null
,
requiredPermission, (finishedReceiver !=
null
),
false
, UserId.getUserId(uid));
至于其他类型的PendingIntentRecord的激发动作,大家可以自行查阅代码,它们的基本代码格局都是差不多的。
3 小结
本文是基于我早先的一点儿笔记整理而成的。当时为了搞清楚PendingIntent的机理,也查阅了一些网上的相关文章,只是都不大满足我的要求,后来只好自己看代码,终于得了些自己的浅见。现在把我过去的一点儿认识整理出来,希望能对学习PendingIntent的同学有点儿帮助。