原文出处——>[Android应用程序发送广播（sendBroadcast）的过程分析](http://blog.csdn.net/luoshengyang/article/details/6744448) 前面我们分析了Android应用程序注册广播接收器的过程，这个过程只完成了万里长征的第一步，接下来它还要等待ActivityManagerService将广播分发过来。ActivityManagerService是如何得到广播并把它分发出去的呢？这就是本文要介绍的广播发送过程了。 广播的发送过程比广播接收器的注册过程要复杂得多了，不过这个过程仍然是以ActivityManagerService为中心。广播的发送者将广播发送到ActivityManagerService，ActivityManagerService接收到这个广播以后，就会在自己的注册中心查看有哪些广播接收器订阅了该广播，然后把这个广播逐一发送到这些广播接收器中，但是ActivityManagerService并不等待广播接收器处理这些广播就返回了，因此，广播的发送和处理是异步的。概括来说，广播的发送路径就是从发送者到ActivityManagerService，再从ActivityManagerService到接收者，这中间的两个过程都是通过Binder进程间通信机制来完成的，因此，希望读者在继续阅读本文之前，对Android系统的Binder进程间通信机制有所了解，具体可以参考Android进程间通信（IPC）机制Binder简要介绍和学习计划一文。 本文继续以Android系统中的广播（Broadcast）机制简要介绍和学习计划一文中所开发的应用程序为例子，并且结合上文Android应用程序注册广播接收器（registerReceiver）的过程分析的内容，一起来分析Android应用程序发送广播的过程。 回顾一下Android系统中的广播（Broadcast）机制简要介绍和学习计划一文中所开发的应用程序的组织架构，MainActivity向ActivityManagerService注册了一个CounterService.BROADCAST_COUNTER_ACTION类型的计数器服务广播接收器，计数器服务CounterService在后台线程中启动了一个异步任务（AsyncTask），这个异步任务负责不断地增加计数，并且不断地将当前计数值通过广播的形式发送出去，以便MainActivity可以将当前计数值在应用程序的界面线程中显示出来。 计数器服务CounterService发送广播的代码如下所示： ~~~ public class CounterService extends Service implements ICounterService { ...... public void startCounter(int initVal) { AsyncTask task = new AsyncTask() { @Override protected Integer doInBackground(Integer... vals) { ...... } @Override protected void onProgressUpdate(Integer... values) { super.onProgressUpdate(values); int counter = values[0]; Intent intent = new Intent(BROADCAST_COUNTER_ACTION); intent.putExtra(COUNTER_VALUE, counter); sendBroadcast(intent); } @Override protected void onPostExecute(Integer val) { ...... } }; task.execute(0); } ...... } ~~~ 在onProgressUpdate函数中，创建了一个BROADCAST_COUNTER_ACTION类型的Intent，并且在这里个Intent中附加上当前的计数器值，然后通过CounterService类的成员函数sendBroadcast将这个Intent发送出去。CounterService类继承了Service类，Service类又继承了ContextWrapper类，成员函数sendBroadcast就是从ContextWrapper类继承下来的，因此，我们就从ContextWrapper类的sendBroadcast函数开始，分析广播发送的过程。 在继承分析广播的发送过程前，我们先来看一下广播发送过程的序列图，然后按照这个序图中的步骤来一步一步分析整个过程。  **Step 1. ContextWrapper.sendBroadcast** 这个函数定义在frameworks/base/core/java/android/content/ContextWrapper.java文件中： ~~~ public class ContextWrapper extends Context { Context mBase; ...... @Override public void sendBroadcast(Intent intent) { mBase.sendBroadcast(intent); } ...... } ~~~ 这里的成员变量mBase是一个ContextImpl实例，这里只简单地调用ContextImpl.sendBroadcast进一行操作。 **Step 2. ContextImpl.sendBroadcast** 这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件中： ~~~ class ContextImpl extends Context { ...... @Override public void sendBroadcast(Intent intent) { String resolvedType = intent.resolveTypeIfNeeded(getContentResolver()); try { ActivityManagerNative.getDefault().broadcastIntent( mMainThread.getApplicationThread(), intent, resolvedType, null, Activity.RESULT_OK, null, null, null, false, false); } catch (RemoteException e) { } } ...... } ~~~ 这里的resolvedType表示这个Intent的MIME类型，我们没有设置这个Intent的MIME类型，因此，这里的resolvedType为null。接下来就调用ActivityManagerService的远程接口ActivityManagerProxy把这个广播发送给ActivityManagerService了。 **Step 3. ActivityManagerProxy.broadcastIntent** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public int broadcastIntent(IApplicationThread caller, Intent intent, String resolvedType, IIntentReceiver resultTo, int resultCode, String resultData, Bundle map, String requiredPermission, boolean serialized, boolean sticky) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); intent.writeToParcel(data, 0); data.writeString(resolvedType); data.writeStrongBinder(resultTo != null ? resultTo.asBinder() : null); data.writeInt(resultCode); data.writeString(resultData); data.writeBundle(map); data.writeString(requiredPermission); data.writeInt(serialized ? 1 : 0); data.writeInt(sticky ? 1 : 0); mRemote.transact(BROADCAST_INTENT_TRANSACTION, data, reply, 0); reply.readException(); int res = reply.readInt(); reply.recycle(); data.recycle(); return res; } ...... } ~~~ 这里的实现比较简单，把要传递的参数封装好，然后通过Binder驱动程序进入到ActivityManagerService的broadcastIntent函数中。 **Step 4. ctivityManagerService.broadcastIntent** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public final int broadcastIntent(IApplicationThread caller, Intent intent, String resolvedType, IIntentReceiver resultTo, int resultCode, String resultData, Bundle map, String requiredPermission, boolean serialized, boolean sticky) { synchronized(this) { intent = verifyBroadcastLocked(intent); final ProcessRecord callerApp = getRecordForAppLocked(caller); final int callingPid = Binder.getCallingPid(); final int callingUid = Binder.getCallingUid(); final long origId = Binder.clearCallingIdentity(); int res = broadcastIntentLocked(callerApp, callerApp != null ? callerApp.info.packageName : null, intent, resolvedType, resultTo, resultCode, resultData, map, requiredPermission, serialized, sticky, callingPid, callingUid); Binder.restoreCallingIdentity(origId); return res; } } ...... } ~~~ 这里调用broadcastIntentLocked函数来进一步处理。 **Step 5. ActivityManagerService.broadcastIntentLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final int broadcastIntentLocked(ProcessRecord callerApp, String callerPackage, Intent intent, String resolvedType, IIntentReceiver resultTo, int resultCode, String resultData, Bundle map, String requiredPermission, boolean ordered, boolean sticky, int callingPid, int callingUid) { intent = new Intent(intent); ...... // Figure out who all will receive this broadcast. List receivers = null; List registeredReceivers = null; try { if (intent.getComponent() != null) { ...... } else { ...... registeredReceivers = mReceiverResolver.queryIntent(intent, resolvedType, false); } } catch (RemoteException ex) { ...... } final boolean replacePending = (intent.getFlags()&Intent.FLAG_RECEIVER_REPLACE_PENDING) != 0; int NR = registeredReceivers != null ? registeredReceivers.size() : 0; if (!ordered && NR > 0) { // If we are not serializing this broadcast, then send the // registered receivers separately so they don't wait for the // components to be launched. BroadcastRecord r = new BroadcastRecord(intent, callerApp, callerPackage, callingPid, callingUid, requiredPermission, registeredReceivers, resultTo, resultCode, resultData, map, ordered, sticky, false); ...... boolean replaced = false; if (replacePending) { for (int i=mParallelBroadcasts.size()-1; i>=0; i--) { if (intent.filterEquals(mParallelBroadcasts.get(i).intent)) { ...... mParallelBroadcasts.set(i, r); replaced = true; break; } } } if (!replaced) { mParallelBroadcasts.add(r); scheduleBroadcastsLocked(); } registeredReceivers = null; NR = 0; } ...... } ...... } ~~~ 这个函数首先是根据intent找出相应的广播接收器： ~~~ // Figure out who all will receive this broadcast. List receivers = null; List registeredReceivers = null; try { if (intent.getComponent() != null) { ...... } else { ...... registeredReceivers = mReceiverResolver.queryIntent(intent, resolvedType, false); } } catch (RemoteException ex) { ...... } ~~~ 回忆一下前面一篇文章Android应用程序注册广播接收器（registerReceiver）的过程分析中的Step 6（ActivityManagerService.registerReceiver）中，我们将一个filter类型为BROADCAST_COUNTER_ACTION类型的BroadcastFilter实例保存在了ActivityManagerService的成员变量mReceiverResolver中，这个BroadcastFilter实例包含了我们所注册的广播接收器，这里就通过mReceiverResolver.queryIntent函数将这个BroadcastFilter实例取回来。由于注册一个广播类型的接收器可能有多个，所以这里把所有符合条件的的BroadcastFilter实例放在一个List中，然后返回来。在我们这个场景中，这个List就只有一个BroadcastFilter实例了，就是MainActivity注册的那个广播接收器。 继续往下看： ~~~ final boolean replacePending = (intent.getFlags()&Intent.FLAG_RECEIVER_REPLACE_PENDING) != 0; ~~~ 这里是查看一下这个intent的Intent.FLAG_RECEIVER_REPLACE_PENDING位有没有设置，如果设置了的话，ActivityManagerService就会在当前的系统中查看有没有相同的intent还未被处理，如果有的话，就有当前这个新的intent来替换旧的intent。这里，我们没有设置intent的Intent.FLAG_RECEIVER_REPLACE_PENDING位，因此，这里的replacePending变量为false。 再接着往下看： ~~~ int NR = registeredReceivers != null ? registeredReceivers.size() : 0; if (!ordered && NR > 0) { // If we are not serializing this broadcast, then send the // registered receivers separately so they don't wait for the // components to be launched. BroadcastRecord r = new BroadcastRecord(intent, callerApp, callerPackage, callingPid, callingUid, requiredPermission, registeredReceivers, resultTo, resultCode, resultData, map, ordered, sticky, false); ...... boolean replaced = false; if (replacePending) { for (int i=mParallelBroadcasts.size()-1; i>=0; i--) { if (intent.filterEquals(mParallelBroadcasts.get(i).intent)) { ...... mParallelBroadcasts.set(i, r); replaced = true; break; } } } if (!replaced) { mParallelBroadcasts.add(r); scheduleBroadcastsLocked(); } registeredReceivers = null; NR = 0; } ~~~ 前面我们说到，这里得到的列表registeredReceivers的大小为1，且传进来的参数ordered为false，表示要将这个广播发送给所有注册了BROADCAST_COUNTER_ACTION类型广播的接收器，因此，会执行下面的if语句。这个if语句首先创建一个广播记录块BroadcastRecord，里面记录了这个广播是由谁发出的以及要发给谁等相关信息。由于前面得到的replacePending变量为false，因此，不会执行接下来的if语句，即不会检查系统中是否有相同类型的未处理的广播。 这样，这里得到的replaced变量的值也为false，于是，就会把这个广播记录块r放在ActivityManagerService的成员变量mParcelBroadcasts中，等待进一步处理；进一步处理的操作由函数scheduleBroadcastsLocked进行。 **Step 6. ActivityManagerService.scheduleBroadcastsLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final void scheduleBroadcastsLocked() { ...... if (mBroadcastsScheduled) { return; } mHandler.sendEmptyMessage(BROADCAST_INTENT_MSG); mBroadcastsScheduled = true; } ...... } ~~~ 这里的mBroadcastsScheduled表示ActivityManagerService当前是不是正在处理其它广播，如果是的话，这里就先不处理直接返回了，保证所有广播串行处理。 注意这里处理广播的方式，它是通过消息循环来处理，每当ActivityManagerService接收到一个广播时，它就把这个广播放进自己的消息队列去就完事了，根本不管这个广播后续是处理的，因此，这里我们可以看出广播的发送和处理是异步的。 这里的成员变量mHandler是一个在ActivityManagerService内部定义的Handler类变量，通过它的sendEmptyMessage函数把一个类型为BROADCAST_INTENT_MSG的空消息放进ActivityManagerService的消息队列中去。这里的空消息是指这个消息除了有类型信息之外，没有任何其它额外的信息，因为前面已经把要处理的广播信息都保存在mParcelBroadcasts中了，等处理这个消息时，从mParcelBroadcasts就可以读回相关的广播信息了，因此，这里不需要把广播信息再放在消息内容中。 **Step 7. Handler.sendEmptyMessage** 这个自定义的Handler类实现在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中，它是ActivityManagerService的内部类，调用了它的sendEmptyMessage函数来把一个消息放到消息队列后，一会就会调用它的handleMessage函数来真正处理这个消息： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... final Handler mHandler = new Handler() { public void handleMessage(Message msg) { switch (msg.what) { ...... case BROADCAST_INTENT_MSG: { ...... processNextBroadcast(true); } break; ...... } } } ...... } ~~~ 这里又调用了ActivityManagerService的processNextBroadcast函数来处理下一个未处理的广播。 **Step 8. ActivityManagerService.processNextBroadcast** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final void processNextBroadcast(boolean fromMsg) { synchronized(this) { BroadcastRecord r; ...... if (fromMsg) { mBroadcastsScheduled = false; } // First, deliver any non-serialized broadcasts right away. while (mParallelBroadcasts.size() > 0) { r = mParallelBroadcasts.remove(0); ...... final int N = r.receivers.size(); ...... for (int i=0; i ';

原文出处——>[Android应用程序注册广播接收器（registerReceiver）的过程分析](http://blog.csdn.net/luoshengyang/article/details/6737352) 前面我们介绍了Android系统的广播机制，从本质来说，它是一种消息订阅/发布机制，因此，使用这种消息驱动模型的第一步便是订阅消息；而对Android应用程序来说，订阅消息其实就是注册广播接收器，本文将探讨Android应用程序是如何注册广播接收器以及把广播接收器注册到哪里去的。 在Android的广播机制中，ActivityManagerService扮演着广播中心的角色，负责系统中所有广播的注册和发布操作，因此，Android应用程序注册广播接收器的过程就把是广播接收器注册到ActivityManagerService的过程。Android应用程序是通过调用ContextWrapper类的registerReceiver函数来把广播接收器BroadcastReceiver注册到ActivityManagerService中去的，而ContextWrapper类本身又借助ContextImpl类来注册广播接收器。 在Android应用程序框架中，Activity和Service类都继承了ContextWrapper类，因此，我们可以在Activity或者Service的子类中调用registerReceiver函数来注册广播接收器。Activity、Service、ContextWrapper和ContextImpl这四个类的关系可以参考前面Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中描述的Activity类图。 这篇文章还是继续以实例来进行情景分析，所用到的例子便是上一篇文章Android系统中的广播（Broadcast）机制简要介绍和学习计划里面介绍的应用程序了，所以希望读者在继续阅读本文之前，先看看这篇文章；又由于Android应用程序是把广播接器注册到ActivityManagerService中去的，因此，这里又会涉入到Binder进程间通信机制，所以希望读者对Android系统的Binder进程间通信机制有所了解，具体请参考Android进程间通信（IPC）机制Binder简要介绍和学习计划一文。 开始进入主题了，在Android系统中的广播（Broadcast）机制简要介绍和学习计划一文所介绍的例子中，注册广播接收器的操作是MainActivity发起的，我们先来看看注册过程的序列图：  在分析这个序列图之前，我们先来看一下MainActivity是如何调用registerReceiver函数来注册广播接收器的： ~~~ public class MainActivity extends Activity implements OnClickListener { ...... @Override public void onResume() { super.onResume(); IntentFilter counterActionFilter = new IntentFilter(CounterService.BROADCAST_COUNTER_ACTION); registerReceiver(counterActionReceiver, counterActionFilter); } ...... } ~~~ MainActivity在onResume函数里，通过其父类ContextWrapper的registerReceiver函数注册了一个BroadcastReceiver实例counterActionReceiver，并且通过IntentFilter实例counterActionFilter告诉ActivityManagerService，它要订阅的广播是CounterService.BROADCAST_COUNTER_ACTION类型的，这样，ActivityManagerService在收到CounterService.BROADCAST_COUNTER_ACTION类型的广播时，就会分发给counterActionReceiver实例的onReceive函数。 接下来，就开始分析注册过程中的每一个步骤了。 **Step 1. ContextWrapper.registerReceiver** 这个函数实现在frameworks/base/core/java/android/content/ContextWrapper.java文件中： ~~~ public class ContextWrapper extends Context { Context mBase; ...... @Override public Intent registerReceiver( BroadcastReceiver receiver, IntentFilter filter) { return mBase.registerReceiver(receiver, filter); } ...... } ~~~ 这里的成员变量mBase是一个ContextImpl实例，想知道为什么，可以回过头去看看Android应用程序启动过程源代码分析这篇文章>~<。 **Step 2. ContextImpl.registerReceiver** 这个函数实现在frameworks/base/core/java/android/app/ContextImpl.java文件中： ~~~ class ContextImpl extends Context { ...... @Override public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter) { return registerReceiver(receiver, filter, null, null); } @Override public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheduler) { return registerReceiverInternal(receiver, filter, broadcastPermission, scheduler, getOuterContext()); } 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 { ...... } } try { return ActivityManagerNative.getDefault().registerReceiver( mMainThread.getApplicationThread(), rd, filter, broadcastPermission); } catch (RemoteException e) { return null; } } ...... } ~~~ 通过两个函数的中转，最终就进入到ContextImpl.registerReceiverInternal这个函数来了。这里的成员变量mPackageInfo是一个LoadedApk实例，它是用来负责处理广播的接收的，在后面一篇文章讲到广播的发送时（sendBroadcast），会详细描述。参数broadcastPermission和scheduler都为null，而参数context是上面的函数通过调用函数getOuterContext得到的，这里它就是指向MainActivity了，因为MainActivity是继承于Context类的，因此，这里用Context类型来引用。 由于条件mPackageInfo != null和context != null都成立，而且条件scheduler == null也成立，于是就调用mMainThread.getHandler来获得一个Handler了，这个Hanlder是后面用来分发ActivityManagerService发送过的广播用的。这里的成员变量mMainThread是一个ActivityThread实例，在前面Android应用程序启动过程源代码分析这篇文章也描述过了。我们先来看看ActivityThread.getHandler函数的实现，然后再回过头来继续分析ContextImpl.registerReceiverInternal函数。 **Step 3. ActivityThread.getHandler** 这个函数实现在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... final H mH = new H(); private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... switch (msg.what) { ...... } ...... } ...... } ...... final Handler getHandler() { return mH; } ...... } ~~~ 有了这个Handler之后，就可以分发消息给应用程序处理了。 再回到上一步的ContextImpl.registerReceiverInternal函数中，它通过mPackageInfo.getReceiverDispatcher函数获得一个IIntentReceiver接口对象rd，这是一个Binder对象，接下来会把它传给ActivityManagerService，ActivityManagerService在收到相应的广播时，就是通过这个Binder对象来通知MainActivity来接收的。 我们也是先来看一下mPackageInfo.getReceiverDispatcher函数的实现，然后再回过头来继续分析ContextImpl.registerReceiverInternal函数。 **Step 4. LoadedApk.getReceiverDispatcher** 这个函数实现在frameworks/base/core/java/android/app/LoadedApk.java文件中： ~~~ final class LoadedApk { ...... public IIntentReceiver getReceiverDispatcher(BroadcastReceiver r, Context context, Handler handler, Instrumentation instrumentation, boolean registered) { synchronized (mReceivers) { LoadedApk.ReceiverDispatcher rd = null; HashMap map = null; if (registered) { map = mReceivers.get(context); if (map != null) { rd = map.get(r); } } if (rd == null) { rd = new ReceiverDispatcher(r, context, handler, instrumentation, registered); if (registered) { if (map == null) { map = new HashMap(); mReceivers.put(context, map); } map.put(r, rd); } } else { rd.validate(context, handler); } return rd.getIIntentReceiver(); } } ...... static final class ReceiverDispatcher { final static class InnerReceiver extends IIntentReceiver.Stub { final WeakReference mDispatcher; ...... InnerReceiver(LoadedApk.ReceiverDispatcher rd, boolean strong) { mDispatcher = new WeakReference(rd); ...... } ...... } ...... final IIntentReceiver.Stub mIIntentReceiver; final Handler mActivityThread; ...... ReceiverDispatcher(BroadcastReceiver receiver, Context context, Handler activityThread, Instrumentation instrumentation, boolean registered) { ...... mIIntentReceiver = new InnerReceiver(this, !registered); mActivityThread = activityThread; ...... } ...... IIntentReceiver getIIntentReceiver() { return mIIntentReceiver; } } ...... } ~~~ 在LoadedApk.getReceiverDispatcher函数中，首先看一下参数r是不是已经有相应的ReceiverDispatcher存在了，如果有，就直接返回了，否则就新建一个ReceiverDispatcher，并且以r为Key值保在一个HashMap中，而这个HashMap以Context，这里即为MainActivity为Key值保存在LoadedApk的成员变量mReceivers中，这样，只要给定一个Activity和BroadcastReceiver，就可以查看LoadedApk里面是否已经存在相应的广播接收发布器ReceiverDispatcher了。 在新建广播接收发布器ReceiverDispatcher时，会在构造函数里面创建一个InnerReceiver实例，这是一个Binder对象，实现了IIntentReceiver接口，可以通过ReceiverDispatcher.getIIntentReceiver函数来获得，获得后就会把它传给ActivityManagerService，以便接收广播。在ReceiverDispatcher类的构造函数中，还会把传进来的Handle类型的参数activityThread保存下来，以便后面在分发广播的时候使用。 现在，再回到ContextImpl.registerReceiverInternal函数，在获得了IIntentReceiver类型的Binder对象后，就开始要把它注册到ActivityManagerService中去了。 **Step 5. ActivityManagerProxy.registerReceiver** 这个函数实现在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public Intent registerReceiver(IApplicationThread caller, IIntentReceiver receiver, IntentFilter filter, String perm) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); data.writeStrongBinder(receiver != null ? receiver.asBinder() : null); filter.writeToParcel(data, 0); data.writeString(perm); mRemote.transact(REGISTER_RECEIVER_TRANSACTION, data, reply, 0); reply.readException(); Intent intent = null; int haveIntent = reply.readInt(); if (haveIntent != 0) { intent = Intent.CREATOR.createFromParcel(reply); } reply.recycle(); data.recycle(); return intent; } ...... } ~~~ 这个函数通过Binder驱动程序就进入到ActivityManagerService中的registerReceiver函数中去了。 **Step 6. ActivityManagerService.registerReceiver** 这个函数实现在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public Intent registerReceiver(IApplicationThread caller, IIntentReceiver receiver, IntentFilter filter, String permission) { synchronized(this) { ProcessRecord callerApp = null; if (caller != null) { callerApp = getRecordForAppLocked(caller); if (callerApp == null) { ...... } } List allSticky = null; // Look for any matching sticky broadcasts... Iterator actions = filter.actionsIterator(); if (actions != null) { while (actions.hasNext()) { String action = (String)actions.next(); allSticky = getStickiesLocked(action, filter, allSticky); } } else { ...... } // The first sticky in the list is returned directly back to // the client. Intent sticky = allSticky != null ? (Intent)allSticky.get(0) : null; ...... if (receiver == null) { return sticky; } ReceiverList rl = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder()); if (rl == null) { rl = new ReceiverList(this, callerApp, Binder.getCallingPid(), Binder.getCallingUid(), receiver); if (rl.app != null) { rl.app.receivers.add(rl); } else { ...... } mRegisteredReceivers.put(receiver.asBinder(), rl); } BroadcastFilter bf = new BroadcastFilter(filter, rl, permission); rl.add(bf); ...... mReceiverResolver.addFilter(bf); // Enqueue broadcasts for all existing stickies that match // this filter. if (allSticky != null) { ...... } return sticky; } } ...... } ~~~ 函数首先是获得调用registerReceiver函数的应用程序进程记录块： ~~~ ProcessRecord callerApp = null; if (caller != null) { callerApp = getRecordForAppLocked(caller); if (callerApp == null) { ...... } } ~~~ 这里得到的便是上一篇文章Android系统中的广播（Broadcast）机制简要介绍和学习计划里面介绍的应用程序Broadcast的进程记录块了，MainActivity就是在里面启动起来的。 ~~~ List allSticky = null; // Look for any matching sticky broadcasts... Iterator actions = filter.actionsIterator(); if (actions != null) { while (actions.hasNext()) { String action = (String)actions.next(); allSticky = getStickiesLocked(action, filter, allSticky); } } else { ...... } // The first sticky in the list is returned directly back to // the client. Intent sticky = allSticky != null ? (Intent)allSticky.get(0) : null; ~~~ 这里传进来的filter只有一个action，就是前面描述的CounterService.BROADCAST_COUNTER_ACTION了，这里先通过getStickiesLocked函数查找一下有没有对应的sticky intent列表存在。什么是Sticky Intent呢？我们在最后一次调用sendStickyBroadcast函数来发送某个Action类型的广播时，系统会把代表这个广播的Intent保存下来，这样，后来调用registerReceiver来注册相同Action类型的广播接收器，就会得到这个最后发出的广播。这就是为什么叫做Sticky Intent了，这个最后发出的广播虽然被处理完了，但是仍然被粘住在ActivityManagerService中，以便下一个注册相应Action类型的广播接收器还能继承处理。 这里，假设我们不使用sendStickyBroadcast来发送CounterService.BROADCAST_COUNTER_ACTION类型的广播，于是，这里得到的allSticky和sticky都为null了。 继续往下看，这里传进来的receiver不为null，于是，继续往下执行： ~~~ ReceiverList rl = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder()); if (rl == null) { rl = new ReceiverList(this, callerApp, Binder.getCallingPid(), Binder.getCallingUid(), receiver); if (rl.app != null) { rl.app.receivers.add(rl); } else { ...... } mRegisteredReceivers.put(receiver.asBinder(), rl); } ~~~ 这里其实就是把广播接收器receiver保存一个ReceiverList列表中，这个列表的宿主进程是rl.app，这里就是MainActivity所在的进程了，在ActivityManagerService中，用一个进程记录块来表示这个应用程序进程，它里面有一个列表receivers，专门用来保存这个进程注册的广播接收器。接着，又把这个ReceiverList列表以receiver为Key值保存在ActivityManagerService的成员变量mRegisteredReceivers中，这些都是为了方便在收到广播时，快速找到对应的广播接收器的。 再往下看： ~~~ BroadcastFilter bf = new BroadcastFilter(filter, rl, permission); rl.add(bf); ...... mReceiverResolver.addFilter(bf); ~~~ 上面只是把广播接收器receiver保存起来了，但是还没有把它和filter关联起来，这里就创建一个BroadcastFilter来把广播接收器列表rl和filter关联起来，然后保存在ActivityManagerService中的成员变量mReceiverResolver中去。 这样，广播接收器注册的过程就介绍完了，比较简单，但是工作又比较琐碎，主要就是将广播接收器receiver及其要接收的广播类型filter保存在ActivityManagerService中，以便以后能够接收到相应的广播并进行处理，在下一篇文章，我们将详细分析这个过程，敬请关注。

原文出处——>[Android系统中的广播（Broadcast）机制简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/6730748) 在Android系统中，广播（Broadcast）是在组件之间传播数据（Intent）的一种机制；这些组件甚至是可以位于不同的进程中，这样它就像Binder机制一样，起到进程间通信的作用；本文通过一个简单的例子来学习Android系统的广播机制，为后续分析广播机制的源代码作准备。 在Android系统中，为什么需要广播机制呢？广播机制，本质上它就是一种组件间的通信方式，如果是两个组件位于不同的进程当中，那么可以用Binder机制来实现，如果两个组件是在同一个进程中，那么它们之间可以用来通信的方式就更多了，这样看来，广播机制似乎是多余的。然而，广播机制却是不可替代的，它和Binder机制不一样的地方在于，广播的发送者和接收者事先是不需要知道对方的存在的，这样带来的好处便是，系统的各个组件可以松耦合地组织在一起，这样系统就具有高度的可扩展性，容易与其它系统进行集成。 在软件工程中，是非常强调模块之间的高内聚低耦合性的，不然的话，随着系统越来越庞大，就会面临着越来越难维护的风险，最后导致整个项目的失败。Android应用程序的组织方式，可以说是把这种高内聚低耦合性的思想贯彻得非常透彻，在任何一个Activity中，都可以使用一个简单的Intent，通过startActivity或者startService，就可以把另外一个Activity或者Service启动起来为它服务，而且它根本上不依赖这个Activity或者Service的实现，只需要知道它的字符串形式的名字即可，而广播机制更绝，它连接收者的名字都不需要知道。 不过话又说回来，广播机制在Android系统中，也不算是什么创新的东西。如果读者了解J2EE或者COM，就会知道，在J2EE中，提供了消息驱动Bean（Message-Driven Bean），用来实现应用程序各个组件之间的消息传递；而在COM中，提供了连接点（Connection Point）的概念，也是用来在应用程序各个组间间进行消息传递。无论是J2EE中的消息驱动Bean，还是COM中的连接点，或者Android系统的广播机制，它们的实现机理都是消息发布/订阅模式的事件驱动模型，消息的生产者发布事件，而使用者订阅感兴趣的事件。 废话说了一大堆，现在开始进入主题了，和前面的文章一样，我们通过具体的例子来介绍Android系统的广播机制。在这个例子中，有一个Service，它在另外一个线程中实现了一个计数器服务，每隔一秒钟就自动加1，然后将结果不断地反馈给应用程序中的界面线程，而界面线程中的Activity在得到这个反馈后，就会把结果显示在界面上。为什么要把计数器服务放在另外一个线程中进行呢？我们可以把这个计数器服务想象成是一个耗时的计算型逻辑，如果放在界面线程中去实现，那么势必就会导致应用程序不能响应界面事件，最后导致应用程序产生ANR（Application Not Responding）问题。计数器线程为了把加1后的数字源源不断地反馈给界面线程，这时候就可以考虑使用广播机制了。 首先在Android源代码工程中创建一个Android应用程序工程，名字就称为Broadcast吧。关于如何获得Android源代码工程，请参考在Ubuntu上下载、编译和安装Android最新源代码一文；关于如何在Android源代码工程中创建应用程序工程，请参考在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文。这个应用程序工程定义了一个名为shy.luo.broadcast的package，这个例子的源代码主要就是实现在这里了。下面，将会逐一介绍这个package里面的文件。 首先，我们在src/shy/luo/broadcast/ICounterService.java文件中定义计数器的服务接口： ~~~ package shy.luo.broadcast; public interface ICounterService { public void startCounter(int initVal); public void stopCounter(); } ~~~ 这个接口很简单，它只有两个成员函数，分别用来启动和停止计数器；启动计数时，还可以指定计数器的初始值。 接着，我们来看一个应用程序的默认Activity的实现，在src/shy/luo/broadcast/MainActivity.java文件中： ~~~ package shy.luo.broadcast; import android.app.Activity; import android.content.BroadcastReceiver; import android.content.ComponentName; import android.content.Context; import android.content.Intent; import android.content.IntentFilter; import android.content.ServiceConnection; import android.os.Bundle; import android.os.IBinder; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.TextView; public class MainActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.broadcast.MainActivity"; private Button startButton = null; private Button stopButton = null; private TextView counterText = null; private ICounterService counterService = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); startButton = (Button)findViewById(R.id.button_start); stopButton = (Button)findViewById(R.id.button_stop); counterText = (TextView)findViewById(R.id.textview_counter); startButton.setOnClickListener(this); stopButton.setOnClickListener(this); startButton.setEnabled(true); stopButton.setEnabled(false); Intent bindIntent = new Intent(MainActivity.this, CounterService.class); bindService(bindIntent, serviceConnection, Context.BIND_AUTO_CREATE); Log.i(LOG_TAG, "Main Activity Created."); } @Override public void onResume() { super.onResume(); IntentFilter counterActionFilter = new IntentFilter(CounterService.BROADCAST_COUNTER_ACTION); registerReceiver(counterActionReceiver, counterActionFilter); } @Override public void onPause() { super.onPause(); unregisterReceiver(counterActionReceiver); } @Override public void onDestroy() { super.onDestroy(); unbindService(serviceConnection); } @Override public void onClick(View v) { if(v.equals(startButton)) { if(counterService != null) { counterService.startCounter(0); startButton.setEnabled(false); stopButton.setEnabled(true); } } else if(v.equals(stopButton)) { if(counterService != null) { counterService.stopCounter(); startButton.setEnabled(true); stopButton.setEnabled(false); } } } private BroadcastReceiver counterActionReceiver = new BroadcastReceiver(){ public void onReceive(Context context, Intent intent) { int counter = intent.getIntExtra(CounterService.COUNTER_VALUE, 0); String text = String.valueOf(counter); counterText.setText(text); Log.i(LOG_TAG, "Receive counter event"); } }; private ServiceConnection serviceConnection = new ServiceConnection() { public void onServiceConnected(ComponentName className, IBinder service) { counterService = ((CounterService.CounterBinder)service).getService(); Log.i(LOG_TAG, "Counter Service Connected"); } public void onServiceDisconnected(ComponentName className) { counterService = null; Log.i(LOG_TAG, "Counter Service Disconnected"); } }; } ~~~ MainActivity的实现也很简单，它在创建（onCreate）的时候，会调用bindService函数来把计数器服务（CounterService）启动起来，它的第二个参数serviceConnection是一个ServiceConnection实例。计数器服务启动起来后，系统会调用这个实例的onServiceConnected函数将一个Binder对象传回来，通过调用这个Binder对象的getService函数，就可以获得计数器服务接口。这里，把这个计数器服务接口保存在MainActivity的counterService成员变量中。同样，当我们调用unbindService停止计数器服务时，系统会调用这个实例的onServiceDisconnected函数告诉MainActivity，它与计数器服务的连接断开了。 注意，这里通过调用bindService函数来启动Service时，这个Service与启动它的Activity是位于同一个进程中，它不像我们在前面一篇文章Android系统在新进程中启动自定义服务过程（startService）的原理分析中所描述那样在新的进程中启动服务，后面我们再写一篇文章来分析bindService启动服务的过程。 在MainActivity的onResume函数中，通过调用registerReceiver函数注册了一个广播接收器counterActionReceiver，它是一个BroadcastReceiver实例，并且指定了这个广播接收器只对CounterService.BROADCAST_COUNTER_ACTION类型的广播感兴趣。当CounterService发出一个CounterService.BROADCAST_COUNTER_ACTION类型的广播时，系统就会把这个广播发送到counterActionReceiver实例的onReceiver函数中去。在onReceive函数中，从参数intent中取出计数器当前的值，显示在界面上。 MainActivity界面上有两个按钮，分别是Start Counter和Stop Counter按钮，点击前者开始计数，而点击后者则停止计数。 计数器服务CounterService实现在src/shy/luo/broadcast/CounterService.java文件中： ~~~ package shy.luo.broadcast; import android.app.Service; import android.content.Intent; import android.os.AsyncTask; import android.os.Binder; import android.os.IBinder; import android.util.Log; public class CounterService extends Service implements ICounterService { private final static String LOG_TAG = "shy.luo.broadcast.CounterService"; public final static String BROADCAST_COUNTER_ACTION = "shy.luo.broadcast.COUNTER_ACTION"; public final static String COUNTER_VALUE = "shy.luo.broadcast.counter.value"; private boolean stop = false; private final IBinder binder = new CounterBinder(); public class CounterBinder extends Binder { public CounterService getService() { return CounterService.this; } } @Override public IBinder onBind(Intent intent) { return binder; } @Override public void onCreate() { super.onCreate(); Log.i(LOG_TAG, "Counter Service Created."); } @Override public void onDestroy() { Log.i(LOG_TAG, "Counter Service Destroyed."); } public void startCounter(int initVal) { AsyncTask task = new AsyncTask() { @Override protected Integer doInBackground(Integer... vals) { Integer initCounter = vals[0]; stop = false; while(!stop) { publishProgress(initCounter); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } initCounter++; } return initCounter; } @Override protected void onProgressUpdate(Integer... values) { super.onProgressUpdate(values); int counter = values[0]; Intent intent = new Intent(BROADCAST_COUNTER_ACTION); intent.putExtra(COUNTER_VALUE, counter); sendBroadcast(intent); } @Override protected void onPostExecute(Integer val) { int counter = val; Intent intent = new Intent(BROADCAST_COUNTER_ACTION); intent.putExtra(COUNTER_VALUE, counter); sendBroadcast(intent); } }; task.execute(0); } public void stopCounter() { stop = true; } } ~~~ 这个计数器服务实现了ICounterService接口。当这个服务被binderService函数启动时，系统会调用它的onBind函数，这个函数返回一个Binder对象给系统。上面我们说到，当MainActivity调用bindService函数来启动计数器服务器时，系统会调用MainActivity的ServiceConnection实例serviceConnection的onServiceConnected函数通知MainActivity，这个服务已经连接上了，并且会通过这个函数传进来一个Binder远程对象，这个Binder远程对象就是来源于这里的onBind的返回值了。 函数onBind返回的Binder对象是一个自定义的CounterBinder实例，它实现了一个getService成员函数。当系统通知MainActivity，计数器服务已经启动起来并且连接成功后，并且将这个Binder对象传给MainActivity时，MainActivity就会把这个Binder对象强制转换为CounterBinder实例，然后调用它的getService函数获得服务接口。这样，MainActivity就通过这个Binder对象和CounterService关联起来了。 当MainActivity调用计数器服务接口的startCounter函数时，计数器服务并不是直接进入计数状态，而是通过使用异步任务（AsyncTask）在后台线程中进行计数。这里为什么要使用异步任务来在后台线程中进行计数呢？前面我们说过，这个计数过程是一个耗时的计算型逻辑，不能把它放在界面线程中进行，因为这里的CounterService启动时，并没有在新的进程中启动，它与MainActivity一样，运行在应用程序的界面线程中，因此，这里需要使用异步任务在在后台线程中进行计数。 异步任务AsyncTask的具体用法可以参考官方文档http://developer.android.com/reference/android/os/AsyncTask.html 。它的大概用法是，当我们调用异步任务实例的execute（task.execute）方法时，当前调用线程就返回了，系统启动一个后台线程来执行这个异步任务实例的doInBackground函数，这个函数就是我们用来执行耗时计算的地方了，它会进入到一个循环中，每隔1秒钟就把计数器加1，然后进入休眠（Thread.sleep），醒过来，再重新这个计算过程。在计算的过程中，可以通过调用publishProgress函数来通知调用者当前计算的进度，好让调用者来更新界面，调用publishProgress函数的效果最终就是直入到这个异步任务实例的onProgressUpdate函数中，这里就可以把这个进度值以广播的形式（sendBroadcast）发送出去了，这里的进度值就定义为当前计数服务的计数值。 当MainActivity调用计数器服务接口的stopCounter函数时，会告诉函数doInBackground停止执行计数（stop = true），于是，函数doInBackground就退出计数循环，然后将最终计数结果返回了，返回的结果最后进入到onPostExecute函数中，这个函数同样通过广播的形式（sendBroadcast）把这个计数结果广播出去。 计算器服务就介绍到这里了，下面我们看看应用程序的配置文件AndroidManifest.xml： ~~~ ~~~ 这个配置文件很简单，只是告诉系统，它有一个Activity和一个Service。 再来看MainActivity的界面文件，它定义在res/layout/main.xml文件中： ~~~ ~~~ 这个界面配置文件也很简单，等一下我们在模拟器把这个应用程序启动起来后，就可以看到它的截图了。 应用程序用到的字符串资源文件位于res/values/strings.xml文件中： ~~~ Broadcast Counter: Start Counter Stop Counter ~~~ 最后，我们还要在工程目录下放置一个编译脚本文件Android.mk： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := Broadcast include $(BUILD_PACKAGE) ~~~ 接下来就要编译了。有关如何单独编译Android源代码工程的模块，以及如何打包system.img，请参考如何单独编译Android源代码中的模块一文。 执行以下命令进行编译和打包： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Broadcast USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们前面创建的Broadcast应用程序了。 再接下来，就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器，请参考在Ubuntu上下载、编译和安装Android最新源代码一文。 执行以下命令启动模拟器： ~~~ USER-NAME@MACHINE-NAME:~/Android$ emulator ~~~ 模拟器启动起，就可以App Launcher中找到Broadcast应用程序图标，接着把它启动起来，然后点击界面上的Start Counter按钮，就可以把计数器服务启动起来了，计数器服务又通过广播把计数值反馈给MainActivity，于是，我们就会在MainActivity界面看到计数器的值不断地增加了：  这样，使用广播的例子就介绍完了。回顾一下，使用广播的两个步骤： 1. 广播的接收者需要通过调用registerReceiver函数告诉系统，它对什么样的广播有兴趣，即指定IntentFilter，并且向系统注册广播接收器，即指定BroadcastReceiver： ~~~ IntentFilter counterActionFilter = new IntentFilter(CounterService.BROADCAST_COUNTER_ACTION); registerReceiver(counterActionReceiver, counterActionFilter); ~~~ 这里，指定感兴趣的广播就是CounterService.BROADCAST_COUNTER_ACTION了，而指定的广播接收器就是counterActonReceiver，它是一个BroadcastReceiver类型的实例。 2. 广播的发送者通过调用sendBroadcast函数来发送一个指定的广播，并且可以指定广播的相关参数： ~~~ Intent intent = new Intent(BROADCAST_COUNTER_ACTION); intent.putExtra(COUNTER_VALUE, counter); sendBroadcast(intent) ~~~ 这里，指定的广播为CounterService.BROADCAST_COUNTER_ACTION，并且附带的带参数当前的计数器值counter。调用了sendBroadcast函数之后，所有注册了CounterService.BROADCAST_COUNTER_ACTION广播的接收者便可以收到这个广播了。 在第1步中，广播的接收者把广播接收器注册到ActivityManagerService中；在第2步中，广播的发送者同样是把广播发送到ActivityManagerService中，由ActivityManagerService去查找注册了这个广播的接收者，然后把广播分发给它们。 在第2步的分发的过程，其实就是把这个广播转换成一个消息，然后放入到接收器所在的线程消息队列中去，最后就可以在消息循环中调用接收器的onReceive函数了。这里有一个要非常注意的地方是，由于ActivityManagerService把这个广播放进接收器所在的线程消息队列后，就返回了，它不关心这个消息什么时候会被处理，因此，对广播的处理是异步的，即调用sendBroadcast时，这个函数不会等待这个广播被处理完后才返回。 下面，我们以一个序列图来总结一下，广播的注册和发送的过程：  虚线上面Step 1到Step 4步是注册广播接收器的过程，其中Step 2通过LoadedApk.getReceiverDispatcher在LoadedApk内部创建了一个IIntentReceiver接口，并且传递给ActivityManagerService；虚线下面的Step 5到Step 11是发送广播的过程，在Step 8中，ActivityManagerService利用上面得到的IIntentReceiver远程接口，调用LoadedApk.performReceiver接口，LoadedApk.performReceiver接口通过ActivityThread.H接口的post函数将这个广播消息放入到ActivityThread的消息队列中去，最后这个消息在LoadedApk的Args.run函数中处理，LoadedApk.Args.run函数接着调用MainActivity.BroadcastReceiver的onReceive函数来最终处理这个广播。 文章开始的时候，我们提到，举这个例子的最终目的，是为了进一步学习Android系统的广播机制，因此，在接下来的两篇文章中，我们将详细描述上述注册广播接收器和发送广播的过程： 1. Android应用程序注册广播接收器（registerReceiver）的过程分析； 2. Android应用程序发送广播（sendBroadcast）的过程分析。 相信学习完这两篇文章后，能够加深对Android系统广播机制的了解，敬请关注。

[Android系统中的广播（Broadcast）机制简要介绍和学习计划](Android%E7%B3%BB%E7%BB%9F%E4%B8%AD%E7%9A%84%E5%B9%BF%E6%92%AD%EF%BC%88Broadcast%EF%BC%89%E6%9C%BA%E5%88%B6%E7%AE%80%E8%A6%81%E4%BB%8B%E7%BB%8D%E5%92%8C%E5%AD%A6%E4%B9%A0%E8%AE%A1%E5%88%92.md) [Android应用程序注册广播接收器（registerReceiver）的过程分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E6%B3%A8%E5%86%8C%E5%B9%BF%E6%92%AD%E6%8E%A5%E6%94%B6%E5%99%A8%EF%BC%88registerReceiver%EF%BC%89%E7%9A%84%E8%BF%87%E7%A8%8B%E5%88%86%E6%9E%90.md) [Android应用程序发送广播（sendBroadcast）的过程分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E5%8F%91%E9%80%81%E5%B9%BF%E6%92%AD%EF%BC%88sendBroadcast%EF%BC%89%E7%9A%84%E8%BF%87%E7%A8%8B%E5%88%86%E6%9E%90.md)

原文出处——>[Android应用程序组件Content Provider的共享数据更新通知机制分析](http://blog.csdn.net/luoshengyang/article/details/6985171) 在Android系统中，应用程序组件Content Provider为不同的应用程序实现数据共享提供了基础设施，它主要通过Binder进程间通信机制和匿名共享内存机制来实现的。关于数据共享的另一个话题便是数据更新通知机制了，即如果一个应用程序对共享数据做了修改，它应该如何通知其它正在使用这些共享数据的应用程序呢？本文将分析Content Provider的共享数据更新通知机制，为读者解答这个问题。 Android应用程序组件Content Provider中的数据更新通知机制和Android系统中的广播（Broadcast）通知机制的实现思路是相似的。在Android的广播机制中，首先是接收者对自己感兴趣的广播进行注册，接着当发送者发出这些广播时，接收者就会得到通知了。更多关于Android系统的广播机制的知识，可以参考前面Android系统中的广播（Broadcast）机制简要介绍和学习计划这一系列文章。然而，Content Provider中的数据监控机制与Android系统中的广播机制又有三个主要的区别，一是前者是通过URI来把通知的发送者和接收者关联在一起的，而后者是通过Intent来关联的，二是前者的通知注册中心是由ContentService服务来扮演的，而后者是由ActivityManagerService服务来扮演的，三是前者负责接收数据更新通知的类必须要继承ContentObserver类，而后者要继承BroadcastReceiver类。之所以会有这些区别，是由于Content Proivder组件的数据共享功能本身就是建立在URI的基础之上的，因此专门针对URI来设计另外一套通知机制会更实用和方便，而Android系统的广播机制是一种更加通用的事件通知机制，它的适用范围会更广泛一些。 与分析Android系统的广播机制类似，我们把Content Provider的数据更新机制划分为三个单元进行分析，第一个单元是ContentService的启动过程，第二个单元是监控数据变化的ContentObserver的注册过程，第二个单元是数据更新通知的发送过程。 与前面两篇文章Android应用程序组件Content Provider的启动过程源代码分析和Android应用程序组件Content Provider在应用程序之间共享数据的原理分析一样，本文仍然以Android应用程序组件Content Provider应用实例这篇文章介绍的应用程序为例来分析Content Provider的数据更新机制。 1. ContentService的启动过程分析 前面提到，在Content Provider的数据更新通知机制中，ContentService扮演者ContentObserver的注册中心的角色，因此，它必须要系统启动的时候就启动起来，以便后面启动起来的应用程序可以使用它。在前面这篇文章Android系统进程Zygote启动过程的源代码分析中，我们提到，Android系统进程Zygote在启动的时候，在启动一个System进程来加载系统的一些关键服务，而ContentService就这些关键服务之一了。在System进程中，负责加载系统关键服务的类为SystemServer类，它定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中，它会通过启动一个线程SystemThread来加载这些关键服务： ~~~ class ServerThread extends Thread { ...... @Override public void run() { ...... Looper.prepare(); // Critical services... try { ...... ContentService.main(context, factoryTest == SystemServer.FACTORY_TEST_LOW_LEVEL); ...... }catch (RuntimeException e) { ...... } ...... Looper.loop(); ...... } } ~~~ ContentService类定义在frameworks/base/core/java/android/content/ContentService.java文件中，它的main函数的实现如下所示： ~~~ public final class ContentService extends IContentService.Stub { ...... public static IContentService main(Context context, boolean factoryTest) { ContentService service = new ContentService(context, factoryTest); ServiceManager.addService(ContentResolver.CONTENT_SERVICE_NAME, service); return service; } ...... } ~~~ 从这里我们就可以看到，在ContentService类的main函数中，会创建一个ContentService实例，然后把它添加到ServiceManager中去，这样，ContentService服务就启动起来了， 其它地方可以通过ServiceManager来获得它的一个远程接口来使用它提供的服务。 2. ContentObserver的注册过程分析 在前面这篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Acticle中，主窗口MainActivity在创建的时候，会调用应用程序上下文的ContentResolver接口来注册一个自定义的ContentObserver来监控ArticlesProvider这个Content Provider中的数据变化： ~~~ public class MainActivity extends Activity implements View.OnClickListener, AdapterView.OnItemClickListener { ...... private ArticleAdapter adapter = null; private ArticleObserver observer = null; ...... @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); ...... observer = new ArticleObserver(new Handler()); getContentResolver().registerContentObserver(Articles.CONTENT_URI, true, observer); ...... } private class ArticleObserver extends ContentObserver { public ArticleObserver(Handler handler) { super(handler); } @Override public void onChange (boolean selfChange) { adapter.notifyDataSetChanged(); } } ...... } ~~~ 从ContentObserver继承下来的子类必须要实现onChange函数。当这个ContentObserver子类负责监控的数据发生变化时，ContentService就会调用它的onChange函数来处理，参数selfChange表示这个变化是否是由自己引起的，在我们这个情景中，不需要关注这个参数的值。在这个应用程序中，ArticleObserver继承了ContentObserver类，它负责监控的URI是Articles.CONTENT_URI，它的值为"content://shy.luo.providers.articles/item" ，这个值是在这篇文章Android应用程序组件Content Provider应用实例介绍的应用程序ActiclesProvider中的Articles.java文件中定义的。当所有以Articles.CONTENT_URI为前缀的URI对应的数据发生改变时，ContentService都会调用这个ArticleObserver类的onChange函数来处理。在ArticleObserver类的onChange函数中，执行的操作就是重新获取ActiclesProvider中的数据来更新界面上的文章信息列表。 在ArticleObserver类的构造函数中，有一个参数handler，它的类型为Handler，它是从MainActivity类的onCreate函数中创建并传过来的。通过前面这篇文章Android应用程序消息处理机制（Looper、Handler）分析的学习，我们知道，这个handler是用来分发和处理消息用的。由于MainActivity类的onCreate函数是在应用程序的主线程中被调用的，因此，这个handler参数就是和应用程序主线程的消息循环关联在一起的。在后面我们分析数据更新通知的发送过程时，便会看到这个handler参数是如何使用的了。 下面我们就开始分析注册ArticleObserver来监控ActiclesProvider中的数据变化的过程，首先来看一下这个过程的时序图，然后再详细分析每一个步骤：  * **Step 1. ContentResolver.registerContentObserver** 这个函数定义在**frameworks/base/core/java/android/content/ContentResolver.java**文件中： ~~~ public abstract class ContentResolver { ...... public final void registerContentObserver(Uri uri, boolean notifyForDescendents, ContentObserver observer) { try { getContentService().registerContentObserver(uri, notifyForDescendents, observer.getContentObserver()); } catch (RemoteException e) { } } ...... } ~~~ 当参数notifyForDescendents为true时，表示要监控所有以uri为前缀的URI对应的数据变化。这个函数做了三件事情，一是调用getContentService函数来获得前面已经启动起来了的ContentService远程接口，二是调用从参数传进来的ContentObserver对象observer的getContentObserver函数来获得一个Binder对象，三是通过调用这个ContentService远程接口的registerContentObserver函数来把这个Binder对象注册到ContentService中去。 * **Step 2.ContentResolver.getContentService** 这个函数定义在**frameworks/base/core/java/android/content/ContentResolver.java**文件中： ~~~ public abstract class ContentResolver { ...... public static IContentService getContentService() { if (sContentService != null) { return sContentService; } IBinder b = ServiceManager.getService(CONTENT_SERVICE_NAME); ...... sContentService = IContentService.Stub.asInterface(b); ...... return sContentService; } private static IContentService sContentService; ...... } ~~~ 在ContentResolver类中，有一个静态成员变量sContentService，开始时它的值为null。当ContentResolver类的getContentService函数第一次被调用时，它便会通过ServiceManager类的getService函数来获得前面已经启动起来了的ContentService服务的远程接口，然后把它保存在sContentService变量中。这样，当下次ContentResolver类的getContentService函数再次被调用时，就可以直接把这个ContentService远程接口返回给调用者了。 * **Step 3. ContentObserver.getContentObserver** 这个函数定义在**frameworks/base/core/java/android/database/ContentObserver.java**文件中： ~~~ public abstract class ContentObserver { ...... private Transport mTransport; ...... private static final class Transport extends IContentObserver.Stub { ContentObserver mContentObserver; public Transport(ContentObserver contentObserver) { mContentObserver = contentObserver; } ...... } ...... public IContentObserver getContentObserver() { synchronized(lock) { if (mTransport == null) { mTransport = new Transport(this); } return mTransport; } } ...... } ~~~ ContentObserver类的getContentObserver函数返回的是一个成员变量mTransport，它的类型为ContentObserver的内部类Transport。从Transport类的定义我们可以知道，它有一个成员变量mContentObserver，用来保存与对应的ContentObserver对象。同时我们还可以看出，ContentObserver类的成员变量mTransport是一个Binder对象，它是要传递给ContentService服务的，以便当ContentObserver所监控的数据发生变化时，ContentService服务可以通过这个Binder对象通知相应的ContentObserver它监控的数据发生变化了。 * **Step 4. ContentService.registerContentObserver** 这个函数定义在**frameworks/base/core/java/android/content/ContentService.java**文件中： ~~~ public final class ContentService extends IContentService.Stub { ...... private final ObserverNode mRootNode = new ObserverNode(""); ...... public void registerContentObserver(Uri uri, boolean notifyForDescendents, IContentObserver observer) { ...... synchronized (mRootNode) { mRootNode.addObserverLocked(uri, observer, notifyForDescendents, mRootNode); ...... } } ...... } ~~~ 它调用了ContentService类的成员变量mRootNode的addObserverLocked函数来注册这个ContentObserver对象observer。成员变量mRootNode的类型为ContentService在内部定义的一个类ObserverNode。 * **Step 5. ObserverNode.addObserverLocked** 这个函数定义在**frameworks/base/core/java/android/content/ContentService.java**文件中： ~~~ public final class ContentService extends IContentService.Stub { ...... public static final class ObserverNode { ...... private String mName; private ArrayList mChildren = new ArrayList(); private ArrayList mObservers = new ArrayList(); public ObserverNode(String name) { mName = name; } private String getUriSegment(Uri uri, int index) { if (uri != null) { if (index == 0) { return uri.getAuthority(); } else { return uri.getPathSegments().get(index - 1); } } else { return null; } } private int countUriSegments(Uri uri) { if (uri == null) { return 0; } return uri.getPathSegments().size() + 1; } public void addObserverLocked(Uri uri, IContentObserver observer, boolean notifyForDescendents, Object observersLock) { addObserverLocked(uri, 0, observer, notifyForDescendents, observersLock); } private void addObserverLocked(Uri uri, int index, IContentObserver observer, boolean notifyForDescendents, Object observersLock) { // If this is the leaf node add the observer if (index == countUriSegments(uri)) { mObservers.add(new ObserverEntry(observer, notifyForDescendents, observersLock)); return; } // Look to see if the proper child already exists String segment = getUriSegment(uri, index); if (segment == null) { throw new IllegalArgumentException("Invalid Uri (" + uri + ") used for observer"); } int N = mChildren.size(); for (int i = 0; i < N; i++) { ObserverNode node = mChildren.get(i); if (node.mName.equals(segment)) { node.addObserverLocked(uri, index + 1, observer, notifyForDescendents, observersLock); return; } } // No child found, create one ObserverNode node = new ObserverNode(segment); mChildren.add(node); node.addObserverLocked(uri, index + 1, observer, notifyForDescendents, observersLock); } ...... } ...... } ~~~ 从这里我们就可以看出，注册到ContentService中的ContentObserver按照树形来组织，树的节点类型为ObserverNode，而树的根节点就为ContentService类的成员变量mRootNode。每一个ObserverNode节点都对应一个名字，它是从URI中解析出来的。 在我们这个情景中，传进来的uri为"content://shy.luo.providers.articles/item" ，从Step 3调用mRootNode的addObserverLocked函数来往树上增加一个ObserverNode节点时，传进来的参数index的值为0，而调用countUriSegments("content://shy.luo.providers.articles/item")函数的返回值为2，不等于index的值，因此就会往下执行，而通过调用getUriSegment("content://shy.luo.providers.articles/item", 0)函数得到的返回值为"shy.luo.providers.articles"。假设这里是第一次调用树的根节点mRootNode来增加"content://shy.luo.providers.articles/item" 这个URI，那么在接下来的for循环中，就不会在mRootNode的孩子节点列表mChildren中找到与名称"shy.luo.providers.articles"对应的ObserverNode，于是就会以"shy.luo.providers.articles"为名称来创建一个新的ObserverNode，并增加到mRootNode的孩子节点列表mChildren中去，并以这个新的ObserverNode来开始新一轮的addObserverLocked函数调用。 第二次进入到addObserverLocked函数时，countUriSegments("content://shy.luo.providers.articles/item")的值仍为2，而index的值为1，因此就会往下执行，这时候通过调用getUriSegment("content://shy.luo.providers.articles/item", 1)函数得到的返回值为"item"。假设这时候在以"shy.luo.providers.articles/item"为名称的ObserverNode中不存在名称为"item"的孩子节点，于是又会以"item"为名称来创建一个新的ObserverNode，并以这个新的ObserverNode来开始新一轮的addObserverLocked函数调用。 第三次进入到addObserverLocked函数时，countUriSegments("content://shy.luo.providers.articles/item")的值仍为2，而index的值也为2，因此就会新建一个ObserverEntry对象，并保存在这个以"item"为名称的ObserverNode的ContentObserver列表mObervers中。 最终我们得到的树形结构如下所示： ~~~ mRootNode("") -- ObserverNode("shy.luo.providers.articles") --ObserverNode("item") , which has a ContentObserver in mObservers ~~~ 这样，ContentObserver的注册过程就完成了。 3. 数据更新通知的发送过程 在前面这篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Acticle中，当调用ArticlesAdapter类的insertArticle往ArticlesProvider中增加一个文章信息条目时： ~~~ public class ArticlesAdapter { ...... public long insertArticle(Article article) { ContentValues values = new ContentValues(); values.put(Articles.TITLE, article.getTitle()); values.put(Articles.ABSTRACT, article.getAbstract()); values.put(Articles.URL, article.getUrl()); Uri uri = resolver.insert(Articles.CONTENT_URI, values); String itemId = uri.getPathSegments().get(1); return Integer.valueOf(itemId).longValue(); } ...... } ~~~ 便会进入到应用程序ArticlesProvider中的ArticlesProvider类的insert函数中： ~~~ public class ArticlesProvider extends ContentProvider { ...... @Override public Uri insert(Uri uri, ContentValues values) { if(uriMatcher.match(uri) != Articles.ITEM) { throw new IllegalArgumentException("Error Uri: " + uri); } SQLiteDatabase db = dbHelper.getWritableDatabase(); long id = db.insert(DB_TABLE, Articles.ID, values); if(id < 0) { throw new SQLiteException("Unable to insert " + values + " for " + uri); } Uri newUri = ContentUris.withAppendedId(uri, id); resolver.notifyChange(newUri, null); return newUri; } ...... } ~~~ 从上面传来的参数uri的值为"content://shy.luo.providers.articles/item" 。假设当这个函数把数据成功增加到SQLite数据库之后，返回来的id值为n，于是通过调用ContentUris.withAppendedId("content://shy.luo.providers.articles/item", n)得到的newUri的值就为"content://shy.luo.providers.articles/item/n" 。这时候就会调用下面语句来通知那些注册了监控"content://shy.luo.providers.articles/item/n" 这个URI的ContentObserver，它监控的数据发生变化了： ~~~ resolver.notifyChange(newUri, null); ~~~ 下面我们就开始分析这个数据变化通知的发送过程，首先来看一下这个过程的时序图，然后再详细分析每一个步骤：  * **Step 1. ContentResolver.notifyChange** 这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中： ~~~ public abstract class ContentResolver { ...... public void notifyChange(Uri uri, ContentObserver observer) { notifyChange(uri, observer, true /* sync to network */); } public void notifyChange(Uri uri, ContentObserver observer, boolean syncToNetwork) { try { getContentService().notifyChange( uri, observer == null ? null : observer.getContentObserver(), observer != null && observer.deliverSelfNotifications(), syncToNetwork); } catch (RemoteException e) { } } ...... } ~~~ 这里调用了ContentService的远接程口来调用它的notifyChange函数来发送数据更新通知。 * **Step 2. ContentService.notifyChange** 这个函数定义在frameworks/base/core/java/android/content/ContentService.java文件中： ~~~ public final class ContentService extends IContentService.Stub { ...... public void notifyChange(Uri uri, IContentObserver observer, boolean observerWantsSelfNotifications, boolean syncToNetwork) { ...... try { ArrayList calls = new ArrayList(); synchronized (mRootNode) { mRootNode.collectObserversLocked(uri, 0, observer, observerWantsSelfNotifications, calls); } final int numCalls = calls.size(); for (int i=0; i calls) { int N = mObservers.size(); IBinder observerBinder = observer == null ? null : observer.asBinder(); for (int i = 0; i < N; i++) { ObserverEntry entry = mObservers.get(i); // Don't notify the observer if it sent the notification and isn't interesed // in self notifications if (entry.observer.asBinder() == observerBinder && !selfNotify) { continue; } // Make sure the observer is interested in the notification if (leaf || (!leaf && entry.notifyForDescendents)) { calls.add(new ObserverCall(this, entry.observer, selfNotify)); } } } public void collectObserversLocked(Uri uri, int index, IContentObserver observer, boolean selfNotify, ArrayList calls) { String segment = null; int segmentCount = countUriSegments(uri); if (index >= segmentCount) { // This is the leaf node, notify all observers collectMyObserversLocked(true, observer, selfNotify, calls); } else if (index < segmentCount){ segment = getUriSegment(uri, index); // Notify any observers at this level who are interested in descendents collectMyObserversLocked(false, observer, selfNotify, calls); } int N = mChildren.size(); for (int i = 0; i < N; i++) { ObserverNode node = mChildren.get(i); if (segment == null || node.mName.equals(segment)) { // We found the child, node.collectObserversLocked(uri, index + 1, observer, selfNotify, calls); if (segment != null) { break; } } } } } } ~~~ 第一次调用collectObserversLocked时，是在mRootNode的这个ObserverNode节点中进行收集ContentObserver的。这时候传进来的uri的值为"content://shy.luo.providers.articles/item/n" ，index的值为0。调用countUriSegments("content://shy.luo.providers.articles/item/n")函数得到的返回值为3，于是就会调用下面语句： ~~~ segment = getUriSegment("content://shy.luo.providers.articles/item/n",0); // Notify any observers at this level who are interested in descendents collectMyObserversLocked(false, observer, selfNotify, calls); ~~~ 这里得到的segment为"shy.luo.providers.articles"。在我们这个情景中，假设mRootNode这个节点中没有注册ContentObserver，于是调用collectMyObserversLocked函数就不会收集到ContentObserver。 在接下来的for循环中，在mRootNode的孩子节点列表mChildren中查找名称等于"shy.luo.providers.articles"的OberverNode节点。在上面分析ContentObserver的注册过程时，我们已经往mRootNode的孩子节点列表mChildren中增加了一个名称为"shy.luo.providers.articles"的OberverNode节点，因此，这里会成功找到它，并且调用它的collectObserversLocked函数来继续收集ContentObserver。 第二次进入到collectObserversLocked函数时，是在名称为"shy.luo.providers.articles"的OberverNode节点中收集ContentObserver的。这时候传来的uri值不变，但是index的值为1，于是执行下面语句： ~~~ segment = getUriSegment("content://shy.luo.providers.articles/item/n",1); // Notify any observers at this level who are interested in descendents collectMyObserversLocked(false, observer, selfNotify, calls); ~~~ 这里得到的segment为"item"。在我们这个情景中，我们没有在名称为"shy.luo.providers.articles"的OberverNode节点中注册有ContentObserver，因此这里调用collectMyObserversLocked函数也不会收集到ContentObserver。 在接下来的for循环中，在名称为"shy.luo.providers.articles"的ObserverNode节点的孩子节点列表mChildren中查找名称等于"item"的OberverNode节点。在上面分析ContentObserver的注册过程时，我们已经往名称为"shy.luo.providers.articles"的ObserverNode节点的孩子节点列表mChildren中增加了一个名称为"item"的OberverNode节点，因此，这里会成功找到它，并且调用它的collectObserversLocked函数来继续收集ContentObserver。 第三次进入到collectObserversLocked函数时，是在名称为"shy.luo.providers.articles"的OberverNode节点的子节点中名称为"item"的ObserverNode节点中收集ContentObserver的。这时候传来的uri值不变，但是index的值为2，于是执行下面语句： ~~~ segment = getUriSegment("content://shy.luo.providers.articles/item/n",2); // Notify any observers at this level who are interested in descendents collectMyObserversLocked(false, observer, selfNotify, calls); ~~~ 这里得到的segment为"n"。前面我们已经在名称为"shy.luo.providers.articles"的OberverNode节点的子节点中名称为"item"的ObserverNode节点中注册了一个ContentObserver，即ArticlesObserver，因此这里调用collectMyObserversLocked函数会收集到这个ContentObserver。注意，这次调用collectMyObserversLocked函数时，虽然传进去的参数leaf为false，但是由于我们注册ArticlesObserver时，指定了notifyForDescendents参数为true，因此，这里可以把它收集回来。 在接下来的for循环中，继续在该节点的子节点列表mChildren中查找名称等于"n"的OberverNode节点。在我们这个情景中，不存在这个名称为"n"的子节点了，于是收集ContentObserver的工作就结束了，收集结果是只有一个ContentObserver，即我们在前面注册的ArticlesObserver。 返回到Step 2中，调用下面语句来通知相应的ContentObserver，它们监控的数据发生变化了： ~~~ for (int i=0; i ';

原文出处——>[Android应用程序组件Content Provider在应用程序之间共享数据的原理分析](http://blog.csdn.net/luoshengyang/article/details/6967204) 在Android系统中，不同的应用程序是不能直接读写对方的数据文件的，如果它们想共享数据的话，只能通过Content Provider组件来实现。那么，Content Provider组件又是如何突破应用程序边界权限控制来实现在不同的应用程序之间共享数据的呢？在前面的文章中，我们已经简要介绍过它是通过Binder进程间通信机制以及匿名共享内存机制来实现的，在本文中，我们将详细分析它的数据共享原理。 Android应用程序之间不能直接访问对方的数据文件的障碍在于每一个应用程序都有自己的用户ID，而每一个应用程序所创建的文件的读写权限都是只赋予给自己所属的用户，因此，就限制了应用程序之间相互读写数据的操作，关于Android应用程序的权限问题，具体可以参考前面一篇文章Android应用程序组件Content Provider简要介绍和学习计划。通过前面Android进程间通信（IPC）机制Binder简要介绍和学习计划等一系列文章的学习，我们知道，Binder进程间通信机制可以突破了以应用程序为边界的权限控制来实现在不同应用程序之间传输数据，而Content Provider组件在不同应用程序之间共享数据正是基于Binder进程间通信机制来实现的。虽然Binder进程间通信机制突破了以应用程序为边界的权限控制，但是它是安全可控的，因为数据的访问接口是由数据的所有者来提供的，换句话来说，就是数据提供方可以在接口层来实现安全控制，决定哪些数据是可以读，哪些数据可以写。虽然Content Provider组件本身也提供了读写权限控制，但是它的控制粒度是比较粗的，如果有需要，我们还是可以在接口访问层做更细粒度的权限控制以达到数据安全的目的。 Binder进程间通信机制虽然打通了应用程序之间共享数据的通道，但是还有一个问题需要解决，那就是数据要以什么来作来媒介来传输。我们知道，应用程序采用Binder进程间通信机制进行通信时，要传输的数据都是采用函数参数的形式进行的，对于一般的进程间调来来说，这是没有问题的，然而，对于应用程序之间的共享数据来说，它们的数据量可能是非常大的，如果还是简单的用函数参数的形式来传递，效率就会比较低下。通过前面Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划等一系列文章的学习，我们知道，在应用程序进程之间以匿名共享内存的方式来传输数据效率是非常高的，因为它们之间只需要传递一个文件描述符就可以了。因此，Content Provider组件在不同应用程序之间传输数据正是基于匿名共享内存机制来实现的。 在继续分析Content Provider组件在不同应用程序之间共享数据的原理之前，我们假设应用程序之间需要共享的数据是保存在数据库（SQLite）中的，因此，接下来的分析都是基于SQLite数据库游标（SQLiteCursor）来进行的。SQLiteCursor在共享数据的传输过程中发挥着重要的作用，因此，我们先来它和其它相关的类的关系图，如下所示：  首先在第三方应用程序这一侧，当它需要访问Content Provider中的数据时，它会在本进程中创建一个CursorWindow对象，它在内部创建了一块匿名共享内存，同时，它实现了Parcel接口，因此它可以在进程间传输。接下来第三方应用程序把这个CursorWindow对象（连同它内部的匿名共享内存文件描述符）通过Binder进程间调用传输到Content Provider这一侧。这个匿名共享内存文件描述符传输到Binder驱动程序的时候，Binder驱动程序就会在目标进程（即Content Provider所在的进程）中创建另一个匿名共享文件描述符，指向前面已经创建好的匿名共享内存，因此，就实现了在两个进程中共享同一块匿名内存，这个过程具体可以参考Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析一文。 在Content Provider这一侧，利用在Binder驱动程序为它创建好的这个匿名共享内存文件描述符，在本进程中创建了一个CursorWindow对象。现在，Content Provider开始要从本地中从数据库中查询第三方应用程序想要获取的数据了。Content Provider首先会创建一个SQLiteCursor对象，即SQLite数据库游标对象，它继承了AbstractWindowedCursor类，后者又继承了AbstractCursor类，而AbstractCursor类又实现了CrossProcessCursor和Cursor接口。其中，最重要的是在AbstractWindowedCursor类中，有一个成员变量mWindow，它的类型为CursorWindow，这个成员变量是通过AbstractWindowedCursor的子类SQLiteCursor的setWindow成员函数来设置的。这个SQLiteCursor对象设置好了父类AbstractWindowedCursor类的mWindow成员变量之后，它就具有传输数据的能力了，因为这个mWindow对象内部包含一块匿名共享内存。此外，这个SQLiteCursor对象的内部有两个成员变量，一个是SQLite数据库对象mDatabase，另外一个是SQLite数据库查询对象mQuery。SQLite数据库查询对象mQuery的类型为SQLiteQuery，它继承了SQLiteProgram类，后者又继承了SQLiteClosable类。SQLiteProgram类代表一个数据库存查询计划，它的成员变量mCompiledSql包含了一个已经编译好的SQL查询语句，SQLiteCursor对象就是利用这个编译好的SQL查询语句来获得数据的，但是它并不是马上就去获取数据的，而是等到需要时才去获取。 那么，要等到什么时候才会需要获取数据呢？一般来说，如果第三方应用程序在请求Content Provider返回数据时，如果指定了要返回关于这些数据的元信息时，例如数据条目的数量，那么Content Provider在把这个SQLiteCursor对象返回给第三方应用程序之前，就会去获取数据，因为只有获取了数据之后，才知道数据条目的数量是多少。SQLiteCursor对象通过调用成员变量mQuery的fillWindow成员函数来把从SQLite数据库中查询得到的数据保存其父类AbstractWindowedCursor的成员变量mWindow中去，即保存到第三方应用程序创建的这块匿名共享内存中去。如果第三方应用程序在请求Content Provider返回数据时，没有指定要返回关于这些数据的元信息，那么，就要等到第三方应用程序首次调用这个从Content Provider处返回的SQLiteCursor对象的数据获取方法时，才会真正执行从数据库存中查询数据的操作，例如调用了SQLiteCursor对象的getCount或者moveToFirst成员函数时。这是一种数据懒加载机制，需要的时候才去加载，这样就提高了数据传输过程中的效率。 上面说到，Content Provider向第三方应用程序返回的数据实际上是一个SQLiteCursor对象，那么，这个SQLiteCursor对象是如何传输到第三方应用程序的呢？因为它本身并不是一个Binder对象，我们需要对它进行适配一下。首先，Content Provider会根据这个SQLiteCursor对象来创建一个CursorToBulkCursorAdaptor适配器对象，这个适配器对象是一个Binder对象，因此，它可以在进程间传输，同时，它实现了IBulkCursor接口。Content Provider接着就通过Binder进程间通信机制把这个CursorToBulkCursorAdaptor对象返回给第三方应用程序，第三方应用程序得到了这个CursorToBulkCursorAdaptor之后，再在本地创建一个BulkCursorToCursorAdaptor对象，这个BulkCursorToCursorAdaptor对象的继承结构和SQLiteCursor对象是一样的，不过，它没有设置父类AbstractWindowedCursor的mWindow成员变量，因此，它只可以通过它内部的CursorToBulkCursorAdaptor对象引用来访问匿名共享内存中的数据，即通过访问Content Provider这一侧的SQLiteCursor对象来访问共享数据。 上面描述的数据共享模型还是比较复杂的，一下子理解不了也不要紧，下面我们还会结合第三方应用程序和Content Provider传输共享数据的完整过程来进一步分析Content Provider的数据共享原理，到时候再回过头来看这个数据共享模型就会清晰很多了。在接下来的内容中，我们就继续以Android应用程序组件Content Provider应用实例一文的例子来分析Content Provider在不同应用程序之间共享数据的原理。在Android应用程序组件Content Provider应用实例这篇文章介绍的应用程序Article中，它的主窗口MainActivity是通过调用它的内部ArticlesAdapter对象的getArticleByPos成员函数来把ArticlesProvider中的文章信息条目一条一条地取回来显示在ListView中的，在这篇文章中，我们就从ArticlesAdapter类的getArticleByPos函数开始，一步一步地分析第三方应用程序Article从ArticlesProvider这个Content Provider中获取数据的过程。同样，我们先来看看这个过程的序列图，然后再详细分析每一个步骤：  * **Step 1. ArticlesAdapter.getArticleByPos** 这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Artilce源代码工程目录下，在文件为packages/experimental/Article/src/shy/luo/article/ArticlesAdapter.java中： ~~~ public class ArticlesAdapter { ...... private ContentResolver resolver = null; public ArticlesAdapter(Context context) { resolver = context.getContentResolver(); } ...... public Article getArticleByPos(int pos) { Uri uri = ContentUris.withAppendedId(Articles.CONTENT_POS_URI, pos); String[] projection = new String[] { Articles.ID, Articles.TITLE, Articles.ABSTRACT, Articles.URL }; Cursor cursor = resolver.query(uri, projection, null, null, Articles.DEFAULT_SORT_ORDER); if (!cursor.moveToFirst()) { return null; } int id = cursor.getInt(0); String title = cursor.getString(1); String abs = cursor.getString(2); String url = cursor.getString(3); return new Article(id, title, abs, url); } } ~~~ 这个函数通过应用程序上下文的ContentResolver接口resolver的query函数来获得与Articles.CONTENT_POS_URI这个URI对应的文章信息条目。常量Articles.CONTENT_POS_URI是在应用程序ArticlesProvider中定义的，它的值为“content://shy.luo.providers.articles/pos” ，通过调用ContentUris.withAppendedId函数来在后面添加了一个整数，表示要获取指定位置的文章信息条目。这个位置是指ArticlesProvider这个Content Provider中的所有文章信息条目按照Articles.DEFAULT_SORT_ORDER来排序后得到的位置的，常量Articles.DEFAULT_SORT_ORDER也是在应用程序ArticlesProvider中定义的，它的值为“_id asc”，即按照文章信息的ID值从小到大来排列。 * **Step 2. ContentResolver.query** 这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中： ~~~ public abstract class ContentResolver { ...... public final Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) { IContentProvider provider = acquireProvider(uri); if (provider == null) { return null; } try { ...... Cursor qCursor = provider.query(uri, projection, selection, selectionArgs, sortOrder); ...... return new CursorWrapperInner(qCursor, provider); } catch (RemoteException e) { ...... } catch(RuntimeException e) { ...... } } ...... } ~~~ 这个函数首先通过调用acquireProvider函数来获得与参数uri对应的Content Provider接口，然后再通过这个接口的query函数来获得相应的数据。我们先来看看acquireProvider函数的实现，再回过头来分析这个Content Provider接口的query函数的实现。 * **Step 3. ContentResolver.acquireProvider** * **Step 4. ApplicationContentResolver.acquireProvider** * **Step 5. ActivityThread.acquireProvider** * **Step 6. ActivityThread.getProvider** 从Step 3到Step 6是获取与上面Step 2中传进来的参数uri对应的Content Provider接口的过程。在前面一篇文章Android应用程序组件Content Provider的启动过程源代码分析中，我们已经详细介绍过这个过程了，这里不再详述。不过这里我们假设，这个Content Provider接口之前已经创建好了，因此，在Step 6的ActivityThread.getProvider函数中，通过getExistingProvider函数就把之前已经好的Content Provider接口返回来了。 回到Step 2中的ContentResolver.query函数中，它继续调用这个返回来的Content Provider接口来获取数据。从这篇文章Android应用程序组件Content Provider的启动过程源代码分析中，我们知道，这个Content Provider接口实际上是一个在ContentProvider类的内部所创建的一个Transport对象的远程接口。这个Transport类继承了ContentProviderNative类，是一个Binder对象的Stub类，因此，接下来就会进入到这个Binder对象的Proxy类ContentProviderProxy中执行query函数。 * **Step 7. ContentProviderProxy.query** 这个函数定义在**frameworks/base/core/java/android/content/ContentProviderNative.java**文件中： ~~~ final class ContentProviderProxy implements IContentProvider { ...... public Cursor query(Uri url, String[] projection, String selection, String[] selectionArgs, String sortOrder) throws RemoteException { //TODO make a pool of windows so we can reuse memory dealers CursorWindow window = new CursorWindow(false /* window will be used remotely */); BulkCursorToCursorAdaptor adaptor = new BulkCursorToCursorAdaptor(); IBulkCursor bulkCursor = bulkQueryInternal( url, projection, selection, selectionArgs, sortOrder, adaptor.getObserver(), window, adaptor); if (bulkCursor == null) { return null; } return adaptor; } ...... } ~~~ 这个函数首先会创建一个CursorWindow对象，前面已经说过，这个CursorWindow对象包含了一块匿名共享内存，它的作用是把这块匿名共享内存通过Binder进程间通信机制传给Content Proivder，好让Content Proivder在里面返回所请求的数据。下面我们就先看看这个CursorWindow对象的创建过程，重点关注它是如何在内部创建匿名共享内存的，然后再回过头来看看它调用bulkQueryInternal函数来做了些什么事情。 CursorWindow类定义在**frameworks/base/core/java/android/database/CursorWindow.java**文件中，我们来看看它的构造函数的实现： ~~~ public class CursorWindow extends SQLiteClosable implements Parcelable { ...... private int nWindow; ...... public CursorWindow(boolean localWindow) { ...... native_init(localWindow); } ...... } ~~~ 它主要调用本地方法native_init来执行初始化的工作，主要就是创建匿名共享内存了，传进来的参数localWindow为false，表示这个匿名共享内存只能通过远程调用来访问，即前面我们所说的，通过Content Proivder返回来的Cursor接口来访问这块匿名共享内存里面的数据。 * **Step 8. CursorWindow.native_init** 这是一个JNI方法，它对应定义在**frameworks/base/core/jni/android_database_CursorWindow.cpp**文件中的native_init_empty函数： ~~~ static JNINativeMethod sMethods[] = { /* name, signature, funcPtr */ {"native_init", "(Z)V", (void *)native_init_empty}, ...... }; ~~~ 函数native_init_empty的定义如下所示： ~~~ static void native_init_empty(JNIEnv * env, jobject object, jboolean localOnly) { ...... CursorWindow * window; window = new CursorWindow(MAX_WINDOW_SIZE); ...... if (!window->initBuffer(localOnly)) { ...... } ...... SET_WINDOW(env, object, window); } ~~~ 这个函数在C++层创建了一个CursorWindow对象，然后通过调用SET_WINDOW宏来把这个C++层的CursorWindow对象与Java层的CursorWindow对象关系起来： ~~~ #define SET_WINDOW(env, object, window) (env->SetIntField(object, gWindowField, (int)window)) ~~~ 这里的gWindowField即定义为Java层的CursorWindow对象中的nWindow成员变量： ~~~ static jfieldID gWindowField; ...... int register_android_database_CursorWindow(JNIEnv * env) { jclass clazz; clazz = env->FindClass("android/database/CursorWindow"); ...... gWindowField = env->GetFieldID(clazz, "nWindow", "I"); ...... } ~~~ 这种用法在Android应用程序框架层中非常普遍。 下面我们重点关注C++层的CursorWindow对象的initBuffer函数的实现。 * **Step 9. CursorWindow.initBuffer** C++层的CursorWindow类定义在frameworks/base/core/jni/CursorWindow.cpp文件中： ~~~ bool CursorWindow::initBuffer(bool localOnly) { ...... sp heap; heap = new MemoryHeapBase(mMaxSize, 0, "CursorWindow"); if (heap != NULL) { mMemory = new MemoryBase(heap, 0, mMaxSize); if (mMemory != NULL) { mData = (uint8_t *) mMemory->pointer(); if (mData) { mHeader = (window_header_t *) mData; mSize = mMaxSize; ...... } } ...... } else { ...... } } ~~~ 这里我们就可以很清楚地看到，在CursorWindow类的内部有一个成员变量mMemory，它的类型是MemoryBase。MemoryBase类为我们封装了匿名共享内存的访问以及在进程间的传输等问题，具体可以参考前面一篇文章Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析，这里就不再详述了。 通过Step 8和Step 9两步，用来在第三方应用程序和Content Provider之间传输数据的媒介就准备好了，我们回到Step 7中，看看系统是如何把这个匿名共享存传递给Content Provider使用的。在Step 7中，最后调用bulkQueryInternal函数来进一步操作。 * **Step 10. ContentProviderProxy.bulkQueryInternal** 这个函数定义在**frameworks/base/core/java/android/content/ContentProviderNative.java**文件中： ~~~ final class ContentProviderProxy implements IContentProvider { ...... private IBulkCursor bulkQueryInternal( Uri url, String[] projection, String selection, String[] selectionArgs, String sortOrder, IContentObserver observer, CursorWindow window, BulkCursorToCursorAdaptor adaptor) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IContentProvider.descriptor); url.writeToParcel(data, 0); int length = 0; if (projection != null) { length = projection.length; } data.writeInt(length); for (int i = 0; i < length; i++) { data.writeString(projection[i]); } data.writeString(selection); if (selectionArgs != null) { length = selectionArgs.length; } else { length = 0; } data.writeInt(length); for (int i = 0; i < length; i++) { data.writeString(selectionArgs[i]); } data.writeString(sortOrder); data.writeStrongBinder(observer.asBinder()); window.writeToParcel(data, 0); // Flag for whether or not we want the number of rows in the // cursor and the position of the "_id" column index (or -1 if // non-existent). Only to be returned if binder != null. final boolean wantsCursorMetadata = (adaptor != null); data.writeInt(wantsCursorMetadata ? 1 : 0); mRemote.transact(IContentProvider.QUERY_TRANSACTION, data, reply, 0); DatabaseUtils.readExceptionFromParcel(reply); IBulkCursor bulkCursor = null; IBinder bulkCursorBinder = reply.readStrongBinder(); if (bulkCursorBinder != null) { bulkCursor = BulkCursorNative.asInterface(bulkCursorBinder); if (wantsCursorMetadata) { int rowCount = reply.readInt(); int idColumnPosition = reply.readInt(); if (bulkCursor != null) { adaptor.set(bulkCursor, rowCount, idColumnPosition); } } } data.recycle(); reply.recycle(); return bulkCursor; } ...... } ~~~ 这个函数有点长，不过它的逻辑很简单，就是把查询参数都写到一个Parcel对象data中去，然后通过下面Binder进程间通信机制把查询请求传给Content Provider处理： ~~~ mRemote.transact(IContentProvider.QUERY_TRANSACTION, data, reply, 0); ~~~ 从这个Binder调用返回以后，就会得到一个IBulkCursor接口，它是一个Binder引用，实际是指向在Content Provider这一侧创建的一个CursorToBulkCursorAdaptor对象，后面我们将会看到。有了这个IBulkCursor接口之后，我们就可以通过Binder进程间调用来访问从Content Provider中查询得到的数据了。这个IBulkCursor接口最终最设置了上面Step 7中创建的BulkCursorToCursorAdaptor对象adaptor中去： ~~~ adaptor.set(bulkCursor, rowCount, idColumnPosition); ~~~ BulkCursorToCursorAdaptor类实现了Cursor接口，因此，我们可以通过Curosr接口来访问这些查询得到的共享数据。 在前面把查询参数写到Parcel对象data中去的过程中，有两个步骤是比较重要的，分别下面这段执行语句： ~~~ window.writeToParcel(data, 0); // Flag for whether or not we want the number of rows in the // cursor and the position of the "_id" column index (or -1 if // non-existent). Only to be returned if binder != null. final boolean wantsCursorMetadata = (adaptor != null); data.writeInt(wantsCursorMetadata ? 1 : 0); ~~~ 调用window.writeToParcel是把window对象内部的匿名共享内存块通过Binder进程间通信机制传输给Content Provider来使用；而当传进来的参数adaptor不为null时，就会往data中写入一个整数1，表示让Content Provider把查询得到数据的元信息一起返回来，例如数据的行数、数据行的ID列的索引位置等信息，这个整数值会促使Content Provider把前面说的IBulkCursor接口返回给第三方应用程序之前，真正执行一把数据库查询操作，后面我们将看到这个过程。 现在，我们重点来关注一下CursorWindow类的writeToParcel函数，看看它是如何把它内部的匿名共享内存对象写到数据流data中去的。 * **Step 11. CursorWindow.writeToParcel** 这个函数定义在**frameworks/base/core/java/android/database/CursorWindow.java**文件中： ~~~ public class CursorWindow extends SQLiteClosable implements Parcelable { ...... public void writeToParcel(Parcel dest, int flags) { ...... dest.writeStrongBinder(native_getBinder()); ...... } ...... } ~~~ 这个函数最主要的操作就是往数据流dest写入一个Binder对象，这个Binder对象是通过调用本地方法native_getBinder来得到的。 * **Step 12. CursorWindow.native_getBinder** 这个函数定义在**frameworks/base/core/jni/android_database_CursorWindow.cpp**文件中： ~~~ static jobject native_getBinder(JNIEnv * env, jobject object) { CursorWindow * window = GET_WINDOW(env, object); if (window) { sp memory = window->getMemory(); if (memory != NULL) { sp binder = memory->asBinder(); return javaObjectForIBinder(env, binder); } } return NULL; } ~~~ 在前面的Step 8中，我们在C++层创建了一个CursorWindow对象，这个对象保存在Java层创建的CursorWindow对象的成员变量nWindow中，这里通过GET_WINDOW宏来把这个在C++层创建的CurosrWindow对象返回来： ~~~ #define GET_WINDOW(env, object) ((CursorWindow *)env->GetIntField(object, gWindowField)) ~~~ 获得了这个CursorWindow对象以后，就调用它的getMemory函数来获得一个IMemory接口，这是一个Binder接口，具体可以参考前面一篇文章Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析。 * **Step 13. CursorWindow.getMemory** 这个函数定义在**frameworks/base/core/jni/CursorWindow.h**文件中： ~~~ class CursorWindow { public: ...... sp getMemory() {return mMemory;} ...... } ~~~ 这个CursorWindow对象的成员变量mMemory就是在前面Step 9中创建的了。 这样，在第三方应用程序这一侧创建的匿名共享存对象就可以传递给Content Provider来使用了。回到前面的Step 10中，所有的参数都就准备就绪以后，就通过Binder进程间通信机制把数据查询请求发送给相应的Content Proivder了。这个请求是在ContentProviderNative类的onTransact函数中响应的。 * **Step 14. ContentProviderNative.onTransact** 这个函数定义在**frameworks/base/core/java/android/content/ContentProviderNative.java**文件中： ~~~ abstract public class ContentProviderNative extends Binder implements IContentProvider { ...... @Override public boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException { try { switch (code) { case QUERY_TRANSACTION: { data.enforceInterface(IContentProvider.descriptor); Uri url = Uri.CREATOR.createFromParcel(data); // String[] projection int num = data.readInt(); String[] projection = null; if (num > 0) { projection = new String[num]; for (int i = 0; i < num; i++) { projection[i] = data.readString(); } } // String selection, String[] selectionArgs... String selection = data.readString(); num = data.readInt(); String[] selectionArgs = null; if (num > 0) { selectionArgs = new String[num]; for (int i = 0; i < num; i++) { selectionArgs[i] = data.readString(); } } String sortOrder = data.readString(); IContentObserver observer = IContentObserver.Stub. asInterface(data.readStrongBinder()); CursorWindow window = CursorWindow.CREATOR.createFromParcel(data); // Flag for whether caller wants the number of // rows in the cursor and the position of the // "_id" column index (or -1 if non-existent) // Only to be returned if binder != null. boolean wantsCursorMetadata = data.readInt() != 0; IBulkCursor bulkCursor = bulkQuery(url, projection, selection, selectionArgs, sortOrder, observer, window); reply.writeNoException(); if (bulkCursor != null) { reply.writeStrongBinder(bulkCursor.asBinder()); if (wantsCursorMetadata) { reply.writeInt(bulkCursor.count()); reply.writeInt(BulkCursorToCursorAdaptor.findRowIdColumnIndex( bulkCursor.getColumnNames())); } } else { reply.writeStrongBinder(null); } return true; } ...... } } catch (Exception e) { DatabaseUtils.writeExceptionToParcel(reply, e); return true; } return super.onTransact(code, data, reply, flags); } ...... } ~~~ 这一步其实就是前面Step 10的逆操作，把请求参数从数据流data中读取出来。这里我们同样是重点关注下面这两个参数读取的步骤： ~~~ CursorWindow window = CursorWindow.CREATOR.createFromParcel(data); // Flag for whether caller wants the number of // rows in the cursor and the position of the // "_id" column index (or -1 if non-existent) // Only to be returned if binder != null. boolean wantsCursorMetadata = data.readInt() != 0; ~~~ 通过调用CursorWindow.CREATOR.createFromParcel函数来从数据流data中重建一个本地的CursorWindow对象；接着又将数据流data的下一个整数值读取出来，如果这个整数值不为0，变量wantsCursorMetadata的值就为true，说明Content Provider在返回IBulkCursor接口给第三方应用程序之前，要先实际执行一把数据库查询操作，以便把结果数据的元信息返回给第三方应用程序。 通过下面的代码我们可以看到，调用bulkQuery函数之后，就得到了一个IBulkCursor接口，这表示要返回的数据准备就绪了，但是这时候实际上还没有把结果数据从数据库中提取出来，而只是准备好了一个SQL查询计划，等到真正要使用这些结果数据时，系统才会真正执行查询数据库的操作: ~~~ if (wantsCursorMetadata) { reply.writeInt(bulkCursor.count()); ...... } ~~~ 在将这个IBulkCursor接口返回给第三方应用程序之前，如果发现wantsCursorMetadata的值就为true，就会调用它的count函数来获得结果数据的总行数，这样就会导致系统真正去执行数据库查询操作，并把结果数据保存到前面得到的CursorWindow对象中的匿名共享内存中去。 下面我们就重点关注CursorWindow.CREATOR.createFromParcel函数是如何从数据流data中在本地构造一个CursorWindow对象的。 * **Step 15. CursorWindow.CREATOR.createFromParcel** 这个函数定义在**frameworks/base/core/java/android/database/CursorWindow.java**文件中： ~~~ public class CursorWindow extends SQLiteClosable implements Parcelable { ...... private CursorWindow(Parcel source) { IBinder nativeBinder = source.readStrongBinder(); ...... native_init(nativeBinder); } ...... public static final Parcelable.Creator CREATOR = new Parcelable.Creator() { public CursorWindow createFromParcel(Parcel source) { return new CursorWindow(source); } ...... }; ...... } ~~~ 在创建CursorWindow对象的过程中，首先是从数据流source中将在前面Step 10中写入的Binder接口读取出来，然后使用这个Binder接口来初始化这个CursorWindow对象，通过前面的Step 13，我们知道，这个Binder接口的实际类型为IMemory，它封装了对匿名共享内存的访问操作。初始化这个匿名共享内存对象的操作是由本地方法native_init函数来实现的，下面我们就看看它的实现。 * **Step 16. CursorWindow.native_init** 这个函数定义在**frameworks/base/core/jni/android_database_CursorWindow.cpp**文件中，对应的函数为native_init_memory函数： ~~~ static JNINativeMethod sMethods[] = { ...... {"native_init", "(Landroid/os/IBinder;)V", (void *)native_init_memory}, }; ~~~ 函数native_init_memory的实现如下所示： ~~~ static void native_init_memory(JNIEnv * env, jobject object, jobject memObj) { sp memory = interface_cast(ibinderForJavaObject(env, memObj)); ...... CursorWindow * window = new CursorWindow(); ...... if (!window->setMemory(memory)) { ...... } ...... SET_WINDOW(env, object, window); } ~~~ 函数首先是将前面Step 15中传进来的Binder接口转换为IMemory接口，接着创建一个C++层的CursorWindow对象，再接着用这个IMemory接口来初始化这个C++层的CursorWindow对象，最后像前面的Step 8一样，通过宏SET_WINDOW把这个C++层的CursorWindow对象和前面在Step 15中创建的Java层CursorWindow对象关联起来。 下面我们就重点关注CursorWindow类的setMemory函数的实现，看看它是如何使用这个IMemory接口来初始化其内部的匿名共享内存对象的。 * **Step 17. CursorWindow.setMemory** 这个函数定义在**frameworks/base/core/jni/CursorWindow.cpp**文件中： ~~~ bool CursorWindow::setMemory(const sp& memory) { mMemory = memory; mData = (uint8_t *) memory->pointer(); ...... mHeader = (window_header_t *) mData; // Make the window read-only ssize_t size = memory->size(); mSize = size; mMaxSize = size; mFreeOffset = size; ...... return true; } ~~~ 从前面一篇文章Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析中，我们知道，这里得到的IMemory接口，实际上是一个Binder引用，它指向前面在Step 9中创建的MemoryBase对象，当我们第一次调用这个接口的pointer函数时，它便会通过Binder进程间通信机制去请求这个MemoryBase对象把它内部的匿名共享内存文件描述符返回来给它，而Binder驱动程序发现要传输的是一个文件描述符的时候，就会在目标进程中创建另外一个文件描述符，这个新建的文件描述符与要传输的文件描述符指向的是同一个文件，在我们这个情景中，这个文件就是我们前面创建的匿名共享内存文件了。因此，在目标进程中，即在Content Provider进程中，它可以通过这个新建的文件描述符来访问这块匿名共享内存，这也是匿名共享内存在进程间的共享原理，具体可以参考另外一篇文章Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析。 这样，在Content Provider这一侧，就可以把第三方应用程序请求的数据保存在这个匿名共享内存中了，回到前面的Step 14中，下一步要执行的函数便是bulkQuery了，它的作用为请求的数据制定好一个SQL数据库查询计划。这个bulkQuery函数是由一个实现了IContentProvider接口的Binder对象来实现的，具体可以参考前面一篇文章Android应用程序组件Content Provider的启动过程源代码分析中，这个Binder对象的实际类型是定义在ContentProivder类内部的Transport类。 * **Step 18. Transport.bulkQuery** 这个函数定义在**frameworks/base/core/java/android/content/ContentProvider.java**文件中： ~~~ public abstract class ContentProvider implements ComponentCallbacks { ...... class Transport extends ContentProviderNative { ...... public IBulkCursor bulkQuery(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder, IContentObserver observer, CursorWindow window) { ...... Cursor cursor = ContentProvider.this.query(uri, projection, selection, selectionArgs, sortOrder); ...... return new CursorToBulkCursorAdaptor(cursor, observer, ContentProvider.this.getClass().getName(), hasWritePermission(uri), window); } ...... } ...... } ~~~ 这个函数主要做了两件事情，一是调用ContentProvider的子类的query函数构造一个数据库查询计划，注意，从这个函数返回来的时候，还没有真正执行数据库查询的操作，而只是按照查询条件准备好了一个SQL语句，要等到第一次使用的时候才会去执行数据库查询操作；二是使用前面一步得到的Cursor接口以及传下来的参数window来创建一个CursorToBulkCursorAdaptor对象，这个对象实现了IBulkCursor接口，同时它也是一个Binder对象，是用来返回给第三方应用程序使用的，第三方应用程序必须通过这个接口来获取从ContentProvider中查询得到的数据，而这个CursorToBulkCursorAdaptor对象的功能就是利用前面获得的Cursor接口来执行数据库查询操作，然后把查询得到的结果保存在从参数传下来的window对象内部所引用的匿名共享内存中去。我们先来看ContentProvider的子类的query函数的实现，在我们这个情景中，这个子类就是ArticlesProvider了，然后再回过头来看看这个CursorToBulkCursorAdaptor对象是如何把数据库查询计划与匿名共享内存关联起来的。 * **Step 19. ArticlesProvider.query** 这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介绍的应用程序ArtilcesProvider源代码工程目录下，在文件**packages/experimental/ArticlesProvider/src/shy/luo/providers/articles/ArticlesProvider.java** 中： ~~~ public class ArticlesProvider extends ContentProvider { ...... @Override public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) { SQLiteDatabase db = dbHelper.getReadableDatabase(); SQLiteQueryBuilder sqlBuilder = new SQLiteQueryBuilder(); String limit = null; switch (uriMatcher.match(uri)) { ...... case Articles.ITEM_POS: { String pos = uri.getPathSegments().get(1); sqlBuilder.setTables(DB_TABLE); sqlBuilder.setProjectionMap(articleProjectionMap); limit = pos + ", 1"; break; } ...... } Cursor cursor = sqlBuilder.query(db, projection, selection, selectionArgs, null, null, TextUtils.isEmpty(sortOrder) ? Articles.DEFAULT_SORT_ORDER : sortOrder, limit); ...... return cursor; } ...... } ~~~ 从前面的Step 1中可以看到，传进来的参数uri的值为“content://shy.luo.providers.articles/pos” ，通过uriMatcher的match函数来匹配这个uri的时候，得到的匹配码为Articles.ITEM_POS，这个知识点可以参考前面这篇文章Android应用程序组件Content Provider应用实例。因为我们的数据是保存在SQLite数据库里面的，因此，必须要构造一个SQL语句来将所请求的数据查询出来。这里是通过SQLiteQueryBuilder类来构造这个SQL查询语句的，构造好了以后，就调用它的query函数来准备一个数据库查询计划。 * **Step 20. SQLiteQueryBuilder.query** 这个函数定义在**frameworks/base/core/java/android/database/sqlite/SQLiteQueryBuilder.java**文件中： ~~~ public class SQLiteQueryBuilder { ...... public Cursor query(SQLiteDatabase db, String[] projectionIn, String selection, String[] selectionArgs, String groupBy, String having, String sortOrder, String limit) { ...... String sql = buildQuery( projectionIn, selection, groupBy, having, sortOrder, limit); ...... return db.rawQueryWithFactory( mFactory, sql, selectionArgs, SQLiteDatabase.findEditTable(mTables)); } ...... } ~~~ 这里首先是调用buildQuery函数来构造一个SQL语句，它无非就是根据从参数传来列名子句、select子句、where子句、group by子句、having子句、order子句以及limit子句来构造一个完整的SQL子句，这些都是SQL语法的基础知识了，这里我们就不关注了。构造好这个SQL查询语句之后，就调用从参数传下来的数据库对象db的rawQueryWithFactory函数来进一步操作了。 * **Step 21. SQLiteDatabase.rawQueryWithFactory** 这个函数定义在**frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java**文件中： ~~~ public class SQLiteDatabase extends SQLiteClosable { ...... public Cursor rawQueryWithFactory( CursorFactory cursorFactory, String sql, String[] selectionArgs, String editTable) { ...... SQLiteCursorDriver driver = new SQLiteDirectCursorDriver(this, sql, editTable); Cursor cursor = null; try { cursor = driver.query( cursorFactory != null ? cursorFactory : mFactory, selectionArgs); } finally { ...... } return cursor; } ...... } ~~~ 这个函数会在内部创建一个SQLiteCursorDriver对象driver，然后调用它的query函数来创建一个Cursor对象，这个Cursor对象的实际类型是SQLiteCursor，下面我们将会看到，前面我们也已经看到，这个SQLiteCursor的内部就包含了一个数据库查询计划。 * **Step 22. SQLiteCursorDriver.query** 这个函数定义在**frameworks/base/core/java/android/database/sqlite/SQLiteDirectCursorDriver.java**文件中： ~~~ public class SQLiteDirectCursorDriver implements SQLiteCursorDriver { ...... public Cursor query(CursorFactory factory, String[] selectionArgs) { // Compile the query SQLiteQuery query = new SQLiteQuery(mDatabase, mSql, 0, selectionArgs); try { ...... // Create the cursor if (factory == null) { mCursor = new SQLiteCursor(mDatabase, this, mEditTable, query); } else { mCursor = factory.newCursor(mDatabase, this, mEditTable, query); } ...... return mCursor; } finally { ...... } } ...... } ~~~ 这里我们就可以清楚地看到，这个函数首先会根据数据库对象mDatabase和原生SQL语句来构造一个SQLiteQuery对象，这个对象的创建的过程中，就会解析这个原生SQL语句，并且创建好数据库查询计划，这样做的好处是等到真正查询的时候就可以马上从数据库中获得取数据了，而不用去分析和理解这个SQL字符串语句，这个就是所谓的SQL语句编译了。有了这个SQLiteQuery对象之后，再把它和数据库对象mDatabase等待信息一起来创建一个SQLiteCursor对象，于是，这个SQLiteCursor对象就圈定要将来要从数据库中获取的数据了。这一步执行完成之后，就把这个SQLiteCursor对象返回给上层，最终回到Step 18中的Transport类bulkQuery函数中。有了这个SQLiteCursor对象之后，就通过创建一个CursorToBulkCursorAdaptor对象来把它和匿名共享内存关联起来，这样，就为将来从数据库中查询得到的数据找到了归宿。 CursorToBulkCursorAdaptor类定义在**frameworks/base/core/java/android/database/CursorToBulkCursorAdaptor.java**文件中，我们来看看它的对象的构造过程，即它的构造函数的实现： ~~~ public final class CursorToBulkCursorAdaptor extends BulkCursorNative implements IBinder.DeathRecipient { ...... public CursorToBulkCursorAdaptor(Cursor cursor, IContentObserver observer, String providerName, boolean allowWrite, CursorWindow window) { try { mCursor = (CrossProcessCursor) cursor; if (mCursor instanceof AbstractWindowedCursor) { AbstractWindowedCursor windowedCursor = (AbstractWindowedCursor) cursor; ...... windowedCursor.setWindow(window); } else { ...... } } catch (ClassCastException e) { ...... } ...... } ...... } ~~~ 这里传进来的参数cursor的类型为SQLiteCursor，从上面的类图我们可以知道，SQLiteCursor实现了CrossProcessCursor接口，并且继承了AbstractWindowedCursor类，因此，上面第一个if语句的条件成立，于是就会把这个SQLiteCurosr对象转换为一个AbstractWindowedCursor对象，目的是为了调用它的setWindow函数来把传进来的CursorWindow对象window保存起来，以便后面用来保存数据。 * **Step 23. AbstractWindowedCursor.setWindow** 这个函数定义在**frameworks/base/core/java/android/database/AbstractWindowedCursor.java**文件中： ~~~ public abstract class AbstractWindowedCursor extends AbstractCursor { ...... public void setWindow(CursorWindow window) { ...... mWindow = window; } ...... protected CursorWindow mWindow; } ~~~ 这个函数很简单，只是把参数window保存在AbstractWindowedCursor类的成员变量mWindow中。注意，这个成员变量mWindow的访问权限为protected，即AbstractWindowedCursor的子类可以直接访问这个成员变量。 这一步完成以后，就返回到前面的Step 14中去了，执行下面语句： ~~~ if (bulkCursor != null) { reply.writeStrongBinder(bulkCursor.asBinder()); if (wantsCursorMetadata) { reply.writeInt(bulkCursor.count()); reply.writeInt(BulkCursorToCursorAdaptor.findRowIdColumnIndex( bulkCursor.getColumnNames())); } } else { ...... } ~~~ 这里的bulkCursor不为null，于是，就会把这个bulkCursor对象写入到数据流reply中，这个接口是要通过Binder进程间通信机制返回到第三方应用程序的，它的实际类型就是我们在前面Step 18中创建的CursorToBulkCursorAdaptor对象了。 从前面的Step 14的分析中，我们知道，这里的布尔变量wantsCursorMetadata为true，于是就会把请求数据的行数以及数据行的ID列索引号一起写入到数据流reply中去了。这里，我们重点分析IBulkCursor接口的count函数，因为这个调用使得这个Content Provider会真正去执行数据库查询的操作。至于是如何得到从数据库查询出来的数据行的ID列的位置呢？回忆前面这篇文章Android应用程序组件Content Provider应用实例，我们提到，如果我们想将数据库表中的某一列作为数据行的ID列的话，那么就必须把这个列的名称设置为"_id"，这里的BulkCursorToCursorAdaptor类的静态成员函数findRowIdColumnIndex函数就是根据这个列名"_id"来找到它是位于数据行的第几列的。 CursorToBulkCursorAdaptor类定义在**frameworks/base/core/java/android/database/CursorToBulkCursorAdaptor.java**文件中，它的count成员函数的实现如下所示： ~~~ public final class CursorToBulkCursorAdaptor extends BulkCursorNative implements IBinder.DeathRecipient { ...... public int count() { return mCursor.getCount(); } ...... } ~~~ 它的成员变量mCursor即为在前面Step 22中创建的SQLiteCursor对象，于是，下面就会执行SQLiteCursor类的getCount成员函数。 * **Step 24. SQLiteCursor.getCount** 这个函数定义在frameworks/base/core/java/android/database/sqlite/SQLiteCursor.java文件中： ~~~ public class SQLiteCursor extends AbstractWindowedCursor { ...... @Override public int getCount() { if (mCount == NO_COUNT) { fillWindow(0); } return mCount; } ...... } ~~~ 它里面的成员变量mCount的初始化为NO_COUNT，表示还没有去执行数据库查询操作，因此，还不知道它的值是多少，需要通过调用fillWindow函数来从数据据库中查询中，第三方应用程序所请求的数据一共有多少行。 * **Step 25. QLiteCursor.fillWindow** 这个函数定义在**frameworks/base/core/java/android/database/sqlite/SQLiteCursor.java**文件中： ~~~ public class SQLiteCursor extends AbstractWindowedCursor { ...... private void fillWindow (int startPos) { ...... mCount = mQuery.fillWindow(mWindow, mInitialRead, 0); ...... } ...... } ~~~ 注意，这里的成员变量mWindow实际上是SQLiteCursor的父类AbstractWindowedCursor的成员变量，是在Step 23中设置的，它的访问权限为protected，因此，SQLiteCursor类可以直接访问它。真正的数据库查询操作是由SQLiteCursor类的成员变量mQuery来执行的，它的类型是SQLiteCursor，是前面的Step 22中创建的，它知道如何去把第三方应用程序请求的数据从数据库中提取出来。 * **Step 26. SQLiteCursor.fillWindow** 这个函数定义在**frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java**文件中： ~~~ public class SQLiteQuery extends SQLiteProgram { ...... /* package */ int fillWindow(CursorWindow window, int maxRead, int lastPos) { ...... try { ...... try { ...... // if the start pos is not equal to 0, then most likely window is // too small for the data set, loading by another thread // is not safe in this situation. the native code will ignore maxRead int numRows = native_fill_window(window, window.getStartPosition(), mOffsetIndex, maxRead, lastPos); ...... return numRows; } catch (IllegalStateException e){ ...... } catch (SQLiteDatabaseCorruptException e) { ...... } finally { ...... } } finally { ...... } } ...... } ~~~ 这里我们可以看到，真正的数据库查询操作是由本地方法native_fill_window来执行的，它最终也是调用了sqlite的库函数来执行数据库查询的操作，这里我们就不跟进去了，对sqlite有兴趣的读者可以自己研究一下。这个函数执行完成之后，就会把从数据库中查询得到的数据的行数返回来，这个行数最终返回到Step 25中的SQLiteCursor.fillWindow函数，设置在SQLiteCursor类的成员变量mCount中，于是，下次再调用它的getCount函数时，就可以马上返回了。 这一步执行完成之后，就回到前面的Step 14中，最终就把从Content Provider中查询得到的数据通过匿名共享内存返回给第三方应用程序了。 至此，Android应用程序组件Content Provider在应用程序之间共享数据的原理就分析完成了，总的来说，它就是通过Binder进程间通信机制和匿名共享内存来实现的了。 关于应用程序间的数据共享还有另外的一个重要话题，就是数据更新通知机制了。因为数据是在多个应用程序中共享的，当其中一个应用程序改变了这些共享数据的时候，它有责任通知其它应用程序，让它们知道共享数据被修改了，这样它们就可以作相应的处理。在下一篇文章中，我们将分析Android应用程序组件Content Provider的数据更新通知机制，敬请关注。

原文出处——>[Android应用程序组件Content Provider的启动过程源代码分析](http://blog.csdn.net/luoshengyang/article/details/6963418) 通过前面的学习，我们知道在Android系统中，Content Provider可以为不同的应用程序访问相同的数据提供统一的入口。Content Provider一般是运行在独立的进程中的，每一个Content Provider在系统中只有一个实例存在，其它应用程序首先要找到这个实例，然后才能访问它的数据。那么，系统中的Content Provider实例是由谁来负责启动的呢？本文将回答这个问题。 Content Provider和应用程序组件Activity、Service一样，需要在AndroidManifest.xml文件中配置之后才能使用。系统在安装包含Content Provider的应用程序的时候，会把这些Content Provider的描述信息保存起来，其中最重要的就是Content Provider的Authority信息，Android应用程序的安装过程具体可以参考Android应用程序安装过程源代码分析一文。注意，安装应用程序的时候，并不会把相应的Content Provider加载到内存中来，系统采取的是懒加载的机制，等到第一次要使用这个Content Provider的时候，系统才会把它加载到内存中来，下次再要使用这个Content Provider的时候，就可以直接返回了。 本文以前面一篇文章Android应用程序组件Content Provider应用实例中的例子来详细分析Content Provider的启动过程。在Android应用程序组件Content Provider应用实例这篇文章介绍的应用程序Article中，第一次使用ArticlesProvider这个Content Provider的地方是ArticlesAdapter类的getArticleCount函数，因为MainActivity要在ListView中显示文章信息列表时， 首先要知道ArticlesProvider中的文章信息的数量。从ArticlesAdapter类的getArticleCount函数调用开始，一直到ArticlesProvider类的onCreate函数被调用，就是ArticlesProvider的完整启动过程，下面我们就先看看这个过程的序列图，然后再详细分析每一个步骤：  **Step 1. ArticlesAdapter.getArticleCount** 这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Artilce源代码工程目录下，在文件为packages/experimental/Article/src/shy/luo/article/ArticlesAdapter.java中： ~~~ public class ArticlesAdapter { ...... private ContentResolver resolver = null; public ArticlesAdapter(Context context) { resolver = context.getContentResolver(); } ...... public int getArticleCount() { int count = 0; try { IContentProvider provider = resolver.acquireProvider(Articles.CONTENT_URI); Bundle bundle = provider.call(Articles.METHOD_GET_ITEM_COUNT, null, null); count = bundle.getInt(Articles.KEY_ITEM_COUNT, 0); } catch(RemoteException e) { e.printStackTrace(); } return count; } ...... } ~~~ 这个函数通过应用程序上下文的ContentResolver接口resolver的acquireProvider函数来获得与Articles.CONTENT_URI对应的Content Provider对象的IContentProvider接口。常量Articles.CONTENT_URI是在应用程序ArticlesProvider中定义的，它的值为“content://shy.luo.providers.articles/item” ，对应的Content Provider就是ArticlesProvider了。 **Step 2. ContentResolver.acqireProvider** 这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中： ~~~ public abstract class ContentResolver { ...... public final IContentProvider acquireProvider(Uri uri) { if (!SCHEME_CONTENT.equals(uri.getScheme())) { return null; } String auth = uri.getAuthority(); if (auth != null) { return acquireProvider(mContext, uri.getAuthority()); } return null; } ...... } ~~~ 函数首先验证参数uri的scheme是否正确，即是否是以content://开头 ，然后取出它的authority部分，最后调用另外一个成员函数acquireProvider执行获取ContentProvider接口的操作。在我们这个情景中，参数uri的authority的内容便是“shy.luo.providers.articles”了。 从ContentResolver类的定义我们可以看出，它是一个抽象类，两个参数版本的acquireProvider函数是由它的子类来实现的。回到Step 1中，这个ContentResolver接口是通过应用程序上下文Context对象的getContentResolver函数来获得的，而应用程序上下文Context是由ContextImpl类来实现的，它定义在**frameworks/base/core/java/android/app/ContextImpl.java**文件中： ~~~ class ContextImpl extends Context { ...... private ApplicationContentResolver mContentResolver; ...... final void init(LoadedApk packageInfo, IBinder activityToken, ActivityThread mainThread, Resources container) { ...... mContentResolver = new ApplicationContentResolver(this, mainThread); ...... } ...... @Override public ContentResolver getContentResolver() { return mContentResolver; } ...... } ~~~ ContextImpl类的init函数是在应用程序启动的时候调用的，具体可以参考Android应用程序启动过程源代码分析一文中的Step 34。 因此，在上面的ContentResolver类的acquireProvider函数里面接下来要调用的ApplicationContentResolver类的acquireProvider函数。 **Step 3. ApplicationContentResolve.acquireProvider** 这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件中： ~~~ class ContextImpl extends Context { ...... private static final class ApplicationContentResolver extends ContentResolver { ...... @Override protected IContentProvider acquireProvider(Context context, String name) { return mMainThread.acquireProvider(context, name); } ...... private final ActivityThread mMainThread; } ...... } ~~~ 它调用ActivityThread类的acquireProvider函数进一步执行获取Content Provider接口的操作。 **Step 4. ActivityThread.acquireProvider** 这个函数定义在**frameworks/base/core/java/android/app/ActivityThread.java**文件中： ~~~ public final class ActivityThread { ...... public final IContentProvider acquireProvider(Context c, String name) { IContentProvider provider = getProvider(c, name); if(provider == null) return null; ...... return provider; } ...... } ~~~ 它又是调用了另外一个成员函数getProvider来进一步执行获取Content Provider接口的操作。 **Step 5. ActivityThread.getProvider** 这个函数定义在**frameworks/base/core/java/android/app/ActivityThread.java**文件中： ~~~ public final class ActivityThread { ...... private final IContentProvider getExistingProvider(Context context, String name) { synchronized(mProviderMap) { final ProviderClientRecord pr = mProviderMap.get(name); if (pr != null) { return pr.mProvider; } return null; } } ...... private final IContentProvider getProvider(Context context, String name) { IContentProvider existing = getExistingProvider(context, name); if (existing != null) { return existing; } IActivityManager.ContentProviderHolder holder = null; try { holder = ActivityManagerNative.getDefault().getContentProvider( getApplicationThread(), name); } catch (RemoteException ex) { } IContentProvider prov = installProvider(context, holder.provider, holder.info, true); ...... return prov; } ...... } ~~~ 这个函数首先会通过getExistingProvider函数来检查本地是否已经存在这个要获取的ContentProvider接口，如果存在，就直接返回了。本地已经存在的ContextProvider接口保存在ActivityThread类的mProviderMap成员变量中，以ContentProvider对应的URI的authority为键值保存。在我们这个情景中，因为是第一次调用ArticlesProvider接口，因此，这时候通过getExistingProvider函数得到的IContentProvider接口为null，于是下面就会调用ActivityManagerService服务的getContentProvider接口来获取一个ContentProviderHolder对象holder，这个对象就包含了我们所要获取的ArticlesProvider接口，在将这个接口返回给调用者之后，还会调用installProvider函数来把这个接口保存在本地中，以便下次要使用这个ContentProvider接口时，直接就可以通过getExistingProvider函数获取了。 我们先进入到ActivityManagerService服务的getContentProvider函数中看看它是如何获取我们所需要的ArticlesProvider接口的，然后再返回来看看installProvider函数的实现。 **Step 6. ActivityManagerService.getContentProvider** 这个函数定义在**frameworks/base/services/java/com/android/server/am/ActivityManagerService.java**文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public final ContentProviderHolder getContentProvider( IApplicationThread caller, String name) { ...... return getContentProviderImpl(caller, name); } ...... } ~~~ 它调用getContentProviderImpl函数来进一步执行操作。 **Step 7. ActivityManagerService.getContentProviderImpl** 这个函数定义在**frameworks/base/services/java/com/android/server/am/ActivityManagerService.java**文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final ContentProviderHolder getContentProviderImpl( IApplicationThread caller, String name) { ContentProviderRecord cpr; ProviderInfo cpi = null; synchronized(this) { ProcessRecord r = null; if (caller != null) { r = getRecordForAppLocked(caller); ...... } // First check if this content provider has been published... cpr = mProvidersByName.get(name); if (cpr != null) { ...... } else { try { cpi = AppGlobals.getPackageManager(). resolveContentProvider(name, STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS); } catch (RemoteException ex) { } ...... } cpr = mProvidersByClass.get(cpi.name); final boolean firstClass = cpr == null; if (firstClass) { try { ApplicationInfo ai = AppGlobals.getPackageManager(). getApplicationInfo( cpi.applicationInfo.packageName, STOCK_PM_FLAGS); ...... cpr = new ContentProviderRecord(cpi, ai); } catch (RemoteException ex) { // pm is in same process, this will never happen. } } if (r != null && cpr.canRunHere(r)) { // If this is a multiprocess provider, then just return its // info and allow the caller to instantiate it. Only do // this if the provider is the same user as the caller's // process, or can run as root (so can be in any process). return cpr; } ...... // This is single process, and our app is now connecting to it. // See if we are already in the process of launching this // provider. final int N = mLaunchingProviders.size(); int i; for (i=0; i= N) { final long origId = Binder.clearCallingIdentity(); ProcessRecord proc = startProcessLocked(cpi.processName, cpr.appInfo, false, 0, "content provider", new ComponentName(cpi.applicationInfo.packageName, cpi.name), false); ...... mLaunchingProviders.add(cpr); ...... } // Make sure the provider is published (the same provider class // may be published under multiple names). if (firstClass) { mProvidersByClass.put(cpi.name, cpr); } cpr.launchingApp = proc; mProvidersByName.put(name, cpr); ...... } // Wait for the provider to be published... synchronized (cpr) { while (cpr.provider == null) { ...... try { cpr.wait(); } catch (InterruptedException ex) { } } } return cpr; } ...... } ~~~ 这个函数比较长，我们一步一步地分析。 函数首先是获取调用者的进程记录块信息： ~~~ ProcessRecord r = null; if (caller != null) { r = getRecordForAppLocked(caller); ...... } ~~~ 在我们这个情景中，要获取的就是应用程序Article的进程记录块信息了，后面会用到。 在ActivityManagerService中，有两个成员变量是用来保存系统中的Content Provider信息的，一个是mProvidersByName，一个是mProvidersByClass，前者是以Content Provider的authoriry值为键值来保存的，后者是以Content Provider的类名为键值来保存的。一个Content Provider可以有多个authority，而只有一个类来和它对应，因此，这里要用两个Map来保存，这里为了方便根据不同条件来快速查找而设计的。下面的代码就是用来检查要获取的Content Provider是否已经加存在的了： ~~~ // First check if this content provider has been published... cpr = mProvidersByName.get(name); if (cpr != null) { ...... } else { try { cpi = AppGlobals.getPackageManager(). resolveContentProvider(name, STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS); } catch (RemoteException ex) { } ...... } cpr = mProvidersByClass.get(cpi.name); final boolean firstClass = cpr == null; if (firstClass) { try { ApplicationInfo ai = AppGlobals.getPackageManager(). getApplicationInfo( cpi.applicationInfo.packageName, STOCK_PM_FLAGS); ...... cpr = new ContentProviderRecord(cpi, ai); } catch (RemoteException ex) { // pm is in same process, this will never happen. } } ~~~ 在我们这个情景中，由于是第一次调用ArticlesProvider接口，因此，在mProvidersByName和mProvidersByClass两个Map中都不存在ArticlesProvider的相关信息，因此，这里会通过AppGlobals.getPackageManager函数来获得PackageManagerService服务接口，然后分别通过它的resolveContentProvider和getApplicationInfo函数来分别获取ArticlesProvider应用程序的相关信息，分别保存在cpi和cpr这两个本地变量中。这些信息都是在安装应用程序的过程中保存下来的，具体可以参考Android应用程序安装过程源代码分析一文。 接下去这个代码判断当前要获取的Content Provider是否允许在客户进程中加载，即查看一个这个Content Provider否配置了multiprocess属性为true，如果允许在客户进程中加载，就直接返回了这个Content Provider的信息了： ~~~ if (r != null && cpr.canRunHere(r)) { // If this is a multiprocess provider, then just return its // info and allow the caller to instantiate it. Only do // this if the provider is the same user as the caller's // process, or can run as root (so can be in any process). return cpr; } ~~~ 在我们这个情景中，要获取的ArticlesProvider设置了要在独立的进程中运行，因此，继续往下执行： ~~~ // This is single process, and our app is now connecting to it. // See if we are already in the process of launching this // provider. final int N = mLaunchingProviders.size(); int i; for (i=0; i= N) { final long origId = Binder.clearCallingIdentity(); ProcessRecord proc = startProcessLocked(cpi.processName, cpr.appInfo, false, 0, "content provider", new ComponentName(cpi.applicationInfo.packageName, cpi.name), false); ...... mLaunchingProviders.add(cpr); ...... } ~~~ 这里的条件i >= N为true，就表明没有其它应用程序正在加载这个Content Provider，因此，就要调用startProcessLocked函数来启动一个新的进程来加载这个Content Provider对应的类了，然后把这个正在加载的信息增加到mLaunchingProviders中去。我们先接着分析这个函数，然后再来看在新进程中加载Content Provider的过程，继续往下执行： ~~~ // Make sure the provider is published (the same provider class // may be published under multiple names). if (firstClass) { mProvidersByClass.put(cpi.name, cpr); } cpr.launchingApp = proc; mProvidersByName.put(name, cpr); ~~~ 这段代码把这个Content Provider的信息分别保存到mProvidersByName和mProviderByCalss两个Map中去，以方便后续查询。 因为我们需要获取的Content Provider是在新的进程中加载的，而getContentProviderImpl这个函数是在系统进程中执行的，它必须要等到要获取的Content Provider是在新的进程中加载完成后才能返回，这样就涉及到进程同步的问题了。这里使用的同步方法是不断地去检查变量cpr的provider域是否被设置了。当要获取的Content Provider在新的进程加载完成之后，它会通过Binder进程间通信机制调用到系统进程中，把这个cpr变量的provider域设置为已经加载好的Content Provider接口，这时候，函数getContentProviderImpl就可以返回了。下面的代码就是用来等待要获取的Content Provider是在新的进程中加载完成的： ~~~ // Wait for the provider to be published... synchronized (cpr) { while (cpr.provider == null) { ...... try { cpr.wait(); } catch (InterruptedException ex) { } } } ~~~ 下面我们再分析在新进程中加载ArticlesProvider这个Content Provider的过程。 **Step 8. ActivityManagerService.startProcessLocked Step 9. Process.start Step 10. ActivityThread.main Step 11. ActivityThread.attach Step 12. ActivityManagerService.attachApplication** 这五步是标准的Android应用程序启动步骤，具体可以参考Android应用程序启动过程源代码分析一文中的Step 23到Step 27，或者Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中的Step 4到Step 9，这里就不再详细描述了。 **Step 13. ActivityManagerService.attachApplicationLocked** 这个函数定义在**frameworks/base/services/java/com/android/server/am/ActivityManagerService.java**文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final boolean attachApplicationLocked(IApplicationThread thread, int pid) { // Find the application record that is being attached... either via // the pid if we are running in multiple processes, or just pull the // next app record if we are emulating process with anonymous threads. ProcessRecord app; if (pid != MY_PID && pid >= 0) { synchronized (mPidsSelfLocked) { app = mPidsSelfLocked.get(pid); } } else if (mStartingProcesses.size() > 0) { ...... } else { ...... } ...... app.thread = thread; app.curAdj = app.setAdj = -100; app.curSchedGroup = Process.THREAD_GROUP_DEFAULT; app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE; app.forcingToForeground = null; app.foregroundServices = false; app.debugging = false; ...... boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info); List providers = normalMode ? generateApplicationProvidersLocked(app) : null; try { ...... thread.bindApplication(processName, app.instrumentationInfo != null ? app.instrumentationInfo : app.info, providers, app.instrumentationClass, app.instrumentationProfileFile, app.instrumentationArguments, app.instrumentationWatcher, testMode, isRestrictedBackupMode || !normalMode, mConfiguration, getCommonServicesLocked()); ...... } catch (Exception e) { ...... } ...... return true; } ...... private final List generateApplicationProvidersLocked(ProcessRecord app) { List providers = null; try { providers = AppGlobals.getPackageManager(). queryContentProviders(app.processName, app.info.uid, STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS); } catch (RemoteException ex) { } if (providers != null) { final int N = providers.size(); for (int i=0; i providers, ComponentName instrumentationName, String profileFile, Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher, int debugMode, boolean isRestrictedBackupMode, Configuration config, Map services) { if (services != null) { // Setup the service cache in the ServiceManager ServiceManager.initServiceCache(services); } AppBindData data = new AppBindData(); data.processName = processName; data.appInfo = appInfo; data.providers = providers; data.instrumentationName = instrumentationName; data.profileFile = profileFile; data.instrumentationArgs = instrumentationArgs; data.instrumentationWatcher = instrumentationWatcher; data.debugMode = debugMode; data.restrictedBackupMode = isRestrictedBackupMode; data.config = config; queueOrSendMessage(H.BIND_APPLICATION, data); } ...... } ...... } ~~~ 这个函数把相关的信息都封装成一个AppBindData对象，然后以一个消息的形式发送到主线程的消息队列中去等等待处理。这个消息最终是是在ActivityThread类的handleBindApplication函数中进行处理的。 **Step 15. ActivityThread.handleBindApplication** 这个函数定义在**frameworks/base/core/java/android/app/ActivityThread.java**文件中： ~~~ public final class ActivityThread { ...... private final void handleBindApplication(AppBindData data) { ...... List providers = data.providers; if (providers != null) { installContentProviders(app, providers); ...... } ...... } ...... } ~~~ 这个函数的内容比较多，我们忽略了其它无关的部分，只关注和Content Provider有关的逻辑，这里主要就是调用installContentProviders函数来在本地安装Content Providers信息。 **Step 16. ActivityThread.installContentProviders** 这个函数定义在**frameworks/base/core/java/android/app/ActivityThread.java**文件中： ~~~ public final class ActivityThread { ...... private final void installContentProviders( Context context, List providers) { final ArrayList results = new ArrayList(); Iterator i = providers.iterator(); while (i.hasNext()) { ProviderInfo cpi = i.next(); StringBuilder buf = new StringBuilder(128); buf.append("Pub "); buf.append(cpi.authority); buf.append(": "); buf.append(cpi.name); Log.i(TAG, buf.toString()); IContentProvider cp = installProvider(context, null, cpi, false); if (cp != null) { IActivityManager.ContentProviderHolder cph = new IActivityManager.ContentProviderHolder(cpi); cph.provider = cp; results.add(cph); // Don't ever unload this provider from the process. synchronized(mProviderMap) { mProviderRefCountMap.put(cp.asBinder(), new ProviderRefCount(10000)); } } } try { ActivityManagerNative.getDefault().publishContentProviders( getApplicationThread(), results); } catch (RemoteException ex) { } } ...... } ~~~ 这个函数主要是做了两件事情，一是调用installProvider来在本地安装每一个Content Proivder的信息，并且为每一个Content Provider创建一个ContentProviderHolder对象来保存相关的信息。ContentProviderHolder对象是一个Binder对象，是用来把Content Provider的信息传递给ActivityManagerService服务的。当这些Content Provider都处理好了以后，还要调用ActivityManagerService服务的publishContentProviders函数来通知ActivityManagerService服务，这个进程中所要加载的Content Provider，都已经准备完毕了，而ActivityManagerService服务的publishContentProviders函数的作用就是用来唤醒在前面Step 7等待的线程的了。我们先来看installProvider的实现，然后再来看ActivityManagerService服务的publishContentProviders函数的实现。 **Step 17. ActivityThread.installProvider** 这个函数定义在**frameworks/base/core/java/android/app/ActivityThread.java**文件中： ~~~ public final class ActivityThread { ...... private final IContentProvider installProvider(Context context, IContentProvider provider, ProviderInfo info, boolean noisy) { ContentProvider localProvider = null; if (provider == null) { ...... Context c = null; ApplicationInfo ai = info.applicationInfo; if (context.getPackageName().equals(ai.packageName)) { c = context; } else if (mInitialApplication != null && mInitialApplication.getPackageName().equals(ai.packageName)) { c = mInitialApplication; } else { try { c = context.createPackageContext(ai.packageName, Context.CONTEXT_INCLUDE_CODE); } catch (PackageManager.NameNotFoundException e) { } } ...... try { final java.lang.ClassLoader cl = c.getClassLoader(); localProvider = (ContentProvider)cl. loadClass(info.name).newInstance(); provider = localProvider.getIContentProvider(); ...... // XXX Need to create the correct context for this provider. localProvider.attachInfo(c, info); } catch (java.lang.Exception e) { ...... } } else if (localLOGV) { ...... } synchronized (mProviderMap) { // Cache the pointer for the remote provider. String names[] = PATTERN_SEMICOLON.split(info.authority); for (int i=0; i providers) { ...... synchronized(this) { final ProcessRecord r = getRecordForAppLocked(caller); ...... final int N = providers.size(); for (int i=0; i ';

原文出处——>[Android应用程序组件Content Provider应用实例](http://blog.csdn.net/luoshengyang/article/details/6950440) 上文简要介绍了Android应用程序组件Content Provider在应用程序间共享数据的原理，但是没有进一步研究它的实现。本文将实现两个应用程序，其中一个以Content Provider的形式来提供数据访问入口，另一个通过这个Content Provider来访问这些数据。本文的例子不仅可以为下文分析Content Provider的实现原理准备好使用情景，还可以学习到它的一个未公开接口。 本文中的应用程序是按照上一篇文章Android应用程序组件Content Provider简要介绍和学习计划中提到的一般应用程序架构方法来设计的。本文包含两个应用程序，其中，第一个应用程序命名为ArticlesProvider，它使用了SQLite数据库来维护一个文章信息列表，同时，它定义了访问这个文章信息列表的URI，这样，我们就可以通过一个Content Provider组件来向第三方应用程序提供访问这个文章信息列表的接口；第二个应用程序命名为Article，它提供了管理保存在ArticlesProvider应用程序中的文章信息的界面入口，在这个应用程序中，用户可以添加、删除和修改这些文章信息。接下来我们就分别介绍这两个应用程序的实现。 1. ArticlesProvider应用程序的实现 首先是参照在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文，在packages/experimental目录下建立工程文件目录ArticlesProvider。在继续介绍这个应用程序的实现之前，我们先介绍一下这个应用程序用来保存文章信息的数据库的设计。 我们知道，在Android系统中，内置了一款轻型的数据库SQLite。SQLite是专门为嵌入式产品而设计的，它具有占用资源低的特点，而且是开源的，非常适合在Android平台中使用，关于SQLite的更多信息可以访问官方网站http://www.sqlite.org。 ArticlesProvider应用程序就是使用SQLite来作为数据库保存文章信息的，数据库文件命名为Articles.db，它里面只有一张表ArticlesTable，表的结构如下所示：  它由四个字段表示，第一个字段_id表示文章的ID，类型为自动递增的integer，它作为表的key值；第二个字段_title表示文章的题目，类型为text；第三个字段_abstract表示文章的摘要，类型为text；第四个字段_url表示文章的URL，类型为text。注意，当我们打算将数据库表的某一列的数据作为一个数据行的ID时，就约定它的列名为_id。这是因为我们经常需要从数据库中获取一批数据，这些数据以Cursor的形式返回，对这些返回来的数据我们一般用一个ListView来显示，而这个ListView需要一个数据适配器Adapter来作为数据源，这时候就我们就可以以这个Cursor来构造一个Adapter。有些Adapter，例如android.widget.CursorAdapter，它们在实现自己的getItemId成员函数来获取指定数据行的ID时，就必须要从这个Cursor中相应的行里面取出列名为_id的字段的内容出来作为这个数据行的ID返回给调用者。当然，我们不在数据库表中定义这个_id列名也是可以的，不过这样从数据库中查询数据后得到的Cursor适合性就变差了，因此，建议我们在设计数据库表时，尽量设置其中一个列名字_id，并且保证这一列的内容是在数据库表中是唯一的。 下面我们就开始介绍这个应用程序的实现了。这个应用程序只有两个源文件，分别是Articles.java和ArticlesProvider，都是放在shy.luo.providers.articles这个package下面。在Articles.java文件里面，主要是定义了一些常量，例如用来访问文章信息数据的URI、MIME（Multipurpose Internet Mail Extensions）类型以及格式等，这些常量是第三方应用程序访问这些文章信息数据时要使用到的，因此，我们把它定义在一个单独的文件中，稍后我们会介绍如果把这个Articles.java文件打包成一个jar文件，然后第三方应用程序就可以引用这个常量了，这样也避免了直接把这个源代码文件暴露给第三方应用程序。 源文件Articles.java位于src/shy/luo/providers/articles目录下，它的内容如下所示： ~~~ package shy.luo.providers.articles; import android.net.Uri; public class Articles { /*Data Field*/ public static final String ID = "_id"; public static final String TITLE = "_title"; public static final String ABSTRACT = "_abstract"; public static final String URL = "_url"; /*Default sort order*/ public static final String DEFAULT_SORT_ORDER = "_id asc"; /*Call Method*/ public static final String METHOD_GET_ITEM_COUNT = "METHOD_GET_ITEM_COUNT"; public static final String KEY_ITEM_COUNT = "KEY_ITEM_COUNT"; /*Authority*/ public static final String AUTHORITY = "shy.luo.providers.articles"; /*Match Code*/ public static final int ITEM = 1; public static final int ITEM_ID = 2; public static final int ITEM_POS = 3; /*MIME*/ public static final String CONTENT_TYPE = "vnd.android.cursor.dir/vnd.shy.luo.article"; public static final String CONTENT_ITEM_TYPE = "vnd.android.cursor.item/vnd.shy.luo.article"; /*Content URI*/ public static final Uri CONTENT_URI = Uri.parse("content://" + AUTHORITY + "/item"); public static final Uri CONTENT_POS_URI = Uri.parse("content://" + AUTHORITY + "/pos"); } ~~~ ID、TITLE、ABSTRACT和URL四个常量前面已经解释过了，它是我们用来保存文章信息的数据表的四个列名；DEFAULT_SORT_ORDER常量是调用ContentProvider接口的query函数来查询数据时用的，它表示对查询结果按照_id列的值从小到大排列；METHOD_GET_ITEM_COUNT和KEY_ITEM_COUNT两个常量是调用ContentProvider接口的一个未公开函数call来查询数据时用的，它类似于微软COM中的IDispatch接口的Invoke函数，使用这个call函数时，传入参数METHOD_GET_ITEM_COUNT表示我们要调用我们自定义的ContentProvider子类中的getItemCount函数来获取数据库中的文章信息条目的数量，结果放在一个Bundle中以KEY_ITEM_COUNT为关键字的域中。 剩下的常量都是跟数据URI相关的，这个需要详细解释一下。URI的全称是Universal Resource Identifier，即通用资源标志符，通过它用来唯一标志某个资源在网络中的位置，它的结构和我们常见的HTTP形式URL是一样的，其实我们可以把常见的HTTP形式的URL看成是URI结构的一个实例，URI是在更高一个层次上的抽象。在Android系统中，它也定义了自己的用来定痊某个特定的Content Provider的URI结构，它通常由四个组件来组成，如下所示：  A组件称为Scheme，它固定为content:// ，表示它后面的路径所表示的资源是由Content Provider来提供的。 B组件称为Authority，它唯一地标识了一个特定的Content Provider，因此，这部分内容一般使用Content Provider所在的package来命名，使得它是唯一的。 C组件称为资源路径，它表示所请求的资源的类型，这部分内容是可选的。如果我们自己所实现的Content Provider只提供一种类型的资源访问，那么这部分内部就可以忽略；如果我们自己实现的Content Provider同时提供了多种类型的资源访问，那么这部分内容就不可以忽略了。例如，我们有两种电脑资源可以提供给用户访问，一种是笔记本电脑，一种是平板电脑，我们就把分别它们定义为notebook和pad；如果我们想进一步按照系统类型来进一步细分这两种电脑资源，对笔记本电脑来说，一种是安装了windows系统的，一种是安装了linux系统的，我们就分别把它们定义为notebook/windows和notebook/linux；对平板电脑来说，一种是安装了ios系统的，一种是安装了android系统的，我们就分别把它们定义为pad/ios和pad/android。 D组件称为资源ID，它表示所请求的是一个特定的资源，它通常是一个数字，对应前面我们所介绍的数据库表中的_id字段的内容，它唯一地标志了某一种资源下的一个特定的实例。继续以前面的电脑资源为例，如果我们请求的是编号为123的装了android系统的平板电脑，我们就把它定义为pad/android/123。当忽略这部分内容时，它有可能是表示请求某一种资源下的所有实例，取决于我们的URI匹配规则，后面我们将会进一步解释如何设置URI匹配规则。 回到上面的Articles.java源文件中，我们定义了两个URI，分别用COTENT_URI和CONTENT_POS_URI两个常量来表示，它们的Authority组件均指定为shy.luo.providers.articles。其中，COTENT_URI常量表示的URI表示是通过ID来访问文章信息的，而CONTENT_POS_URI常量表示的URI表示是通过位置来访问文章信息的。例如，content://shy.luo.providers.articles/item 表示访问所有的文章信息条目；content://shy.luo.providers.articles/item/123 表示只访问ID值为123的文章信息条目；content://shy.luo.providers.articles/pos/1 表示访问数据库表中的第1条文章信息条目，这条文章信息条目的ID值不一定为1。通过常量CONTENT_POS_URI来访问文章信息条目时，必须要指定位置，这也是我们设置的URI匹配规则来指定的，后面我们将会看到。 此外，我们还需要定义与URI对应的资源的MIME类型。每个MIME类型由两部分组成，前面是数据的大类别，后面定义具体的种类。在Content Provider中，URI所对应的资源的MIME类型的大类别根据同时访问的资源的数量分为两种，对于访问单个资源的URI，它的大类别就为vnd.android.cursor.item，而对于同时访问多个资源的URI，它的大类别就为vnd.android.cursor.dir。Content Provider的URI所对应的资源的MIME类型的具体类别就需要由Content Provider的提供者来设置了，它的格式一般为vnd.[company name].[resource type]的形式。例如，在我们的例子中，CONTENT_TYPE和COTENT_ITEM_TYPE两个常量分别定义了两种MIME类型，它们的大类别分别为vnd.android.cursor.dir和vnd.android.cursor.item，而具体类别均为vdn.shy.luo.article，其中shy.luo就是表示公司名了，而article表示资源的类型为文章。这两个MIME类型常量主要是在实现ContentProvider的getType函数时用到的，后面我们将会看到。 最后，ITEM、ITEM_ID和POS_ID三个常量分别定了三个URI匹配规则的匹配码。如果URI的形式为content://shy.luo.providers.articles/item ，则匹配规则返回的匹配码为ITEM；如果URI的形式为content://shy.luo.providers.articles/item/# ，其中#表示任意一个数字，则匹配规则返回的匹配码为ITEM_ID；如果URI的形式为#也是表示任意一个数字，则匹配规则返回的匹配码为ITEM_POS。这三个常量的用法我们在后面也将会看到。 这样，Articles.java文件的内容就介绍完了。下面我们再接着介绍位于src/shy/luo/providers/articles目录下的ArticlesProvider.java文件，它的内容如下所示： ~~~ import java.util.HashMap; import android.content.ContentValues; import android.content.Context; import android.content.UriMatcher; import android.content.ContentProvider; import android.content.ContentUris; import android.content.ContentResolver; import android.database.Cursor; import android.database.sqlite.SQLiteDatabase; import android.database.sqlite.SQLiteDatabase.CursorFactory; import android.database.sqlite.SQLiteException; import android.database.sqlite.SQLiteOpenHelper; import android.database.sqlite.SQLiteQueryBuilder; import android.net.Uri; import android.os.Bundle; import android.text.TextUtils; import android.util.Log; public class ArticlesProvider extends ContentProvider { private static final String LOG_TAG = "shy.luo.providers.articles.ArticlesProvider"; private static final String DB_NAME = "Articles.db"; private static final String DB_TABLE = "ArticlesTable"; private static final int DB_VERSION = 1; private static final String DB_CREATE = "create table " + DB_TABLE + " (" + Articles.ID + " integer primary key autoincrement, " + Articles.TITLE + " text not null, " + Articles.ABSTRACT + " text not null, " + Articles.URL + " text not null);"; private static final UriMatcher uriMatcher; static { uriMatcher = new UriMatcher(UriMatcher.NO_MATCH); uriMatcher.addURI(Articles.AUTHORITY, "item", Articles.ITEM); uriMatcher.addURI(Articles.AUTHORITY, "item/#", Articles.ITEM_ID); uriMatcher.addURI(Articles.AUTHORITY, "pos/#", Articles.ITEM_POS); } private static final HashMap articleProjectionMap; static { articleProjectionMap = new HashMap(); articleProjectionMap.put(Articles.ID, Articles.ID); articleProjectionMap.put(Articles.TITLE, Articles.TITLE); articleProjectionMap.put(Articles.ABSTRACT, Articles.ABSTRACT); articleProjectionMap.put(Articles.URL, Articles.URL); } private DBHelper dbHelper = null; private ContentResolver resolver = null; @Override public boolean onCreate() { Context context = getContext(); resolver = context.getContentResolver(); dbHelper = new DBHelper(context, DB_NAME, null, DB_VERSION); Log.i(LOG_TAG, "Articles Provider Create"); return true; } @Override public String getType(Uri uri) { switch (uriMatcher.match(uri)) { case Articles.ITEM: return Articles.CONTENT_TYPE; case Articles.ITEM_ID: case Articles.ITEM_POS: return Articles.CONTENT_ITEM_TYPE; default: throw new IllegalArgumentException("Error Uri: " + uri); } } @Override public Uri insert(Uri uri, ContentValues values) { if(uriMatcher.match(uri) != Articles.ITEM) { throw new IllegalArgumentException("Error Uri: " + uri); } SQLiteDatabase db = dbHelper.getWritableDatabase(); long id = db.insert(DB_TABLE, Articles.ID, values); if(id < 0) { throw new SQLiteException("Unable to insert " + values + " for " + uri); } Uri newUri = ContentUris.withAppendedId(uri, id); resolver.notifyChange(newUri, null); return newUri; } @Override public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) { SQLiteDatabase db = dbHelper.getWritableDatabase(); int count = 0; switch(uriMatcher.match(uri)) { case Articles.ITEM: { count = db.update(DB_TABLE, values, selection, selectionArgs); break; } case Articles.ITEM_ID: { String id = uri.getPathSegments().get(1); count = db.update(DB_TABLE, values, Articles.ID + "=" + id + (!TextUtils.isEmpty(selection) ? " and (" + selection + ')' : ""), selectionArgs); break; } default: throw new IllegalArgumentException("Error Uri: " + uri); } resolver.notifyChange(uri, null); return count; } @Override public int delete(Uri uri, String selection, String[] selectionArgs) { SQLiteDatabase db = dbHelper.getWritableDatabase(); int count = 0; switch(uriMatcher.match(uri)) { case Articles.ITEM: { count = db.delete(DB_TABLE, selection, selectionArgs); break; } case Articles.ITEM_ID: { String id = uri.getPathSegments().get(1); count = db.delete(DB_TABLE, Articles.ID + "=" + id + (!TextUtils.isEmpty(selection) ? " and (" + selection + ')' : ""), selectionArgs); break; } default: throw new IllegalArgumentException("Error Uri: " + uri); } resolver.notifyChange(uri, null); return count; } @Override public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) { Log.i(LOG_TAG, "ArticlesProvider.query: " + uri); SQLiteDatabase db = dbHelper.getReadableDatabase(); SQLiteQueryBuilder sqlBuilder = new SQLiteQueryBuilder(); String limit = null; switch (uriMatcher.match(uri)) { case Articles.ITEM: { sqlBuilder.setTables(DB_TABLE); sqlBuilder.setProjectionMap(articleProjectionMap); break; } case Articles.ITEM_ID: { String id = uri.getPathSegments().get(1); sqlBuilder.setTables(DB_TABLE); sqlBuilder.setProjectionMap(articleProjectionMap); sqlBuilder.appendWhere(Articles.ID + "=" + id); break; } case Articles.ITEM_POS: { String pos = uri.getPathSegments().get(1); sqlBuilder.setTables(DB_TABLE); sqlBuilder.setProjectionMap(articleProjectionMap); limit = pos + ", 1"; break; } default: throw new IllegalArgumentException("Error Uri: " + uri); } Cursor cursor = sqlBuilder.query(db, projection, selection, selectionArgs, null, null, TextUtils.isEmpty(sortOrder) ? Articles.DEFAULT_SORT_ORDER : sortOrder, limit); cursor.setNotificationUri(resolver, uri); return cursor; } @Override public Bundle call(String method, String request, Bundle args) { Log.i(LOG_TAG, "ArticlesProvider.call: " + method); if(method.equals(Articles.METHOD_GET_ITEM_COUNT)) { return getItemCount(); } throw new IllegalArgumentException("Error method call: " + method); } private Bundle getItemCount() { Log.i(LOG_TAG, "ArticlesProvider.getItemCount"); SQLiteDatabase db = dbHelper.getReadableDatabase(); Cursor cursor = db.rawQuery("select count(*) from " + DB_TABLE, null); int count = 0; if (cursor.moveToFirst()) { count = cursor.getInt(0); } Bundle bundle = new Bundle(); bundle.putInt(Articles.KEY_ITEM_COUNT, count); cursor.close(); db.close(); return bundle; } private static class DBHelper extends SQLiteOpenHelper { public DBHelper(Context context, String name, CursorFactory factory, int version) { super(context, name, factory, version); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL(DB_CREATE); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { db.execSQL("DROP TABLE IF EXISTS " + DB_TABLE); onCreate(db); } } } ~~~ 我们在实现自己的Content Provider时，必须继承于ContentProvider类，并且实现以下六个函数： * onCreate()，用来执行一些初始化的工作。 * query(Uri, String[], String, String[], String)，用来返回数据给调用者。 * insert(Uri, ContentValues)，用来插入新的数据。 * update(Uri, ContentValues, String, String[])，用来更新已有的数据。 * delete(Uri, String, String[])，用来删除数据。 * getType(Uri)，用来返回数据的MIME类型。 这些函数的实现都比较简单，这里我们就不详细介绍了，主要解释五个要点。 第一点是我们在ArticlesProvider类的内部中定义了一个DBHelper类，它继承于SQLiteOpenHelper类，它用是用辅助我们操作数据库的。使用这个DBHelper类来辅助操作数据库的好处是只有当我们第一次对数据库时行操作时，系统才会执行打开数据库文件的操作。拿我们这个例子来说，只有第三方应用程序第一次调用query、insert、update或者delete函数来操作数据库时，我们才会真正去打开相应的数据库文件。这样在onCreate函数里，就不用执行打开数据库的操作，因为这是一个耗时的操作，而在onCreate函数中，要避免执行这些耗时的操作。 第二点是设置URI匹配规则。因为我们是根据URI来操作数据库的，不同的URI对应不同的操作，所以我们首先要定义好URI匹配规则，这样，当我们获得一个URI时，就能快速地判断出要如何去操作数据库。设置URI匹配规则的代码如下所示： ~~~ private static final UriMatcher uriMatcher; static { uriMatcher = new UriMatcher(UriMatcher.NO_MATCH); uriMatcher.addURI(Articles.AUTHORITY, "item", Articles.ITEM); uriMatcher.addURI(Articles.AUTHORITY, "item/#", Articles.ITEM_ID); uriMatcher.addURI(Articles.AUTHORITY, "pos/#", Articles.ITEM_POS); } ~~~ 在创建UriMatcher对象uriMatcher时，我们传给构造函数的参数为UriMatcher.NO_MATCH，它表示当uriMatcher不能匹配指定的URI时，就返回代码UriMatcher.NO_MATCH。接下来增加了三个匹配规则，分别是content://shy.luo.providers.articles/item、content://shy.luo.providers.articles/item/# 和content://shy.luo.providers.articles/pos/# ，它们的匹配码分别是Articles.ITEM、Articles.ITEM_ID和Articles.ITEM_POS，其中，符号#表示匹配任何数字。 第三点是SQLiteQueryBuilder的使用。在query函数中，我们使用SQLiteQueryBuilder来辅助数据库查询操作，使用这个类的好处是我们可以不把数据库表的字段暴露出来，而是提供别名给第三方应用程序使用，这样就可以把数据库表内部设计隐藏起来，方便后续扩展和维护。列别名到真实列名的映射是由下面这个HashMap成员变量来实现的： ~~~ private static final HashMap articleProjectionMap; static { articleProjectionMap = new HashMap(); articleProjectionMap.put(Articles.ID, Articles.ID); articleProjectionMap.put(Articles.TITLE, Articles.TITLE); articleProjectionMap.put(Articles.ABSTRACT, Articles.ABSTRACT); articleProjectionMap.put(Articles.URL, Articles.URL); } ~~~ 在上面的put函数中，第一个参数表示列的别名，第二个参数表示列的真实名称。在这个例子中，我们把列的别名和和真实名称都设置成一样的。 第四点是数据更新机制的使用。执行insert、update和delete三个函数时，都会导致数据库中的数据发生变化，所以这时候要通过调用ContentResolver接口的notifyChange函数来通知那些注册了监控特定URI的ContentObserver对象，使得它们可以相应地执行一些处理，例如更新数据在界面上的显示。在query函数中，最终返回给调用者的是一个Cursor，调用者获得这个Cursor以后，可以通过它的deleteRow或者commitUpdates来执行一些更新数据库的操作，这时候也要通知那些注册了相应的URI的ContentObserver来作相应的处理，因此，这里在返回Cursor之前，要通过Cursor类的setNotificationUri函数来把当前上下文的ContentResolver对象保存到Curosr里面去，以便当通过这个Cursor来改变数据库中的数据时，可以通知相应的ContentObserver来处理。不过这种用法已经过时了，即不建议通过这个Cursor来改变数据库的数据，要把Cursor中的数据看作是只读数据。这里调用Cursor类的setNotificationUri函数还有另外一个作用，我们注意到它的第二个参数uri，对应的是Cursor中的内容，当把这个uri传给Cursor时，Cursor就会注册自己的ContentObserver来监控这个uri对应的数据的变化。一旦这个uri对应的数据发生变化，这个Cursor对应的数据就不是再新的了，这时候就需要采取一些操作来更新内容了。 第五点我们实现了ContentProvider的call函数。这个函数是一个未公开的函数，第三方应用程序只有Android源代码环境下开发，才能使用这个函数。设计这个函数的目的是什么呢？我们知道，当我们需要从Content Provider中获得数据时，一般都是要通过调用它的query函数来获得的，而这个函数将数据放在Cursor中来返回给调用者。以前面一篇文章Android应用程序组件Content Provider简要介绍和学习计划中，我们提到，Content Provider传给第三方应用程序的数据，是通过匿名共享内存来传输的。当要传输的数据量大的时候，使用匿名共享内存来传输数据是有好处的，它可以减入数据的拷贝，提高传输效率。但是，当要传输的数据量小时，使用匿名共享内存来作为媒介就有点用牛刀来杀鸡的味道了，因为匿名共享内存并不是免费的午餐，系统创建和匿名共享内存也是有开销的。因此，Content Provider提供了call函数来让第三方应用程序来获取一些自定义数据，这些数据一般都比较小，例如，只是传输一个整数，这样就可以用较小的代价来达到相同的数据传输的目的。 至此，ArticlesProvider的源代码就分析完了，下面我们还要在AndroidManifest.xml文件中配置这个ArticlesProvider类才能正常使用。AndroidManifest.xml文件的内容如下所示： ~~~ ~~~ 在配置Content Provider的时候，最重要的就是要指定它的authorities属性了，只有配置了这个属性，第三方应用程序才能通过它来找到这个Content Provider。这要需要注意的，这里配置的authorities属性的值是和我们前面在Articles.java文件中定义的AUTHORITY常量的值是一致的。另外一个属性multiprocess是一个布尔值，它表示这个Content Provider是否可以在每个客户进程中创建一个实例，这样做的目的是为了减少进程间通信的开销。这里我们为了减少不必要的内存开销，把属性multiprocess的值设置为false，使得系统只能有一个Content Provider实例存在，它运行在自己的进程中。在这个配置文件里面，我们还可以设置这个Content Provider的访问权限，这里我们为了简单起见，就不设置权限了。有关Content Provider的访问权限的设置，可以参考官方文档http://developer.android.com/guide/topics/manifest/provider-element.html。 这个应用程序使用到的字符串资源定义在res/values/strings.xml文件中，它的内容如下所示： ~~~ Articles Storage Articles ~~~ 由于Content Provider类型的应用程序是没有用户界面的，因此，我们不需要在res/layout目录下为程序准备界面配置文件。 程序的编译脚本Android.mk的内容如下所示： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := ArticlesProvider include $(BUILD_PACKAGE) ~~~ 下面我们就可以参照如何单独编译Android源代码中的模块一文来编译和打包这个应用程序了： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/ArticlesProvider USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们这里所创建的ArticlesProvider应用程序了。 前面说过，在Articles.java文件中定义的常量是要给第三方应用程序使用的，那么我们是不是直接把这个源文件交给第三方呢？这样就显得太不专业了，第三方拿到这个文件后，还必须要放在shy/luo/providers/articles目录下或者要把这个Articles类所在的package改掉才能正常使用。正确的做法是把编译好的Articles.java文件打包成一个jar文件交给第三方使用。编译ArticlesProvider这个应用程序成功后，生成的中间文件放在out/target/common/obj/APPS/ArticlesProvider_intermediates目录下，我们进入到这个目录中，然后执后下面的命令把Articles.class文件提取出来： ~~~ USER-NAME@MACHINE-NAME:~/Android/out/target/common/obj/APPS/ArticlesProvider_intermediates$ jar -xvf classes.jar shy/luo/providers/articles/Articles.class ~~~ 然后再单独打包这个Articles.class文件： ~~~ USER-NAME@MACHINE-NAME:~/Android/out/target/common/obj/APPS/ArticlesProvider_intermediates$ jar -cvf ArticlesProvider.jar ./shy ~~~ 这样，我们得到的ArticlesProvider.jar文件就包含了Articles.java这个文件中定义的常量了，第三方拿到这个文件后，就可以开发自己的应用程序来访问我们在ArticlesProvider这个Content Provider中保存的数据了。接下来我们就介绍调用这个ArticlesProvider来获取数据的第三方应用程序Article。 2. Article应用程序的实现 首先是参照前面的ArticlesProvider工程，在packages/experimental目录下建立工程文件目录Article。这个应用程序的作用是用来管理ArticlesProvider应用程序中保存的文章信息的，因此，它需要获得相应的Content Provider接口来访问ArticlesProvider中的数据。我们首先在工程目录Article下面创建一个libs目录，把上面得到的ArticlesProvider.jar放在libs目录下，后面我们在编译脚本的时候，再把它引用到工程上来。下面我们就开始分析这个应用程序的实现。 这个应用程序的主界面MainActivity包含了一个ListView控件，用来显示从ArticlesProvider中得到的文章信息条目，在这个主界面上，可以浏览、增加、删除和更新文章信息。当需要增加、删除或者更新文章信息时，就会跳到另外一个界面ArticleActivity中去执行具体的操作。为了方便开发，我们把每一个文章信息条目封装成了一个Article类，并且把与ArticlesProvider进交互的操作都通过ArticlesAdapter类来实现。下面介绍每一个类的具本实现。 下面是Article类的实现，它实现在src/shy/luo/Article.java文件中： ~~~ package shy.luo.article; public class Article { private int id; private String title; private String abs; private String url; public Article(int id, String title, String abs, String url) { this.id = id; this.title = title; this.abs = abs; this.url = url; } public void setId(int id) { this.id = id; } public int getId() { return this.id; } public void setTitle(String title) { this.title = title; } public String getTitle() { return this.title; } public void setAbstract(String abs) { this.abs = abs; } public String getAbstract() { return this.abs; } public void setUrl(String url) { this.url = url; } public String getUrl() { return this.url; } } 下面是ArticlesAdapter类的实现，它实现在src/shy/luo/ArticlesAdapter.java文件中： [java] view plain copy package shy.luo.article; import java.util.LinkedList; import shy.luo.providers.articles.Articles; import android.content.ContentResolver; import android.content.ContentUris; import android.content.ContentValues; import android.content.Context; import android.content.IContentProvider; import android.database.Cursor; import android.net.Uri; import android.os.Bundle; import android.os.RemoteException; import android.util.Log; public class ArticlesAdapter { private static final String LOG_TAG = "shy.luo.article.ArticlesAdapter"; private ContentResolver resolver = null; public ArticlesAdapter(Context context) { resolver = context.getContentResolver(); } public long insertArticle(Article article) { ContentValues values = new ContentValues(); values.put(Articles.TITLE, article.getTitle()); values.put(Articles.ABSTRACT, article.getAbstract()); values.put(Articles.URL, article.getUrl()); Uri uri = resolver.insert(Articles.CONTENT_URI, values); String itemId = uri.getPathSegments().get(1); return Integer.valueOf(itemId).longValue(); } public boolean updateArticle(Article article) { Uri uri = ContentUris.withAppendedId(Articles.CONTENT_URI, article.getId()); ContentValues values = new ContentValues(); values.put(Articles.TITLE, article.getTitle()); values.put(Articles.ABSTRACT, article.getAbstract()); values.put(Articles.URL, article.getUrl()); int count = resolver.update(uri, values, null, null); return count > 0; } public boolean removeArticle(int id) { Uri uri = ContentUris.withAppendedId(Articles.CONTENT_URI, id); int count = resolver.delete(uri, null, null); return count > 0; } public LinkedList

getAllArticles() { LinkedList

articles = new LinkedList

(); String[] projection = new String[] { Articles.ID, Articles.TITLE, Articles.ABSTRACT, Articles.URL }; Cursor cursor = resolver.query(Articles.CONTENT_URI, projection, null, null, Articles.DEFAULT_SORT_ORDER); if (cursor.moveToFirst()) { do { int id = cursor.getInt(0); String title = cursor.getString(1); String abs = cursor.getString(2); String url = cursor.getString(3); Article article = new Article(id, title, abs, url); articles.add(article); } while(cursor.moveToNext()); } return articles; } public int getArticleCount() { int count = 0; try { IContentProvider provider = resolver.acquireProvider(Articles.CONTENT_URI); Bundle bundle = provider.call(Articles.METHOD_GET_ITEM_COUNT, null, null); count = bundle.getInt(Articles.KEY_ITEM_COUNT, 0); } catch(RemoteException e) { e.printStackTrace(); } return count; } public Article getArticleById(int id) { Uri uri = ContentUris.withAppendedId(Articles.CONTENT_URI, id); String[] projection = new String[] { Articles.ID, Articles.TITLE, Articles.ABSTRACT, Articles.URL }; Cursor cursor = resolver.query(uri, projection, null, null, Articles.DEFAULT_SORT_ORDER); Log.i(LOG_TAG, "cursor.moveToFirst"); if (!cursor.moveToFirst()) { return null; } String title = cursor.getString(1); String abs = cursor.getString(2); String url = cursor.getString(3); return new Article(id, title, abs, url); } public Article getArticleByPos(int pos) { Uri uri = ContentUris.withAppendedId(Articles.CONTENT_POS_URI, pos); String[] projection = new String[] { Articles.ID, Articles.TITLE, Articles.ABSTRACT, Articles.URL }; Cursor cursor = resolver.query(uri, projection, null, null, Articles.DEFAULT_SORT_ORDER); if (!cursor.moveToFirst()) { return null; } int id = cursor.getInt(0); String title = cursor.getString(1); String abs = cursor.getString(2); String url = cursor.getString(3); return new Article(id, title, abs, url); } } ~~~ 这个类首先在构造函数里面获得应用程序上下文的ContentResolver接口，然后通过就可以通过这个接口来访问ArticlesProvider中的文章信息了。成员函数insertArticle、updateArticle和removeArticle分别用来新增、更新和删除一个文章信息条目；成员函数getAllArticlese用来获取所有的文章信息；成员函数getArticleById和getArticleByPos分别根据文章的ID和位置来获得具体文章信息条目；成员函数getArticleCount直接使用ContentProvider的未公开接口call来获得文章信息条目的数量，注意，这个函数要源代码环境下编译才能通过。 下面是程序主界面MainActivity类的实现，它实现在src/shy/luo/article/MainActivity.java文件中： ~~~ package shy.luo.article; import shy.luo.providers.articles.Articles; import android.app.Activity; import android.content.Context; import android.content.Intent; import android.database.ContentObserver; import android.os.Bundle; import android.os.Handler; import android.util.Log; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; import android.widget.AdapterView; import android.widget.BaseAdapter; import android.widget.Button; import android.widget.ListView; import android.widget.TextView; public class MainActivity extends Activity implements View.OnClickListener, AdapterView.OnItemClickListener { private final static String LOG_TAG = "shy.luo.article.MainActivity"; private final static int ADD_ARTICAL_ACTIVITY = 1; private final static int EDIT_ARTICAL_ACTIVITY = 2; private ArticlesAdapter aa = null; private ArticleAdapter adapter = null; private ArticleObserver observer = null; private ListView articleList = null; private Button addButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); aa = new ArticlesAdapter(this); articleList = (ListView)findViewById(R.id.listview_article); adapter = new ArticleAdapter(this); articleList.setAdapter(adapter); articleList.setOnItemClickListener(this); observer = new ArticleObserver(new Handler()); getContentResolver().registerContentObserver(Articles.CONTENT_URI, true, observer); addButton = (Button)findViewById(R.id.button_add); addButton.setOnClickListener(this); Log.i(LOG_TAG, "MainActivity Created"); } @Override public void onDestroy() { super.onDestroy(); getContentResolver().unregisterContentObserver(observer); } @Override public void onClick(View v) { if(v.equals(addButton)) { Intent intent = new Intent(this, ArticleActivity.class); startActivityForResult(intent, ADD_ARTICAL_ACTIVITY); } } @Override public void onItemClick(AdapterView parent, View view, int pos, long id) { Intent intent = new Intent(this, ArticleActivity.class); Article article = aa.getArticleByPos(pos); intent.putExtra(Articles.ID, article.getId()); intent.putExtra(Articles.TITLE, article.getTitle()); intent.putExtra(Articles.ABSTRACT, article.getAbstract()); intent.putExtra(Articles.URL, article.getUrl()); startActivityForResult(intent, EDIT_ARTICAL_ACTIVITY); } @Override public void onActivityResult(int requestCode,int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); switch(requestCode) { case ADD_ARTICAL_ACTIVITY: { if(resultCode == Activity.RESULT_OK) { String title = data.getStringExtra(Articles.TITLE); String abs = data.getStringExtra(Articles.ABSTRACT); String url = data.getStringExtra(Articles.URL); Article article = new Article(-1, title, abs, url); aa.insertArticle(article); } break; } case EDIT_ARTICAL_ACTIVITY: { if(resultCode == Activity.RESULT_OK) { int action = data.getIntExtra(ArticleActivity.EDIT_ARTICLE_ACTION, -1); if(action == ArticleActivity.MODIFY_ARTICLE) { int id = data.getIntExtra(Articles.ID, -1); String title = data.getStringExtra(Articles.TITLE); String abs = data.getStringExtra(Articles.ABSTRACT); String url = data.getStringExtra(Articles.URL); Article article = new Article(id, title, abs, url); aa.updateArticle(article); } else if(action == ArticleActivity.DELETE_ARTICLE) { int id = data.getIntExtra(Articles.ID, -1); aa.removeArticle(id); } } break; } } } private class ArticleObserver extends ContentObserver { public ArticleObserver(Handler handler) { super(handler); } @Override public void onChange (boolean selfChange) { adapter.notifyDataSetChanged(); } } private class ArticleAdapter extends BaseAdapter { private LayoutInflater inflater; public ArticleAdapter(Context context){ inflater = LayoutInflater.from(context); } @Override public int getCount() { return aa.getArticleCount(); } @Override public Object getItem(int pos) { return aa.getArticleByPos(pos); } @Override public long getItemId(int pos) { return aa.getArticleByPos(pos).getId(); } @Override public View getView(int position, View convertView, ViewGroup parent) { Article article = (Article)getItem(position); if (convertView == null) { convertView = inflater.inflate(R.layout.item, null); } TextView titleView = (TextView)convertView.findViewById(R.id.textview_article_title); titleView.setText("Title: " + article.getTitle()); TextView abstractView = (TextView)convertView.findViewById(R.id.textview_article_abstract); abstractView.setText("Abstract: " + article.getAbstract()); TextView urlView = (TextView)convertView.findViewById(R.id.textview_article_url); urlView.setText("URL: " + article.getUrl()); return convertView; } } } ~~~ 在应用程序的主界面中，我们使用一个ListView来显示文章信息条目，这个ListView的数据源由ArticleAdapter类来提供，而ArticleAdapter类又是通过ArticlesAdapter类来获得ArticlesProvider中的文章信息的。在MainActivity的onCreate函数，我们还通过应用程序上下文的ContentResolver接口来注册了一个ArticleObserver对象来监控ArticlesProvider中的文章信息。一旦ArticlesProvider中的文章信息发生变化，就会通过ArticleAdapter类来实时更新ListView中的文章信息。 下面是ArticleActivity类的实现，它实现在src/shy/luo/article/ArticleActivity.java文件中： ~~~ package shy.luo.article; import shy.luo.providers.articles.Articles; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.EditText; public class ArticleActivity extends Activity implements View.OnClickListener { private final static String LOG_TAG = "shy.luo.article.ArticleActivity"; public final static String EDIT_ARTICLE_ACTION = "EDIT_ARTICLE_ACTION"; public final static int MODIFY_ARTICLE = 1; public final static int DELETE_ARTICLE = 2; private int articleId = -1; private EditText titleEdit = null; private EditText abstractEdit = null; private EditText urlEdit = null; private Button addButton = null; private Button modifyButton = null; private Button deleteButton = null; private Button cancelButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.article); titleEdit = (EditText)findViewById(R.id.edit_article_title); abstractEdit = (EditText)findViewById(R.id.edit_article_abstract); urlEdit = (EditText)findViewById(R.id.edit_article_url); addButton = (Button)findViewById(R.id.button_add_article); addButton.setOnClickListener(this); modifyButton = (Button)findViewById(R.id.button_modify); modifyButton.setOnClickListener(this); deleteButton = (Button)findViewById(R.id.button_delete); deleteButton.setOnClickListener(this); cancelButton = (Button)findViewById(R.id.button_cancel); cancelButton.setOnClickListener(this); Intent intent = getIntent(); articleId = intent.getIntExtra(Articles.ID, -1); if(articleId != -1) { String title = intent.getStringExtra(Articles.TITLE); titleEdit.setText(title); String abs = intent.getStringExtra(Articles.ABSTRACT); abstractEdit.setText(abs); String url = intent.getStringExtra(Articles.URL); urlEdit.setText(url); addButton.setVisibility(View.GONE); } else { modifyButton.setVisibility(View.GONE); deleteButton.setVisibility(View.GONE); } Log.i(LOG_TAG, "ArticleActivity Created"); } @Override public void onClick(View v) { if(v.equals(addButton)) { String title = titleEdit.getText().toString(); String abs = abstractEdit.getText().toString(); String url = urlEdit.getText().toString(); Intent result = new Intent(); result.putExtra(Articles.TITLE, title); result.putExtra(Articles.ABSTRACT, abs); result.putExtra(Articles.URL, url); setResult(Activity.RESULT_OK, result); finish(); } else if(v.equals(modifyButton)){ String title = titleEdit.getText().toString(); String abs = abstractEdit.getText().toString(); String url = urlEdit.getText().toString(); Intent result = new Intent(); result.putExtra(Articles.ID, articleId); result.putExtra(Articles.TITLE, title); result.putExtra(Articles.ABSTRACT, abs); result.putExtra(Articles.URL, url); result.putExtra(EDIT_ARTICLE_ACTION, MODIFY_ARTICLE); setResult(Activity.RESULT_OK, result); finish(); } else if(v.equals(deleteButton)) { Intent result = new Intent(); result.putExtra(Articles.ID, articleId); result.putExtra(EDIT_ARTICLE_ACTION, DELETE_ARTICLE); setResult(Activity.RESULT_OK, result); finish(); } else if(v.equals(cancelButton)) { setResult(Activity.RESULT_CANCELED, null); finish(); } } } ~~~ 在ArticleActivity窗口中，我们可以执行新增、更新和删除文章信息的操作。如果启动ArticleActivity时，没有把文章ID传进来，就说明要执行操作是新增文章信息；如果启动ArticleActivity时，把文章ID和其它信自都传进来了，就说明要执行的操作是更新或者删除文章，根据用户在界面点击的是更新按钮还是删除按钮来确定。 程序使用到的界面文件定义在res/layout目录下，其中，main.xml文件定义MainActivity的界面，它的内容如下所示： ~~~ ~~~ item.xml文件定义了ListView中每一个文章信息条目的显示界面，它的内容如下所示： ~~~ ~~~ article.xml文件定义了ArticleActivity的界面，它的内容如下所示： ~~~ ~~~ 在res/drawable目录下，有一个border.xml文件定义了MainActivity界面上的ListView的背景，它的内容如下所示： ~~~ ~~~ 程序使用到的字符串资源文件定义在res/values/strings.xml文件中，它的内容如下所示： ~~~ Article Article Add Modify Delete Title: Abstract: URL: OK Cancel ~~~ 接下来再来看程序的配置文件AndroidManifest.xml： ~~~ ~~~ 编译脚本Android.mk的内容如下所示： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_STATIC_JAVA_LIBRARIES := libArticlesProvider LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := Article include $(BUILD_PACKAGE) ################################################### include $(CLEAR_VARS) LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES := libArticlesProvider:./libs/ArticlesProvider.jar include $(BUILD_MULTI_PREBUILT) ~~~ 这个编译脚本包含了两个部分的指令，一个是把libs目录下的预编译静态库ArticlesProvider.jar编译成一本地静态库libArticlesProvider，它的相关库文件保存在out/target/common/obj/JAVA_LIBRARIES/libArticlesProvider_intermediates目录下；另一个就是编译我们的程序Article了，它通过LOCAL_STATIC_JAVA_LIBRARIES变量来引用前面的libArticlesProvider库，这个库包含了所有我们用来访问ArticlesProvider这个Content Provider中的数据的常量。 下面我们就可以编译和打包这个应用程序了： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Article USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们这里所创建的Article应用程序了。 最后，就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器，请参考在Ubuntu上下载、编译和安装Android最新源代码一文。 执行以下命令启动模拟器： ~~~ USER-NAME@MACHINE-NAME:~/Android$ emulator ~~~ 这个应用程序的主界面如下图所示：  点击下面的Add按钮，可以添加新的文章信息条目：  在前一个界面的文件列表中，点击某一个文章条目，便可以更新或者删除文章信息条目：  这样，Content Provider的使用实例就介绍完了。这篇文章的目的是使读者对Content Provider有一个大概的了解和感性的认识，在下一篇文章中，我们将详细介绍Article应用程序是如何获得ArticlesProvider这个ContentProvider接口的，只有获得了这个接口之后，Article应用程序才能访问ArticlesProvider的数据，敬请关注。

原文出处——>[Android应用程序组件Content Provider简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/6946067) 在Android系统中，Content Provider作为应用程序四大组件之一，它起到在应用程序之间共享数据的作用，同时，它还是标准的数据访问接口。前面的一系列文章已经分析过Android应用程序的其它三大组件（Activity、Service和Broadcast Receiver）了，本文将简要介绍Content Provider组件在Android应用程序设计中的地位，为进一步学习打好基础。 我们知道，在Android系统上，每一个应用程序都有一个独立的用户ID。为什么要给每一个应用程序分配一个独立的用户ID呢？这是为了保护各个应用程序的数据不被其它应用程序恶意破坏而设计的。Android系统是基于Linux内核来开发的，而在Linux系统中，每一个文件除了文件本身的数据之外，还具有一定的属性，其中最重要的就是文件权限了。所谓的文件权限，就是指对文件的读、写和执行权限。此外，Linux还是一个多用户的操作系统，因此，Linux将系统中的每一个文件都与一个用户以及用户组关联起来，基于不同的用户而赋予不同的文件权限。只有当一个用户对某个文件拥有相应的权限时，才能执行相应的操作，例如，只有当一个用户对某个文件拥有读权限时，这个用户才可以调用read系统调用来读取这个文件的内容。Android系统继承了Linux系统管理文件的方法，为每一个应用程序分配一个独立的用户ID和用户组ID，而由这个应用程序创建出来的数据文件就赋予相应的用户以及用户组读写的权限，其余用户则无权对该文件进行读写。 如果我们通过adb shell命令连上模拟器，切换到/data/data目录下，就可以看到很多以应用程序包（package）命名的文件夹，这些文件夹里面存放的就是各个应用程序的数据文件，例如，如果我们进入到Android系统日历应用程序数据目录com.android.providers.calendar下的databases文件中，会看到一个用来保存日历数据的数据库文件calendar.db，它的权限设置如下所示： ~~~ root@android:/data/data/com.android.providers.calendar/databases # ls -l -rw-rw---- app_17 app_17 33792 2011-11-07 15:50 calendar.db ~~~ 在前面的十字符-rw-rw----中，最前面的符号-表示这是一个普通文件，接下来的三个字符rw-表示这个文件的所有者对这个文件可读可写不可执行，再接下来的三个字符rw-表示这个文件的所有者所在的用户组的用户对这个文件可读可写不可执行，而最后的三个字符---表示其它的用户对这个文件不可读写也不可执行，因为这是一个数据文件，所认所有用户都不可以执行它是正确的。在接下来的两个app_17字符串表示这个文件的所有者和这个所有者所在的用户组的名称均为app_17，这是应用程序在安装的时候系统分配的，在不同的系统上，这个字符串可能是不一样，不过它所表示的意义是一样的。这意味着只有用户ID为app_17或者用户组ID为app_17的那些进程才可以对这个calendar.db文件进行读写操作。我们通过执行终端上执行ps命令来查看一下哪个进程的用户ID为app_17： ~~~ root@android:/ # ps USER PID PPID VSIZE RSS WCHAN PC NAME root 1 0 272 184 c009f230 0000875c S /init ... ... ... ... ... ... ... ... app_17 295 35 107468 21492 ffffffff afd0c38c S com.android.providers.calendar .. ... ... ... ... ... ... ... root 556 527 892 332 00000000 afd0b24c R ps ~~~ 这里我们看到，正是这个日历应用程序com.android.providers.calendar进程的用户ID为app_17。这样，就验证了我们前面的分析了：只有这个日历应用程序com.android.providers.calendar才可以对这个calendar.db文件进行读写操作。这个日历应用程序com.android.providers.calendar其实是由一个Content Provider组件来实现的，在下一篇文章中，我们将实现一个自己的Content Provider，然后再对Content Provider的实现原理进行详细分析。 Android系统对应用程序的数据文件作如此严格的保护会不会有点过头了呢？如果一个应用程序想要读写另外一个应用程序的数据文件时，应该怎么办呢？举一个典型的应用场景，我们在开发自己的应用程序时，有时候会希望读取通讯录里面某个联系人的手机号码或者电子邮件，以便可以对这个联系人打电话或者发送电子邮件，这时候就需要读取通讯录里面的联系人数据文件了。 现在在互联网里面，都流行平台的概念，各大公司都打着开放平台的口号，来吸引第三方来为自己的平台做应用，例如，国外最流行的Fackbook开放平台和Google+开放平台等，国内的有腾讯的Q+开放平台，还有新浪微博开放平台、360的开放平台等。这些开放平台的核心就是要开放用户数据给第三方来使使用，就像前面我们说的Android系统的通讯录，它需要把自己联系人数据开放出来给其它应用程序使用。但是，这些数据都是各个平台自己的核心数据和核心竞争力，它们需要有保护地进行开放。Android系统中的Content Provider应用程序组件正是结合上面分析的这种文件权限机制来秉承这种有保护地开放自己的数据给其它应用程序使用的理念。 从另外一个观点来看，即使我们不是在做平台，而只是在做一个应用程序软件，是不是就不需要这么使用到Content Provider机制了呢？非也，现在的应用程序软件，越着公司业务的成长，越来越庞大，越来越复杂。软件工程告诉我们，我们在设计这种大型的复杂的软件的时候，需要分模块和分层次来实现各个子功能组件，使得各个模块功能以松耦合的方式组织在一起完成整个应用程序功能。这样做的好处当然就是便于我们维护和扩展应用程序的代码和功能了，以及适应复杂的业务环境。在一个大型的应用程序软件架构中，从垂直的方向来看，一般都会划分为数据层、数据访问接口层以及上面的业务层。数据层用来保存数据，这些数据可以用文件的方式来组织，也可以用数据库的方式来组织，甚至可以保存在网络中；数据访问层负责向上面的业务层提供数据，而向下管理好数据层的数据；最后业务层通过数据访问层来获取一些业务相关的数据来实现自己的业务逻辑。 基于这种开放平台建设或者复杂软件架构的理念，我们得出一个Android应用程序设计的一般方法，如下图所示：  在这个架构中， 数据层采用数据库、文件或者网络来保存数据，数据访问层使用Content Provider来实现，而业务层就通过一些APP来实现。为了降低各个功能模块间耦合性，我们可以把业务层的各个APP和数据访问层中的Content Provider，放在不同的应用程序进程中来实现，而数据库中的数据统一由Content Provider来管理，即Content Provider拥有对这些文件直接进行读写的权限，同时，它又根据需要来有保护地把这些数据开放出来给上层的APP来使用。 那么，Content Provider又是如何把数据开放给上面的APP使用呢？一方面是这些APP没有权限读取这些数据文件，另一外面是Content Provider和这些APP是在不同的进程空间里面。回忆一下，我们在前面Android进程间通信（IPC）机制Binder简要介绍和学习计划这一系文章中学习的Android系统中Binder进程间通信机制，不同的应用程序之间可以通过Binder进程间调用来传输数据。因此，前面关于一个应用程序应该如何来读写另外一个应用程序的数据的问题的答案就是使用Binder进程间通信机制，虽然一个应用程序不能直接读取另一个应用程序的数据，但是它却可以通过进程间通信方式来请求另一个这个应用程序给它传输数据。这样我们就解决了文件权限限制所带来的问题了。 然而，事情还不是那么简单，一般Content Provider管理的都是大量的数据，如果在进程间传输大量的数据，效率是不是会很低下呢？这时候，前面我们在Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划这一系列文章中学习的匿名共享内存（Anonymous Shared Memory）就派上用场了。把需要在进程间传输的数据都写到共享内存中去，然后只能通过Binder进程间通信机制来传输一个共享内存的打开文件描述符给对方就好了，是不是很简单呢。在Android系统中，Binder进程间通信机制和匿名共享内存机制结合在一起使用，真是太完美了。 Content Provider如何在应用程序之间共享数据以及它在应用程序设计中的地位就简要介绍到这里了，在接下来的四篇文章中，我们将以一个 Content Provider的应用实例来详细分析它的启动过程、数据共享原理以及数据监控机制： 1. Android应用程序组件Content Provider的应用实例。 2. Android应用程序组件Content Provider的启动过程源代码分析。 3. Android应用程序组件Content Provider在不同应用程序之间共享数据的原理分析。 4. Android应用程序组件Content Provider的数据监控机制分析。

[Android应用程序组件Content Provider简要介绍和学习计划](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6ContentProvider%E7%AE%80%E8%A6%81%E4%BB%8B%E7%BB%8D%E5%92%8C%E5%AD%A6%E4%B9%A0%E8%AE%A1%E5%88%92.md) [Android应用程序组件Content Provider应用实例](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6ContentProvider%E5%BA%94%E7%94%A8%E5%AE%9E%E4%BE%8B.md) [Android应用程序组件Content Provider的启动过程源代码分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6ContentProvider%E7%9A%84%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90.md) [Android应用程序组件Content Provider在应用程序之间共享数据的原理分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6ContentProvider%E5%9C%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E4%B9%8B%E9%97%B4%E5%85%B1%E4%BA%AB%E6%95%B0%E6%8D%AE%E7%9A%84%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90.md) [Android应用程序组件Content Provider的共享数据更新通知机制分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6ContentProvider%E7%9A%84%E5%85%B1%E4%BA%AB%E6%95%B0%E6%8D%AE%E6%9B%B4%E6%96%B0%E9%80%9A%E7%9F%A5%E6%9C%BA%E5%88%B6%E5%88%86%E6%9E%90.md)

原文出处——>[Android应用程序绑定服务（bindService）的过程源代码分析](http://blog.csdn.net/luoshengyang/article/details/6745181) Android应用程序组件Service与Activity一样，既可以在新的进程中启动，也可以在应用程序进程内部启动；前面我们已经分析了在新的进程中启动Service的过程，本文将要介绍在应用程序内部绑定Service的过程，这是一种在应用程序进程内部启动Service的方法。 在前面一篇文章Android进程间通信（IPC）机制Binder简要介绍和学习计划中，我们就曾经提到，在Android系统中，每一个应用程序都是由一些Activity和Service组成的，一般Service运行在独立的进程中，而Activity有可能运行在同一个进程中，也有可能运行在不同的进程中；在接下来的文章中，Android系统在新进程中启动自定义服务过程（startService）的原理分析一文介绍了在新的进程中启动Service的过程，Android应用程序启动过程源代码分析一文介绍了在新的进程中启动Activity的过程，而Android应用程序内部启动Activity过程（startActivity）的源代码分析一文则介绍了在应用程序进程内部启动Activity的过程；本文接过最后一棒，继续介绍在应用程序进程内部启动Service的过程，这种过程又可以称在应用程序进程内部绑定服务（bindService）的过程，这样，读者应该就可以对Android应用程序启动Activity和Service有一个充分的认识了。 这里仍然是按照老规矩，通过具体的例子来分析Android应用程序绑定Service的过程，而所使用的例子便是前面我们在介绍Android系统广播机制的一篇文章Android系统中的广播（Broadcast）机制简要介绍和学习计划中所开发的应用程序Broadcast了。 我们先简单回顾一下这个应用程序实例绑定Service的过程。在这个应用程序的MainActivity的onCreate函数中，会调用bindService来绑定一个计数器服务CounterService，这里绑定的意思其实就是在MainActivity内部获得CounterService的接口，所以，这个过程的第一步就是要把CounterService启动起来。当CounterService的onCreate函数被调用起来了，就说明CounterService已经启动起来了，接下来系统还要调用CounterService的onBind函数，跟CounterService要一个Binder对象，这个Binder对象是在CounterService内部自定义的CounterBinder类的一个实例，它继承于Binder类，里面实现一个getService函数，用来返回外部的CounterService接口。系统得到这个Binder对象之后，就会调用MainActivity在bindService函数里面传过来的ServiceConnection实例的onServiceConnected函数，并把这个Binder对象以参数的形式传到onServiceConnected函数里面，于是，MainActivity就可以调用这个Binder对象的getService函数来获得CounterService的接口了。 这个过程比较复杂，但总体来说，思路还是比较清晰的，整个调用过程为MainActivity.bindService->CounterService.onCreate->CounterService.onBind->MainActivity.ServiceConnection.onServiceConnection->CounterService.CounterBinder.getService。下面，我们就先用一个序列图来总体描述这个服务绑定的过程，然后就具体分析每一个步骤。  **Step 1. ContextWrapper.bindService** 这个函数定义在frameworks/base/core/java/android/content/ContextWrapper.java文件中： ~~~ public class ContextWrapper extends Context { Context mBase; ...... @Override public boolean bindService(Intent service, ServiceConnection conn, int flags) { return mBase.bindService(service, conn, flags); } ...... } ~~~ 这里的mBase是一个ContextImpl实例变量，于是就调用ContextImpl的bindService函数来进一步处理。 **Step 2. ContextImpl.bindServi**ce 这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件中： ~~~ class ContextImpl extends Context { ...... @Override public boolean bindService(Intent service, ServiceConnection conn, int flags) { IServiceConnection sd; if (mPackageInfo != null) { sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), mMainThread.getHandler(), flags); } else { ...... } try { int res = ActivityManagerNative.getDefault().bindService( mMainThread.getApplicationThread(), getActivityToken(), service, service.resolveTypeIfNeeded(getContentResolver()), sd, flags); ...... return res != 0; } catch (RemoteException e) { return false; } } ...... } ~~~ 这里的mMainThread是一个ActivityThread实例，通过它的getHandler函数可以获得一个Handler对象，有了这个Handler对象后，就可以把消息分发到ActivityThread所在的线程消息队列中去了，后面我们将会看到这个用法，现在我们暂时不关注，只要知道这里从ActivityThread处获得了一个Handler并且保存在下面要介绍的ServiceDispatcher中去就可以了。 我们先看一下ActivityThread.getHandler的实现，然后再回到这里的bindService函数来。 **Step 3. ActivityThread.getHandler** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... final H mH = new H(); ...... private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... } ...... } ...... final Handler getHandler() { return mH; } ...... } ~~~ 这里返回的Handler是在ActivityThread类内部从Handler类继承下来的一个H类实例变量。 回到Step 2中的ContextImpl.bindService函数中，获得了这个Handler对象后，就调用mPackageInfo.getServiceDispatcher函数来获得一个IServiceConnection接口，这里的mPackageInfo的类型是LoadedApk，我们来看看它的getServiceDispatcher函数的实现，然后再回到ContextImpl.bindService函数来。 **Step 4. LoadedApk.getServiceDispatcher** 这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件中： ~~~ final class LoadedApk { ...... public final IServiceConnection getServiceDispatcher(ServiceConnection c, Context context, Handler handler, int flags) { synchronized (mServices) { LoadedApk.ServiceDispatcher sd = null; HashMap map = mServices.get(context); if (map != null) { sd = map.get(c); } if (sd == null) { sd = new ServiceDispatcher(c, context, handler, flags); if (map == null) { map = new HashMap(); mServices.put(context, map); } map.put(c, sd); } else { sd.validate(context, handler); } return sd.getIServiceConnection(); } } ...... static final class ServiceDispatcher { private final ServiceDispatcher.InnerConnection mIServiceConnection; private final ServiceConnection mConnection; private final Handler mActivityThread; ...... private static class InnerConnection extends IServiceConnection.Stub { final WeakReference mDispatcher; ...... InnerConnection(LoadedApk.ServiceDispatcher sd) { mDispatcher = new WeakReference(sd); } ...... } ...... ServiceDispatcher(ServiceConnection conn, Context context, Handler activityThread, int flags) { mIServiceConnection = new InnerConnection(this); mConnection = conn; mActivityThread = activityThread; ...... } ...... IServiceConnection getIServiceConnection() { return mIServiceConnection; } ...... } ...... } ~~~ 在getServiceDispatcher函数中，传进来的参数context是一个MainActivity实例，先以它为Key值在mServices中查看一下，是不是已经存在相应的ServiceDispatcher实例，如果有了，就不用创建了，直接取出来。在我们这个情景中，需要创建一个新的ServiceDispatcher。在创建新的ServiceDispatcher实例的过程中，将上面传下来ServiceConnection参数c和Hanlder参数保存在了ServiceDispatcher实例的内部，并且创建了一个InnerConnection对象，这是一个Binder对象，一会是要传递给ActivityManagerService的，ActivityManagerServic后续就是要通过这个Binder对象和ServiceConnection通信的。 函数getServiceDispatcher最后就是返回了一个InnerConnection对象给ContextImpl.bindService函数。回到ContextImpl.bindService函数中，它接着就要调用ActivityManagerService的远程接口来进一步处理了。 **Step 5. ActivityManagerService.bindService** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public int bindService(IApplicationThread caller, IBinder token, Intent service, String resolvedType, IServiceConnection connection, int flags) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); data.writeStrongBinder(token); service.writeToParcel(data, 0); data.writeString(resolvedType); data.writeStrongBinder(connection.asBinder()); data.writeInt(flags); mRemote.transact(BIND_SERVICE_TRANSACTION, data, reply, 0); reply.readException(); int res = reply.readInt(); data.recycle(); reply.recycle(); return res; } ...... } ~~~ 这个函数通过Binder驱动程序就进入到ActivityManagerService的bindService函数去了。 **Step 6. ActivityManagerService.bindService** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public int bindService(IApplicationThread caller, IBinder token, Intent service, String resolvedType, IServiceConnection connection, int flags) { ...... synchronized(this) { ...... final ProcessRecord callerApp = getRecordForAppLocked(caller); ...... ActivityRecord activity = null; if (token != null) { int aindex = mMainStack.indexOfTokenLocked(token); ...... activity = (ActivityRecord)mMainStack.mHistory.get(aindex); } ...... ServiceLookupResult res = retrieveServiceLocked(service, resolvedType, Binder.getCallingPid(), Binder.getCallingUid()); ...... ServiceRecord s = res.record; final long origId = Binder.clearCallingIdentity(); ...... AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp); ConnectionRecord c = new ConnectionRecord(b, activity, connection, flags, clientLabel, clientIntent); IBinder binder = connection.asBinder(); ArrayList clist = s.connections.get(binder); if (clist == null) { clist = new ArrayList(); s.connections.put(binder, clist); } clist.add(c); b.connections.add(c); if (activity != null) { if (activity.connections == null) { activity.connections = new HashSet(); } activity.connections.add(c); } b.client.connections.add(c); clist = mServiceConnections.get(binder); if (clist == null) { clist = new ArrayList(); mServiceConnections.put(binder, clist); } clist.add(c); if ((flags&Context.BIND_AUTO_CREATE) != 0) { ...... if (!bringUpServiceLocked(s, service.getFlags(), false)) { return 0; } } ...... } return 1; } ...... } ~~~ 函数首先根据传进来的参数token是MainActivity在ActivityManagerService里面的一个令牌，通过这个令牌就可以将这个代表MainActivity的ActivityRecord取回来了。 接着通过retrieveServiceLocked函数，得到一个ServiceRecord，这个ServiceReocrd描述的是一个Service对象，这里就是CounterService了，这是根据传进来的参数service的内容获得的。回忆一下在MainActivity.onCreate函数绑定服务的语句： ~~~ Intent bindIntent = new Intent(MainActivity.this, CounterService.class); bindService(bindIntent, serviceConnection, Context.BIND_AUTO_CREATE); ~~~ 这里的参数service，就是上面的bindIntent了，它里面设置了CounterService类的信息（CounterService.class），因此，这里可以通过它来把CounterService的信息取出来，并且保存在ServiceRecord对象s中。 接下来，就是把传进来的参数connection封装成一个ConnectionRecord对象。注意，这里的参数connection是一个Binder对象，它的类型是LoadedApk.ServiceDispatcher.InnerConnection，是在Step 4中创建的，后续ActivityManagerService就是要通过它来告诉MainActivity，CounterService已经启动起来了，因此，这里要把这个ConnectionRecord变量c保存下来，它保在在好几个地方，都是为了后面要用时方便地取回来的，这里就不仔细去研究了，只要知道ActivityManagerService要使用它时就可以方便地把它取出来就可以了，具体后面我们再分析。 最后，传进来的参数flags的位Context.BIND_AUTO_CREATE为1（参见上面MainActivity.onCreate函数调用bindService函数时设置的参数），因此，这里会调用bringUpServiceLocked函数进一步处理。 **Step 7. ActivityManagerService.bringUpServiceLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final boolean bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean whileRestarting) { ...... final String appName = r.processName; ProcessRecord app = getProcessRecordLocked(appName, r.appInfo.uid); if (app != null && app.thread != null) { try { realStartServiceLocked(r, app); return true; } catch (RemoteException e) { ...... } } // Not running -- get it started, and enqueue this service record // to be executed when the app comes up. if (startProcessLocked(appName, r.appInfo, true, intentFlags, "service", r.name, false) == null) { ...... } ...... } ...... } ~~~ 回忆在Android系统中的广播（Broadcast）机制简要介绍和学习计划中一文中，我们没有在程序的AndroidManifest.xml配置文件中设置CounterService的process属性值，因此，它默认就为application标签的process属性值，而application标签的process属性值也没有设置，于是，它们就默认为应用程序的包名了，即这里的appName的值为"shy.luo.broadcast"。接下来根据appName和应用程序的uid值获得一个ProcessRecord记录，由于之前在启动MainActivity的时候，已经根据这个appName和uid值创建了一个ProcessReocrd对象（具体可以参考Android应用程序启动过程源代码分析一文），因此，这里取回来的app和app.thread均不为null，于是，就执行realStartServiceLocked函数来执行下一步操作了。 如果这里得到的ProcessRecord变量app为null，又是什么情况呢？在这种情况下，就会执行后面的startProcessLocked函数来创建一个新的进程，然后在这个新的进程中启动这个Service了，具体可以参考前面一篇文章Android系统在新进程中启动自定义服务过程（startService）的原理分析。 **Step 8. ActivityManagerService.realStartServiceLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final void realStartServiceLocked(ServiceRecord r, ProcessRecord app) throws RemoteException { ...... r.app = app; ...... app.services.add(r); ...... try { ...... app.thread.scheduleCreateService(r, r.serviceInfo); ...... } finally { ...... } requestServiceBindingsLocked(r); ...... } ...... } ~~~ 这个函数执行了两个操作，一个是操作是调用app.thread.scheduleCreateService函数来在应用程序进程内部启动CounterService，这个操作会导致CounterService的onCreate函数被调用；另一个操作是调用requestServiceBindingsLocked函数来向CounterService要一个Binder对象，这个操作会导致CounterService的onBind函数被调用。 这里，我们先沿着app.thread.scheduleCreateService这个路径分析下去，然后再回过头来分析requestServiceBindingsLocked的调用过程。这里的app.thread是一个Binder对象的远程接口，类型为ApplicationThreadProxy。每一个Android应用程序进程里面都有一个ActivtyThread对象和一个ApplicationThread对象，其中是ApplicationThread对象是ActivityThread对象的一个成员变量，是ActivityThread与ActivityManagerService之间用来执行进程间通信的，具体可以参考Android应用程序启动过程源代码分析一文。 **Step 9. ApplicationThreadProxy.scheduleCreateService** 这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中： ~~~ class ApplicationThreadProxy implements IApplicationThread { ...... public final void scheduleCreateService(IBinder token, ServiceInfo info) throws RemoteException { Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); data.writeStrongBinder(token); info.writeToParcel(data, 0); mRemote.transact(SCHEDULE_CREATE_SERVICE_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle(); } ...... } ~~~ 这里通过Binder驱动程序就进入到ApplicationThread的scheduleCreateService函数去了。 **Step 10. ApplicationThread.scheduleCreateService** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class ApplicationThread extends ApplicationThreadNative { ...... public final void scheduleCreateService(IBinder token, ServiceInfo info) { CreateServiceData s = new CreateServiceData(); s.token = token; s.info = info; queueOrSendMessage(H.CREATE_SERVICE, s); } ...... } ...... } ~~~ 这里它执行的操作就是调用ActivityThread的queueOrSendMessage函数把一个H.CREATE_SERVICE类型的消息放到ActivityThread的消息队列中去。 **Step 11. ActivityThread.queueOrSendMessage** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... // if the thread hasn't started yet, we don't have the handler, so just // save the messages until we're ready. private final void queueOrSendMessage(int what, Object obj) { queueOrSendMessage(what, obj, 0, 0); } private final void queueOrSendMessage(int what, Object obj, int arg1) { queueOrSendMessage(what, obj, arg1, 0); } private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) { synchronized (this) { ...... Message msg = Message.obtain(); msg.what = what; msg.obj = obj; msg.arg1 = arg1; msg.arg2 = arg2; mH.sendMessage(msg); } } ...... } ~~~ 这个消息最终是通过mH.sendMessage发送出去的，这里的mH是一个在ActivityThread内部定义的一个类，继承于Hanlder类，用于处理消息的。 **Step 12. H.sendMessage** 由于H类继承于Handler类，因此，这里实际执行的Handler.sendMessage函数，这个函数定义在frameworks/base/core/java/android/os/Handler.java文件，这里我们就不看了，有兴趣的读者可以自己研究一下，调用了这个函数之后，这个消息就真正地进入到ActivityThread的消息队列去了，最终这个消息由H.handleMessage函数来处理，这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... switch (msg.what) { ...... case CREATE_SERVICE: handleCreateService((CreateServiceData)msg.obj); break; ...... } } } ...... } ~~~ 这个消息最终由ActivityThread的handleCreateService函数来处理。 **Step 13. ActivityThread.handleCreateService** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void handleCreateService(CreateServiceData data) { ...... LoadedApk packageInfo = getPackageInfoNoCheck( data.info.applicationInfo); Service service = null; try { java.lang.ClassLoader cl = packageInfo.getClassLoader(); service = (Service) cl.loadClass(data.info.name).newInstance(); } catch (Exception e) { ...... } try { ...... ContextImpl context = new ContextImpl(); context.init(packageInfo, null, this); Application app = packageInfo.makeApplication(false, mInstrumentation); context.setOuterContext(service); service.attach(context, this, data.info.name, data.token, app, ActivityManagerNative.getDefault()); service.onCreate(); mServices.put(data.token, service); ...... } catch (Exception e) { ...... } } ...... } ~~~ 这个函数的工作就是把CounterService类加载到内存中来，然后调用它的onCreate函数。 **Step 14. CounterService.onCreate** 这个函数定义在Android系统中的广播（Broadcast）机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的工程目录下的src/shy/luo/broadcast/CounterService.java文件中： ~~~ public class CounterService extends Service implements ICounterService { ...... @Override public void onCreate() { super.onCreate(); Log.i(LOG_TAG, "Counter Service Created."); } ...... } ~~~ 这样，CounterService就启动起来了。 至此，应用程序绑定服务过程中的第一步MainActivity.bindService->CounterService.onCreate就完成了。 这一步完成之后，我们还要回到Step 8中去，执行下一个操作，即调用ActivityManagerService.requestServiceBindingsLocked函数，这个调用是用来执行CounterService的onBind函数的。 **Step 15. ActivityManagerService.requestServiceBindingsLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final void requestServiceBindingsLocked(ServiceRecord r) { Iterator bindings = r.bindings.values().iterator(); while (bindings.hasNext()) { IntentBindRecord i = bindings.next(); if (!requestServiceBindingLocked(r, i, false)) { break; } } } private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i, boolean rebind) { ...... if ((!i.requested || rebind) && i.apps.size() > 0) { try { ...... r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind); ...... } catch (RemoteException e) { ...... } } return true; } ...... } ~~~ 这里的参数r就是我们在前面的Step 6中创建的ServiceRecord了，它代表刚才已经启动了的CounterService。函数requestServiceBindingsLocked调用了requestServiceBindingLocked函数来处理绑定服务的操作，而函数requestServiceBindingLocked又调用了app.thread.scheduleBindService函数执行操作，前面我们已经介绍过app.thread，它是一个Binder对象的远程接口，类型是ApplicationThreadProxy。 **Step 16. ApplicationThreadProxy.scheduleBindService** 这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中： ~~~ class ApplicationThreadProxy implements IApplicationThread { ...... public final void scheduleBindService(IBinder token, Intent intent, boolean rebind) throws RemoteException { Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); data.writeStrongBinder(token); intent.writeToParcel(data, 0); data.writeInt(rebind ? 1 : 0); mRemote.transact(SCHEDULE_BIND_SERVICE_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle(); } ...... } ~~~ 这里通过Binder驱动程序就进入到ApplicationThread的scheduleBindService函数去了。 **Step 17. ApplicationThread.scheduleBindService** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... public final void scheduleBindService(IBinder token, Intent intent, boolean rebind) { BindServiceData s = new BindServiceData(); s.token = token; s.intent = intent; s.rebind = rebind; queueOrSendMessage(H.BIND_SERVICE, s); } ...... } ~~~ 这里像上面的Step 11一样，调用ActivityThread.queueOrSendMessage函数来发送消息。 **Step 18. ActivityThread.queueOrSendMessage** 参考上面的Step 11，不过这里的消息类型是H.BIND_SERVICE。 **Step 19. H.sendMessage** 参考上面的Step 12，不过这里最终在H.handleMessage函数中，要处理的消息类型是H.BIND_SERVICE： ~~~ public final class ActivityThread { ...... private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... switch (msg.what) { ...... case BIND_SERVICE: handleBindService((BindServiceData)msg.obj); break; ...... } } } ...... } ~~~ 这里调用ActivityThread.handleBindService函数来进一步处理。 **Step 20. ActivityThread.handleBindService** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void handleBindService(BindServiceData data) { Service s = mServices.get(data.token); if (s != null) { try { data.intent.setExtrasClassLoader(s.getClassLoader()); try { if (!data.rebind) { IBinder binder = s.onBind(data.intent); ActivityManagerNative.getDefault().publishService( data.token, data.intent, binder); } else { ...... } ...... } catch (RemoteException ex) { } } catch (Exception e) { ...... } } } ...... } ~~~ 在前面的Step 13执行ActivityThread.handleCreateService函数中，已经将这个CounterService实例保存在mServices中，因此，这里首先通过data.token值将它取回来，保存在本地变量s中，接着执行了两个操作，一个操作是调用s.onBind，即CounterService.onBind获得一个Binder对象，另一个操作就是把这个Binder对象传递给ActivityManagerService。 我们先看CounterService.onBind操作，然后再回到ActivityThread.handleBindService函数中来。 **Step 21. CounterService.onBind** 这个函数定义在Android系统中的广播（Broadcast）机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的工程目录下的src/shy/luo/broadcast/CounterService.java文件中： ~~~ public class CounterService extends Service implements ICounterService { ...... private final IBinder binder = new CounterBinder(); public class CounterBinder extends Binder { public CounterService getService() { return CounterService.this; } } @Override public IBinder onBind(Intent intent) { return binder; } ...... } ~~~ 这里的onBind函数返回一个是CounterBinder类型的Binder对象，它里面实现一个成员函数getService，用于返回CounterService接口。 至此，应用程序绑定服务过程中的第二步CounterService.onBind就完成了。 回到ActivityThread.handleBindService函数中，获得了这个CounterBinder对象后，就调用ActivityManagerProxy.publishService来通知MainActivity，CounterService已经连接好了。 **Step 22. ActivityManagerProxy.publishService** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public void publishService(IBinder token, Intent intent, IBinder service) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(token); intent.writeToParcel(data, 0); data.writeStrongBinder(service); mRemote.transact(PUBLISH_SERVICE_TRANSACTION, data, reply, 0); reply.readException(); data.recycle(); reply.recycle(); } ...... } ~~~ 这里通过Binder驱动程序就进入到ActivityManagerService的publishService函数中去了。 **Step 23. ActivityManagerService.publishService** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public void publishService(IBinder token, Intent intent, IBinder service) { ...... synchronized(this) { ...... ServiceRecord r = (ServiceRecord)token; ...... ...... if (r != null) { Intent.FilterComparison filter = new Intent.FilterComparison(intent); IntentBindRecord b = r.bindings.get(filter); if (b != null && !b.received) { b.binder = service; b.requested = true; b.received = true; if (r.connections.size() > 0) { Iterator> it = r.connections.values().iterator(); while (it.hasNext()) { ArrayList clist = it.next(); for (int i=0; i clist = s.connections.get(binder); if (clist == null) { clist = new ArrayList(); s.connections.put(binder, clist); } ~~~ 因此，这里可以从r.connections中将这个ConnectionRecord取出来： ~~~ Iterator> it = r.connections.values().iterator(); while (it.hasNext()) { ArrayList clist = it.next(); for (int i=0; i ';

[Android应用程序绑定服务（bindService）的过程源代码分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%91%E5%AE%9A%E6%9C%8D%E5%8A%A1%EF%BC%88bindService%EF%BC%89%E7%9A%84%E8%BF%87%E7%A8%8B%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90.md)

原文出处——>[Android应用程序在新的进程中启动新的Activity的方法和过程分析](http://blog.csdn.net/luoshengyang/article/details/6720261) 前面我们在分析Activity启动过程的时候，看到同一个应用程序的Activity一般都是在同一个进程中启动，事实上，Activity也可以像Service一样在新的进程中启动，这样，一个应用程序就可以跨越好几个进程了，本文就分析一下在新的进程中启动Activity的方法和过程。 在前面Android进程间通信（IPC）机制Binder简要介绍和学习计划一文中，我们提到，在Android系统中，每一个应用程序都是由一些Activity和Service组成的，一般Service运行在独立的进程中，而Activity有可能运行在同一个进程中，也有可能运行在不同的进程中。在前面Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中，我们已经介绍了使用Activity.startService接口来在新进程中启动Service的过程，然后又在前面Android应用程序内部启动Activity过程（startActivity）的源代码分析一文中介绍了使用Activity.startActivity接口来在原来的进程中启动Activity的过程，现在，我们就来看一下同一个Android应用程序如何在新的进程中启动新的Activity。 老规矩，我们通过例子来介绍Android应用程序在新的进程中启动新的Activity的方法以及分析其过程。首先在Android源代码工程中创建一个Android应用程序工程，名字就称为Process吧。关于如何获得Android源代码工程，请参考在Ubuntu上下载、编译和安装Android最新源代码一文；关于如何在Android源代码工程中创建应用程序工程，请参考在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文。这个应用程序工程定义了一个名为shy.luo.process的package，这个例子的源代码主要就是实现在这里了。下面，将会逐一介绍这个package里面的文件。 应用程序的默认Activity定义在**src/shy/luo/process/MainActivity.java**文件中： ~~~ package shy.luo.process; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class MainActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.process.MainActivity"; private Button startButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); startButton = (Button)findViewById(R.id.button_start); startButton.setOnClickListener(this); Log.i(LOG_TAG, "Main Activity Created."); } @Override public void onClick(View v) { if(v.equals(startButton)) { Intent intent = new Intent("shy.luo.process.subactivity"); startActivity(intent); } } } ~~~ 和前面文章的例子一样，它的实现很简单，当点击它上面的一个按钮的时候，就会启动另外一个名字为“shy.luo.process.subactivity”的Actvity。 名字为“shy.luo.process.subactivity”的Actvity实现在src/shy/luo/process/SubActivity.java文件中： ~~~ package shy.luo.process; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class SubActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.process.SubActivity"; private Button finishButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.sub); finishButton = (Button)findViewById(R.id.button_finish); finishButton.setOnClickListener(this); Log.i(LOG_TAG, "Sub Activity Created."); } @Override public void onClick(View v) { if(v.equals(finishButton)) { finish(); } } } ~~~ 它的实现也很简单，当点击上面的一个铵钮的时候，就结束自己，回到前面一个Activity中去。 再来重点看一下应用程序的配置文件AndroidManifest.xml： ~~~ android:process=":shy.luo.process.main" ~~~ 为了使MainActivity和SubActivity在不同的进程中启动，我们分别配置了这两个Activity的android:process属性。在官方文档http://developer.android.com/guide/topics/manifest/activity-element.html 中，是这样介绍Activity的android:process属性的： > The name of the process in which the activity should run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The ` `element's process attribute can set a different default for all components. But each component can override the default, allowing you to spread your application across multiple processes. > If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the activity runs in that process. If the process name begins with a lowercase character, the activity will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage. 大意为，一般情况下，同一个应用程序的Activity组件都是运行在同一个进程中，但是，如果Activity配置了android:process这个属性，那么，它就会运行在自己的进程中。如果android:process属性的值以":"开头，则表示这个进程是私有的；如果android:process属性的值以小写字母开头，则表示这是一个全局进程，允许其它应用程序组件也在这个进程中运行。 因此，这里我们以":"开头，表示创建的是私有的进程。事实上，这里我们不要前面的":"也是可以的，但是必须保证这个属性性字符串内至少有一个"."字符，具体可以看一下解析AndroidManiefst.xml文件的源代码，在frameworks/base/core/java/android/content/pm/PackageParser.java文件中： ~~~ public class PackageParser { ...... private boolean parseApplication(Package owner, Resources res, XmlPullParser parser, AttributeSet attrs, int flags, String[] outError) throws XmlPullParserException, IOException { final ApplicationInfo ai = owner.applicationInfo; final String pkgName = owner.applicationInfo.packageName; TypedArray sa = res.obtainAttributes(attrs, com.android.internal.R.styleable.AndroidManifestApplication); ...... if (outError[0] == null) { CharSequence pname; if (owner.applicationInfo.targetSdkVersion >= Build.VERSION_CODES.FROYO) { pname = sa.getNonConfigurationString( com.android.internal.R.styleable.AndroidManifestApplication_process, 0); } else { // Some older apps have been seen to use a resource reference // here that on older builds was ignored (with a warning). We // need to continue to do this for them so they don't break. pname = sa.getNonResourceString( com.android.internal.R.styleable.AndroidManifestApplication_process); } ai.processName = buildProcessName(ai.packageName, null, pname, flags, mSeparateProcesses, outError); ...... } ...... } private static String buildProcessName(String pkg, String defProc, CharSequence procSeq, int flags, String[] separateProcesses, String[] outError) { if ((flags&PARSE_IGNORE_PROCESSES) != 0 && !"system".equals(procSeq)) { return defProc != null ? defProc : pkg; } if (separateProcesses != null) { for (int i=separateProcesses.length-1; i>=0; i--) { String sp = separateProcesses[i]; if (sp.equals(pkg) || sp.equals(defProc) || sp.equals(procSeq)) { return pkg; } } } if (procSeq == null || procSeq.length() <= 0) { return defProc; } return buildCompoundName(pkg, procSeq, "process", outError); } private static String buildCompoundName(String pkg, CharSequence procSeq, String type, String[] outError) { String proc = procSeq.toString(); char c = proc.charAt(0); if (pkg != null && c == ':') { if (proc.length() < 2) { outError[0] = "Bad " + type + " name " + proc + " in package " + pkg + ": must be at least two characters"; return null; } String subName = proc.substring(1); String nameError = validateName(subName, false); if (nameError != null) { outError[0] = "Invalid " + type + " name " + proc + " in package " + pkg + ": " + nameError; return null; } return (pkg + proc).intern(); } String nameError = validateName(proc, true); if (nameError != null && !"system".equals(proc)) { outError[0] = "Invalid " + type + " name " + proc + " in package " + pkg + ": " + nameError; return null; } return proc.intern(); } private static String validateName(String name, boolean requiresSeparator) { final int N = name.length(); boolean hasSep = false; boolean front = true; for (int i=0; i= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z')) { front = false; continue; } if (!front) { if ((c >= '0' && c <= '9') || c == '_') { continue; } } if (c == '.') { hasSep = true; front = true; continue; } return "bad character '" + c + "'"; } return hasSep || !requiresSeparator ? null : "must have at least one '.' separator"; } ...... } ~~~ 从调用parseApplication函数解析application标签开始，通过调用buildProcessName函数对android:process属性进解析，接着又会调用buildCompoundName进一步解析，这里传进来的参数pkg就为"shy.luo.process"，参数procSeq为MainActivity的属性android:process的值":shy.luo.process.main"，进一步将这个字符串保存在本地变量proc中。如果proc的第一个字符是":"，则只需要调用validateName函数来验证proc字符串里面的字符都是合法组成就可以了，即以大小写字母或者"."开头，后面可以跟数字或者"_"字符；如果proc的第一个字符不是":"，除了保证proc字符里面的字符都是合法组成外，还要求至少有一个"."字符。 MainActivity和SubActivity的android:process属性配置就介绍到这里了，其它更多的信息读者可以参考官方文档http://developer.android.com/guide/topics/manifest/activity-element.html 或者源代码文件frameworks/base/core/java/android/content/pm/PackageParser.java。 再来看界面配置文件，它们定义在res/layout目录中，main.xml文件对应MainActivity的界面： ~~~ ~~~ 而sub.xml对应SubActivity的界面： ~~~ ~~~ 字符串文件位于res/values/strings.xml文件中： ~~~ Process Sub Activity Start activity in new process Finish activity ~~~ 最后，我们还要在工程目录下放置一个编译脚本文件Android.mk： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := Process include $(BUILD_PACKAGE) ~~~ 接下来就要编译了。有关如何单独编译Android源代码工程的模块，以及如何打包system.img，请参考如何单独编译Android源代码中的模块一文。 执行以下命令进行编译和打包： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Process USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们前面创建的Process应用程序了。 再接下来，就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器，请参考在Ubuntu上下载、编译和安装Android最新源代码一文。 执行以下命令启动模拟器： ~~~ USER-NAME@MACHINE-NAME:~/Android$ emulator ~~~ 模拟器启动起，就可以App Launcher中找到Process应用程序图标，接着把它启动起来：  点击中间的按钮，就会在新的进程中启动SubActivity：  现在，我们如何来确认SubActivity是不是在新的进程中启动呢？Android源代码工程为我们准备了adb工具，可以查看模拟器上系统运行的状况，执行下面的命令查看： ~~~ USER-NAME@MACHINE-NAME:~/Android$ adb shell dumpsys activity ~~~ 这个命令输出的内容比较多，这里我们只关心系统中的任务和进程部分： ~~~ ...... Running activities (most recent first): TaskRecord{40770440 #3 A shy.luo.process} Run #2: HistoryRecord{406d4b20 shy.luo.process/.SubActivity} Run #1: HistoryRecord{40662bd8 shy.luo.process/.MainActivity} TaskRecord{40679eb8 #2 A com.android.launcher} Run #0: HistoryRecord{40677570 com.android.launcher/com.android.launcher2.Launcher} ...... PID mappings: ...... PID #416: ProcessRecord{4064b720 416:shy.luo.process:shy.luo.process.main/10037} PID #425: ProcessRecord{406ddc30 425:shy.luo.process:shy.luo.process.sub/10037} ...... ~~~ 这里我们看到，虽然MainActivity和SubActivity都是在同一个应用程序并且运行在同一个任务中，然而，它们却是运行在两个不同的进程中，这就可以看到Android系统中任务这个概念的强大之处了，它使得我们在开发应用程序的时候，可以把相对独立的模块放在独立的进程中运行，以降低模块之间的耦合性，同时，我们又不必去考虑一个应用程序在两个进程中运行的细节的问题，Android系统中的任务会为我们打点好一切。 在启动Activity的时候，系统是如何做到在新的进程中来启动这个Activity的呢？在前面两篇文章Android应用程序启动过程源代码分析和Android应用程序内部启动Activity过程（startActivity）的源代码分析中，分别在Step 22和Step 21中分析了Activity在启动过程中与进程相关的函数ActivityStack.startSpecificActivityLocked函数中，它定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) { // Is this activity's application already running? ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid); ...... if (app != null && app.thread != null) { try { realStartActivityLocked(r, app, andResume, checkConfig); return; } catch (RemoteException e) { ...... } } mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0, "activity", r.intent.getComponent(), false); } ...... } ~~~ 从这个函数可以看出，决定一个Activity是在新的进程中启动还是在原有的进程中启动的因素有两个，一个是看这个Activity的process属性的值，另一个是这个Activity所在的应用程序的uid。应用程序的UID是由系统分配的，而Activity的process属性值，如前所述，是可以在AndroidManifest.xml文件中进行配置的，如果没有配置，它默认就为application标签的process属性值，如果application标签的process属性值也没有配置，那么，它们就默认为应用程序的package名。这里就是根据processName和uid在系统查找是否已有相应的进程存在，如果已经有了，就会调用realStartActivityLocked来直接启动Activity，否则的话，就要通过调用ActivityManagerService.startProcessLocked函数来创建一个新的进程，然后在新进程中启动这个Activity了。对于前者，可以参考Android应用程序内部启动Activity过程（startActivity）的源代码分析一文，而后者，可以参考Android应用程序启动过程源代码分析一文。 至此，Android应用程序在新的进程中启动新的Activity的方法和过程分析就结束了。在实际开发中，一个应用程序一般很少会在一个新的进程中启动另外一个Activity，如果真的需要这样做，还要考虑如何与应用程序中其它进程的Activity进行通信，这时候不妨考虑使用Binder进程间通信机制。写这篇文章的目的，更多是让我们去了解Android应用程序的架构，这种架构可以使得应用程序组件以松耦合的方式组合在一起，便于后续的扩展和维护，这是非常值得我们学习的。

原文出处——>[解开Android应用程序组件Activity的"singleTask"之谜](http://blog.csdn.net/luoshengyang/article/details/6714543) 在Android应用程序中，可以配置Activity以四种方式来启动，其中最令人迷惑的就是"singleTask"这种方式了，官方文档称以这种方式启动的Activity总是属于一个任务的根Activity。果真如此吗？本文将为你解开Activity的"singleTask"之谜。 在解开这个谜之前，我们先来简单了解一下在Android应用程序中，任务（Task）是个什么样的概念。我们知道，Activity是Android应用程序的基础组件之一，在应用程序运行时，每一个Activity代表一个用户操作。用户为了完成某个功能而执行的一系列操作就形成了一个Activity序列，这个序列在Android应用程序中就称之为任务，它是从用户体验的角度出发，把一组相关的Activity组织在一起而抽象出来的概念。 对初学者来说，在开发Android应用程序时，对任务的概念可能不是那么的直观，一般我们只关注如何实现应用程序中的每一个Activity。事实上，Android系统中的任务更多的是体现是应用程序运行的时候，因此，它相对于Activity来说是动态存在的，这就是为什么我们在开发时对任务这个概念不是那么直观的原因。不过，我们在开发Android应用程序时，还是可以配置Activity的任务属性的，即告诉系统，它是要在新的任务中启动呢，还是在已有的任务中启动，亦或是其它的Activity能不能与它共享同一个任务，具体配置请参考官方文档：http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html 它是这样介绍以"singleTask"方式启动的Activity的： The system creates a new task and instantiates the activity at the root of the new task. However, if an instance of the activity already exists in a separate task, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Only one instance of the activity can exist at a time. 它明确说明，以"singleTask"方式启动的Activity，全局只有唯一个实例存在，因此，当我们第一次启动这个Activity时，系统便会创建一个新的任务，并且初始化一个这样的Activity的实例，放在新任务的底部，如果下次再启动这个Activity时，系统发现已经存在这样的Activity实例，就会调用这个Activity实例的onNewIntent成员函数，从而把它激活起来。从这句话就可以推断出，以"singleTask"方式启动的Activity总是属于一个任务的根Activity。 但是文档接着举例子说明，当用户按下键盘上的Back键时，如果此时在前台中运行的任务堆栈顶端是一个"singleTask"的Activity，系统会回到当前任务的下一个Activity中去，而不是回到前一个Activity中去，如下图所示：  真是坑爹啊！有木有！前面刚说"singleTask"会在新的任务中运行，并且位于任务堆栈的底部，这里在Task B中，一个赤裸裸的带着"singleTask"标签的箭头无情地指向Task B堆栈顶端的Activity Y，刚转身就翻脸不认人了呢！ 事实胜于雄辩，我们来做一个实验吧，看看到底在启动这个"singleTask"的Activity的时候，它是位于新任务堆栈的底部呢，还是在已有任务的顶部。 首先在Android源代码工程中创建一个Android应用程序工程，名字就称为Task吧。关于如何获得Android源代码工程，请参考在Ubuntu上下载、编译和安装Android最新源代码一文；关于如何在Android源代码工程中创建应用程序工程，请参考在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文。这个应用程序工程定义了一个名为shy.luo.task的package，这个例子的源代码主要就是实现在这里了。下面，将会逐一介绍这个package里面的文件。 应用程序的默认Activity定义在src/shy/luo/task/MainActivity.java文件中： ~~~ package shy.luo.task; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class MainActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.task.MainActivity"; private Button startButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); startButton = (Button)findViewById(R.id.button_start); startButton.setOnClickListener(this); Log.i(LOG_TAG, "Main Activity Created."); } @Override public void onClick(View v) { if(v.equals(startButton)) { Intent intent = new Intent("shy.luo.task.subactivity"); startActivity(intent); } } } ~~~ 它的实现很简单，当点击它上面的一个按钮的时候，就会启动另外一个名字为“shy.luo.task.subactivity”的Actvity。 名字为“shy.luo.task.subactivity”的Actvity实现在src/shy/luo/task/SubActivity.java文件中： ~~~ package shy.luo.task; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class SubActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.task.SubActivity"; private Button finishButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.sub); finishButton = (Button)findViewById(R.id.button_finish); finishButton.setOnClickListener(this); Log.i(LOG_TAG, "Sub Activity Created."); } @Override public void onClick(View v) { if(v.equals(finishButton)) { finish(); } } } ~~~ 它的实现也很简单，当点击上面的一个铵钮的时候，就结束自己，回到前面一个Activity中去。 再来看一下应用程序的配置文件AndroidManifest.xml： ~~~ ~~~ 注意，这里的SubActivity的launchMode属性配置为"singleTask"。 再来看界面配置文件，它们定义在res/layout目录中，main.xml文件对应MainActivity的界面： ~~~ ~~~ 而sub.xml对应SubActivity的界面： ~~~ ~~~ 字符串文件位于res/values/strings.xml文件中： ~~~ Task Sub Activity Start singleTask activity Finish activity ~~~ 最后，我们还要在工程目录下放置一个编译脚本文件Android.mk： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := Task include $(BUILD_PACKAGE) ~~~ 这样，原材料就准备好了，接下来就要编译了。有关如何单独编译Android源代码工程的模块，以及如何打包system.img，请参考如何单独编译Android源代码中的模块一文。 执行以下命令进行编译和打包： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Task USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们前面创建的Task应用程序了。 再接下来，就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器，请参考在Ubuntu上下载、编译和安装Android最新源代码一文。 执行以下命令启动模拟器： ~~~ USER-NAME@MACHINE-NAME:~/Android$ emulator ~~~ 模拟器启动起，就可以App Launcher中找到Task应用程序图标，接着把它启动起来：  点击中间的按钮，就会以"singleTask"的方式来启动SubActivity：  现在，我们如何来确认SubActivity是不是在新的任务中启动并且位于这个新任务的堆栈底部呢？Android源代码工程为我们准备了adb工具，可以查看模拟器上系统运行的状况，执行下面的命令查看; ~~~ USER-NAME@MACHINE-NAME:~/Android$ adb shell dumpsys activity ~~~ 这个命令输出的内容比较多，这里我们只关心TaskRecord部分： ~~~ Running activities (most recent first): TaskRecord{4070d8f8 #3 A shy.luo.task} Run #2: HistoryRecord{406a13f8 shy.luo.task/.SubActivity} Run #1: HistoryRecord{406a0e00 shy.luo.task/.MainActivity} TaskRecord{4067a510 #2 A com.android.launcher} Run #0: HistoryRecord{40677518 com.android.launcher/com.android.launcher2.Launcher} ~~~ 果然，SubActivity和MainActivity都是运行在TaskRecord#3中，并且SubActivity在MainActivity的上面。这是怎么回事呢？碰到这种情况，Linus Torvalds告诫我们：Read the fucking source code；去年张麻子又说：枪在手，跟我走；我们没有枪，但是有source code，因此，我要说：跟着代码走。 前面我们在两篇文章Android应用程序启动过程源代码分析和Android应用程序内部启动Activity过程（startActivity）的源代码分析时，分别在Step 9和Step 8中分析了Activity在启动过程中与任务相关的函数ActivityStack.startActivityUncheckedLocked函数中，它定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final int startActivityUncheckedLocked(ActivityRecord r, ActivityRecord sourceRecord, Uri[] grantedUriPermissions, int grantedMode, boolean onlyIfNeeded, boolean doResume) { final Intent intent = r.intent; final int callingUid = r.launchedFromUid; int launchFlags = intent.getFlags(); ...... ActivityRecord notTop = (launchFlags&Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP) != 0 ? r : null; ...... if (sourceRecord == null) { ...... } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) { // The activity being started is a single instance... it always // gets launched into its own task. launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK; } ...... boolean addingToTask = false; if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 && (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0) || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { // If bring to front is requested, and no result is requested, and // we can find a task that was started with this same // component, then instead of launching bring that one to the front. if (r.resultTo == null) { // See if there is a task to bring to the front. If this is // a SINGLE_INSTANCE activity, there can be one and only one // instance of it in the history, and it is always in its own // unique task, so we do a special search. ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE ? findTaskLocked(intent, r.info) : findActivityLocked(intent, r.info); if (taskTop != null) { ...... if ((launchFlags&Intent.FLAG_ACTIVITY_CLEAR_TOP) != 0 || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { // In this situation we want to remove all activities // from the task up to the one being started. In most // cases this means we are resetting the task to its // initial state. ActivityRecord top = performClearTaskLocked( taskTop.task.taskId, r, launchFlags, true); if (top != null) { ...... } else { // A special case: we need to // start the activity because it is not currently // running, and the caller has asked to clear the // current task to have this activity at the top. addingToTask = true; // Now pretend like this activity is being started // by the top of its task, so it is put in the // right place. sourceRecord = taskTop; } } else if (r.realActivity.equals(taskTop.task.realActivity)) { ...... } else if ((launchFlags&Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED) == 0) { ...... } else if (!taskTop.task.rootWasReset) { ...... } ...... } } } ...... if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { if (top.app != null && top.app.thread != null) { ...... } } } } else { ...... } boolean newTask = false; // Should this be considered a new task? if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { // todo: should do better management of integers. mService.mCurTask++; if (mService.mCurTask <= 0) { mService.mCurTask = 1; } r.task = new TaskRecord(mService.mCurTask, r.info, intent, (r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0); if (DEBUG_TASKS) Slog.v(TAG, "Starting new activity " + r + " in new task " + r.task); newTask = true; if (mMainStack) { mService.addRecentTaskLocked(r.task); } } else if (sourceRecord != null) { if (!addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_CLEAR_TOP) != 0) { ...... } else if (!addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_REORDER_TO_FRONT) != 0) { ...... } // An existing activity is starting this new activity, so we want // to keep the new one in the same task as the one that is starting // it. r.task = sourceRecord.task; ...... } else { ...... } ...... startActivityLocked(r, newTask, doResume); return START_SUCCESS; } ...... } ~~~ 首先是获得用来启动Activity的Intent的Flags，并且保存在launchFlags变量中，这里，launcFlags的Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP位没有置位，因此，notTop为null。 接下来的这个if语句： ~~~ if (sourceRecord == null) { ...... } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) { // The activity being started is a single instance... it always // gets launched into its own task. launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK; } ~~~ 这里变量r的类型为ActivityRecord，它表示即将在启动的Activity，在这个例子中，即为SubActivity，因此，这里的r.launchMode等于ActivityInfo.LAUNCH_SINGLE_TASK，于是，无条件将launchFlags的Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP位置为1，表示这个SubActivity要在新的任务中启动，但是别急，还要看看其它条件是否满足，如果条件都满足，才可以在新的任务中启动这个SubActivity。 接下将addingToTask变量初始化为false，这个变量也将决定是否要将SubActivity在新的任务中启动，从名字我们就可以看出，默认不增加到原有的任务中启动，即要在新的任务中启动。这里的r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK条成立，条件r.resultTo == null也成立，它表这个Activity不需要将结果返回给启动它的Activity。于是会进入接下来的if语句中，执行： ~~~ ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE ? findTaskLocked(intent, r.info) : findActivityLocked(intent, r.info) ~~~ 这里的条件r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE成立，于是执行findTaskLocked函数，这个函数也是定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... /** * Returns the top activity in any existing task matching the given * Intent. Returns null if no such task is found. */ private ActivityRecord findTaskLocked(Intent intent, ActivityInfo info) { ComponentName cls = intent.getComponent(); if (info.targetActivity != null) { cls = new ComponentName(info.packageName, info.targetActivity); } TaskRecord cp = null; final int N = mHistory.size(); for (int i=(N-1); i>=0; i--) { ActivityRecord r = (ActivityRecord)mHistory.get(i); if (!r.finishing && r.task != cp && r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE) { cp = r.task; //Slog.i(TAG, "Comparing existing cls=" + r.task.intent.getComponent().flattenToShortString() // + "/aff=" + r.task.affinity + " to new cls=" // + intent.getComponent().flattenToShortString() + "/aff=" + taskAffinity); if (r.task.affinity != null) { if (r.task.affinity.equals(info.taskAffinity)) { //Slog.i(TAG, "Found matching affinity!"); return r; } } else if (r.task.intent != null && r.task.intent.getComponent().equals(cls)) { //Slog.i(TAG, "Found matching class!"); //dump(); //Slog.i(TAG, "For Intent " + intent + " bringing to top: " + r.intent); return r; } else if (r.task.affinityIntent != null && r.task.affinityIntent.getComponent().equals(cls)) { //Slog.i(TAG, "Found matching class!"); //dump(); //Slog.i(TAG, "For Intent " + intent + " bringing to top: " + r.intent); return r; } } } return null; } ...... } ~~~ 这个函数无非就是根据即将要启动的SubActivity的taskAffinity属性值在系统中查找这样的一个Task：Task的affinity属性值与即将要启动的Activity的taskAffinity属性值一致。如果存在，就返回这个Task堆栈顶端的Activity回去。在上面的AndroidManifest.xml文件中，没有配置MainActivity和SubActivity的taskAffinity属性，于是它们的taskAffinity属性值就默认为父标签application的taskAffinity属性值，这里，标签application的taskAffinity也没有配置，于是它们就默认为包名，即"shy.luo.task"。由于在启动SubActivity之前，MainActivity已经启动，MainActivity启动的时候，会在一个新的任务里面启动，而这个新的任务的affinity属性就等于它的第一个Activity的taskAffinity属性值。于是，这个函数会动回表示MainActivity的ActivityRecord回去. 回到前面的startActivityUncheckedLocked函数中，这里的taskTop就表示MainActivity，它不为null，于是继续往前执行。由于条件r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK成立，于是执行下面语句： ~~~ ActivityRecord top = performClearTaskLocked( kTop.task.taskId, r, launchFlags, true); ~~~ 函数performClearTaskLocked也是定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... /** * Perform clear operation as requested by * {@link Intent#FLAG_ACTIVITY_CLEAR_TOP}: search from the top of the * stack to the given task, then look for * an instance of that activity in the stack and, if found, finish all * activities on top of it and return the instance. * * @param newR Description of the new activity being started. * @return Returns the old activity that should be continue to be used, * or null if none was found. */ private final ActivityRecord performClearTaskLocked(int taskId, ActivityRecord newR, int launchFlags, boolean doClear) { int i = mHistory.size(); // First find the requested task. while (i > 0) { i--; ActivityRecord r = (ActivityRecord)mHistory.get(i); if (r.task.taskId == taskId) { i++; break; } } // Now clear it. while (i > 0) { i--; ActivityRecord r = (ActivityRecord)mHistory.get(i); if (r.finishing) { continue; } if (r.task.taskId != taskId) { return null; } if (r.realActivity.equals(newR.realActivity)) { // Here it is! Now finish everything in front... ActivityRecord ret = r; if (doClear) { while (i < (mHistory.size()-1)) { i++; r = (ActivityRecord)mHistory.get(i); if (r.finishing) { continue; } if (finishActivityLocked(r, i, Activity.RESULT_CANCELED, null, "clear")) { i--; } } } // Finally, if this is a normal launch mode (that is, not // expecting onNewIntent()), then we will finish the current // instance of the activity so a new fresh one can be started. if (ret.launchMode == ActivityInfo.LAUNCH_MULTIPLE && (launchFlags&Intent.FLAG_ACTIVITY_SINGLE_TOP) == 0) { if (!ret.finishing) { int index = indexOfTokenLocked(ret); if (index >= 0) { finishActivityLocked(ret, index, Activity.RESULT_CANCELED, null, "clear"); } return null; } } return ret; } } return null; } ...... } ~~~ 这个函数中作用无非就是找到ID等于参数taskId的任务，然后在这个任务中查找是否已经存在即将要启动的Activity的实例，如果存在，就会把这个Actvity实例上面直到任务堆栈顶端的Activity通过调用finishActivityLocked函数将它们结束掉。在这个例子中，就是要在属性值affinity等于"shy.luo.task"的任务中看看是否存在SubActivity类型的实例，如果有，就把它上面的Activity都结束掉。这里，属性值affinity等于"shy.luo.task"的任务只有一个MainActivity，而且它不是SubActivity的实例，所以这个函数就返回null了。 回到前面的startActivityUncheckedLocked函数中，这里的变量top就为null了，于是执行下面的else语句： ~~~ if (top != null) { ...... } else { // A special case: we need to // start the activity because it is not currently // running, and the caller has asked to clear the // current task to have this activity at the top. addingToTask = true; // Now pretend like this activity is being started // by the top of its task, so it is put in the // right place. sourceRecord = taskTop; } ~~~ 于是，变量addingToTask值就为true了，同时将变量sourceRecord的值设置为taskTop，即前面调用findTaskLocked函数的返回值，这里，它就是表示MainActivity了。 继续往下看，下面这个if语句： ~~~ if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { if (top.app != null && top.app.thread != null) { ...... } } } } else { ...... } ~~~ 它是例行性地检查当前任务顶端的Activity，是否是即将启动的Activity的实例，如果是否的话，在某些情况下，它什么也不做，就结束这个函数调用了。这里，当前任务顶端的Activity为MainActivity，它不是SubActivity实例，于是继续往下执行： ~~~ boolean newTask = false; // Should this be considered a new task? if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { ...... } else if (sourceRecord != null) { if (!addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_CLEAR_TOP) != 0) { ...... } else if (!addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_REORDER_TO_FRONT) != 0) { ...... } // An existing activity is starting this new activity, so we want // to keep the new one in the same task as the one that is starting // it. r.task = sourceRecord.task; ...... } else { ...... } ~~~ 这里首先将newTask变量初始化为false，表示不要在新的任务中启动这个SubActivity。由于前面的已经把addingToTask设置为true，因此，这里会执行中间的else if语句，即这里会把r.task设置为sourceRecord.task，即把SubActivity放在MainActivity所在的任务中启动。 最后，就是调用startActivityLocked函数继续进行启动Activity的操作了。后面的操作这里就不跟下去了，有兴趣的读者可以参考两篇文章Android应用程序启动过程源代码分析和Android应用程序内部启动Activity过程（startActivity）的源代码分析。 到这里，思路就理清了，虽然SubActivity的launchMode被设置为"singleTask"模式，但是它并不像官方文档描述的一样：The system creates a new task and instantiates the activity at the root of the new task，而是在跟它有相同taskAffinity的任务中启动，并且位于这个任务的堆栈顶端，于是，前面那个图中，就会出现一个带着"singleTask"标签的箭头指向一个任务堆栈顶端的Activity Y了。 那么，我们有没有办法让一个"singleTask"的Activity在新的任务中启动呢？答案是肯定的。从上面的代码分析中，只要我们能够进入函数startActivityUncheckedLocked的这个if语句中： ~~~ if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { // todo: should do better management of integers. mService.mCurTask++; if (mService.mCurTask <= 0) { mService.mCurTask = 1; } r.task = new TaskRecord(mService.mCurTask, r.info, intent, (r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0); if (DEBUG_TASKS) Slog.v(TAG, "Starting new activity " + r + " in new task " + r.task); newTask = true; if (mMainStack) { mService.addRecentTaskLocked(r.task); } } ~~~ 那么，这个即将要启动的Activity就会在新的任务中启动了。进入这个if语句需要满足三个条件，r.resultTo为null，launchFlags的Intent.FLAG_ACTIVITY_NEW_TASK位为1，并且addingToTask值为false。从上面的分析中可以看到，当即将要启动的Activity的launchMode为"singleTask"，并且调用startActivity时不要求返回要启动的Activity的执行结果时，前面两个条件可以满足，要满足第三个条件，只要当前系统不存在affinity属性值等于即将要启动的Activity的taskAffinity属性值的任务就可以了。 我们可以稍微修改一下上面的AndroidManifest.xml配置文件来做一下这个实验： ~~~ ~~~ 注意，这里我们设置MainActivity的taskAffinity属性值为"shy.luo.task.main.activity"，设置SubActivity的taskAffinity属性值为"shy.luo.task.sub.activity"。重新编译一下程序，在模拟器上把这个应用程序再次跑起来，用“adb shell dumpsys activity”命令再来查看一下系统运行的的任务，就会看到： ~~~ Running activities (most recent first): TaskRecord{4069c020 #4 A shy.luo.task.sub.activity} Run #2: HistoryRecord{40725040 shy.luo.task/.SubActivity} TaskRecord{40695220 #3 A shy.luo.task.main.activity} Run #1: HistoryRecord{406b26b8 shy.luo.task/.MainActivity} TaskRecord{40599c90 #2 A com.android.launcher} Run #0: HistoryRecord{40646628 com.android.launcher/com.android.launcher2.Launcher} ~~~ 这里就可以看到，SubActivity和MainActivity就分别运行在不同的任务中了。 至此，我们总结一下，设置了"singleTask"启动模式的Activity的特点： 1. 设置了"singleTask"启动模式的Activity，它在启动的时候，会先在系统中查找属性值affinity等于它的属性值taskAffinity的任务存在；如果存在这样的任务，它就会在这个任务中启动，否则就会在新任务中启动。因此，如果我们想要设置了"singleTask"启动模式的Activity在新的任务中启动，就要为它设置一个独立的taskAffinity属性值。 2. 如果设置了"singleTask"启动模式的Activity不是在新的任务中启动时，它会在已有的任务中查看是否已经存在相应的Activity实例，如果存在，就会把位于这个Activity实例上面的Activity全部结束掉，即最终这个Activity实例会位于任务的堆栈顶端中。 看来，要解开Activity的"singleTask"之谜，还是要自力更生啊，不过，如果我们仔细阅读官方文档，在http://developer.android.com/guide/topics/manifest/activity-element.html 中，有这样的描述： As shown in the table above, standard is the default mode and is appropriate for most types of activities. SingleTop is also a common and useful launch mode for many types of activities. The other modes — singleTask and singleInstance —are not appropriate for most applications, since they result in an interaction model that is likely to be unfamiliar to users and is very different from most other applications. Regardless of the launch mode that you choose, make sure to test the usability of the activity during launch and when navigating back to it from other activities and tasks using the BACK key. 这样看，官方文档也没有坑我们呢，它告诫我们：make sure to test the usability of the activity during launch。

原文出处——>[ndroid应用程序内部启动Activity过程（startActivity）的源代码分析](http://blog.csdn.net/luoshengyang/article/details/6703247) 上文介绍了Android应用程序的启动过程，即应用程序默认Activity的启动过程，一般来说，这种默认Activity是在新的进程和任务中启动的；本文将继续分析在应用程序内部启动非默认Activity的过程的源代码，这种非默认Activity一般是在原来的进程和任务中启动的。 这里，我们像上一篇文章Android应用程序启动过程源代码分析一样，采用再上一篇文章Android应用程序的Activity启动过程简要介绍和学习计划所举的例子来分析在应用程序内部启动非默认Activity的过程。 在应用程序内部启动非默认Activity的过程与在应用程序启动器Launcher中启动另外一个应用程序的默认Activity的过程大体上一致的，因此，这里不会像上文Android应用程序启动过程源代码分析一样详细分析每一个步骤，我们着重关注有差别的地方。 回忆一下Android应用程序的Activity启动过程简要介绍和学习计划一文所用的应用程序Activity，它包含两个Activity，分别是MainActivity和SubActivity，前者是应用程序的默认Activity，后者是非默认Activity。MainActivity启动起来，通过点击它界面上的按钮，便可以在应用程序内部启动SubActivity。 我们先来看一下应用程序的配置文件AndroidManifest.xml，看看这两个Activity是如何配置的： ~~~ ~~~ 这里可以很清楚地看到，MainActivity被配置成了应用程序的默认Activity，而SubActivity可以通过名称“shy.luo.activity.subactivity”隐式地启动，我们来看一下src/shy/luo/activity/MainActivity.java文件的内容，可以清楚地看到SubActivity是如何隐式地启动的： ~~~ public class MainActivity extends Activity implements OnClickListener { ...... @Override public void onClick(View v) { if(v.equals(startButton)) { Intent intent = new Intent("shy.luo.activity.subactivity"); startActivity(intent); } } } ~~~ 这里，首先创建一个名称为“shy.luo.activity.subactivity”的Intent，然后以这个Intent为参数，通过调用startActivity函数来实现隐式地启动SubActivity。 有了这些背景知识后，我们就来看一下SubActivity启动过程的序列图：  与前面介绍的MainActivity启动过程相比，这里少了中间创建新的进程的步骤；接下来，我们就详细分析一下SubActivity与MainActivity启动过程中有差别的地方，相同的地方请参考Android应用程序启动过程源代码分析一文。 * Step 1. Activity.startActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 2大体一致，通过指定名称“shy.luo.activity.subactivity”来告诉应用程序框架层，它要隐式地启动SubActivity。所不同的是传入的参数intent没有Intent.FLAG_ACTIVITY_NEW_TASK标志，表示这个SubActivity和启动它的MainActivity运行在同一个Task中。 * Step 2. Activity.startActivityForResult 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 3一致。 * Step 3. Instrumentation.execStartActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 4一致。 * Step 4. ActivityManagerProxy.startActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 5一致。 * Step 5. ActivityManagerService.startActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 6一致。 * Step 6. ActivityStack.startActivityMayWait 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 7一致。 * Step 7. ActivityStack.startActivityLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 8一致。 * Step 8. ActivityStack.startActivityUncheckedLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 9有所不同，主要是当前要启动的Activity与启动它的Activity是在同一个Task中运行的，我们来详细看一下。这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final int startActivityUncheckedLocked(ActivityRecord r, ActivityRecord sourceRecord, Uri[] grantedUriPermissions, int grantedMode, boolean onlyIfNeeded, boolean doResume) { final Intent intent = r.intent; final int callingUid = r.launchedFromUid; int launchFlags = intent.getFlags(); ...... if (sourceRecord == null) { ...... } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE ...... } if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { ...... } boolean addingToTask = false; if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 && (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0) || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { ...... } } } else { ...... } boolean newTask = false; // Should this be considered a new task? if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { ...... } else if (sourceRecord != null) { ...... // An existing activity is starting this new activity, so we want // to keep the new one in the same task as the one that is starting // it. r.task = sourceRecord.task; ...... } else { ...... } ...... startActivityLocked(r, newTask, doResume); return START_SUCCESS; } ...... } ~~~ 这里，参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，在配置文件AndriodManifest.xml中，SubActivity也没有配置启动模式launchMode，于是它就默认标准模式，即ActivityInfo.LAUNCH_MULTIPLE，因此，下面if语句不会执行： ~~~ if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 && (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0) || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } ~~~ 于是，变量addingToTask为false。 继续往下看： ~~~ if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { ...... } } } ~~~ 这里看一下当前要启动的Activity是否就是当前堆栈顶端的Activity，如果是的话，在某些情况下，就不用再重新启动了。函数topRunningNonDelayedActivityLocked返回当前 堆栈顶端的Activity，这里即为MainActivity，而当前要启动的Activity为SubActivity，因此，这二者不相等，于是跳过里面的if语句。 接着往下执行： ~~~ // Should this be considered a new task? if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { ...... } else if (sourceRecord != null) { ...... // An existing activity is starting this new activity, so we want // to keep the new one in the same task as the one that is starting // it. r.task = sourceRecord.task; ...... } else { ...... } ~~~ 前面说过参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，而这里的sourceRecord即为当前执行启动Activity操作的Activity，这里即为MainActivity，因此，它不为null，于是于MainActivity所属的Task设置到r.task中去，这里的r即为SubActivity。看到这里，我们就知道SubActivity要和MainActivity运行在同一个Task中了，同时，变量newTask的值为false。 最后，函数进 入startActivityLocked(r, newTask, doResume)进一步处理了。这个函数同样是定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startActivityLocked(ActivityRecord r, boolean newTask, boolean doResume) { final int NH = mHistory.size(); int addPos = -1; if (!newTask) { // If starting in an existing task, find where that is... boolean startIt = true; for (int i = NH-1; i >= 0; i--) { ActivityRecord p = (ActivityRecord)mHistory.get(i); if (p.finishing) { continue; } if (p.task == r.task) { // Here it is! Now, if this is not yet visible to the // user, then just add it without starting; it will // get started when the user navigates back to it. addPos = i+1; if (!startIt) { mHistory.add(addPos, r); r.inHistory = true; r.task.numActivities++; mService.mWindowManager.addAppToken(addPos, r, r.task.taskId, r.info.screenOrientation, r.fullscreen); if (VALIDATE_TOKENS) { mService.mWindowManager.validateAppTokens(mHistory); } return; } break; } if (p.fullscreen) { startIt = false; } } } ...... // Slot the activity into the history stack and proceed mHistory.add(addPos, r); r.inHistory = true; r.frontOfTask = newTask; r.task.numActivities++; ...... if (doResume) { resumeTopActivityLocked(null); } } ...... } ~~~ 这里传进来的参数newTask为false，doResume为true。当newTask为false，表示即将要启动的Activity是在原有的Task运行时，如果这个原有的Task当前对用户不可见时，这时候就不需要继续执行下去了，因为即使把这个Activity启动起来，用户也看不到，还不如先把它保存起来，等到下次这个Task对用户可见的时候，再启动不迟。这里，这个原有的Task，即运行MainActivity的Task当前对用户是可见的，因此，会继续往下执行。 接下去执行就会把这个SubActivity通过mHistroy.add(addPos, r)添加到堆栈顶端去，然后调用resumeTopActivityLocked进一步操作。 * ep 9. ActivityStack.resumeTopActivityLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 10一致。 但是要注意的是，执行到这个函数的时候，当前处于堆栈顶端的Activity为SubActivity，ActivityStack的成员变量mResumedActivity指向MainActivity。 * Step 10. ActivityStack.startPausingLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 11一致。 从这里开始，ActivityManagerService通知MainActivity进入Paused状态。 * Step 11. ApplicationThreadProxy.schedulePauseActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 12一致。 * Step 12. ApplicationThread.schedulePauseActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 13一致。 * Step 13. ActivityThread.queueOrSendMessage 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 14一致。 * Step 14. H.handleMessage 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 15一致。 * Step 15. ActivityThread.handlePauseActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 16一致。 * Step 16. ActivityManagerProxy.activityPaused 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 17一致。 * Step 17. ActivityManagerService.activityPaused 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 18一致。 * Step 18. ActivityStack.activityPaused 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 19一致。 * Step 19. ActivityStack.completePauseLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 20一致。 执行到这里的时候，MainActivity就进入Paused状态了，下面就开始要启动SubActivity了。 * Step 20. ActivityStack.resumeTopActivityLokced 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 21一致。 * Sep 21. ActivityStack.startSpecificActivityLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 22就有所不同了，这里，它不会调用mService.startProcessLocked来创建一个新的进程来启动新的Activity，我们来看一下这个函数的实现，这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) { // Is this activity's application already running? ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid); ...... if (app != null && app.thread != null) { try { realStartActivityLocked(r, app, andResume, checkConfig); return; } catch (RemoteException e) { ...... } } ...... } ...... } ~~~ 这里由于不是第一次启动应用程序的Activity（MainActivity是这个应用程序第一个启动的Activity），所以下面语句： ~~~ ProcessRecord app = mService.getProcessRecordLocked(r.processName, nfo.applicationInfo.uid); ~~~ 取回来的app不为null。在上一篇文章Android应用程序启动过程源代码分析中，我们介绍过，在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定application标签的process属性，于是系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid + process的组合就可以创建一个全局唯一的ProcessRecord。这个ProcessRecord是在前面启动MainActivity时创建的，因此，这里将它取回来，并保存在变量app中。注意，我们也可以在AndroidManifest.xml配置文件中指定SubActivity的process属性值，这样SubActivity就可以在另外一个进程中启动，不过很少有应用程序会这样做，我们不考虑这种情况。 这个app的thread也是在前面启动MainActivity时创建好的，于是，这里就直接调用realStartActivityLocked函数来启动新的Activity了，新的Activity的相关信息都保存在参数r中了。 * Step 22. ActivityStack.realStartActivityLocked 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 28一致。 * Step 23. ApplicationThreadProxy.scheduleLaunchActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 29一致。 * Step 24. ApplicationThread.scheduleLaunchActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 30一致。 * Step 25. ActivityThread.queueOrSendMessage 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 31一致。 * Step 26. H.handleMessage 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 32一致。 * Step 27. ActivityThread.handleLaunchActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 33一致。 * Step 28. ActivityThread.performLaunchActivity 这一步与上一篇文章Android应用程序启动过程源代码分析的Step 34一致，不过，这里要从ClassLoader里面加载的类就是shy.luo.activity.SubActivity了。 * Step 29. SubAcitiviy.onCreate 这个函数定义在packages/experimental/Activity/src/shy/luo/activity/SubActivity.java文件中，这是我们自定义的app工程文件： ~~~ public class SubActivity extends Activity implements OnClickListener { ...... @Override public void onCreate(Bundle savedInstanceState) { ...... Log.i(LOG_TAG, "Sub Activity Created."); } ...... } ~~~ 这样，SubActivity就在应用程序Activity内部启动起来了。 在应用程序内部启动新的Activity的过程要执行很多步骤，但是整体来看，主要分为以下四个阶段： * 一. Step 1 - Step 10：应用程序的MainActivity通过Binder进程间通信机制通知ActivityManagerService，它要启动一个新的Activity； * 二. Step 11 - Step 15：ActivityManagerService通过Binder进程间通信机制通知MainActivity进入Paused状态； * 三. Step 16 - Step 22：MainActivity通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就准备要在MainActivity所在的进程和任务中启动新的Activity了； * 四. Step 23 - Step 29：ActivityManagerService通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。 和上一篇文章Android应用程序启动过程源代码分析中启动应用程序的默认Activity相比，这里在应用程序内部启动新的Activity的过程少了中间创建新的进程这一步，这是因为新的Activity是在已有的进程和任务中执行的，无须创建新的进程和任务。 这里同样不少地方涉及到了Binder进程间通信机制，相关资料请参考Android进程间通信（IPC）机制Binder简要介绍和学习计划一文。 这里希望读者能够把本文和上文Android应用程序启动过程源代码分析仔细比较一下应用程序的默认Activity和非默认Activity启动过程的不同之处，以加深对Activity的理解。 最后，在本文和上文中，我们多次提到了Android应用程序中任务（Task）的概念，它既不是我们在Linux系统中所理解的进程（Process），也不是线程（Thread），它是用户为了完成某个目标而需要执行的一系列操作的过程的一种抽象。这是一个非常重要的概念，它从用户体验的角度出发，界定了应用程序的边界，极大地方便了开发者利用现成的组件（Activity）来搭建自己的应用程序，就像搭积木一样，而且，它还为应用程序屏蔽了底层的进程，即一个任务中的Activity可以都是运行在同一个进程中，也中可以运行在不同的进程中。Android应用程序中的任务的概念，具体可以参考官方文档http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html ，上面已经介绍的非常清楚了。

原文出处——>[Android应用程序的Activity启动过程简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/6685853) 在Android系统中，Activity和Service是应用程序的核心组件，它们以松藕合的方式组合在一起构成了一个完整的应用程序，这得益于应用程序框架层提供了一套完整的机制来协助应用程序启动这些Activity和Service，以及提供Binder机制帮助它们相互间进行通信。在前面的文章Android进程间通信（IPC）机制Binder简要介绍和学习计划和Android系统在新进程中启动自定义服务过程（startService）的原理分析中，我们已经系统地介绍了Binder机制和Service的启动过程了，在本文中，简要介绍Activity的启动过程以及后续学习计划。 在Android系统中，有两种操作会引发Activity的启动，一种用户点击应用程序图标时，Launcher会为我们启动应用程序的主Activity；应用程序的默认Activity启动起来后，它又可以在内部通过调用startActvity接口启动新的Activity，依此类推，每一个Activity都可以在内部启动新的Activity。通过这种连锁反应，按需启动Activity，从而完成应用程序的功能。 这里，我们通过一个具体的例子来说明如何启动Android应用程序的Activity。Activity的启动方式有两种，一种是显式的，一种是隐式的，隐式启动可以使得Activity之间的藕合性更加松散，因此，这里只关注隐式启动Activity的方法。 首先在Android源代码工程的packages/experimental目录下创建一个应用程序工程目录Activity。关于如何获得Android源代码工程，请参考在Ubuntu上下载、编译和安装Android最新源代码一文；关于如何在Android源代码工程中创建应用程序工程，请参考在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文。这里，工程名称就是Activity了，它定义了一个路径为shy.luo.activity的package，这个例子的源代码主要就是实现在这里了。下面，将会逐一介绍这个package里面的文件。 应用程序的默认Activity定义在src/shy/luo/activity/MainActivity.java文件中： ~~~ package shy.luo.activity; import shy.luo.activity.R; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class MainActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.activity.MainActivity"; private Button startButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); startButton = (Button)findViewById(R.id.button_start); startButton.setOnClickListener(this); Log.i(LOG_TAG, "Main Activity Created."); } @Override public void onClick(View v) { if(v.equals(startButton)) { Intent intent = new Intent("shy.luo.activity.subactivity"); startActivity(intent); } } } ~~~ 它的实现很简单，当点击它上面的一个按钮的时候，就会启动另外一个名字为“shy.luo.activity.subactivity”的Actvity。 名字为“shy.luo.activity.subactivity”的Actvity实现在src/shy/luo/activity/SubActivity.java文件中： ~~~ package shy.luo.activity; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class SubActivity extends Activity implements OnClickListener { private final static String LOG_TAG = "shy.luo.activity.SubActivity"; private Button finishButton = null; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.sub); finishButton = (Button)findViewById(R.id.button_finish); finishButton.setOnClickListener(this); Log.i(LOG_TAG, "Sub Activity Created."); } @Override public void onClick(View v) { if(v.equals(finishButton)) { finish(); } } } ~~~ 它的实现也很简单，当点击上面的一个铵钮的时候，就结束自己，回到前面一个Activity中去。 这里我们可以看到，Android应用程序架构中非常核心的一点：MainActivity不需要知道SubActivity的存在，即它不直接拥有SubActivity的接口，但是它可以通过一个字符串来告诉应用程序框架层，它要启动的Activity的名称是什么，其它的事情就交给应用程序框架层来做，当然，应用程序框架层会根据这个字符串来找到其对应的Activity，然后把它启动起来。这样，就使得Android应用程序中的Activity藕合性很松散，从而使得Android应用程序的模块性程度很高，并且有利于以后程序的维护和更新，对于大型的客户端软件来说，这一点是非常重要的。 当然，应用程序框架能够根据名字来找到相应的Activity，是需要应用程序本身来配合的，这就是要通过应用程序的配置文件AndroidManifest.xml来实现了： ~~~ ~~~ 从这个配置文件中，我们可以看到，MainActivity被配置成了应用程序的默认Activity，即用户在手机屏幕上点击Activity应用程序图标时，Launcher就会默认启动MainActivity这个Activity： ~~~ ~~~ 这个配置文件也将名字“shy.luo.activity.subactivity”和SubActivity关联了起来，因此，应用程序框架层能够根据名字来找到它： ~~~ ~~~ 下面再列出这个应用程序的界面配置文件和字符串文件。 界面配置文件在res/layout目录中，main.xml文件对应MainActivity的界面： ~~~ ~~~ 而sub.xml对应SubActivity的界面： ~~~ ~~~ 字符串文件位于res/values/strings.xml文件中： ~~~ Activity Sub Activity Start sub-activity Finish activity ~~~ 最后，我们还要在工程目录下放置一个编译脚本文件Android.mk： ~~~ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := Activity include $(BUILD_PACKAGE) ~~~ 这样，整个例子的源代码实现就介绍完了，接下来就要编译了。有关如何单独编译Android源代码工程的模块，以及如何打包system.img，请参考如何单独编译Android源代码中的模块一文。 执行以下命令进行编译和打包： ~~~ USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Activity USER-NAME@MACHINE-NAME:~/Android$ make snod ~~~ 这样，打包好的Android系统镜像文件system.img就包含我们前面创建的Activity应用程序了。 再接下来，就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器，请参考在Ubuntu上下载、编译和安装Android最新源代码一文。 执行以下命令启动模拟器： ~~~ USER-NAME@MACHINE-NAME:~/Android$ emulator ~~~ 模拟器启动起，就可以在屏幕上看到Activity应用程序图标了：  点击Activity这个应用程序图标后，Launcher就会把MainActivity启动起来：  点击上面的Start sub-activity铵钮，MainActivity内部就会通过startActivity接口来启动SubActivity： ~~~ Intent intent = new Intent("shy.luo.activity.subactivity"); startActivity(intent); ~~~ 如下图所示：  无论是通过点击应用程序图标来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都要借助于应用程序框架层的ActivityManagerService服务进程。在前面一篇文章Android系统在新进程中启动自定义服务过程（startService）的原理分析中，我们已经看到，Service也是由ActivityManagerService进程来启动的。在Android应用程序框架层中，ActivityManagerService是一个非常重要的接口，它不但负责启动Activity和Service，还负责管理Activity和Service。 Android应用程序框架层中的ActivityManagerService启动Activity的过程大致如下图所示：  在这个图中，ActivityManagerService和ActivityStack位于同一个进程中，而ApplicationThread和ActivityThread位于另一个进程中。其中，ActivityManagerService是负责管理Activity的生命周期的，ActivityManagerService还借助ActivityStack是来把所有的Activity按照后进先出的顺序放在一个堆栈中；对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。 下面简要介绍一下启动的过程： * Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口； * Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息； * Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了； * Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity； * Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动； * Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作； * Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。 这样，Android应用程序的Activity启动过程就简要介绍到这里了，在接下来的两篇文章中，我们将根据Activity的这两种启动情景，深入到应用程序框架层的源代码里面去，一步一步地分析它们的启动过程： 1. Android应用程序启动过程的源代码分析； 2. Android应用程序内部启动Activity过程（startActivity）的源代码分析。

[Android应用程序的Activity启动过程简要介绍和学习计划](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%9A%84Activity%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B%E7%AE%80%E8%A6%81%E4%BB%8B%E7%BB%8D%E5%92%8C%E5%AD%A6%E4%B9%A0%E8%AE%A1%E5%88%92.md) [Android应用程序内部启动Activity过程（startActivity）的源代码分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E5%86%85%E9%83%A8%E5%90%AF%E5%8A%A8Activity%E8%BF%87%E7%A8%8B%EF%BC%88startActivity%EF%BC%89%E7%9A%84%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90.md) [解开Android应用程序组件Activity的"singleTask"之谜](%E8%A7%A3%E5%BC%80Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%BB%84%E4%BB%B6Activity%E7%9A%84singleTask%E4%B9%8B%E8%B0%9C.md) [Android应用程序在新的进程中启动新的Activity的方法和过程分析](Android%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E5%9C%A8%E6%96%B0%E7%9A%84%E8%BF%9B%E7%A8%8B%E4%B8%AD%E5%90%AF%E5%8A%A8%E6%96%B0%E7%9A%84Activity%E7%9A%84%E6%96%B9%E6%B3%95%E5%92%8C%E8%BF%87%E7%A8%8B%E5%88%86%E6%9E%90.md)

[Activity](Activity.md) [Service](Service.md) [ContentProvider](ContentProvider.md) [BroadcastReceiver](BroadcastReceiver.md)

原文出处——>[Android应用程序启动过程源代码分析](http://blog.csdn.net/luoshengyang/article/details/6689748) 前文简要介绍了Android应用程序的Activity的启动过程。在Android系统中，应用程序是由Activity组成的，因此，应用程序的启动过程实际上就是应用程序中的默认Activity的启动过程，本文将详细分析应用程序框架层的源代码，了解Android应用程序的启动过程。 在上一篇文章Android应用程序的Activity启动过程简要介绍和学习计划中，我们举例子说明了启动Android应用程序中的Activity的两种情景，其中，在手机屏幕中点击应用程序图标的情景就会引发Android应用程序中的默认Activity的启动，从而把应用程序启动起来。这种启动方式的特点是会启动一个新的进程来加载相应的Activity。这里，我们继续以这个例子为例来说明Android应用程序的启动过程，即MainActivity的启动过程。 MainActivity的启动过程如下图所示： :-:  图1 根Activity的启动过程 上面的图太小了，可以看我在老罗的系统源代码书中的插图 [点击看大图](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/51d2ff0baa74f1871a56ff5355931a9c_1501x2356.jpg) :-:  图2 根Activity的完整启动过程图 下面详细分析每一步是如何实现的。 #### **Step 1. Launcher.startActivitySafely** 在Android系统中，应用程序是由Launcher启动起来的，其实，Launcher本身也是一个应用程序，其它的应用程序安装后，就会Launcher的界面上出现一个相应的图标，点击这个图标时，Launcher就会对应的应用程序启动起来。 Launcher的源代码工程在packages/apps/Launcher2目录下，负责启动其它应用程序的源代码实现在src/com/android/launcher2/Launcher.java文件中： ~~~ /** * Default launcher application. */ public final class Launcher extends Activity implements View.OnClickListener, OnLongClickListener, LauncherModel.Callbacks, AllAppsView.Watcher { ...... /** * Launches the intent referred by the clicked shortcut. * * @param v The view representing the clicked shortcut. */ public void onClick(View v) { Object tag = v.getTag(); if (tag instanceof ShortcutInfo) { // Open shortcut final Intent intent = ((ShortcutInfo) tag).intent; int[] pos = new int[2]; v.getLocationOnScreen(pos); intent.setSourceBounds(new Rect(pos[0], pos[1], pos[0] + v.getWidth(), pos[1] + v.getHeight())); startActivitySafely(intent, tag); } else if (tag instanceof FolderInfo) { ...... } else if (v == mHandleView) { ...... } } void startActivitySafely(Intent intent, Object tag) { intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); try { startActivity(intent); } catch (ActivityNotFoundException e) { ...... } catch (SecurityException e) { ...... } } ...... } ~~~ 回忆一下前面一篇文章Android应用程序的Activity启动过程简要介绍和学习计划说到的应用程序Activity，它的默认Activity是MainActivity，这里是AndroidManifest.xml文件中配置的： ~~~ ~~~ 因此，这里的intent包含的信息为：action = "android.intent.action.Main"，category="android.intent.category.LAUNCHER", cmp="shy.luo.activity/.MainActivity"，表示它要启动的Activity为shy.luo.activity.MainActivity。Intent.FLAG_ACTIVITY_NEW_TASK表示要在一个新的Task中启动这个Activity，注意，Task是Android系统中的概念，它不同于进程Process的概念。简单地说，一个Task是一系列Activity的集合，这个集合是以堆栈的形式来组织的，遵循后进先出的原则。事实上，Task是一个非常复杂的概念，有兴趣的读者可以到官网http://developer.android.com/guide/topics/manifest/activity-element.html 查看相关的资料。这里，我们只要知道，这个MainActivity要在一个新的Task中启动就可以了。 **Step 2. Activity.startActivity** 在Step 1中，我们看到，Launcher继承于Activity类，而Activity类实现了startActivity函数，因此，这里就调用了Activity.startActivity函数，它实现在frameworks/base/core/java/android/app/Activity.java文件中： ~~~ public class Activity extends ContextThemeWrapper implements LayoutInflater.Factory, Window.Callback, KeyEvent.Callback, OnCreateContextMenuListener, ComponentCallbacks { ...... @Override public void startActivity(Intent intent) { startActivityForResult(intent, -1); } ...... } ~~~ 这个函数实现很简单，它调用startActivityForResult来进一步处理，第二个参数传入-1表示不需要这个Actvity结束后的返回结果。 **Step 3. Activity.startActivityForResult** 这个函数也是实现在frameworks/base/core/java/android/app/Activity.java文件中： ~~~ public class Activity extends ContextThemeWrapper implements LayoutInflater.Factory, Window.Callback, KeyEvent.Callback, OnCreateContextMenuListener, ComponentCallbacks { ...... public void startActivityForResult(Intent intent, int requestCode) { if (mParent == null) { Instrumentation.ActivityResult ar = mInstrumentation.execStartActivity( this, mMainThread.getApplicationThread(), mToken, this, intent, requestCode); ...... } else { ...... } ...... } ~~~ 这里的mInstrumentation是Activity类的成员变量，它的类型是Intrumentation，定义在frameworks/base/core/java/android/app/Instrumentation.java文件中，它用来监控应用程序和系统的交互。 这里的mMainThread也是Activity类的成员变量，它的类型是ActivityThread，它代表的是应用程序的主线程，我们在Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中已经介绍过了。这里通过mMainThread.getApplicationThread获得它里面的ApplicationThread成员变量，它是一个Binder对象，后面我们会看到，ActivityManagerService会使用它来和ActivityThread来进行进程间通信。这里我们需注意的是，这里的mMainThread代表的是Launcher应用程序运行的进程。 这里的mToken也是Activity类的成员变量，它是一个Binder对象的远程接口。 **Step 4. Instrumentation.execStartActivity** 这个函数定义在frameworks/base/core/java/android/app/Instrumentation.java文件中： ~~~ public class Instrumentation { ...... public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode) { IApplicationThread whoThread = (IApplicationThread) contextThread; if (mActivityMonitors != null) { ...... } try { int result = ActivityManagerNative.getDefault() .startActivity(whoThread, intent, intent.resolveTypeIfNeeded(who.getContentResolver()), null, 0, token, target != null ? target.mEmbeddedID : null, requestCode, false, false); ...... } catch (RemoteException e) { } return null; } ...... } ~~~ 这里的ActivityManagerNative.getDefault返回ActivityManagerService的远程接口，即ActivityManagerProxy接口，具体可以参考Android系统在新进程中启动自定义服务过程（startService）的原理分析一文。 这里的intent.resolveTypeIfNeeded返回这个intent的MIME类型，在这个例子中，没有AndroidManifest.xml设置MainActivity的MIME类型，因此，这里返回null。 这里的target不为null，但是target.mEmbddedID为null，我们不用关注。 **Step 5. ActivityManagerProxy.startActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public int startActivity(IApplicationThread caller, Intent intent, String resolvedType, Uri[] grantedUriPermissions, int grantedMode, IBinder resultTo, String resultWho, int requestCode, boolean onlyIfNeeded, boolean debug) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); intent.writeToParcel(data, 0); data.writeString(resolvedType); data.writeTypedArray(grantedUriPermissions, 0); data.writeInt(grantedMode); data.writeStrongBinder(resultTo); data.writeString(resultWho); data.writeInt(requestCode); data.writeInt(onlyIfNeeded ? 1 : 0); data.writeInt(debug ? 1 : 0); mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0); reply.readException(); int result = reply.readInt(); reply.recycle(); data.recycle(); return result; } ...... } ~~~ 这里的参数比较多，我们先整理一下。从上面的调用可以知道，这里的参数resolvedType、grantedUriPermissions和resultWho均为null；参数caller为ApplicationThread类型的Binder实体；参数resultTo为一个Binder实体的远程接口，我们先不关注它；参数grantedMode为0，我们也先不关注它；参数requestCode为-1；参数onlyIfNeeded和debug均空false。 **Step 6. ActivityManagerService.startActivity** 上一步Step 5通过Binder驱动程序就进入到ActivityManagerService的startActivity函数来了，它定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public final int startActivity(IApplicationThread caller, Intent intent, String resolvedType, Uri[] grantedUriPermissions, int grantedMode, IBinder resultTo, String resultWho, int requestCode, boolean onlyIfNeeded, boolean debug) { return mMainStack.startActivityMayWait(caller, intent, resolvedType, grantedUriPermissions, grantedMode, resultTo, resultWho, requestCode, onlyIfNeeded, debug, null, null); } ...... } ~~~ 这里只是简单地将操作转发给成员变量mMainStack的startActivityMayWait函数，这里的mMainStack的类型为ActivityStack。 **Step 7. ActivityStack.startActivityMayWait** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final int startActivityMayWait(IApplicationThread caller, Intent intent, String resolvedType, Uri[] grantedUriPermissions, int grantedMode, IBinder resultTo, String resultWho, int requestCode, boolean onlyIfNeeded, boolean debug, WaitResult outResult, Configuration config) { ...... boolean componentSpecified = intent.getComponent() != null; // Don't modify the client's object! intent = new Intent(intent); // Collect information about the target of the Intent. ActivityInfo aInfo; try { ResolveInfo rInfo = AppGlobals.getPackageManager().resolveIntent( intent, resolvedType, PackageManager.MATCH_DEFAULT_ONLY | ActivityManagerService.STOCK_PM_FLAGS); aInfo = rInfo != null ? rInfo.activityInfo : null; } catch (RemoteException e) { ...... } if (aInfo != null) { // Store the found target back into the intent, because now that // we have it we never want to do this again. For example, if the // user navigates back to this point in the history, we should // always restart the exact same activity. intent.setComponent(new ComponentName( aInfo.applicationInfo.packageName, aInfo.name)); ...... } synchronized (mService) { int callingPid; int callingUid; if (caller == null) { ...... } else { callingPid = callingUid = -1; } mConfigWillChange = config != null && mService.mConfiguration.diff(config) != 0; ...... if (mMainStack && aInfo != null && (aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0) { ...... } int res = startActivityLocked(caller, intent, resolvedType, grantedUriPermissions, grantedMode, aInfo, resultTo, resultWho, requestCode, callingPid, callingUid, onlyIfNeeded, componentSpecified); if (mConfigWillChange && mMainStack) { ...... } ...... if (outResult != null) { ...... } return res; } } ...... } ~~~ 注意，从Step 6传下来的参数outResult和config均为null，此外，表达式(aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0为false，因此，这里忽略了无关代码。 下面语句对参数intent的内容进行解析，得到MainActivity的相关信息，保存在aInfo变量中： ~~~ ActivityInfo aInfo; try { ResolveInfo rInfo = AppGlobals.getPackageManager().resolveIntent( intent, resolvedType, PackageManager.MATCH_DEFAULT_ONLY | ActivityManagerService.STOCK_PM_FLAGS); aInfo = rInfo != null ? rInfo.activityInfo : null; } catch (RemoteException e) { ...... } ~~~ 解析之后，得到的aInfo.applicationInfo.packageName的值为"shy.luo.activity"，aInfo.name的值为"shy.luo.activity.MainActivity"，这是在这个实例的配置文件AndroidManifest.xml里面配置的。 此外，函数开始的地方调用intent.getComponent()函数的返回值不为null，因此，这里的componentSpecified变量为true。 接下去就调用startActivityLocked进一步处理了。 **Step 8. ActivityStack.startActivityLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final int startActivityLocked(IApplicationThread caller, Intent intent, String resolvedType, Uri[] grantedUriPermissions, int grantedMode, ActivityInfo aInfo, IBinder resultTo, String resultWho, int requestCode, int callingPid, int callingUid, boolean onlyIfNeeded, boolean componentSpecified) { int err = START_SUCCESS; ProcessRecord callerApp = null; if (caller != null) { callerApp = mService.getRecordForAppLocked(caller); if (callerApp != null) { callingPid = callerApp.pid; callingUid = callerApp.info.uid; } else { ...... } } ...... ActivityRecord sourceRecord = null; ActivityRecord resultRecord = null; if (resultTo != null) { int index = indexOfTokenLocked(resultTo); ...... if (index >= 0) { sourceRecord = (ActivityRecord)mHistory.get(index); if (requestCode >= 0 && !sourceRecord.finishing) { ...... } } } int launchFlags = intent.getFlags(); if ((launchFlags&Intent.FLAG_ACTIVITY_FORWARD_RESULT) != 0 && sourceRecord != null) { ...... } if (err == START_SUCCESS && intent.getComponent() == null) { ...... } if (err == START_SUCCESS && aInfo == null) { ...... } if (err != START_SUCCESS) { ...... } ...... ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid, intent, resolvedType, aInfo, mService.mConfiguration, resultRecord, resultWho, requestCode, componentSpecified); ...... return startActivityUncheckedLocked(r, sourceRecord, grantedUriPermissions, grantedMode, onlyIfNeeded, true); } ...... } ~~~ 从传进来的参数caller得到调用者的进程信息，并保存在callerApp变量中，这里就是Launcher应用程序的进程信息了。 前面说过，参数resultTo是Launcher这个Activity里面的一个Binder对象，通过它可以获得Launcher这个Activity的相关信息，保存在sourceRecord变量中。 再接下来，创建即将要启动的Activity的相关信息，并保存在r变量中： ~~~ ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid, intent, resolvedType, aInfo, mService.mConfiguration, resultRecord, resultWho, requestCode, componentSpecified); ~~~ 接着调用startActivityUncheckedLocked函数进行下一步操作。 **Step 9. ActivityStack.startActivityUncheckedLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final int startActivityUncheckedLocked(ActivityRecord r, ActivityRecord sourceRecord, Uri[] grantedUriPermissions, int grantedMode, boolean onlyIfNeeded, boolean doResume) { final Intent intent = r.intent; final int callingUid = r.launchedFromUid; int launchFlags = intent.getFlags(); // We'll invoke onUserLeaving before onPause only if the launching // activity did not explicitly state that this is an automated launch. mUserLeaving = (launchFlags&Intent.FLAG_ACTIVITY_NO_USER_ACTION) == 0; ...... ActivityRecord notTop = (launchFlags&Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP) != 0 ? r : null; // If the onlyIfNeeded flag is set, then we can do this if the activity // being launched is the same as the one making the call... or, as // a special case, if we do not know the caller then we count the // current top activity as the caller. if (onlyIfNeeded) { ...... } if (sourceRecord == null) { ...... } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { ...... } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) { ...... } if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { ...... } boolean addingToTask = false; if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 && (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0) || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { // If bring to front is requested, and no result is requested, and // we can find a task that was started with this same // component, then instead of launching bring that one to the front. if (r.resultTo == null) { // See if there is a task to bring to the front. If this is // a SINGLE_INSTANCE activity, there can be one and only one // instance of it in the history, and it is always in its own // unique task, so we do a special search. ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE ? findTaskLocked(intent, r.info) : findActivityLocked(intent, r.info); if (taskTop != null) { ...... } } } ...... if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { ...... } } } else { ...... } boolean newTask = false; // Should this be considered a new task? if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { // todo: should do better management of integers. mService.mCurTask++; if (mService.mCurTask <= 0) { mService.mCurTask = 1; } r.task = new TaskRecord(mService.mCurTask, r.info, intent, (r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0); ...... newTask = true; if (mMainStack) { mService.addRecentTaskLocked(r.task); } } else if (sourceRecord != null) { ...... } else { ...... } ...... startActivityLocked(r, newTask, doResume); return START_SUCCESS; } ...... } ~~~ 函数首先获得intent的标志值，保存在launchFlags变量中。 这个intent的标志值的位Intent.FLAG_ACTIVITY_NO_USER_ACTION没有置位，因此 ，成员变量mUserLeaving的值为true。 这个intent的标志值的位Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP也没有置位，因此，变量notTop的值为null。 由于在这个例子的AndroidManifest.xml文件中，MainActivity没有配置launchMode属值，因此，这里的r.launchMode为默认值0，表示以标准（Standard，或者称为ActivityInfo.LAUNCH_MULTIPLE）的方式来启动这个Activity。Activity的启动方式有四种，其余三种分别是ActivityInfo.LAUNCH_SINGLE_INSTANCE、ActivityInfo.LAUNCH_SINGLE_TASK和ActivityInfo.LAUNCH_SINGLE_TOP，具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。 传进来的参数r.resultTo为null，表示Launcher不需要等这个即将要启动的MainActivity的执行结果。 由于这个intent的标志值的位Intent.FLAG_ACTIVITY_NEW_TASK被置位，而且Intent.FLAG_ACTIVITY_MULTIPLE_TASK没有置位，因此，下面的if语句会被执行： ~~~ if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 && (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0) || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) { // If bring to front is requested, and no result is requested, and // we can find a task that was started with this same // component, then instead of launching bring that one to the front. if (r.resultTo == null) { // See if there is a task to bring to the front. If this is // a SINGLE_INSTANCE activity, there can be one and only one // instance of it in the history, and it is always in its own // unique task, so we do a special search. ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE ? findTaskLocked(intent, r.info) : findActivityLocked(intent, r.info); if (taskTop != null) { ...... } } } ~~~ 这段代码的逻辑是查看一下，当前有没有Task可以用来执行这个Activity。由于r.launchMode的值不为ActivityInfo.LAUNCH_SINGLE_INSTANCE，因此，它通过findTaskLocked函数来查找存不存这样的Task，这里返回的结果是null，即taskTop为null，因此，需要创建一个新的Task来启动这个Activity。 接着往下看： ~~~ if (r.packageName != null) { // If the activity being launched is the same as the one currently // at the top, then we need to check if it should only be launched // once. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop); if (top != null && r.resultTo == null) { if (top.realActivity.equals(r.realActivity)) { ...... } } } ~~~ 这段代码的逻辑是看一下，当前在堆栈顶端的Activity是否就是即将要启动的Activity，有些情况下，如果即将要启动的Activity就在堆栈的顶端，那么，就不会重新启动这个Activity的别一个实例了，具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。现在处理堆栈顶端的Activity是Launcher，与我们即将要启动的MainActivity不是同一个Activity，因此，这里不用进一步处理上述介绍的情况。 执行到这里，我们知道，要在一个新的Task里面来启动这个Activity了，于是新创建一个Task： ~~~ if (r.resultTo == null && !addingToTask && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) { // todo: should do better management of integers. mService.mCurTask++; if (mService.mCurTask <= 0) { mService.mCurTask = 1; } r.task = new TaskRecord(mService.mCurTask, r.info, intent, (r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0); ...... newTask = true; if (mMainStack) { mService.addRecentTaskLocked(r.task); } } ~~~ 新建的Task保存在r.task域中，同时，添加到mService中去，这里的mService就是ActivityManagerService了。 最后就进入startActivityLocked(r, newTask, doResume)进一步处理了。这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startActivityLocked(ActivityRecord r, boolean newTask, boolean doResume) { final int NH = mHistory.size(); int addPos = -1; if (!newTask) { ...... } // Place a new activity at top of stack, so it is next to interact // with the user. if (addPos < 0) { addPos = NH; } // If we are not placing the new activity frontmost, we do not want // to deliver the onUserLeaving callback to the actual frontmost // activity if (addPos < NH) { ...... } // Slot the activity into the history stack and proceed mHistory.add(addPos, r); r.inHistory = true; r.frontOfTask = newTask; r.task.numActivities++; if (NH > 0) { // We want to show the starting preview window if we are // switching to a new task, or the next activity's process is // not currently running. ...... } else { // If this is the first activity, don't do any fancy animations, // because there is nothing for it to animate on top of. ...... } ...... if (doResume) { resumeTopActivityLocked(null); } } ...... } ~~~ 这里的NH表示当前系统中历史任务的个数，这里肯定是大于0，因为Launcher已经跑起来了。当NH>0时，并且现在要切换新任务时，要做一些任务切的界面操作，这段代码我们就不看了，这里不会影响到下面启Activity的过程，有兴趣的读取可以自己研究一下。 这里传进来的参数doResume为true，于是调用resumeTopActivityLocked进一步操作。 **Step 10. Activity.resumeTopActivityLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... /** * Ensure that the top activity in the stack is resumed. * * @param prev The previously resumed activity, for when in the process * of pausing; can be null to call from elsewhere. * * @return Returns true if something is being resumed, or false if * nothing happened. */ final boolean resumeTopActivityLocked(ActivityRecord prev) { // Find the first activity that is not finishing. ActivityRecord next = topRunningActivityLocked(null); // Remember how we'll process this pause/resume situation, and ensure // that the state is reset however we wind up proceeding. final boolean userLeaving = mUserLeaving; mUserLeaving = false; if (next == null) { ...... } next.delayedResume = false; // If the top activity is the resumed one, nothing to do. if (mResumedActivity == next && next.state == ActivityState.RESUMED) { ...... } // If we are sleeping, and there is no resumed activity, and the top // activity is paused, well that is the state we want. if ((mService.mSleeping || mService.mShuttingDown) && mLastPausedActivity == next && next.state == ActivityState.PAUSED) { ...... } ...... // If we are currently pausing an activity, then don't do anything // until that is done. if (mPausingActivity != null) { ...... } ...... // We need to start pausing the current activity so the top one // can be resumed... if (mResumedActivity != null) { ...... startPausingLocked(userLeaving, false); return true; } ...... } ...... } ~~~ 函数先通过调用topRunningActivityLocked函数获得堆栈顶端的Activity，这里就是MainActivity了，这是在上面的Step 9设置好的，保存在next变量中。 接下来把mUserLeaving的保存在本地变量userLeaving中，然后重新设置为false，在上面的Step 9中，mUserLeaving的值为true，因此，这里的userLeaving为true。 这里的mResumedActivity为Launcher，因为Launcher是当前正被执行的Activity。 当我们处理休眠状态时，mLastPausedActivity保存堆栈顶端的Activity，因为当前不是休眠状态，所以mLastPausedActivity为null。 有了这些信息之后，下面的语句就容易理解了： ~~~ // If the top activity is the resumed one, nothing to do. if (mResumedActivity == next && next.state == ActivityState.RESUMED) { ...... } // If we are sleeping, and there is no resumed activity, and the top // activity is paused, well that is the state we want. if ((mService.mSleeping || mService.mShuttingDown) && mLastPausedActivity == next && next.state == ActivityState.PAUSED) { ...... } ~~~ 它首先看要启动的Activity是否就是当前处理Resumed状态的Activity，如果是的话，那就什么都不用做，直接返回就可以了；否则再看一下系统当前是否休眠状态，如果是的话，再看看要启动的Activity是否就是当前处于堆栈顶端的Activity，如果是的话，也是什么都不用做。 上面两个条件都不满足，因此，在继续往下执行之前，首先要把当处于Resumed状态的Activity推入Paused状态，然后才可以启动新的Activity。但是在将当前这个Resumed状态的Activity推入Paused状态之前，首先要看一下当前是否有Activity正在进入Pausing状态，如果有的话，当前这个Resumed状态的Activity就要稍后才能进入Paused状态了，这样就保证了所有需要进入Paused状态的Activity串行处理。 这里没有处于Pausing状态的Activity，即mPausingActivity为null，而且mResumedActivity也不为null，于是就调用startPausingLocked函数把Launcher推入Paused状态去了。 **Step 11. ActivityStack.startPausingLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startPausingLocked(boolean userLeaving, boolean uiSleeping) { if (mPausingActivity != null) { ...... } ActivityRecord prev = mResumedActivity; if (prev == null) { ...... } ...... mResumedActivity = null; mPausingActivity = prev; mLastPausedActivity = prev; prev.state = ActivityState.PAUSING; ...... if (prev.app != null && prev.app.thread != null) { ...... try { ...... prev.app.thread.schedulePauseActivity(prev, prev.finishing, userLeaving, prev.configChangeFlags); ...... } catch (Exception e) { ...... } } else { ...... } ...... } ...... } ~~~ 函数首先把mResumedActivity保存在本地变量prev中。在上一步Step 10中，说到mResumedActivity就是Launcher，因此，这里把Launcher进程中的ApplicationThread对象取出来，通过它来通知Launcher这个Activity它要进入Paused状态了。当然，这里的prev.app.thread是一个ApplicationThread对象的远程接口，通过调用这个远程接口的schedulePauseActivity来通知Launcher进入Paused状态。 参数prev.finishing表示prev所代表的Activity是否正在等待结束的Activity列表中，由于Laucher这个Activity还没结束，所以这里为false；参数prev.configChangeFlags表示哪些config发生了变化，这里我们不关心它的值。 **Step 12. ApplicationThreadProxy.schedulePauseActivity** 这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中： ~~~ class ApplicationThreadProxy implements IApplicationThread { ...... public final void schedulePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges) throws RemoteException { Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); data.writeStrongBinder(token); data.writeInt(finished ? 1 : 0); data.writeInt(userLeaving ? 1 :0); data.writeInt(configChanges); mRemote.transact(SCHEDULE_PAUSE_ACTIVITY_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle(); } ...... } ~~~ 这个函数通过Binder进程间通信机制进入到ApplicationThread.schedulePauseActivity函数中。 **Step 13. ApplicationThread.schedulePauseActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中，它是ActivityThread的内部类： ~~~ public final class ActivityThread { ...... private final class ApplicationThread extends ApplicationThreadNative { ...... public final void schedulePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges) { queueOrSendMessage( finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY, token, (userLeaving ? 1 : 0), configChanges); } ...... } ...... } ~~~ 这里调用的函数queueOrSendMessage是ActivityThread类的成员函数。 上面说到，这里的finished值为false，因此，queueOrSendMessage的第一个参数值为H.PAUSE_ACTIVITY，表示要暂停token所代表的Activity，即Launcher。 **Step 14. ActivityThread.queueOrSendMessage** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void queueOrSendMessage(int what, Object obj, int arg1) { queueOrSendMessage(what, obj, arg1, 0); } private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) { synchronized (this) { ...... Message msg = Message.obtain(); msg.what = what; msg.obj = obj; msg.arg1 = arg1; msg.arg2 = arg2; mH.sendMessage(msg); } } ...... } ~~~ 这里首先将相关信息组装成一个msg，然后通过mH成员变量发送出去，mH的类型是H，继承于Handler类，是ActivityThread的内部类，因此，这个消息最后由H.handleMessage来处理。 **Step 15. H.handleMessage** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... switch (msg.what) { ...... case PAUSE_ACTIVITY: handlePauseActivity((IBinder)msg.obj, false, msg.arg1 != 0, msg.arg2); maybeSnapshot(); break; ...... } ...... } ...... } ~~~ 这里调用ActivityThread.handlePauseActivity进一步操作，msg.obj是一个ActivityRecord对象的引用，它代表的是Launcher这个Activity。 **Step 16. ActivityThread.handlePauseActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges) { ActivityClientRecord r = mActivities.get(token); if (r != null) { //Slog.v(TAG, "userLeaving=" + userLeaving + " handling pause of " + r); if (userLeaving) { performUserLeavingActivity(r); } r.activity.mConfigChangeFlags |= configChanges; Bundle state = performPauseActivity(token, finished, true); // Make sure any pending writes are now committed. QueuedWork.waitToFinish(); // Tell the activity manager we have paused. try { ActivityManagerNative.getDefault().activityPaused(token, state); } catch (RemoteException ex) { } } } ...... } ~~~ 函数首先将Binder引用token转换成ActivityRecord的远程接口ActivityClientRecord，然后做了三个事情：1. 如果userLeaving为true，则通过调用performUserLeavingActivity函数来调用Activity.onUserLeaveHint通知Activity，用户要离开它了；2. 调用performPauseActivity函数来调用Activity.onPause函数，我们知道，在Activity的生命周期中，当它要让位于其它的Activity时，系统就会调用它的onPause函数；3. 它通知ActivityManagerService，这个Activity已经进入Paused状态了，ActivityManagerService现在可以完成未竟的事情，即启动MainActivity了。 **Step 17. ActivityManagerProxy.activityPaused** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public void activityPaused(IBinder token, Bundle state) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(token); data.writeBundle(state); mRemote.transact(ACTIVITY_PAUSED_TRANSACTION, data, reply, 0); reply.readException(); data.recycle(); reply.recycle(); } ...... } ~~~ 这里通过Binder进程间通信机制就进入到ActivityManagerService.activityPaused函数中去了。 **Step 18. ActivityManagerService.activityPaused** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public final void activityPaused(IBinder token, Bundle icicle) { ...... final long origId = Binder.clearCallingIdentity(); mMainStack.activityPaused(token, icicle, false); ...... } ...... } ~~~ 这里，又再次进入到ActivityStack类中，执行activityPaused函数。 **Step 19. ActivityStack.activityPaused** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final void activityPaused(IBinder token, Bundle icicle, boolean timeout) { ...... ActivityRecord r = null; synchronized (mService) { int index = indexOfTokenLocked(token); if (index >= 0) { r = (ActivityRecord)mHistory.get(index); if (!timeout) { r.icicle = icicle; r.haveState = true; } mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r); if (mPausingActivity == r) { r.state = ActivityState.PAUSED; completePauseLocked(); } else { ...... } } } } ...... } ~~~ 这里通过参数token在mHistory列表中得到ActivityRecord，从上面我们知道，这个ActivityRecord代表的是Launcher这个Activity，而我们在Step 11中，把Launcher这个Activity的信息保存在mPausingActivity中，因此，这里mPausingActivity等于r，于是，执行completePauseLocked操作。 **Step 20. ActivityStack.completePauseLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void completePauseLocked() { ActivityRecord prev = mPausingActivity; ...... if (prev != null) { ...... mPausingActivity = null; } if (!mService.mSleeping && !mService.mShuttingDown) { resumeTopActivityLocked(prev); } else { ...... } ...... } ...... } ~~~ 函数首先把mPausingActivity变量清空，因为现在不需要它了，然后调用resumeTopActivityLokced进一步操作，它传入的参数即为代表Launcher这个Activity的ActivityRecord。 **Step 21. ActivityStack.resumeTopActivityLokced** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final boolean resumeTopActivityLocked(ActivityRecord prev) { ...... // Find the first activity that is not finishing. ActivityRecord next = topRunningActivityLocked(null); // Remember how we'll process this pause/resume situation, and ensure // that the state is reset however we wind up proceeding. final boolean userLeaving = mUserLeaving; mUserLeaving = false; ...... next.delayedResume = false; // If the top activity is the resumed one, nothing to do. if (mResumedActivity == next && next.state == ActivityState.RESUMED) { ...... return false; } // If we are sleeping, and there is no resumed activity, and the top // activity is paused, well that is the state we want. if ((mService.mSleeping || mService.mShuttingDown) && mLastPausedActivity == next && next.state == ActivityState.PAUSED) { ...... return false; } ....... // We need to start pausing the current activity so the top one // can be resumed... if (mResumedActivity != null) { ...... return true; } ...... if (next.app != null && next.app.thread != null) { ...... } else { ...... startSpecificActivityLocked(next, true, true); } return true; } ...... } ~~~ 通过上面的Step 9，我们知道，当前在堆栈顶端的Activity为我们即将要启动的MainActivity，这里通过调用topRunningActivityLocked将它取回来，保存在next变量中。之前最后一个Resumed状态的Activity，即Launcher，到了这里已经处于Paused状态了，因此，mResumedActivity为null。最后一个处于Paused状态的Activity为Launcher，因此，这里的mLastPausedActivity就为Launcher。前面我们为MainActivity创建了ActivityRecord后，它的app域一直保持为null。有了这些信息后，上面这段代码就容易理解了，它最终调用startSpecificActivityLocked进行下一步操作。 **Step 22. ActivityStack.startSpecificActivityLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... private final void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) { // Is this activity's application already running? ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid); ...... if (app != null && app.thread != null) { try { realStartActivityLocked(r, app, andResume, checkConfig); return; } catch (RemoteException e) { ...... } } mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0, "activity", r.intent.getComponent(), false); } ...... } ~~~ 注意，这里由于是第一次启动应用程序的Activity，所以下面语句： ~~~ ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid); ~~~ 取回来的app为null。在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定Application标签的process属性，系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然，我们可以配置两个应用程序具有相同的uid和package，或者在AndroidManifest.xml配置文件的application标签或者activity标签中显式指定相同的process属性值，这样，不同的应用程序也可以在同一个进程中启动。 函数最终执行ActivityManagerService.startProcessLocked函数进行下一步操作。 **Step 23. ActivityManagerService.startProcessLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... final ProcessRecord startProcessLocked(String processName, ApplicationInfo info, boolean knownToBeDead, int intentFlags, String hostingType, ComponentName hostingName, boolean allowWhileBooting) { ProcessRecord app = getProcessRecordLocked(processName, info.uid); ...... String hostingNameStr = hostingName != null ? hostingName.flattenToShortString() : null; ...... if (app == null) { app = new ProcessRecordLocked(null, info, processName); mProcessNames.put(processName, info.uid, app); } else { // If this is a new package in the process, add the package to the list app.addPackage(info.packageName); } ...... startProcessLocked(app, hostingType, hostingNameStr); return (app.pid != 0) ? app : null; } ...... } ~~~ 这里再次检查是否已经有以process + uid命名的进程存在，在我们这个情景中，返回值app为null，因此，后面会创建一个ProcessRecord，并存保存在成员变量mProcessNames中，最后，调用另一个startProcessLocked函数进一步操作： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final void startProcessLocked(ProcessRecord app, String hostingType, String hostingNameStr) { ...... try { int uid = app.info.uid; int[] gids = null; try { gids = mContext.getPackageManager().getPackageGids( app.info.packageName); } catch (PackageManager.NameNotFoundException e) { ...... } ...... int debugFlags = 0; ...... int pid = Process.start("android.app.ActivityThread", mSimpleProcessManagement ? app.processName : null, uid, uid, gids, debugFlags, null); ...... } catch (RuntimeException e) { ...... } } ...... } ~~~ 这里主要是调用Process.start接口来创建一个新的进程，新的进程会导入android.app.ActivityThread类，并且执行它的main函数，这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。 **Step 24. ActivityThread.main** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void attach(boolean system) { ...... mSystemThread = system; if (!system) { ...... IActivityManager mgr = ActivityManagerNative.getDefault(); try { mgr.attachApplication(mAppThread); } catch (RemoteException ex) { } } else { ...... } } ...... public static final void main(String[] args) { ....... ActivityThread thread = new ActivityThread(); thread.attach(false); ...... Looper.loop(); ....... thread.detach(); ...... } } ~~~ 这个函数在进程中创建一个ActivityThread实例，然后调用它的attach函数，接着就进入消息循环了，直到最后进程退出。 函数attach最终调用了ActivityManagerService的远程接口ActivityManagerProxy的attachApplication函数，传入的参数是mAppThread，这是一个ApplicationThread类型的Binder对象，它的作用是用来进行进程间通信的。 **Step 25. ActivityManagerProxy.attachApplication** 这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中： ~~~ class ActivityManagerProxy implements IActivityManager { ...... public void attachApplication(IApplicationThread app) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(app.asBinder()); mRemote.transact(ATTACH_APPLICATION_TRANSACTION, data, reply, 0); reply.readException(); data.recycle(); reply.recycle(); } ...... } ~~~ 这里通过Binder驱动程序，最后进入ActivityManagerService的attachApplication函数中。 **Step 26. ActivityManagerService.attachApplication** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... public final void attachApplication(IApplicationThread thread) { synchronized (this) { int callingPid = Binder.getCallingPid(); final long origId = Binder.clearCallingIdentity(); attachApplicationLocked(thread, callingPid); Binder.restoreCallingIdentity(origId); } } ...... } ~~~ 这里将操作转发给attachApplicationLocked函数。 **Step 27. ActivityManagerService.attachApplicationLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中： ~~~ public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { ...... private final boolean attachApplicationLocked(IApplicationThread thread, int pid) { // Find the application record that is being attached... either via // the pid if we are running in multiple processes, or just pull the // next app record if we are emulating process with anonymous threads. ProcessRecord app; if (pid != MY_PID && pid >= 0) { synchronized (mPidsSelfLocked) { app = mPidsSelfLocked.get(pid); } } else if (mStartingProcesses.size() > 0) { ...... } else { ...... } if (app == null) { ...... return false; } ...... String processName = app.processName; try { thread.asBinder().linkToDeath(new AppDeathRecipient( app, pid, thread), 0); } catch (RemoteException e) { ...... return false; } ...... app.thread = thread; app.curAdj = app.setAdj = -100; app.curSchedGroup = Process.THREAD_GROUP_DEFAULT; app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE; app.forcingToForeground = null; app.foregroundServices = false; app.debugging = false; ...... boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info); ...... boolean badApp = false; boolean didSomething = false; // See if the top visible activity is waiting to run in this process... ActivityRecord hr = mMainStack.topRunningActivityLocked(null); if (hr != null && normalMode) { if (hr.app == null && app.info.uid == hr.info.applicationInfo.uid && processName.equals(hr.processName)) { try { if (mMainStack.realStartActivityLocked(hr, app, true, true)) { didSomething = true; } } catch (Exception e) { ...... } } else { ...... } } ...... return true; } ...... } ~~~ 在前面的Step 23中，已经创建了一个ProcessRecord，这里首先通过pid将它取回来，放在app变量中，然后对app的其它成员进行初始化，最后调用mMainStack.realStartActivityLocked执行真正的Activity启动操作。这里要启动的Activity通过调用mMainStack.topRunningActivityLocked(null)从堆栈顶端取回来，这时候在堆栈顶端的Activity就是MainActivity了。 **Step 28. ActivityStack.realStartActivityLocked** 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： ~~~ public class ActivityStack { ...... final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException { ...... r.app = app; ...... int idx = app.activities.indexOf(r); if (idx < 0) { app.activities.add(r); } ...... try { ...... List results = null; List newIntents = null; if (andResume) { results = r.results; newIntents = r.newIntents; } ...... app.thread.scheduleLaunchActivity(new Intent(r.intent), r, System.identityHashCode(r), r.info, r.icicle, results, newIntents, !andResume, mService.isNextTransitionForward()); ...... } catch (RemoteException e) { ...... } ...... return true; } ...... } ~~~ 这里最终通过app.thread进入到ApplicationThreadProxy的scheduleLaunchActivity函数中，注意，这里的第二个参数r，是一个ActivityRecord类型的Binder对象，用来作来这个Activity的token值。 **Step 29. ApplicationThreadProxy.scheduleLaunchActivity** 这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中： ~~~ class ApplicationThreadProxy implements IApplicationThread { ...... public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Bundle state, List pendingResults, List pendingNewIntents, boolean notResumed, boolean isForward) throws RemoteException { Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); intent.writeToParcel(data, 0); data.writeStrongBinder(token); data.writeInt(ident); info.writeToParcel(data, 0); data.writeBundle(state); data.writeTypedList(pendingResults); data.writeTypedList(pendingNewIntents); data.writeInt(notResumed ? 1 : 0); data.writeInt(isForward ? 1 : 0); mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle(); } ...... } ~~~ 这个函数最终通过Binder驱动程序进入到ApplicationThread的scheduleLaunchActivity函数中。 **Step 30. ApplicationThread.scheduleLaunchActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class ApplicationThread extends ApplicationThreadNative { ...... // we use token to identify this activity without having to send the // activity itself back to the activity manager. (matters more with ipc) public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Bundle state, List pendingResults, List pendingNewIntents, boolean notResumed, boolean isForward) { ActivityClientRecord r = new ActivityClientRecord(); r.token = token; r.ident = ident; r.intent = intent; r.activityInfo = info; r.state = state; r.pendingResults = pendingResults; r.pendingIntents = pendingNewIntents; r.startsNotResumed = notResumed; r.isForward = isForward; queueOrSendMessage(H.LAUNCH_ACTIVITY, r); } ...... } ...... } ~~~ 函数首先创建一个ActivityClientRecord实例，并且初始化它的成员变量，然后调用ActivityThread类的queueOrSendMessage函数进一步处理。 **Step 31. ActivityThread.queueOrSendMessage** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class ApplicationThread extends ApplicationThreadNative { ...... // if the thread hasn't started yet, we don't have the handler, so just // save the messages until we're ready. private final void queueOrSendMessage(int what, Object obj) { queueOrSendMessage(what, obj, 0, 0); } ...... private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) { synchronized (this) { ...... Message msg = Message.obtain(); msg.what = what; msg.obj = obj; msg.arg1 = arg1; msg.arg2 = arg2; mH.sendMessage(msg); } } ...... } ...... } ~~~ 函数把消息内容放在msg中，然后通过mH把消息分发出去，这里的成员变量mH我们在前面已经见过，消息分发出去后，最后会调用H类的handleMessage函数。 **Step 32. H.handleMessage** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final class H extends Handler { ...... public void handleMessage(Message msg) { ...... switch (msg.what) { case LAUNCH_ACTIVITY: { ActivityClientRecord r = (ActivityClientRecord)msg.obj; r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo); handleLaunchActivity(r, null); } break; ...... } ...... } ...... } ~~~ 这里最后调用ActivityThread类的handleLaunchActivity函数进一步处理。 **Step 33. ActivityThread.handleLaunchActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) { ...... Activity a = performLaunchActivity(r, customIntent); if (a != null) { r.createdConfig = new Configuration(mConfiguration); Bundle oldState = r.state; handleResumeActivity(r.token, false, r.isForward); ...... } else { ...... } } ...... } ~~~ 这里首先调用performLaunchActivity函数来加载这个Activity类，即shy.luo.activity.MainActivity，然后调用它的onCreate函数，最后回到handleLaunchActivity函数时，再调用handleResumeActivity函数来使这个Activity进入Resumed状态，即会调用这个Activity的onResume函数，这是遵循Activity的生命周期的。 **Step 34. ActivityThread.performLaunchActivity** 这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中： ~~~ public final class ActivityThread { ...... private final Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { ActivityInfo aInfo = r.activityInfo; if (r.packageInfo == null) { r.packageInfo = getPackageInfo(aInfo.applicationInfo, Context.CONTEXT_INCLUDE_CODE); } ComponentName component = r.intent.getComponent(); if (component == null) { component = r.intent.resolveActivity( mInitialApplication.getPackageManager()); r.intent.setComponent(component); } if (r.activityInfo.targetActivity != null) { component = new ComponentName(r.activityInfo.packageName, r.activityInfo.targetActivity); } Activity activity = null; try { java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); r.intent.setExtrasClassLoader(cl); if (r.state != null) { r.state.setClassLoader(cl); } } catch (Exception e) { ...... } try { Application app = r.packageInfo.makeApplication(false, mInstrumentation); ...... if (activity != null) { ContextImpl appContext = new ContextImpl(); appContext.init(r.packageInfo, r.token, this); appContext.setOuterContext(activity); CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager()); Configuration config = new Configuration(mConfiguration); ...... activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstance, r.lastNonConfigurationChildInstances, config); if (customIntent != null) { activity.mIntent = customIntent; } r.lastNonConfigurationInstance = null; r.lastNonConfigurationChildInstances = null; activity.mStartedActivity = false; int theme = r.activityInfo.getThemeResource(); if (theme != 0) { activity.setTheme(theme); } activity.mCalled = false; mInstrumentation.callActivityOnCreate(activity, r.state); ...... r.activity = activity; r.stopped = true; if (!r.activity.mFinished) { activity.performStart(); r.stopped = false; } if (!r.activity.mFinished) { if (r.state != null) { mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state); } } if (!r.activity.mFinished) { activity.mCalled = false; mInstrumentation.callActivityOnPostCreate(activity, r.state); if (!activity.mCalled) { throw new SuperNotCalledException( "Activity " + r.intent.getComponent().toShortString() + " did not call through to super.onPostCreate()"); } } } r.paused = true; mActivities.put(r.token, r); } catch (SuperNotCalledException e) { ...... } catch (Exception e) { ...... } return activity; } ...... } ~~~ 函数前面是收集要启动的Activity的相关信息，主要package和component信息： ~~~ ActivityInfo aInfo = r.activityInfo; if (r.packageInfo == null) { r.packageInfo = getPackageInfo(aInfo.applicationInfo, Context.CONTEXT_INCLUDE_CODE); } ComponentName component = r.intent.getComponent(); if (component == null) { component = r.intent.resolveActivity( mInitialApplication.getPackageManager()); r.intent.setComponent(component); } if (r.activityInfo.targetActivity != null) { component = new ComponentName(r.activityInfo.packageName, r.activityInfo.targetActivity); } ~~~ 然后通过ClassLoader将shy.luo.activity.MainActivity类加载进来： ~~~ Activity activity = null; try { java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); r.intent.setExtrasClassLoader(cl); if (r.state != null) { r.state.setClassLoader(cl); } } catch (Exception e) { ...... } ~~~ 接下来是创建Application对象，这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的： ~~~ Application app = r.packageInfo.makeApplication(false, mInstrumentation); ~~~ 后面的代码主要创建Activity的上下文信息，并通过attach方法将这些上下文信息设置到MainActivity中去： ~~~ activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstance, r.lastNonConfigurationChildInstances, config); ~~~ 最后还要调用MainActivity的onCreate函数： ~~~ mInstrumentation.callActivityOnCreate(activity, r.state); ~~~ 这里不是直接调用MainActivity的onCreate函数，而是通过mInstrumentation的callActivityOnCreate函数来间接调用，前面我们说过，mInstrumentation在这里的作用是监控Activity与系统的交互操作，相当于是系统运行日志。 **Step 35. MainActivity.onCreate** 这个函数定义在packages/experimental/Activity/src/shy/luo/activity/MainActivity.java文件中，这是我们自定义的app工程文件： ~~~ public class MainActivity extends Activity implements OnClickListener { ...... @Override public void onCreate(Bundle savedInstanceState) { ...... Log.i(LOG_TAG, "Main Activity Created."); } ...... } ~~~ 这样，MainActivity就启动起来了，整个应用程序也启动起来了。 整个应用程序的启动过程要执行很多步骤，但是整体来看，主要分为以下五个阶段： * 一. Step1 - Step 11：Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity； * 二. Step 12 - Step 16：ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态； * 三. Step 17 - Step 24：Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行； * 四. Step 25 - Step 27：ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信； * 五. Step 28 - Step 35：ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。 这里不少地方涉及到了Binder进程间通信机制，相关资料请参考Android进程间通信（IPC）机制Binder简要介绍和学习计划一文。 这样，应用程序的启动过程就介绍完了，它实质上是启动应用程序的默认Activity，在下一篇文章中，我们将介绍在应用程序内部启动另一个Activity的过程，即新的Activity与启动它的Activity将会在同一个进程（Process）和任务（Task）运行，敬请关注。

原文出处——>[Android应用程序安装过程源代码分析](http://blog.csdn.net/luoshengyang/article/details/6766010) Android系统在启动的过程中，会启动一个应用程序管理服务PackageManagerService，这个服务负责扫描系统中特定的目录，找到里面的应用程序文件，即以Apk为后缀的文件，然后对这些文件进解析，得到应用程序的相关信息，完成应用程序的安装过程，本文将详细分析这个过程。 应用程序管理服务PackageManagerService安装应用程序的过程，其实就是解析析应用程序配置文件AndroidManifest.xml的过程，并从里面得到得到应用程序的相关信息，例如得到应用程序的组件Activity、Service、Broadcast Receiver和Content Provider等信息，有了这些信息后，通过ActivityManagerService这个服务，我们就可以在系统中正常地使用这些应用程序了。 应用程序管理服务PackageManagerService是系统启动的时候由SystemServer组件启动的，启后它就会执行应用程序安装的过程，因此，本文将从SystemServer启动PackageManagerService服务的过程开始分析系统中的应用程序安装的过程。 应用程序管理服务PackageManagerService从启动到安装应用程序的过程如下图所示：  下面我们具体分析每一个步骤。 **Step 1. SystemServer.main** 这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中： ~~~ public class SystemServer { ...... native public static void init1(String[] args); ...... public static void main(String[] args) { ...... init1(args); ...... } ...... } ~~~ SystemServer组件是由Zygote进程负责启动的，启动的时候就会调用它的main函数，这个函数主要调用了JNI方法init1来做一些系统初始化的工作。 **Step 2. SystemServer.init1** 这个函数是一个JNI方法，实现在 frameworks/base/services/jni/com_android_server_SystemServer.cpp文件中： ~~~ namespace android { extern "C" int system_init(); static void android_server_SystemServer_init1(JNIEnv* env, jobject clazz) { system_init(); } /* * JNI registration. */ static JNINativeMethod gMethods[] = { /* name, signature, funcPtr */ { "init1", "([Ljava/lang/String;)V", (void*) android_server_SystemServer_init1 }, }; int register_android_server_SystemServer(JNIEnv* env) { return jniRegisterNativeMethods(env, "com/android/server/SystemServer", gMethods, NELEM(gMethods)); } }; // namespace android ~~~ 这个函数很简单，只是调用了system_init函数来进一步执行操作。 **Step 3. libsystem_server.system_init** 函数system_init实现在libsystem_server库中，源代码位于frameworks/base/cmds/system_server/library/system_init.cpp文件中： ~~~ extern "C" status_t system_init() { LOGI("Entered system_init()"); sp proc(ProcessState::self()); sp sm = defaultServiceManager(); LOGI("ServiceManager: %p\n", sm.get()); sp grim = new GrimReaper(); sm->asBinder()->linkToDeath(grim, grim.get(), 0); char propBuf[PROPERTY_VALUE_MAX]; property_get("system_init.startsurfaceflinger", propBuf, "1"); if (strcmp(propBuf, "1") == 0) { // Start the SurfaceFlinger SurfaceFlinger::instantiate(); } // Start the sensor service SensorService::instantiate(); // On the simulator, audioflinger et al don't get started the // same way as on the device, and we need to start them here if (!proc->supportsProcesses()) { // Start the AudioFlinger AudioFlinger::instantiate(); // Start the media playback service MediaPlayerService::instantiate(); // Start the camera service CameraService::instantiate(); // Start the audio policy service AudioPolicyService::instantiate(); } // And now start the Android runtime. We have to do this bit // of nastiness because the Android runtime initialization requires // some of the core system services to already be started. // All other servers should just start the Android runtime at // the beginning of their processes's main(), before calling // the init function. LOGI("System server: starting Android runtime.\n"); AndroidRuntime* runtime = AndroidRuntime::getRuntime(); LOGI("System server: starting Android services.\n"); runtime->callStatic("com/android/server/SystemServer", "init2"); // If running in our own process, just go into the thread // pool. Otherwise, call the initialization finished // func to let this process continue its initilization. if (proc->supportsProcesses()) { LOGI("System server: entering thread pool.\n"); ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); LOGI("System server: exiting thread pool.\n"); } return NO_ERROR; } ~~~ 这个函数首先会初始化SurfaceFlinger、SensorService、AudioFlinger、MediaPlayerService、CameraService和AudioPolicyService这几个服务，然后就通过系统全局唯一的AndroidRuntime实例变量runtime的callStatic来调用SystemServer的init2函数了。关于这个AndroidRuntime实例变量runtime的相关资料，可能参考前面一篇文章Android应用程序进程启动过程的源代码分析一文。 **Step 4. AndroidRuntime.callStatic** 这个函数定义在frameworks/base/core/jni/AndroidRuntime.cpp文件中： ~~~ /* * Call a static Java Programming Language function that takes no arguments and returns void. */ status_t AndroidRuntime::callStatic(const char* className, const char* methodName) { JNIEnv* env; jclass clazz; jmethodID methodId; env = getJNIEnv(); if (env == NULL) return UNKNOWN_ERROR; clazz = findClass(env, className); if (clazz == NULL) { LOGE("ERROR: could not find class '%s'\n", className); return UNKNOWN_ERROR; } methodId = env->GetStaticMethodID(clazz, methodName, "()V"); if (methodId == NULL) { LOGE("ERROR: could not find method %s.%s\n", className, methodName); return UNKNOWN_ERROR; } env->CallStaticVoidMethod(clazz, methodId); return NO_ERROR; } ~~~ 这个函数调用由参数className指定的java类的静态成员函数，这个静态成员函数是由参数methodName指定的。上面传进来的参数className的值为"com/android/server/SystemServer"，而参数methodName的值为"init2"，因此，接下来就会调用SystemServer类的init2函数了。 **Step 5. SystemServer.init2** 这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中： ~~~ public class SystemServer { ...... public static final void init2() { Slog.i(TAG, "Entered the Android system server!"); Thread thr = new ServerThread(); thr.setName("android.server.ServerThread"); thr.start(); } } ~~~ 这个函数创建了一个ServerThread线程，PackageManagerService服务就是这个线程中启动的了。这里调用了ServerThread实例thr的start函数之后，下面就会执行这个实例的run函数了。 **Step 6. ServerThread.run** 这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中： ~~~ class ServerThread extends Thread { ...... @Override public void run() { ...... IPackageManager pm = null; ...... // Critical services... try { ...... Slog.i(TAG, "Package Manager"); pm = PackageManagerService.main(context, factoryTest != SystemServer.FACTORY_TEST_OFF); ...... } catch (RuntimeException e) { Slog.e("System", "Failure starting core service", e); } ...... } ...... } ~~~ 这个函数除了启动PackageManagerService服务之外，还启动了其它很多的服务，例如在前面学习Activity和Service的几篇文章中经常看到的ActivityManagerService服务，有兴趣的读者可以自己研究一下。 **Step 7. PackageManagerService.main** 这个函数定义在frameworks/base/services/java/com/android/server/PackageManagerService.java文件中： ~~~ class PackageManagerService extends IPackageManager.Stub { ...... public static final IPackageManager main(Context context, boolean factoryTest) { PackageManagerService m = new PackageManagerService(context, factoryTest); ServiceManager.addService("package", m); return m; } ...... } ~~~ 这个函数创建了一个PackageManagerService服务实例，然后把这个服务添加到ServiceManager中去，ServiceManager是Android系统Binder进程间通信机制的守护进程，负责管理系统中的Binder对象，具体可以参考浅谈Service Manager成为Android进程间通信（IPC）机制Binder守护进程之路一文。 在创建这个PackageManagerService服务实例时，会在PackageManagerService类的构造函数中开始执行安装应用程序的过程： ~~~ class PackageManagerService extends IPackageManager.Stub { ...... public PackageManagerService(Context context, boolean factoryTest) { ...... synchronized (mInstallLock) { synchronized (mPackages) { ...... File dataDir = Environment.getDataDirectory(); mAppDataDir = new File(dataDir, "data"); mSecureAppDataDir = new File(dataDir, "secure/data"); mDrmAppPrivateInstallDir = new File(dataDir, "app-private"); ...... mFrameworkDir = new File(Environment.getRootDirectory(), "framework"); mDalvikCacheDir = new File(dataDir, "dalvik-cache"); ...... // Find base frameworks (resource packages without code). mFrameworkInstallObserver = new AppDirObserver( mFrameworkDir.getPath(), OBSERVER_EVENTS, true); mFrameworkInstallObserver.startWatching(); scanDirLI(mFrameworkDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode | SCAN_NO_DEX, 0); // Collect all system packages. mSystemAppDir = new File(Environment.getRootDirectory(), "app"); mSystemInstallObserver = new AppDirObserver( mSystemAppDir.getPath(), OBSERVER_EVENTS, true); mSystemInstallObserver.startWatching(); scanDirLI(mSystemAppDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode, 0); // Collect all vendor packages. mVendorAppDir = new File("/vendor/app"); mVendorInstallObserver = new AppDirObserver( mVendorAppDir.getPath(), OBSERVER_EVENTS, true); mVendorInstallObserver.startWatching(); scanDirLI(mVendorAppDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode, 0); mAppInstallObserver = new AppDirObserver( mAppInstallDir.getPath(), OBSERVER_EVENTS, false); mAppInstallObserver.startWatching(); scanDirLI(mAppInstallDir, 0, scanMode, 0); mDrmAppInstallObserver = new AppDirObserver( mDrmAppPrivateInstallDir.getPath(), OBSERVER_EVENTS, false); mDrmAppInstallObserver.startWatching(); scanDirLI(mDrmAppPrivateInstallDir, PackageParser.PARSE_FORWARD_LOCK, scanMode, 0); ...... } } } ...... } ~~~ 这里会调用scanDirLI函数来扫描移动设备上的下面这五个目录中的Apk文件： * /system/framework * /system/app * /vendor/app * /data/app * /data/app-private **Step 8. PackageManagerService.scanDirLI** 这个函数定义在frameworks/base/services/java/com/android/server/PackageManagerService.java文件中： ~~~ class PackageManagerService extends IPackageManager.Stub { ...... private void scanDirLI(File dir, int flags, int scanMode, long currentTime) { String[] files = dir.list(); ...... int i; for (i=0; i outerDepth)) { if (type == parser.END_TAG || type == parser.TEXT) { continue; } String tagName = parser.getName(); if (tagName.equals("application")) { ...... if (!parseApplication(pkg, res, parser, attrs, flags, outError)) { return null; } } else if (tagName.equals("permission-group")) { ...... } else if (tagName.equals("permission")) { ...... } else if (tagName.equals("permission-tree")) { ...... } else if (tagName.equals("uses-permission")) { ...... } else if (tagName.equals("uses-configuration")) { ...... } else if (tagName.equals("uses-feature")) { ...... } else if (tagName.equals("uses-sdk")) { ...... } else if (tagName.equals("supports-screens")) { ...... } else if (tagName.equals("protected-broadcast")) { ...... } else if (tagName.equals("instrumentation")) { ...... } else if (tagName.equals("original-package")) { ...... } else if (tagName.equals("adopt-permissions")) { ...... } else if (tagName.equals("uses-gl-texture")) { ...... } else if (tagName.equals("compatible-screens")) { ...... } else if (tagName.equals("eat-comment")) { ...... } else if (RIGID_PARSER) { ...... } else { ...... } } ...... return pkg; } ...... } ~~~ 这里就是对AndroidManifest.xml文件中的各个标签进行解析了，各个标签的含义可以参考官方文档http://developer.android.com/guide/topics/manifest/manifest-intro.html， 这里我们只简单看一下application标签的解析，这是通过调用parseApplication函数来进行的。 **Step 11. PackageParser.parseApplication** 这个函数定义在frameworks/base/core/java/android/content/pm/PackageParser.java文件中： ~~~ public class PackageParser { ...... private boolean parseApplication(Package owner, Resources res, XmlPullParser parser, AttributeSet attrs, int flags, String[] outError) throws XmlPullParserException, IOException { final ApplicationInfo ai = owner.applicationInfo; final String pkgName = owner.applicationInfo.packageName; TypedArray sa = res.obtainAttributes(attrs, com.android.internal.R.styleable.AndroidManifestApplication); ...... int type; while ((type=parser.next()) != parser.END_DOCUMENT && (type != parser.END_TAG || parser.getDepth() > innerDepth)) { if (type == parser.END_TAG || type == parser.TEXT) { continue; } String tagName = parser.getName(); if (tagName.equals("activity")) { Activity a = parseActivity(owner, res, parser, attrs, flags, outError, false); ...... owner.activities.add(a); } else if (tagName.equals("receiver")) { Activity a = parseActivity(owner, res, parser, attrs, flags, outError, true); ...... owner.receivers.add(a); } else if (tagName.equals("service")) { Service s = parseService(owner, res, parser, attrs, flags, outError); ...... owner.services.add(s); } else if (tagName.equals("provider")) { Provider p = parseProvider(owner, res, parser, attrs, flags, outError); ...... owner.providers.add(p); } else if (tagName.equals("activity-alias")) { Activity a = parseActivityAlias(owner, res, parser, attrs, flags, outError); ...... owner.activities.add(a); } else if (parser.getName().equals("meta-data")) { ...... } else if (tagName.equals("uses-library")) { ...... } else if (tagName.equals("uses-package")) { ...... } else { ...... } } return true; } ...... } ~~~ 这里就是对AndroidManifest.xml文件中的application标签进行解析了，我们常用到的标签就有activity、service、receiver和provider，各个标签的含义可以参考官方文档http://developer.android.com/guide/topics/manifest/manifest-intro.html。 这里解析完成后，一层层返回到Step 9中，调用另一个版本的scanPackageLI函数把来解析后得到的应用程序信息保存下来。 **Step 12. PackageManagerService.scanPackageLI** 这个函数定义在frameworks/base/services/java/com/android/server/PackageManagerService.java文件中： ~~~ class PackageManagerService extends IPackageManager.Stub { ...... // Keys are String (package name), values are Package. This also serves // as the lock for the global state. Methods that must be called with // this lock held have the prefix "LP". final HashMap mPackages = new HashMap(); ...... // All available activities, for your resolving pleasure. final ActivityIntentResolver mActivities = new ActivityIntentResolver(); // All available receivers, for your resolving pleasure. final ActivityIntentResolver mReceivers = new ActivityIntentResolver(); // All available services, for your resolving pleasure. final ServiceIntentResolver mServices = new ServiceIntentResolver(); // Keys are String (provider class name), values are Provider. final HashMap mProvidersByComponent = new HashMap(); ...... private PackageParser.Package scanPackageLI(PackageParser.Package pkg, int parseFlags, int scanMode, long currentTime) { ...... synchronized (mPackages) { ...... // Add the new setting to mPackages mPackages.put(pkg.applicationInfo.packageName, pkg); ...... int N = pkg.providers.size(); int i; for (i=0; i ';