title: 四大组件启动过程
date: 2020-05-05 13:13:02
tags:[android源码,]
typora-copy-images-to: ./四大组件启动过程
typora-root-url: ./四大组件启动过程
本文主要记录四大组件在framework和APP中如何交互启动.记录大概框架.不追求完备的细节.源码根据8.0
Activity启动过程
主要流程
桌面程序通常是launch.我们点击桌面图标启动app时.是由桌面launch程序通过AMS来启动Activity.这个过程大概如下
image-20200505163411999
简单说就是.launch通知AMS启动新Activity. AMS则会先暂停当前进程.然后在启动新进程.然后在新进程启动完成后在创建Activity并启动.
通过intent定位Activity
APP在安装时.通过PackageManagerService 安装.并解析出来AndroidManifest.xml里声明的所有Activity.然后吧主Activity和应用图标绑定起来.这样点击图标.就能找到对应的Activity信息.
Instrumentation启动Activity
execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options){
int result = ActivityManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
}
这个可以说是代理类,他用来监控程序和系统间的交互.里边有针对Activity启动的监控ActivityMonitor.
他会通过AMS在客户端的代理来通知AMS启动Activity.并且传给AMS一个IBinder类的ApplicationThread,这是用来让AMS回调通知客户端进程的binder本地对象.
同时还传入一个IBinder的 token. 代表当前Activity对象在AMS中的标识. 每个启动的Activity都会有这个token.在AMS端是ActivityRecord对象.
ActivityManager 拿到AMS的代理,进行binder通信
ActivityManager.getService通过ServiceManager 拿到AMS对应的用户端binder.然后包装成AMS的客户端代理.
然后通过binder通信.调用AMS服务端.启动Activity.
image-20200505173538751
AMS端处理请求
这里内部会有几个类共同处理.而且每个版本的代码也有所不同.显示AcctivityStack来处理Activity的堆栈管理.
image-20200505173614505
PMS解析intent.找到对应的Activity.
PMS在启动的时候,已经解析了所有apk的androidManifest.xml文件.然后就知道所有intent格式对应的Activity.这里会通过PMS来找到合适的Activity.保存在ActivityInfo中.
检查调用进程的权限,封装信息
通过调用进程的ProsessRecord 来在AMS端对应一个用户进程. AMS检查调用者Launcher的进程.看是否有启动Activity的权限等. 同时封装要启动的Activity的信息为ActivityRecord.也拿到了源Activity(也就是launcher)的组件信息.
处理启动标识Intent.FLAG
这里处理各种启动模式,然后产生Activity对应的taskRecord. TaskRecord表示任务栈. 如果这个任务已经存在,就把待启动的Activity加入进去.如果新Activity对应的是新的任务.就要创建新的TaskRecord.
通过管理当前激活的Activity.上次中止的Activity.正在被中止的Activity.AMS来决定把旧Activity(launcher)执行暂停.然后在启动新的Activity.
暂停旧的activity
通过 用户进程的ApplicationThread 在AMS端的代理. AMS通知 旧Activity(launcher) 进行 pause.并把他保存在即将pause的变量中. launcher的Activity在pause后.又会通知AMS他已经pause完毕.然后AMS就会继续执行新Activity的启动过程.
启动新的Activity
先根据新Activity的进程名称判断对应进程是否启动.如果没有启动就先通过zygote来启动新进程.Activity的进程在AMS中的对应的对象是ProcessRecord. 新进程启动完成后必须在规定时间内通知AMS已经启动完成.新进程会执行ActivityThread的main方法.
新进程ActivityThread.main
通过ams.attach.通知AMS 新进程已启动完毕并传入新的ApplicationThread.创建主线程的looper和Handler.开始消息循环.
AMS继续启动Activity
AMS收到ActivityThread的att通知后.继续启动新Activity.此时新进程已经和ProcessRecord对应上.然后通过上边的ApplicationThread在AMS的代理.通知ActivityThread启动Activity.而客户端ApplicationThread收到AMS的消息后.通过向主线程looper 发送消息.启动Activity. ActivityThread收到消息后.取出要启动的Activity信息
ActivityThread 启动Activity
通过执行handleLauncherActivity,反射 创建activity所属的Application.ContextImpl.和activity.
然后执行activity.attach .使activity和WMS建立联系.获得应用窗口.
在执行activity.onCreate. 创建view树.
Activity 的启动.因为之前已经写过了.这里就简单的过一下
Service启动过程
Service的启动分为显示启动和隐式启动.并且可以运行在不同的进程.并且可以通过startService启动.和bindService启动.
activity启动服务
最开始其余 startService. 他会调用到ContextWrapper.startService.有会调用到mBase.startService(service). mBase实际是一个ComtextImpl对象.每个Activity创建时都有一个ContextImpl对象. 他又会调用AMS.startService.通过binder来启动.
AMS接收调用.启动服务
AMS内部又通过 mServices.startServiceLocked 来启动 mService 是ActiveServices类.
ActiveServices.java
startServiceLocked(){
继续启动Service,找到 intent对应的Service.
ServiceLookupResult res =retrieveServiceLocked(service, resolvedType, callingPackage,
callingPid, callingUid, userId, true, callerFg, false);
启动完的Service在AMS里抽象为ServiceRecord
ServiceRecord r = res.record;
然后是一些权限的验证处理
生成了一个 ComponentName.这里一会看.
ComponentName cmp = startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}
通过intent找到Service
ActivityService.java
根据intent.找到对应的Service,在AMS里.每个ServiceRecord是和ComponentName绑定的
private ServiceLookupResult retrieveServiceLocked(Intent service...){
ServiceRecord r = null;
找到进程对应的 ServiceMap.然后根据componentName找Service.
ServiceMap smap = getServiceMapLocked(userId);
final ComponentName comp = service.getComponent();
if (comp != null) {
r = smap.mServicesByName.get(comp);
}
接下来是对ServiceRecord 权限的检查,看用户进程是否可以启动这个Service
最后封装后返回出去
return new ServiceLookupResult(r, null);
}
启动服务 startServiceInnerLocked
这里又调用的同名函数 bringUpServiceLocked 这是真正启懂Service的地方.然后又调度队列.启动所以等待的Service
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r...){
//启动Service
String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false, false);
//通过队列.把等待启动的Service 再次通过startServiceInnerLocked方法启动.
if (r.startRequested && addToStarting) {
if (first) {
smap.rescheduleDelayedStartsLocked();
}
} else if (callerFg || r.fgRequired) {
smap.ensureNotStartingBackgroundLocked(r);
}
}
AMS启动service对应进程
这里会看Service对应的进程是否启动.如果启动.就直接启动Service就行了.如果没有.就先启动对应的进程.进程在AMS端的代表对象是ProsessRecord
private String bringUpServiceLocked(ServiceRecord r){
进程存在,直接启动Service
if (r.app != null && r.app.thread != null) {
sendServiceArgsLocked(r, execInFg, false);
return null;
}
进程不存在.启动进程,然后在把Service放入队列,等待启动
if (app == null && !permissionsReviewRequired) {
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
hostingType, r.name, false, isolated, false)) == null) {
}
}
if (!mPendingServices.contains(r)) {
mPendingServices.add(r);
}
}
AMS启动Service的进程,这里还是通过Process.start来启动新进程.这里和之前的Activity比较类似.也是通过zygote进程来fork出新进程.然后执行ActivityThread的main函数. 进程初始化完成后.会调用AMS.attachApplication.
这里和Activity的启动是一个方法.这次他会在这里看上边加入队列的
ActivityManagerService.java
boolean attachApplicationLocked(IApplicationThread thread,int pid) {
又回调到了Service的方法区去处理启动Service
// Find any services that should be running in this process...
if (!badApp) {
try {
didSomething |= mServices.attachApplicationLocked(app, processName);
} catch (Exception e) {
badApp = true;
}
}
}
Service继续启动服务
遍历pending队列,启动Service
ActivityServices.java
boolean attachApplicationLocked(ProcessRecord proc, String processName) {
if (mPendingServices.size() > 0) {
ServiceRecord sr = null;
for (int i=0; i<mPendingServices.size(); i++) {
sr = mPendingServices.get(i);
realStartServiceLocked(sr, proc, sr.createdFromFg);
}
}
}
realStartServiceLocked里最主要的是,下边的.也就是通过binder调用用户进程启动service,通过ApplicationThread继而通知ActivityThread启动服务
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),app.repProcState);
用户进程启动service
ActivityThread.java
void handleCreateService(CreateServiceData data) {
每个app都有一个loadedApk来描述应用程序的资源.
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
反射加载servi的类.
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
}
try {
为service创建ContextImpl上下文环境. activity也有这个.
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
service 绑定Application. 执行onCreate
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
service.onCreate();
ActivityThread 保存所有的service
mServices.put(data.token, service);
try {
通知AMS.service启动成功
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} catch (Exception e) {
}
}
最后AMS里会做一些收尾工作.
附一个流程图.
Sample sequence diagram
service绑定过程
绑定的Service也是需要先启动起来的. 过程和启动服务类似. 都是从ContextImpl通知AMS开始.这里会封装一个IServiceConnection.这个IServiceConnection 是一个adil类.这是夸进程传递给AMS 的对象. 这里.APP的进程是IServiceConnection的binder服务端. AMS则持有 IServiceConnection的binder的代理端.
封装ServiceConnect.通知AMS
bindServiceCommon(Intent service, ServiceConnection conn,){
IServiceConnection sd;
//封装成一个IBinder.
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);
// 调用ams的方法.
int res = ActivityManager.getService().bindService(
mMainThread.getApplicationThread(), getActivityToken(), service,
service.resolveTypeIfNeeded(getContentResolver()),
sd, flags, getOpPackageName(), user.getIdentifier());
}
AMS转给ActiveServices处理.
这里的流程比较复杂.简单说就是找到service的记录.然后和对应的Activity. 及Activity对应的process创建绑定关系ConnectionRecord并保存起来.保存在service 的ServiceRecord中.然后开始启动service
ActivityServices.java
bindServiceLocked (IApplicationThread caller, IBinder token, Intent service, final IServiceConnection connection..){
请求绑定服务的Activity的进程.
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
请求的Activity的记录
ActivityRecord activity = null;
if (token != null) {
activity = ActivityRecord.isInStackLocked(token);
}
//同启动服务一样.找到对应的service记录.
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage, Binder.getCallingPid(),
Binder.getCallingUid(), userId, true, callerFg, isBindExternal);
ServiceRecord s = res.record;
找到service对应的app绑定描述对象.表示service绑定在callerApp进程中.表示绑定在这个service上的进程.
这是一种对应关系. 一个service可以被多个进程绑定.
AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
这里是描述Activity.service.process 的对应关系的一个记录.
ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent);
得到connection的远程代理类.,保存上边的映射关系.
IBinder binder = connection.asBinder();
ArrayList<ConnectionRecord> clist = s.connections.get(binder);
接着启动这个service
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,
permissionsReviewRequired) != null) {
return 0;
}
clist.add(c);
c.conn.connected(s.name, b.intent.binder, false);
}
ActivityServices 继续启动
bringUpServiceLocked方法.在启动service里已经出现过了.流程就是启动service对应的进程. 进程启动完后通知AMS.AMS在通知创建Service. 直到执行service的onStart.onCreate
但是这里不太一样的是realStartServiceLocked里又会执行requestServiceBindingsLocked.进而遍历调用r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind, r.app.repProcState); 也就是变量得到该service所有对应的要绑定的activity的相关记录.
private final void requestServiceBindingsLocked(ServiceRecord r, boolean execInFg)
throws TransactionTooLargeException {
for (int i=r.bindings.size()-1; i>=0; i--) {
IntentBindRecord ibr = r.bindings.valueAt(i);
if (!requestServiceBindingLocked(r, ibr, execInFg, false)) {
break;
}
}
}
private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
boolean execInFg, boolean rebind) throws TransactionTooLargeException {
if ((!i.requested || rebind) && i.apps.size() > 0) {
r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.repProcState);
}
return true;
}
ActivityThread处理绑定服务
这时.又通过Binder通知到了ActivityThread,他调用servic的onBind. 获取服务的binder对象.然后回传给AMS
ActivityThread.java
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
try {
if (!data.rebind) {
调用了service的onBind 获取service的 binder. ActivityThread保存所有的service.
IBinder binder = s.onBind(data.intent);
再把service服务的binder传递个AMS.用来发送回所有绑定到该service的进程.当然发送过去的是本地binder的代理类.
ActivityManager.getService().publishService(
data.token, data.intent, binder);
} else {
s.onRebind(data.intent);
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
}
}
AMS获取service的binder代理对象
ams还是把请求交个ActivityServices来处理.
ActivityServices.java
publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
final long origId = Binder.clearCallingIdentity();
try {
Intent.FilterComparison filter= new Intent.FilterComparison(intent);
IntentBindRecord b = r.bindings.get(filter);
if (b != null && !b.received) {
ConnectionRecord是上问我们介绍的 service和Activity和acitivity的process建立的绑定关系.
这里拿到这个服务的所有ConnectionRecord.然后取出里边的binder代理类 IServiceConnection.
在调用connected方法.并传入service发过来的binder. 就实现了 service和Activity的绑定.
for (int conni=r.connections.size()-1; conni>=0; conni--) {
ArrayList<ConnectionRecord> clist = r.connections.valueAt(conni);
for (int i=0; i<clist.size(); i++) {
ConnectionRecord c = clist.get(i);
c.conn.connected(r.name, service, false);
}
}
}
serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
}
} finally {
Binder.restoreCallingIdentity(origId);
}
}
看到这里就明白了. activity提供的ServiceConnection 被包装成Binder后.发送到AMS中.与要绑定的Service建立关系.产生ConnectionRecord对象. 而service在对应的进程启动完成.service也启动完成后. 由AMS调用service 的onBind. service 则会提供代表他的功能的binder给AMS. 在publishServiceLocked方法中.遍历所有的ConnectionRecord, 调用conn.connected 把service 传来的binder发送给 activity里的ServiceConnection .这就实现了 activity和service的绑定.
ServiceDispatcher 处理connection
上边的 c.conn.connected(r.name, service, false); 其实是调用的的InnerConnection的方法.他是LoadApk 里ServiceDispatcher的内部类.是aidl实现的类.这里又涉及到AMS和最初 的Activity 通过aidl 方式来进程ipc.
loadApk.java
public void connected(ComponentName name, IBinder service, boolean dead) {
if (mActivityThread != null) {
可以看到.通过handler.把connec推到住线程来处理了.
mActivityThread.post(new RunConnection(name, service, 0, dead));
} else {
doConnected(name, service, dead);
}
}
Runnconection 在主线程处理
简单说就是找到旧的服务.将他断开,然后执行新的connection 的onServiceConnected方法.也就是回调activity里设置的connection.
public void doConnected(ComponentName name, IBinder service, boolean dead) {
ServiceDispatcher.ConnectionInfo old;
ServiceDispatcher.ConnectionInfo info;
synchronized (this) {
}
old = mActiveConnections.get(name);
if (service != null) {
info = new ConnectionInfo();
info.binder = service;
info.deathMonitor = new DeathMonitor(name, service);
try {
service.linkToDeath(info.deathMonitor, 0);
mActiveConnections.put(name, info);
} catch (RemoteException e) {
}
if (old != null) {
old.binder.unlinkToDeath(old.deathMonitor, 0);
}
}
断开旧服务
if (old != null) {
mConnection.onServiceDisconnected(name);
}
开启新服务
if (service != null) {
mConnection.onServiceConnected(name, service);
}
}
Service_Start
广播机制
广播机制是在binder的基础上实现的.广播机制存在注册中心.就是AMS.广播订阅者要先向AMS注册,并指明接受广播的类型.然后广播发送者把广播发送给AMS.再由AMS分发给对应的接收者.
广播分为有序广播和无序广播. 注册时有静态注册和动态注册.
注册广播
同样是从ContextImpl开始.先拿到主线程的handler.然后封装一个 receiverDispatcher.然后通知AMS来注册,
这个ReceiverDispatcher也是对receiver的封装.并且内部有实现aidl 的类.也就是利用binder 把代理类发给AMS.用于回调.
ContextImpl.java
private Intent registerReceiverInternal(BroadcastReceiver receiver, int userId,
IntentFilter filter, String broadcastPermission,
Handler scheduler, Context context, int flags) {
IIntentReceiver rd = null;
if (receiver != null) {
封装一个receiverDispatcher .这个和service原理有点类似.都是发给AMS用来回调app进程的binder类
if (mPackageInfo != null && context != null) {
if (scheduler == null) {
还拿到了ui线程的handler,用来向主线程发消息.
scheduler = mMainThread.getHandler();
}
rd = mPackageInfo.getReceiverDispatcher(
receiver, context, scheduler,
mMainThread.getInstrumentation(), true);
}
}
通过ams注册
final Intent intent = ActivityManager.getService().registerReceiver(
mMainThread.getApplicationThread(), mBasePackageName, rd, filter,
broadcastPermission, userId, flags);
}
AMS中注册广播
这里有对粘性广播和普通广播的处理. 如果存在粘性广播.就把他们保存在 allSticky中.粘性广播就是广播发送在广播注册之前.但是也能收到.粘性广播会一直留在AMS中.直到下一个同类型粘性广播的到来.
public Intent registerReceiver(IApplicationThread caller, String callerPackage,
IIntentReceiver receiver, IntentFilter filter, String permission, int userId,
int flags) {
ArrayList<Intent> stickyIntents = null;
ProcessRecord callerApp = null;
callerApp = getRecordForAppLocked(caller);
instantApp = isInstantApp(callerApp, callerPackage, callingUid);
找到匹配的粘性广播,保存intent
ArrayList<Intent> allSticky = null;
if (stickyIntents != null) {
final ContentResolver resolver = mContext.getContentResolver();
// Look for any matching sticky broadcasts...
for (int i = 0, N = stickyIntents.size(); i < N; i++) {
Intent intent = stickyIntents.get(i);
if (filter.match(resolver, intent, true, TAG) >= 0) {
allSticky.add(intent);
}
}
}
每个广播接收者是用BroadcastFilter 来描述.BroadcastFilter和APP传过来的InnerReceiver.而可能多个activity会使用同一个InnerReceiver.因此用集合来保存相同InneReceiver的广播接收者.
也就是如果多个activity注册同一个广播.就会有一个InnerReceiver.对应多个BroadcastFilter.
synchronized (this) {
ReceiverList rl = mRegisteredReceivers.get(receiver.asBinder());
if (rl == null) {
rl = new ReceiverList(this, callerApp, callingPid, callingUid,
userId, receiver);
mRegisteredReceivers.put(receiver.asBinder(), rl);
}
BroadcastFilter bf = new BroadcastFilter(filter, rl, callerPackage,
permission, callingUid, userId, instantApp, visibleToInstantApps);
rl.add(bf);
if (!bf.debugCheck()) {
Slog.w(TAG, "==> For Dynamic broadcast");
}
加到这里后.以后来了广播.就能找到对应的接收者.
mReceiverResolver.addFilter(bf);
把粘性广播返回给activity组件.也就实现了粘性广播的发送.
if (allSticky != null) {
ArrayList receivers = new ArrayList();
receivers.add(bf);
final int stickyCount = allSticky.size();
for (int i = 0; i < stickyCount; i++) {
Intent intent = allSticky.get(i);
BroadcastQueue queue = broadcastQueueForIntent(intent);
每个广播对应的就是 BroadCastRecord 记录.这里是入栈.然后发送粘性广播.
BroadcastRecord r = new BroadcastRecord(queue, intent, null,
null, -1, -1, false, null, null, AppOpsManager.OP_NONE, null, receivers,
null, 0, null, null, false, true, true, -1);
queue.enqueueParallelBroadcastLocked(r);
queue.scheduleBroadcastsLocked();
}
}
return sticky;
}
}
发送广播
首先广播发送者把广播发送给AMS.
然后AMS找到这个广播对应的接收者,再把这个广播和接收者添加到广播队列中.并向AMS中发送一个BROADCAST_INTENT_MSG的消息.等待AMS处理.
当AMS处理到这个消息时,取出广播及接收者,分别将广播发给接收者的进程
接受者进程的ActivityThread会再次把消息发送到主线程的消息队列.等消息被处理时在交给广播接收者.
发送广播给AMS
由ContextImpl 通过binder通信把广播发给AMS.
AMS接收处理广播
broadcastIntent()
验证广播intent参数的合法性.
broadcastIntentLocked()
先是对intent里的action的不同类型的处理.如检查权限.同时对系统广播进行处理.
接着是对粘性广播的处理.所有的粘性广播都保存在一个hashmap中,并已action作为key
然后如果广播指定了接收者的Component.就从pms中找到对应的接收者,保存起来
然后在判断intent的flag 是发给动态接收者还是动态接收者以及静态接收者.静态和动态的广播接收者分别保存在不同的集合中.
针对无序广播.并且有动态接收者.在发给静态接收者.封装成BroadcastRecord,加入队列.
接着把剩下的广播都加入到BroadcastQueue,并且接收者会按照优先级排序.合并静态动态接受者.
BroadcastQueue.scheduleBroadcastsLocked
将广播加入队列后.通过handler发送给AMS的线程.可以看到广播的发送和接收是异步的
BroadcastQueue.processNextBroadcast
取出广播对象BroadcastRecord,处理无序广播队列,找到所有的无序接收者.遍历执行deliverToRegisteredReceiverLocked
然后执行有序广播的处理. 如果对应的广播接收者还没启动.则先启动对应的进程,然后继续处理下一个有序广播接收者.
入股有序广播不能再一个限定时间内处理完成.就会结束这个有序广播.
BroadcastQueue.deliverToRegisteredReceiverLocked
这里AMS把广播转发给APP所在进程.其实是通过回调ApplicationThread的scheduleRegisteredReceiver把消息发给ActivityThread的.这时发送给APP进程的是之前包装过的InntentReceiver的代理类. 他内部封装了一个广播接收者.
ActivityThread.scheduleRegisteredReceiver
这里就到了APP进程.然后由之前传入的InnerReceiver 来继续执行.
他内部会发消息给ActivityThread的主线程. 发一个runnable过去.等主线程处理这个消息. runnable是Args
的内部类.
Args.getRunnable
最后调用receiver.onReceive .也就是接收者接收到了消息.然后在回调AMS.finishReceive表示消息接收完成
contentprovider 以后再补充.他是用共享内存作为夸进程传输数据的.
网友评论