整个Android系统的启动分为Linux Kernel的启动和Android系统的启动。Linux Kernel启动起来后，然后运行第一个用户程序，在Android中就是init程序。
-------------------------------------------------
以下的内容应该算是学习笔记，特地整理成文。
-------------------------------------------------
1 init程序
init是linux系统中用户空间的第一个进程。由于Android是基于linux内核的，所以init也是Android系统中用户空间的第一个进程，它的进程号是1。init程序并不是由一个源文件组成的，而是由一组源代码文件的目标文件链接而成，这些文件位于如下目录：
<android source code directory>/system/core/init/
它的主要职责在于：
1)、挂载目录，比如/sys, /dev, /proc
mkdir("/dev", 0755); mkdir("/proc", 0755); mkdir("/sys", 0755); ......
2)、初始化属性，提供property service(属性服务)管理Android系统中的属性
3)、处理配置文件命令（主要是init.rc脚本文件）
4)、性能分析和执行其它进程
2.1 init分析
init进程的入口函数是main，主要做了这些工作：
1)、解析配置文件，主要是系统配置文件init.rc和与硬件平台相关的配置文件（如init.xxx.rc），在此阶段，也会解析service。
init.rc文件包含五个类型的声明：
- Actions（动作以命令流程命名，有一个触发器决定动作是否发生）
-
on <trigger> <command> <command>
- Commands
-
class_start <serviceclass> Start all services of the specified class if they are not already running
- Services（是init进程启动的程序，以及当服务退出时init进程会视情况重启服务）
- Options（选项是对服务的描述，它们影响init进程如何以及何时启动服务）
-
service <name> <pathname> [ <argument> ]* <option> <option>
- Imports
-
import <path> Parse an init config file, extending the current configuration.
| Action | Service | 描述 |
| on | early-init | 设置init进程以及它创建的子进程的优先级，设置init进程的安全环境 |
| on | init | 设置全局环境，为cpu accounting创建cgroup(资源控制)挂载点 |
| on | fs | 挂载mtd分区 |
| on | post-fs | 改变系统目录的访问权限 |
| on | post-fs-data | 改变/data目录以及它的子目录的访问权限 |
| on | boot | 基本网络的初始化，内存管理等等 |
| service | servicemanager | 启动系统管理器管理所有的本地服务，比如位置、音频、Shared preference等等 |
| service | zygote | 启动zygote作为应用进程 |
2)、执行各个阶段的动作，创建zygote的工作就是在其中某个阶段完成。
3)、调用property_init初始化属性相关的资源，并且通过property_start_service启动属性服务。
4)、init进入一个无限循环，然后等待响应。
2.2 属性服务
应用程序可以通过这个属性机制，查询或设置属性。这个属性服务是怎么实现的呢？其中与init.c和属性服务有关的代码：
property_init();
property_set_fd = start_property_service();
2.2.1 属性服务初始化
首先创建存储空间，property_service.c中有property_init函数
void property_init(void){ init_property_area(); // 初始化属性存储区域 // 加载default.prop文件 load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT); }
虽然属性区域是由init进程创建的，但Android系统希望其它进程也能读取这块内存里的东西。为了做到这一点，它做了以下的工作：
1)、把属性区域创建在共享内存上，而共享内存是可以跨进程的。
2)、Android利用gcc的constructor属性，指明了一个__libc_prenit函数，当bionic libc库被加载时，将自动调用这个__libc_preni，这个函数内部就将完成共享内存到本地进程的映射工作。这样一来，其它进程就知道了这个共享内存。
接着，客户端进程获取存储空间。
2.2.2 属性服务器的分析
2.2.2.1 启动属性服务器
init进程会启动一个属性服务器，而客户端只能通过与属性服务器交互来设置属性。
2.2.2.2 处理设置属性请求
接受请求的地方在init进程中，当属性服务器收到客户端请求时，init会调用handle_property_set_fd进行处理。
if(ufds[1].revents == POLLIN){ handle_property_set_fd(property_set_fd); }
当客户端的权限满足要求时，init就调用property_set进行相关处理。
if(check_perms(msg.name, cr.uid, cr.gid)){ property_set((char *) msg.name, (char *) msg.value); }
2.2.2.3 客户端发送请求
客户端通过property_set发送请求，property_set由libcutils库提供。
int property_set(const chatr *key, const char *value){ prop_msg msg; unsigned resp; // other code ...... msg.cmd = PROP_MSG_SETPROP; // 设置消息码 strcpy((char *) msg.name, key); strcpy((char *) msg.value, value); // 发送请求 return send_prop_msg(&msg); }
static int send_prop_msg(prop_msg *msg){ int s; int r; // 建立和属性服务器的socket链接 s = socket_local_client(PROP_SERVICE_NAME, ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM); if(s < 0){ return -1; } // 通过socket发送 while((r = send(s, msg, sizeof(prop_msg), 0)) < 0){ if((errno == EINTR) || (errno == EAGAIN)){ continue; } break; } if(r == sizeof(prop_msg)){ r = 0; } else { r = -1; } close(s); return r; }
2 zygote分析
zygote本身是一个Native的应用程序，与驱动、内核等无关。它是由init进程根据init.rc文件中的配置创建的。zygote最初的名字叫“app_process”，这个名字是在Android.mk文件中指定的。在运行中，app_process通过linux下的pctrl系统调用将自己的名字换成了zygote。
在Java中，我们知道不同的虚拟机实例会为不同的应用分配不同的内存。假如Android应用应该尽可能快地启动，但如果Android系统为每一个应用启动不同的Dalvik虚拟机实例，就会消耗大量的内存以及时间。因此，为了克服这个问题，Android系统创造了”zygote”。zygote让Dalvik虚拟机共享代码、低内存占用以及最小的启动时间成为可能。
zygote进程由init通过fork而来，在init.rc中设置的启动参数如下：
-Xzygote /system/bin --zygote --start-system-server
zygote的原型app_process对应的源文件是App_main.cpp。
int main(int argc, const char* const argv[]){ ...... AppRuntime runtime; ...... int i = runtime.addVmArguments(argc, argv); if(i < argc){ runtime.mParentDir = argv[i++]; } if(i < argc){ arg = argv[i++]; if(0 == strcmp("--zygote", arg)){ bool startSystemServer = (i < argc) ? strcmp(argv[i], "--start-system-server") == 0: false; setArgv0(argv0, "zygote"); set_process_name("zygote"); // 设置进程名 runtime.start("com.android.internal.os.ZygoteInit", startSystemServer); } ...... } ...... }
2.1 AppRuntime分析
AppRuntime从AndroidRuntime类派生，它的声明和实现在App_main.cpp中。AppRuntime重载了onStarted, onZygoteInit和onExit函数。其中AndroidRuntime::start(const char* className, const bool startSystemServer)函数做了几件事情：
2.1.1 创建虚拟机--startVm
int AndroidRuntime::startVm(JavaVm** pJavaVM, JNIEnv** pEnv){ // JNI check是指Native层调用JNI函数时，系统所做的一些检查工作。例如，调用NewUTFString函数时，系统会检查传入的字符串是不是符合UTF-8的要求。 property_get("dalvik.vm.checkjni", propBuf, ""); ...... // 设置虚拟机的heapsize，默认为16MB strcpy(heapsizeOptsBuf, "-Xmx"); property_get("dalvik.vm.heapsize", heapsizeOptsBuf + 4, "16m"); ...... if(checkJni){ opt.optionsString = "-Xcheck:jni"; mOptions.add(opt); // JNI check中的资源检查，系统中创建的Global Reference个数不能超过2000 opt.optionString = "-Xjnigreflimit:2000"; mOptions.add(opt); } // 调用JNI_CreateJavaVM创建虚拟机，pEnv返回当前线程的JNIEnv变量 if(JNI_CreateJavaVM(pJavaVM, pEnv, &initArgs) < 0){ goto bail; } return 0; bail: free(stackTraceFile); return result; }
2.1.2 注册JNI函数--startReg
int AndroidRuntime::startReg(JNIEnv* env){ ...... if(register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0){ env->PopLocalFrame(NULL); return -1; } env->PopLocalFrame(NULL); return 0; }
static int register_jni_procs(const RegJNIRec array[], size_t count, JNIEnv* env){ for(size_t i = 0; i < count; i++){ if(array[i].mProc(env) < 0){ return -1; } } return 0; }
statci const RegJNIRec gRegJNI[] = { REG_JNI(register_android_debug_JNITest), REG_JNI(register_com_android_internal_os_RuntimeInit), REG_JNI(register_android_os_SystemClock), ...... }
上面的mProc就是为Java类注册JNI函数。
2.1.3 通过JNI调用Java函数，进入Java世界
env->CallStaticVoidMethod(startClass, startMeth, strArray);
CallStaticVoidMethod最终将调用com.android.internal.os.ZygoteInit的main函数。
public static void main(String argv[]){ try{ SamplingProfilerIntegration.start(); // 1. 注册zygote用的socket. 基于AF_UNIX类型，是一个本机socket registerZygoteSocket(); // 2. 预加载类和资源 preloadClasses(); preloadResources(); ...... // 强制执行一次垃圾回收 gc(); if(argv[1].equals("true")){ startSystemServer(); // 3. 启动system_server进程。该进程是framework的核心。 } else if(!argv[1].equals("false")){ throw new RuntimeException(argv[0] + USAGE_STRING); } if(ZYGOTE_FORK_MODE){ runForkMode(); } else { runSelectLoopMode(); // 4. zygote调用这个函数，进入等待唤醒的状态 } closeServerSocket(); } catch(MethodAndArgsCaller caller){ caller.run(); } catch(RuntimeException ex){ closeServerSocket(); throw ex; } ...... }
3 SystemServer分析
SystemServer是由Zygote通过Zygote.forkSystemServer函数fork出来的。
pid = Zygote.forkSystemServer(); if(pid == 0){ // 子进程返回0，即systemServer handleSystemServerProcess(parseArgs); }
在handleSystemServerProcess函数中，首先会关闭从Zygote继承下来的socket，并设置SystemServer进程的一些参数，然后调用RuntimeInit.java中的ZygoteInit函数。
public static final void zygoteInit(String[] argv) throws ZygoteInit.MethodAndArgsCaller { commonInit(); // native层的初始化 zygoteInitNative(); ...... invokeStaticMain(startClass, startArgs); // 调用com.android.server.SystemServer类的main函数 }
SystemServer调用了zygoteInitNative后，将与Binder通信系统建立联系，这样SystemServer就可以使用Binder了。zygoteInitNative中调用了onZygoteInit()
virtual void onZygoteInit(){ sp<ProcessState> proc = ProcessState::self(); if(proc->supportsProcesses()){ proc->startThreadPool(); // 启动一个线程，用于Binder通信 } }
而另外一个关键函数invokeStaticMain
private static void invokeStaticMain(String className, String[] argv) throws ZygoteInit.MethodAndArgsCaller { // 参数传入，className = "com.android.server.SystemServer" ...... Method m; try{ m = cl.getMethod("main", new Class[] { String[].class }); // 找到com.android.server.SystemServer类的main函数 } catch(NoSuchMethodException ex){ ...... } catch(SecurityException ex){ ...... } ...... throw new ZygoteInit.MethodAndArgsCaller(m, argv); // 主动抛出一个异常 }
抛出的异常在哪里被捕获呢？上面已经给出过了。也就是在ZygoteInit.java中
...... catch(MethodAndArgsCaller caller){ caller.run(); // 调用caller的run函数 }
而MethodAndArgsCaller的run函数如下：
public void run(){ try{ mMethod.invoke(null, new Object[] { mArgs }); // mMethod为com.android.server.SystemServer的main函数 } catch(IllegalAccessException ex){ ...... } }
为什么要主动抛出这样一个异常来执行main函数呢？
《深入理解Android 卷I》中是这样解释的：这个调用是在ZygoteInit.main中，相当于Native的main函数，也即入口函数，位于堆栈的顶层。如果不采用抛异常的方式，而是在invokeStaticMain那调用，则会浪费之前函数调用所占用的一些调用堆栈。
那么，这个main函数又做了什么工作呢？
public static void main(String[] args){ System.loadLibrary("android_servers"); // 加载libandroid_servers.so init1(args); // 调用native的init1函数 }
其中init1函数创建了一些系统服务，然后把调用线程加入到Binder通信中。期间还通过JNI调用了com.android.server.SystemServer类的init2函数，通过单独创建一个线程，用以启动系统的各项服务，如PowerManagerService, BatteryService, WindowManagerService, ActivityManagerService等。
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，它的override的run方法在SystemServer.java中，主要做了以下一些工作：
private void run() { ...... // Initialize native services. System.loadLibrary("android_servers"); ...... // Initialize the system context. createSystemContext(); ...... startCoreServices(); startOtherServices(); ...... }
/** * Starts some essential services that are not tangled up in the bootstrap process. */ private void startCoreServices() { // Tracks the battery level. Requires LightService. mSystemServiceManager.startService(BatteryService.class); // Tracks application usage stats. mSystemServiceManager.startService(UsageStatsService.class); mActivityManagerService.setUsageStatsManager( LocalServices.getService(UsageStatsManagerInternal.class)); // Update after UsageStatsService is available, needed before performBootDexOpt. mPackageManagerService.getUsageStatsIfNoPackageUsageInfo(); // Tracks whether the updatable WebView is in a ready state and watches for update installs. mSystemServiceManager.startService(WebViewUpdateService.class); }
/** * Starts a miscellaneous grab bag of stuff that has yet to be refactored * and organized. */ private void startOtherServices() { ...... try { Slog.i(TAG, "Reading configuration..."); SystemConfig.getInstance(); traceBeginAndSlog("StartSchedulingPolicyService"); ServiceManager.addService("scheduling_policy", new SchedulingPolicyService()); Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER); mSystemServiceManager.startService(TelecomLoaderService.class); traceBeginAndSlog("StartTelephonyRegistry"); telephonyRegistry = new TelephonyRegistry(context); ServiceManager.addService("telephony.registry", telephonyRegistry); Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
...... } ...... }
至此，让我们总结一下SystemServer
1)、ZygoteInit调用startSystemServer创建system_server进程。
2)、SystemServer调用handleSystemServerProcess完成自己的使命。
3)、handleSystemServerProcess抛出异常，最终调用com.android.server.SystemServer的main函数。
4)、main函数加载libandroid_server.so并调用native的init1函数。
5)、init1函数通过JNI调用com.android.server.SystemServer类的init2函数。init2函数创建一个线程，用于加载各种service。
6)、init1函数最终加入到Binder通信系统。
4 Zygote的分裂
zygote分裂出system_server后，就等待runSelectLoopMode等待并处理来自客户的请求。那么，谁会向zygote发送消息呢？这里以一个activity的启动为例作分析。
4.1 ActivityManagerService发送请求
ActivityManagerService由SystemServer创建。假设通过startActivity来启动一个新的acitivity，而这个activity属于一个还未启动的进程，那么这个进程又如何启动呢？先看ActivityManagerService中的startProcessLocked函数
private final void startProcessLocked(ProcessRecord app, String hostingType, String hostingNameStr){ ...... int pid = Process.start("android.app.ActivityThread", mSimpleProcessManagement ? app.processName : null, uid, uid, gids, debugFlags, null); ...... }
Process.start位于android.os.Process中，而它又调用了startViaZygote, zygoteSendArgsAndGetPid。而在zygoteSendArgsAndGetPid中，首先打开了和zygote通信的socket，接着把请求的参数发到zygote，然后读取zygote处理完的结果，得知是某个进程的pid。
由于ActivityManagerService驻留于SystemServer进程中，所以正是SystemServer向Zygote发送了消息。
还记得前面提过的runSelectLoopMode函数么？它在里面又调用了ZygoteConnection的runOnce
boolean runOnce() throws ZygoteInit.MethodAndArgsCaller { try{ args = readArgumentList(); // 读取SystemServer发送过来的参数 descriptors = mSocket.getAncillaryFileDescriptors(); } ...... pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids, parsedArgs.debugFlags, rlimits); ...... if(pid ==0){ handleClientProc(parsedArgs, descriptors, newStderr); //子进程处理 return true; } else { return handleParentProc(pid, descriptors, parsedArgs); } }
由此可见，zygote分裂子进程后，自己将在handleParentProc中做一些扫尾工作，然后继续等待请求进行下一次分裂。
4.2 zygote响应请求的流程
1)、Zygote进程调用runSelectLoopMode
2)、SystemServer进程发送消息到Zygote
3)、Zygote通过fork创建子进程
4)、子进程调用android.app.ActivityThread的main函数
5 Home界面启动
待Application Framework层的ActivityManagerService准备就绪后，就会通知各个模块，继续执行上层应用。
先附一张体系结构图：
// We now tell the activity manager it is okay to run third party // code. It will call back into us once it has gotten to the state // where third party code can really run (but before it has actually // started launching the initial applications), for us to complete our // initialization. mActivityManagerService.systemReady(new Runnable() { @Override public void run() { Slog.i(TAG, "Making services ready"); ...... try { mActivityManagerService.startObservingNativeCrashes(); } catch (Throwable e) { reportWtf("observing native crashes", e); } ...... try { if (networkScoreF != null) networkScoreF.systemReady(); } catch (Throwable e) { reportWtf("making Network Score Service ready", e); } ...... try { if (networkManagementF != null) networkManagementF.systemReady(); } catch (Throwable e) { reportWtf("making Network Managment Service ready", e); } ...... try { if (networkStatsF != null) networkStatsF.systemReady(); } catch (Throwable e) { reportWtf("making Network Stats Service ready", e); } ...... try { if (networkPolicyF != null) networkPolicyF.systemReady(); } catch (Throwable e) { reportWtf("making Network Policy Service ready", e); } ...... try { if (connectivityF != null) connectivityF.systemReady(); } catch (Throwable e) { reportWtf("making Connectivity Service ready", e); } ...... try { if (audioServiceF != null) audioServiceF.systemReady(); } catch (Throwable e) { reportWtf("Notifying AudioService running", e); } ...... } });
public void systemReady(final Runnable goingCallback) { ...... // Start up initial activity. mBooting = true; startHomeActivityLocked(mCurrentUserId, "systemReady"); ...... }
这样一来，就启动了Home界面，完成了整个Android启动流程。
下面是启动流程图：
参考：
《深入理解Android 卷I》 邓凡平 著