大家知道，当Android系统启动时候，会解析init.rc文件，然后根据里面的定义，启动各种服务，如netd、zygote、servier_manager等等，但这些服务之间其实是有依赖关系的，而且当其中的某个服务启动失败时，有时候会影响后续的服务启动。这篇文章就具体的分析一下开机服务的启动顺序。
服务的分类
init.rc中对服务做了分类，在service section里面有一个’class’标签，指明了该服务所属的类。如：
service surfaceflinger /system/bin/surfaceflinger
class core //所属类为‘core’
user system
group graphics drmrpc
onrestart restart zygote
service media /system/bin/mediaserver
class main //所属类为‘main’
user media
group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm system
ioprio rt 4
init.rc中总共有三个分类：core、main和late_start，下面整理了各分类下属的服务：
core
ueventd、logd、healthd、adbd（disabled）、lmkd（LowMemoryKiller）、servicemanager、vold、debuggerd、surfaceflinger、bootanim（disabled）等
core分类中的服务都是一些核心服务，它们不启动，后续的服务或系统启动就可能出问题。比如servicemanager，binder通信大管家，它的启动很靠前，因为，其他服务启动时候需要向servicemanager注册binder服务。vold，负责存储类设备的挂载；还有surfaceflinger，图形显示的核心服务等。
main
debuggerd64、drm、media、ril-daemon、installd、flash_recovery、racoon（disabled）、mtpd（disabled）、keystore、dumpstate（disabled）、mdnsd（disabled）、pre-recovery（disabled）、cmd_services（disabled）、phasecheckserver、zygote等。
main分类中的服务是一些系统的基本服务，有了这些服务android系统、Java世界才能正常运行。
late_start
字面意思是晚些启动。/device/中一些硬件厂商的.rc文件中会将一些服务设置为该类。
上面服务后面加”（disabled）”，代表init进程在初始化阶段不会启动该服务。该服务的启动是由其他的因素触发而启动的，比如：
on property:persist.sys.cmdservice.enable=enable
start cmd_services
表示当属性persist.sys.cmdservice.enable的值设置为enable时，会触发该action，执行下面的命令。由于命令是start，所以init进程会启动cmd_services。
除了“disabled”的服务，上面的顺序基本上就是服务的开机启动顺序，即先启动core服务，然后启动main服务，最后启动late_start类别的服务。注意，相同类别的服务，基本上是同时启动，相互之间的延时很小。
服务的启动
首先看一下，init.c–>main()源码：
int main(int argc, char **argv)
{
...
action_for_each_trigger("early-init", action_add_queue_tail);
...
action_for_each_trigger("init", action_add_queue_tail);
...
action_for_each_trigger("late-init", action_add_queue_tail);
...
for(;;) {
...
execute_one_command();
...
}
}
可以看到，依次将early-init、init、late-init三个section对应的命令插入到操作队列中。
然后在后面的for循环中，调用execute_one_command依次执行操作队列中的命令。
前面说了core类别的服务有很多，那这些服务的启动顺序怎么定义的呢？init进程在解析init.rc（init.rc中还import了其他的rc文件，解析完init.rc后，依次解析其他的rc文件）文件时，是从上到下依次解析，并存放在一个全局链表中的。服务的启动顺序就是该服务在全局链表中的位置。所以在rc文件中定义靠前的服务也会在全局链表的靠前位置，也就会先执行。
core类别的服务启动完了，那main类别的服务什么时候启动呢？
init.rc中对启动main类别服务的定义如下：
on nonencrypted
class_start main
class_start late_start
on property:vold.decrypt=trigger_restart_min_framework
class_start main
on property:vold.decrypt=trigger_restart_framework
class_start main
class_start late_start
可见，有以上三种方式，会触发启动main类别的服务。通过名字可以看出，都和系统是否加密有关。
这里，我们分析一下nonencrypted。前面提到，在“late-init”section中会触发“fs”section。
on late-init
... trigger fs
...//这个section一般在init.${ro.hardware}.rc中定义
on fs
... mount_all fstab
...
在“fs”section中会执行mount_all fstab命令。fstab是Android下比较重要的配置文件，它包含了系统在启动时挂载文件系统和存储设备的详细信息。对应的处理函数为：
int do_mount_all(int nargs, char **args)
{
...
pid = fork();
if (pid > 0) {
// 父进程，等待子进程的处理返回结果
int wp_ret = TEMP_FAILURE_RETRY(waitpid(pid, &status, 0));
if (WIFEXITED(status)) {
ret = WEXITSTATUS(status);
} else {
ret = -1;
}
} else if (pid == 0) {
// 子进程，进一步调用fs_mgr_mount_all()
fstab = fs_mgr_read_fstab(args[1]);
child_ret = fs_mgr_mount_all(fstab);
...
_exit(child_ret);
} else {
...
}
if (ret == FS_MGR_MNTALL_DEV_NEEDS_ENCRYPTION) {
...
} else if (ret == FS_MGR_MNTALL_DEV_MIGHT_BE_ENCRYPTED) {
...
} else if (ret == FS_MGR_MNTALL_DEV_NOT_ENCRYPTED) {
...
// 这里就将"nonencrypted"中的操作加入到操作队列中
action_for_each_trigger("nonencrypted", action_add_queue_tail);
} else if (ret == FS_MGR_MNTALL_DEV_NEEDS_RECOVERY) {
...
}
...
}
这里注意：如果调用fs_mgr_mount_all()返回结果不是FS_MGR_MNTALL_DEV_NOT_ENCRYPTED，就不会执行action_for_each_trigger(“nonencrypted”, action_add_queue_tail);这样main类别的服务就不会执行，系统就会无法正常启动。
总结
本文简单介绍了系统启动阶段各服务的启动顺序，实际过程会复杂很多。有时间的话，会进一步补充。