原文：http://blog.sina.com.cn/s/blog_4b1fbf210100l40z.html
参考：Talking about Android process
Android process
android启动时所运行的进程：
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 264 176 c00acc6c 0000c36c S /init
root 28 1 724 308 c0051354 afe0c4cc S /system/bin/sh
system 30 1 796 248 c026516c afe0b74c S /system/bin/servicemanager
root 31 1 1824 316 ffffffff afe0b50c S /system/bin/mountd
root 32 1 652 248 c02976e0 afe0c0bc S /system/bin/debuggerd
radio 33 1 5344 664 ffffffff afe0bdbc S /system/bin/rild
root 34 1 71028 18828 c00ad308 afe0b874 S zygote
media 37 1 16812 3456 ffffffff afe0b74c S /system/bin/mediaserver
root 39 1 788 288 c02f9ae4 afe0b50c S /system/bin/installd
system 86 34 187756 21836 ffffffff afe0b74c S system_server
radio 118 34 103476 13896 ffffffff afe0c824 S com.android.phone
app_4 124 34 117848 19248 ffffffff afe0c824 S android.process.acore
app_5 139 34 98672 11516 ffffffff afe0c824 S com.android.mms
app_3 151 34 92096 10976 ffffffff afe0c824 S com.android.alarmclock
app_6 161 34 94436 12616 ffffffff afe0c824 S com.android.calendar
app_9 173 34 93248 11728 ffffffff afe0c824 S android.process.media
app_15 182 34 91848 9764 ffffffff afe0c824 S com.android.voicedialer
app_16 190 34 94524 10812 ffffffff afe0c824 S android.process.im
这些进程又被划分为3类：
1 Root Process
2 Native Application Process
3 JAVA Application Process
-------------------------------------
1 Root Process
它是在内核启动以后，最先运行的进程，它的主要任务：
◎解析和执行 init.rc 和 init.%hardware%.rc
◎自动在 /dev 下产生设备节点
◎开启log和property service
◎监视设备，property设置和子进程退出事件。
2 Native Application Process
根据init.rc，初始化过程将产生本地应用程序进程分支。
◎console : 开启 shell.
◎servicemanager : 开启绑定 IPC 服务管理.
◎mountd : 挂载所有的定义在/system/etc/mountd.conf 的fs,从本地的socket接收commands去挂载所有的fs。
◎debuggerd : 开启 debug 系统.
◎rild : 开启radio interface layer daemon.
◎zygote : 开启Android Java VM Runtime 并开启system server. 这是最重要的进程.
◎mediaserver : 开启 AudioFlinger, MediaPlayerService和CameraService.
◎installd : 开始安装 package daemon.
3 JAVA Application Process
java应用程序进程是zygote进程的分支，system_server 是一个特殊的java进程，他直接就是zygote的分支。
其它的java进程由ActivityManagerService(run in system_server process)创建。
如：
int pid = Process.start("android.app.ActivityThread", mSimpleProcessManagement ? app.processName : null, uid, uid, gids, ((app.info.flags&ApplicationInfo.FLAG_DEBUGGABLE) != 0), null);
Process.java用UNIX的socket和zygote联系。
全局图如下：
◎System Server
它是zygote运行的第一个java程序，他开启了android的核心服务，如ActivityManager, WindowManager, PackageManager 等。
它是android的核心引擎。
◎Persistent Application
在启动过程中，ActivityManagerService.systemReady 将开始所有的持久稳固的应用程序(persistent applications)。
List apps = ActivityThread.getPackageManager(). getPersistentApplication(PackageManager.GET_SHARED_LIBRARY_FILES);
if (apps != null) {
int N = apps.size();
int i;
for (i=0; i<N; i++) {
ApplicationInfo info = (ApplicationInfo)apps.get(i);
if (info != null && !info.packageName.equals("android")) {
addAppLocked(info);
}
}
}
而此时，只有phone应用程序在AndroidManifest.xml 中以persistent app的形式注册过。
<application android:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
所以在启动过程中，只有phone应用程序是自动执行的。即“com.android.phone”进程。
◎The First Activity
第一个activity的执行是由ActivityManagerService送来的Intent.CATEGORY_HOME 意图所引起的。
Intent intent = new Intent( mTopAction, mTopData != null ? Uri.parse(mTopData) : null);
intent.setComponent(mTopComponent);
if (mFactoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL) {
intent.addCategory(Intent.CATEGORY_HOME );
}
ActivityInfo aInfo = intent.resolveActivityInfo(mContext.getPackageManager(), PackageManager.GET_SHARED_LIBRARY_FILES);
if (aInfo != null) {
intent.setComponent(new ComponentName( aInfo.applicationInfo.packageName, aInfo.name));
// Don't do this if the home app is currently being instrumented.
ProcessRecord app = getProcessRecordLocked(aInfo.processName,
aInfo.applicationInfo.uid);
if (app == null || app.instrumentationClass == null) {
intent.setFlags(intent.getFlags() | Intent.FLAG_ACTIVITY_NEW_TASK);
startActivityLocked(null, intent, null, null, 0, aInfo,
null, null, 0, 0, 0, false);
}
}
它是“android.process.acore”进程。进程名是在AndroidManifest.xml中定义的。
◎Auto-launched Application After Booting
当activity idle (Idle()功能该函数在用户每次活动（例如，按键盘、移动鼠标等）后重置定时器，n秒后触发应用对象的Idle事件。)
被ActivityManagerService检测到，它立即broadcast ACTION_BOOT_COMPLETED 意图。
if (mFactoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL) {
// Tell anyone interested that we are done booting!
synchronized (this) {
broadcastIntentLocked(null, null,
new Intent(Intent.ACTION_BOOT_COMPLETED , null),
null, null, 0, null, null,
android.Manifest.permission.RECEIVE_BOOT_COMPLETED,
false, false, MY_PID, Process.SYSTEM_UID);
}
}
此时，MMS, AlarmClock, Calendar, MediaProvider, VoiceDialer 和 IM 已经作为ACTION_BOOT_COMPLETED意图的接受者在AndroidManifest.xml中注册过了。所以他们将被自动激发执行。
Email 也是作为ACTION_BOOT_COMPLETED 意图的接受者在AndroidManifest.xml注册了, 但它定义了android:enable=”false”. 所以它不会被自动激发执行。
<receiver android:name=".service.BootReceiver" android:enabled="false" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.DEVICE_STORAGE_LOW" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.DEVICE_STORAGE_OK" />
</intent-filter>
</receiver>
DownloadProvider同Email，它定义了android:exported=”false”所以也不会被自动执行。
<receiver android:name=".DownloadReceiver" android:exported="false" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
</receiver>
◎Behind the JAVA process
system_server是一个特殊情况，它呼叫ActivityThread.java 的systemMain静态函数，这个静态函数创建了一个ActivityThread. ActivityThread的实例，继而创建ApplicationThread， Application 和 ApplicationContext的实例。
每个其他的java进程都以不同的方式工作，它们受system_server 的控制，system_server 又是zygote的分支。所有是zygote分支的的java进程除了system_server，都会自动的呼叫ActivityThread.java 的main静态函数。
try {
ZygoteInit.invokeStaticMain(cloader, className, mainArgs);
} catch (RuntimeException ex) {
logAndPrintError (newStderr, "Error starting. ", ex);
}
ActivityThread.java的main静态函数创建了一个ActivityThread实例。ActivityThread然后创建了一个ApplicationThread的实例。ApplicationThread将以IBinder对象的形式工作，并和system_server中的ActivityManagerService相互作用。新的进程此时其它的事不做，专门等待system_server过来的IPC的呼叫。 Application 和 ApplicationContext 的对象此时也不会创建。事实上它会推迟到当进程真正工作的时候，如开始一个activity，接受intent或者开始一个service时才创建。
例如：当开始一个activity时，ActivityManagerService知道activity需要在哪个进程中执行，然后他将RPC呼叫ApplicationThread的scheduleLaunchActivity，并在那个进程中执行这个新的activity。然后ApplicationThreadpost一个消息，让ActivityThread知道它需要启动一个activity。ActivityThread然后创建Application 和 ApplicationContext 对象.再然后，他呼叫Instrumentation。最后Instrumentation呼叫JAVA dalvik VM 去准备创建一个activity java对象。
