分析基于28的源码，涉及源码：
system/core/init/ - init.cpp - init_parser.cpp - signal_handler.cppinit进程是Linux系统中用户空间的第一个进程，进程号固定为1。Kernel启动后，在用户空间启动init进程，并调用init中的main()方法执行init进程的职责。对于init进程的功能分为4部分：
1.解析并运行所有的init.rc相关文件 2.根据rc文件，生成相应的设备驱动节点 3.处理子进程的终止(signal方式) 4.提供属性服务的功能
接下来从main()方法说起。
看的LoadBootScripts方法内，逻辑就是去解析init.rc文件
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) { Parser parser = CreateParser(action_manager, service_list); std::string bootscript = GetProperty("ro.boot.init_rc", ""); if (bootscript.empty()) { parser.ParseConfig("/init.rc"); if (!parser.ParseConfig("/system/etc/init")) { late_import_paths.emplace_back("/system/etc/init"); } if (!parser.ParseConfig("/product/etc/init")) { late_import_paths.emplace_back("/product/etc/init"); } if (!parser.ParseConfig("/odm/etc/init")) { late_import_paths.emplace_back("/odm/etc/init"); } if (!parser.ParseConfig("/vendor/etc/init")) { late_import_paths.emplace_back("/vendor/etc/init"); } } else { parser.ParseConfig(bootscript); } }函数解释： 1.umask(0) 其实这个函数的作用，就是设置允许当前进程创建文件或者目录最大可操作的权限，比如这里设置为0，它的意思就是0取反再创建文件时权限相与，也就是：(~0) & mode 等于八进制的值0777 & mode了，这样就是给后面的代码调用函数mkdir给出最大的权限，避免了创建目录或文件的权限不确定性。
2.strcmp strcmp() 用来比较字符串（区分大小写），其原型为： int strcmp(const char *s1, const char *s2);
【返回值】若参数s1 和s2 字符串相同则返回0。s1 若大于s2 则返回大于0 的值。s1 若小于s2 则返回小于0 的值。
3.setenv Linux setenv命令用于查询或显示环境变量。
4.mount Linux mount命令是经常会使用到的命令，它用于挂载Linux系统外的文件。
5.mkdir 建立一个目录
6.emplace_back emplace， 比如如果你想要向 std::vector 的末尾添加一个数据，你可以：
std::vector<int> nums; nums.push_back(1)你也可以使用：
std::vector<int> nums; nums.empace_back(1);emplace 最大的作用是避免产生不必要的临时变量
log.cpp
void InitKernelLogging(char* argv[]) { // Make stdin/stdout/stderr all point to /dev/null. int fd = open("/sys/fs/selinux/null", O_RDWR); if (fd == -1) { int saved_errno = errno; android::base::InitLogging(argv, &android::base::KernelLogger, InitAborter); errno = saved_errno; PLOG(FATAL) << "Couldn't open /sys/fs/selinux/null"; } dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); if (fd > 2) close(fd); android::base::InitLogging(argv, &android::base::KernelLogger, InitAborter); }上述代码将stdin、stdout、stderr全部重定向到/sys/fs/selinux/null(黑洞)中了，下面我们继续分析InitLogging函数
logging.cpp部分源码
void InitLogging(char* argv[], LogFunction&& logger, AbortFunction&& aborter) { SetLogger(std::forward<LogFunction>(logger)); SetAborter(std::forward<AbortFunction>(aborter)); ...... } void SetLogger(LogFunction&& logger) { std::lock_guard<std::mutex> lock(LoggingLock()); Logger() = std::move(logger); } void SetAborter(AbortFunction&& aborter) { std::lock_guard<std::mutex> lock(LoggingLock()); Aborter() = std::move(aborter); }现在我们来分析init进程很重要的一个功能属性服务 system/core/init/init.cpp
...... property_init();//初始化属性服务 ......在Android系统中，所有的进程共享系统设置值，为此提供一个名称为属性的保存空间。init进程调用property_init函数，在共享内存区域中创建并初始化属性域。而后通过执行进程所提供的API访问属性域中的设置值。但更改属性域时，要预先向init进程提交值变更申请，然后init进程处理该申请，并修改属性值（用propert_set()和property_get()来处理）
...... epoll_fd = epoll_create1(EPOLL_CLOEXEC);//创建轮询的描述符 ...... start_property_service();//开启属性服务 ......epoll_create1用来创建轮询监听子进程终止和属性变更请求的文件描述符，后面会看到监听子进程终止套接字fd和属性变更请求套接字fd通过epoll_ctl注册到epoll_fd中，然后通过epoll_wait监听轮询这两个fd。
start_property_service()开启属性服务
void start_property_service() { ...... //创建用于接收属性变更请求的socket (/dev/socket/property_service) property_set_fd = CreateSocket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,false, 0666, 0, 0, nullptr); ...... listen(property_set_fd, 8);//同时可以监听八个请求 //注册property_set_fd到epoll_fd register_epoll_handler(property_set_fd, handle_property_set_fd); }如前所述，属性值的更改仅能在init进程中进行，即一个进程若想修改属性值，必须向init进程提交申请，为此init进程生成“/dev/socket/property_service”套接字，以接收其它进程提交的申请。
注册属性变更socket文件描述符（fd）到epoll_fd
system/core/init/init.cpp
void register_epoll_handler(int fd, void (*fn)()) { epoll_event ev; ev.events = EPOLLIN; //触发事件是当文件描述符可读时 ev.data.ptr = reinterpret_cast<void*>(fn); //触发后的回调函数 //注册属性socket fd到epoll_fd if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev) == -1) { PLOG(ERROR) << "epoll_ctl failed"; } }register_epoll_handler函数主要的作用是注册属性socket文件描述符到轮询描述符epoll_fd,当property_set_fd可读时，会调用上面register_epoll_handler函数的第二个参数(处理函数handle_property_set_fd())
system/core/init/property_service.cpp
static void handle_property_set_fd() { ...... uint32_t cmd = 0; if (!socket.RecvUint32(&cmd, &timeout_ms)) {//读取命令 return; } switch (cmd) { case PROP_MSG_SETPROP: { char prop_name[PROP_NAME_MAX]; char prop_value[PROP_VALUE_MAX]; //读取属性名和属性值 if (!socket.RecvChars(prop_name, PROP_NAME_MAX, &timeout_ms) || !socket.RecvChars(prop_value, PROP_VALUE_MAX, &timeout_ms)) { return; } ...... //设置属性值 uint32_t result = HandlePropertySet(prop_name, prop_value,socket.source_context(), cr, &error); break; } case PROP_MSG_SETPROP2: ......当监听到属性变更时，从socket读取命令和属性名与属性值，设置新的属性或者更改属性值。HandlePropertySet最后会调用ActionManager::QueuePropetyChange将属性变更（属性触发器）添加到已触发队列中，最后会执行相应command命令(init.rc中定义的command)
现在我们来讲解init进程的另外一个重要功能，处理子进程终止。 system/core/init/init.cpp
...... sigchld_handler_init();//注册子进程死亡监听socket ...... system/core/init/sigchld_hanlder.cpp ```c void sigchld_handler_init() { // Create a signalling mechanism for SIGCHLD. int s[2]; //创建套接字对，往一个socket中写，就可以从另外一个套接字中读取到数据 if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) { PLOG(FATAL) << "socketpair failed in sigchld_handler_init"; } signal_write_fd = s[0]; signal_read_fd = s[1]; // Write to signal_write_fd if we catch SIGCHLD. struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = SIGCHLD_handler;//收到SIGCHLD信号后的处理函数 act.sa_flags = SA_NOCLDSTOP; sigaction(SIGCHLD, &act, 0);//注册SIGCHLD信号 ReapAnyOutstandingChildren(); //注册signal_read_fd到epoll_fd register_epoll_handler(signal_read_fd, handle_signal); }当init子进程意外终止时，会向init进程发送SIGCHLD信号，这个时候会调用SIGCHLD_handler这个处理函数。
system/core/init/sigchld_hanlder.cpp
static void SIGCHLD_handler(int) { if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) { PLOG(ERROR) << "write(signal_write_fd) failed"; } }SIGCHLD_handler的作用是当init进程接收到SIGCHLD信号时，往signal_write_fd中写入数据，这个时候套接字对中的另外一个signal_read_fd就可读了。
通过register_epoll_handler（这个函数上面已经分析过了）将signal_read_fd注册到epoll_fd中，当signal_read_fd可读时，会调用register_epoll_handler的第二个参数（handle_signal处理函数）。
handle_signal()函数分析 system/core/init/sigchld_hanlder.cpp
static void handle_signal() { // 清空signal_read_fd中的数据 char buf[32]; read(signal_read_fd, buf, sizeof(buf)); ReapAnyOutstandingChildren();//见下 } void ReapAnyOutstandingChildren() { while (ReapOneProcess()) {//见下 } } static bool ReapOneProcess() { ...... //等待子进程终止 auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); }); ...... //获取到终止子进程对应的Service对象 service = ServiceList::GetInstance().FindService(pid, &Service::pid); ...... //处理退出后的后续事项 service->Reap(siginfo); ...... }收到子进程的SIGCHLD信号后，找出该进程对应的Service对象，调用Reap函数。
service->Reap处理退出后进程的事项，如下： system/core/init/service.cpp
void Service::Reap(const siginfo_t& siginfo) { //如果标志位是onshot或者是重启的子进程就杀掉整个进程组 if (!(flags_ & SVC_ONESHOT) || (flags_ & SVC_RESTART)) { KillProcessGroup(SIGKILL); } // Oneshot processes go into the disabled state on exit, // except when manually restarted. if ((flags_ & SVC_ONESHOT) && !(flags_ & SVC_RESTART)) { flags_ |= SVC_DISABLED; } ...... //后续Init进程重启子进程会通过这个标志位来判断是否需要重启该子进程 flags_ |= SVC_RESTARTING; ...... return; }当init进程收到子进程意外终止SIGCHLD信号后，会根据对应进程Service对象的flags_标志位来判断该进程能不能重启，如果需要重启，就给flags_标志位添加SVC_RESTARTING标志位。
/system/core/init/init.cpp
static std::optional<boot_clock::time_point> RestartProcesses() { std::optional<boot_clock::time_point> next_process_restart_time; for (const auto& s : ServiceList::GetInstance()) { if (!(s->flags() & SVC_RESTARTING)) continue; auto restart_time = s->time_started() + 5s; if (boot_clock::now() > restart_time) { if (auto result = s->Start(); !result) { LOG(ERROR) << "Could not restart process '" << s->name() << "': " << result.error(); } } else { if (!next_process_restart_time || restart_time < *next_process_restart_time) { next_process_restart_time = restart_time; } } } return next_process_restart_time; }检查service_list中的所有服务，对于带有SVC_RESTARTING标志的服务，则都会调用其相应的start()方法。
函数说明： 1.const auto& 当只想读取range中元素时，使用const auto&,如：for(const auto&x:range),它不会进行拷贝，也不会修改range
Result<Success> Service::Start() { bool disabled = (flags_ & (SVC_DISABLED | SVC_RESET)); // Starting a service removes it from the disabled or reset state and // immediately takes it out of the restarting state if it was in there. flags_ &= (~(SVC_DISABLED|SVC_RESTARTING|SVC_RESET|SVC_RESTART|SVC_DISABLED_START)); if (flags_ & SVC_RUNNING) { if ((flags_ & SVC_ONESHOT) && disabled) { flags_ |= SVC_RESTART; } // It is not an error to try to start a service that is already running. return Success(); } bool needs_console = (flags_ & SVC_CONSOLE); if (needs_console) { if (console_.empty()) { console_ = default_console; } // Make sure that open call succeeds to ensure a console driver is // properly registered for the device node int console_fd = open(console_.c_str(), O_RDWR | O_CLOEXEC); if (console_fd < 0) { flags_ |= SVC_DISABLED; return ErrnoError() << "Couldn't open console '" << console_ << "'"; } close(console_fd); } struct stat sb; if (stat(args_[0].c_str(), &sb) == -1) { flags_ |= SVC_DISABLED; return ErrnoError() << "Cannot find '" << args_[0] << "'"; } ........ pid_t pid = -1; //如果该进程未启动，调用fork启动该进程 if (namespace_flags_) { pid = clone(nullptr, nullptr, namespace_flags_ | SIGCHLD, nullptr); } else { pid = fork(); } if (pid == 0) { umask(077); ...... } // priority. Aborts on failure. SetProcessAttributes(); if (!ExpandArgsAndExecv(args_)) { PLOG(ERROR) << "cannot execve('" << args_[0] << "')"; } _exit(127); } if (pid < 0) { pid_ = 0; return ErrnoError() << "Failed to fork"; } ....... time_started_ = boot_clock::now(); pid_ = pid; flags_ |= SVC_RUNNING; start_order_ = next_start_order_++; process_cgroup_empty_ = false; ....... NotifyStateChange("running"); return Success(); }其主要流程如下： 是否正在运行，如正在运行，直接返回； 子进程是否启动，如未启动，调用fork并返回pid值； 如果以上正常，则调用ExpandArgsAndExecve启动该进程，完成Zygote的启动。
init.cpp的main()方法中通过signal_handler_init()来初始化信号处理过程。
主要工作： 初始化signal句柄； 循环处理子进程； 注册epoll句柄； 处理子进程的终止；
[-> signal_handler.cpp]
void sigchld_handler_init() { // Create a signalling mechanism for SIGCHLD. int s[2]; // 创建socket pair if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) { PLOG(FATAL) << "socketpair failed in sigchld_handler_init"; } signal_write_fd = s[0]; signal_read_fd = s[1]; // Write to signal_write_fd if we catch SIGCHLD. //当捕获信号SIGCHLD，则写入signal_write_fd struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = SIGCHLD_handler; //SA_NOCLDSTOP使init进程只有在其子进程终止时才会受到SIGCHLD信号 act.sa_flags = SA_NOCLDSTOP; sigaction(SIGCHLD, &act, 0); //进入waitpid来处理子进程是否退出的情况 ReapAnyOutstandingChildren(); //调用epoll_ctl方法来注册epoll的回调函数 register_epoll_handler(signal_read_fd, handle_signal); }每个进程在处理其他进程发送的signal信号时都需要先注册，当进程的运行状态改变或终止时会产生某种signal信号，init进程是所有用户空间进程的父进程，当其子进程终止时产生SIGCHLD信号，init进程调用信号安装函数sigaction()，传递参数给sigaction结构体，便完成信号处理的过程。
这里有两个重要的函数：SIGCHLD_handler和handle_signal，如下：
sigchld_handler.cpp
//写入数据 static void SIGCHLD_handler(int) { //向signal_write_fd写入1，直到成功为止 if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) { PLOG(ERROR) << "write(signal_write_fd) failed"; } } //读取数据 static void handle_signal() { // Clear outstanding requests. char buf[32]; //读取signal_read_fd中的数据，并放入buf read(signal_read_fd, buf, sizeof(buf)); ReapAnyOutstandingChildren(); }ReapAnyOutstandingChildren()
void ReapAnyOutstandingChildren() { while (ReapOneProcess()) { } }ReapOneProcess
static bool ReapOneProcess() { siginfo_t siginfo = {}; // This returns a zombie pid or informs us that there are no zombies left to be reaped. // It does NOT reap the pid; that is done below. //等待任意子进程，如果子进程没有退出则返回0，否则则返回该子进程pid。 if (TEMP_FAILURE_RETRY(waitid(P_ALL, 0, &siginfo, WEXITED | WNOHANG | WNOWAIT)) != 0) { PLOG(ERROR) << "waitid failed"; return false; } auto pid = siginfo.si_pid; if (pid == 0) return false; // At this point we know we have a zombie pid, so we use this scopeguard to reap the pid // whenever the function returns from this point forward. // We do NOT want to reap the zombie earlier as in Service::Reap(), we kill(-pid, ...) and we // want the pid to remain valid throughout that (and potentially future) usages. auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); }); std::string name; std::string wait_string; Service* service = nullptr; if (PropertyChildReap(pid)) { name = "Async property child"; } else if (SubcontextChildReap(pid)) { name = "Subcontext"; } else { service = ServiceList::GetInstance().FindService(pid, &Service::pid); if (service) { name = StringPrintf("Service '%s' (pid %d)", service->name().c_str(), pid); if (service->flags() & SVC_EXEC) { auto exec_duration = boot_clock::now() - service->time_started(); auto exec_duration_ms = std::chrono::duration_cast<std::chrono::milliseconds>(exec_duration).count(); wait_string = StringPrintf(" waiting took %f seconds", exec_duration_ms / 1000.0f); } } else { name = StringPrintf("Untracked pid %d", pid); } } if (siginfo.si_code == CLD_EXITED) { LOG(INFO) << name << " exited with status " << siginfo.si_status << wait_string; } else { LOG(INFO) << name << " received signal " << siginfo.si_status << wait_string; } if (!service) return true; service->Reap(siginfo); if (service->flags() & SVC_TEMPORARY) { ServiceList::GetInstance().RemoveService(*service); } return true; }重点逻辑在service->Reap(siginfo)
service.cpp
void Service::Reap(const siginfo_t& siginfo) { //当flags为RESTART，且不是ONESHOT时，先kill进程组内所有的子进程或子线程 if (!(flags_ & SVC_ONESHOT) || (flags_ & SVC_RESTART)) { KillProcessGroup(SIGKILL); } ...... // Oneshot processes go into the disabled state on exit, // except when manually restarted. //禁用和重置的服务，都不再自动重启 if ((flags_ & SVC_ONESHOT) && !(flags_ & SVC_RESTART)) { flags_ |= SVC_DISABLED; } // Disabled and reset processes do not get restarted automatically. //禁用和重置的服务，都不再自动重启 if (flags_ & (SVC_DISABLED | SVC_RESET)) { NotifyStateChange("stopped"); return; } // If we crash > 4 times in 4 minutes, reboot into recovery. //服务在4分钟内重启次数超过4次，则重启手机进入recovery模式 boot_clock::time_point now = boot_clock::now(); if ((flags_ & SVC_CRITICAL) && !(flags_ & SVC_RESTART)) { if (now < time_crashed_ + 4min) { if (++crash_count_ > 4) { LOG(FATAL) << "critical process '" << name_ << "' exited 4 times in 4 minutes"; } } else { time_crashed_ = now; crash_count_ = 1; } } flags_ &= (~SVC_RESTART); flags_ |= SVC_RESTARTING; // Execute all onrestart commands for this service. //执行当前service中所有onrestart命令 onrestart_.ExecuteAllCommands(); //设置相应的service状态为restarting NotifyStateChange("restarting"); return; }另外：通过getprop | grep init.svc 可查看所有的service运行状态。状态总共分为：running, stopped, restarting
register_epoll_handler
void register_epoll_handler(int fd, void (*fn)()) { epoll_event ev; ev.events = EPOLLIN; ev.data.ptr = reinterpret_cast<void*>(fn); //将fd的可读事件加入到epoll_fd的监听队列中 if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev) == -1) { PLOG(ERROR) << "epoll_ctl failed"; } }当fd可读，则会触发调用(*fn)函数。
前面说了初始化init.rc,那么就得知道rc文件的语法 rc文件语法是以行尾单位，以空格间隔的语法，以#开始代表注释行。rc文件主要包含Action、Service、Command、Options，其中对于Action和Service的名称都是唯一的，对于重复的命名视为无效。
Action
Action： 通过触发器trigger，即以on开头的语句来决定执行相应的service的时机，具体有如下时机：
on early-init; 在初始化早期阶段触发； on init; 在初始化阶段触发； on late-init; 在初始化晚期阶段触发； on boot/charger： 当系统启动/充电时触发，还包含其他情况，此处不一一列举； on property:=: 当属性值满足条件时触发；
Service 服务Service，以 service开头，由init进程启动，一般运行在init的一个子进程，所以启动service前需要判断对应的可执行文件是否存在。init生成的子进程，定义在rc文件，其中每一个service在启动时会通过fork方式生成子进程。
例如： service servicemanager /system/bin/servicemanager代表的是服务名为servicemanager，服务执行的路径为/system/bin/servicemanager。
Command 下面列举常用的命令
class_start <service_class_name>： 启动属于同一个class的所有服务； start <service_name>： 启动指定的服务，若已启动则跳过； stop <service_name>： 停止正在运行的服务 setprop ：设置属性值 mkdir ：创建指定目录 symlink <sym_link>： 创建连接到的<sym_link>符号链接； write ： 向文件path中写入字符串； exec： fork并执行，会阻塞init进程直到程序完毕； exprot ：设定环境变量； loglevel ：设置log级别
Options Options是Service的可选项，与service配合使用
disabled: 不随class自动启动，只有根据service名才启动； oneshot: service退出后不再重启； user/group： 设置执行服务的用户/用户组，默认都是root； class：设置所属的类名，当所属类启动/退出时，服务也启动/停止，默认为default； onrestart:当服务重启时执行相应命令； socket: 创建名为/dev/socket/的socket critical: 在规定时间内该service不断重启，则系统会重启并进入恢复模式
default: 意味着disabled=false，oneshot=false，critical=false。
init.rc文件的路径如下： /system/core/rootdir/init.rc 下面截取重要的代码段：
on early-init on init on late-init trigger early-fs trigger fs trigger post-fs trigger late-fs trigger post-fs-data trigger zygote-start trigger load_persist_props_action trigger firmware_mounts_complete trigger early-boot trigger boot on post-fs # Load properties from # /system/build.prop, # /odm/build.prop, # /vendor/build.prop and # /factory/factory.prop load_system_props # start essential services start logd start servicemanager start hwservicemanager start vndservicemanager mount rootfs rootfs / remount bind ro # Mount shared so changes propagate into child namespaces mount rootfs rootfs / shared rec # Mount default storage into root namespace mount none /mnt/runtime/default /storage bind rec mount none none /storage slave rec ...... on boot //启动核心服务 ...... class_start core //启动core class触发器的执行顺序为on early-init -> init -> late-init，从上面的代码可知，在late-init触发器中会触发文件系统挂载以及on boot。再on boot过程会触发启动core class。至于main class的启动是由vold.decrypt的以下4个值的设置所决定的， 该过程位于system/vold/cryptfs.c文件。
system/core/init/init.cpp
//am中的actions_成员变量用来保存action list(动作列表) ActionManager& am = ActionManager::GetInstance(); //sm中的service_成员变量用来保存service list(服务列表) ServiceList& sm = ServiceList::GetInstance(); //解析rc文件，并将动作和服务分别添加到am和sm中 LoadBootScripts(am, sm);LoadBootScripts解析rc文件，将动作和服务添加到am的动作列表和sm的服务列表中去。 system/core/init/init.cpp
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) { //创建解析器 Parser parser = CreateParser(action_manager, service_list); ...... //解析init.rc文件 parser.ParseConfig("/init.rc"); ...... } Parser CreateParser(ActionManager& action_manager, ServiceList& service_list) { Parser parser; //添加ServiceParser触发器 parser.AddSectionParser("service", std::make_unique<ServiceParser>(&service_list, subcontexts)); //添加ActionParser触发器 parser.AddSectionParser("on", std::make_unique<ActionParser>(&action_manager, subcontexts)); //添加ImportParser触发器 parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser)); return parser; } void Parser::AddSectionParser(const std::string& name, std::unique_ptr<SectionParser> parser) { //以键值对的形式添加到section_parsers_中 section_parsers_[name] = std::move(parser); }分别将service(ServiceParser),on(ActionParser)和import(ImportParser)以键值对的形式添加到section_parsers_中。这三个Parser都继承自SectionParser,可以看到这里使用了组合和面向抽象编程的设计原则，将具体的解析器和解析行为解耦。下面会分析它们是如何使用相同的代码，不同的解析器解析不同的关键字（on,service,import等）。
现在分析ParseConfig("/init.rc")方法 system/core/init/parser.cpp
//ParseConfig->ParseConfigFile bool Parser::ParseConfigFile(const std::string& path, size_t* parse_errors) { ...... //ReadFile将init.rc文件转换为config_contents字符串 auto config_contents = ReadFile(path); ...... //解析config_contents字符串 ParseData(path, *config_contents, parse_errors); ...... } void Parser::ParseData(const std::string& filename, const std::string& data, size_t* parse_errors) { std::vector<char> data_copy(data.begin(), data.end()); data_copy.push_back('\0'); parse_state state; ....... state.ptr = &data_copy[0]; ...... std::vector<std::string> args; //lambda表达式，函数的引用，每次解析新的一行之前 //都会调用这个将上一行解析的结果放到对应的数组中 auto end_section = [&] {//⑤ if (section_parser == nullptr) return; if (auto result = section_parser->EndSection(); !result) { (*parse_errors)++; LOG(ERROR) << filename << ": " << section_start_line << ": " << result.error(); } //重置 section_parser = nullptr; section_start_line = -1; }; for (;;) { switch (next_token(&state)) { // ① case T_EOF: end_section();// ⑤ 上一行的解析工作 return; case T_NEWLINE: // ⑦ state.line++; ...... if (section_parsers_.count(args[0])) {//② end_section(); // ⑤ 上一行解析的收尾工作 section_parser = section_parsers_[args[0]].get(); section_start_line = state.line; auto result = section_parser-> ParseSection(std::move(args), filename, state.line); // ③ } else if (section_parser) { auto result = section_parser-> ParseLineSection(std::move(args), state.line); // ④ args.clear(); break; case T_TEXT: // ⑥ args.emplace_back(state.text); break; } } }下面我们分析一下，ParseData是如何解析的： ①： next_token扫描init.rc中的token 找到其中的文件结束（EOF）、文本（TEXT）、新行（NEWLINE），其中的空格’ ‘、’\t’、’\r’会被忽略掉；对于TEXT,空格’ ‘、’\t’、’\r’、’\n’都是TEXT的结束标志。
例如：service ueventd /system/sbin/ueventd 中有三个TEXT (“servcie”、“ueventd”、"/system/sbin/") 这些都会加入到args[]数组中⑥，然后就是⑦解析args数组
②： 会判断args[]第一个字符是不是on、service或import 如果是就拿到对应的解析器，例如是service开头的新行，section_parser就是对应之前添加的ServcieParser解析器，并且执行③，否则就执行④ ③： 这里会执行ServiceParser解析器的ParseSection代码 会新建一个Service对象，变量名service_ ④： 这里会执行ServiceParser解析器的ParseLineSection代码 这里是解析service下面附带的option(例如oneshot,class等等),并将这些属性添加到Service对象中)
小提示： 如果args[0]是"on",section_parser对应的就是ActionParser；如果是"import",section_parser对应的就是ImportParser；本文只会分析ServiceParser，另外两个解析器，读者可以参照着分析。
⑤： 解析完一个Service对象后 end_section()中的section_parser->EndSection()将Service对象添加到Service List（services_）中，并且重置section_parser = null，为解析下一个Service做准备。
system/core/init/service.cpp 分析③的代码：
Result<Success> ServiceParser::ParseSection(std::vector<std::string>&& args, const std::string& filename, int line) { const std::string& name = args[1]; ...... std::vector<std::string> str_args(args.begin() + 2, args.end()); //新建一个Service对象，args[1]表示服务名，后面的是运行参数 service_ = std::make_unique<Service>(name, restart_action_subcontext, str_args); return Success(); }system/core/init/service.cpp 分析④的代码：
Result<Success> ServiceParser::ParseLineSection(std::vector<std::string>&& args, int line) { return service_ ? service_->ParseLine(std::move(args)) : Success(); } Result<Success> Service::ParseLine(const std::vector<std::string>& args) { static const OptionParserMap parser_map; //找到service中option对应的函数 auto parser = parser_map.FindFunction(args); if (!parser) return parser.error(); //执行相应的函数，添加对应的属性到Service对象中 return std::invoke(*parser, this, args); }下面我们看一下paser_map中option和函数名的对应关系。 system/core/init/service.cpp
static const Map option_parsers = { ...... {"class", {1, kMax, &Service::ParseClass}}, {"console", {0, 1, &Service::ParseConsole}}, {"disabled", {0, 0, &Service::ParseDisabled}}, ...... {"oneshot", {0, 0, &Service::ParseOneshot}}, {"onrestart", {1, kMax, &Service::ParseOnrestart}}, ...... {"user", {1, 1, &Service::ParseUser}}, };这个我们分析oneshot为例，oneshot对应的函数是Service::ParseOneshot。
Result<Success> Service::ParseOneshot(const std::vector<std::string>& args) { flags_ |= SVC_ONESHOT; return Success(); }std::invoke调用这个函数后，会将SVC_ONESHOT添加到这个Service对象中，当这个服务意外终止时，init进程会根据这个标志位而不去重启这个Service。
system/core/init/service.cpp 分析⑤的代码
Result<Success> ServiceParser::EndSection() { if (service_) { ...... //service_对象存在的时候，就添加到service list中 service_list_->AddService(std::move(service_)); } return Success(); } void ServiceList::AddService(std::unique_ptr<Service> service) { //将服务添加到Service List（services_）中 services_.emplace_back(std::move(service)); }到这里一个服务就解析完成了，on和import依葫芦画瓢，可以自行分析。
on开头的使用ActionParser解析器解析,该解析器的ParseSection方法主要是生成action对象，并将action对象添加到actions_数组中，ParseLineSection方法主要是解析command对应的函数，然后添加到action对象的commands_数组中。细心的读者可能已经发现，ServiceParser的ParseLineSection是直接执行option对应函数,而ActionParser是将对应函数保存到commands_数组中，当Action触发时，才会依次执行command函数。
我们继续往下分析源码 system/core/init/init.cpp
// 解析init.rc文件，上面已经分析完 LoadBootScripts(am, sm); ...... // ① 触发early-init Action am.QueueEventTrigger("early-init"); // ② 新建一个"wait_for_coldboot_done"触发器，并且触发该触发器 am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done"); ...... // ③ 触发"init"，触发器 am.QueueEventTrigger("init");①： 使用QueueEventTrigger方法触发early-init(还有一种触发方式是在rc文件中使用trigger命令，如trigger early-init) system/core/init/action_manager.cpp
void ActionManager::QueueEventTrigger(const std::string& trigger) { event_queue_.emplace(trigger); }event_queue_是一个保存以触发事件的队列,QueueEventTrigger(“early-init”)就表示触发了"early-init"事件 system/core/init/action_manager.h
std::queue<std::variant<EventTrigger, PropertyChange, BuiltinAction>> event_queue_;system/core/init/action.h
using EventTrigger = std::string; using PropertyChange = std::pair<std::string, std::string>; using BuiltinAction = class Action*;event_queue_可以存储三种触发器，EventTrigger(事件触发器，如on early-init)，PropertyChange(属性触发器,如on property: = )，例如：属性服务监听到属性变更请求时会添加该触发器，BuiltinAction(内建触发器,代码实时添加的，不在rc文件中配置)
②：创建内置触发器，并且触发 system/core/init/action_manager.cpp
void ActionManager::QueueBuiltinAction(BuiltinFunction func, const std::string& name) { //创建内置action对象 auto action = std::make_unique<Action>(true, nullptr, "<Builtin Action>", 0, name, std::map<std::string, std::string>{}); std::vector<std::string> name_vector{name}; //添加func到action对象的commands_数组中 action->AddCommand(func, name_vector, 0); //触发内置触发器 event_queue_.emplace(action.get()); //添加action对象到action list（actions_数组中） actions_.emplace_back(std::move(action)); }③：触发事件触发器 on init
继续向下分析，就是依次执行已经触发的触发器action对象的command命令，并且监听属性服务和子进程的终止。 system/core/init/init.cpp
while (true) { ...... // ① am.ExecuteOneCommand(); ...... // ② auto next_process_restart_time = RestartProcesses(); ...... // ③ int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, epoll_timeout_ms)); }①：依次执行已触发aciton的command命令 system/core/init/action_manager.cpp
void ActionManager::ExecuteOneCommand() { // Loop through the event queue until we have an action to execute while (current_executing_actions_.empty() && !event_queue_.empty()) { for (const auto& action : actions_) { //如果该触发(event,就是前面说的三个触发器)匹配到当前action，就添加到current_excuting_actions_队列中 if (std::visit([&action](const auto& event) { return action->CheckEvent(event); },event_queue_.front())) { current_executing_actions_.emplace(action.get()); } } //从已触发事件弹出 event_queue_.pop(); } //如果没有可执行action，就直接返回 if (current_executing_actions_.empty()) { return; } auto action = current_executing_actions_.front(); ...... //每次执行一个命令 action->ExecuteOneCommand(current_command_); // If this was the last command in the current action, then remove // the action from the executing list. ++current_command_;//命令索引加一 //如果是当前action最后一个命令，就从执行列表中移除action if (current_command_ == action->NumCommands()) { current_executing_actions_.pop(); current_command_ = 0; ...... } } }从触发事件队列event_queue_中取出一个触发事件，从actions_中寻找匹配的action,然后添加到当前正在执行事件的队列current_executing_actions_中，取出aciton,依次执行action中commands_数组中的命令。遍历的执行上述操作，直至event_queue_和current_executing_actions_为空。
system/core/init/action.cpp
oid Action::ExecuteOneCommand(std::size_t command) const { Command cmd = commands_[command]; //每次调用一个command命令 ExecuteCommand(cmd); } void Action::ExecuteCommand(const Command& command) const { ...... auto result = command.InvokeFunc(subcontext_); ...... }②：重启需要重启的子进程 system/core/init/init.cpp
static std::optional<boot_clock::time_point> RestartProcesses() { ...... for (const auto& s : ServiceList::GetInstance()) { //如果是需要重启的服务，会添加SVC_RESTARTING标志位，前面已经介绍过 if (!(s->flags() & SVC_RESTARTING)) continue; ...... //重启进程 if (auto result = s->Start(); !result) { LOG(ERROR) << "Could not restart process '" << s->name() << "': " << result.error(); } ...... }③：上面通过epoll_ctl注册了属性服务和子进程终止，现在通过epoll_wait来真正的监听。当有属性申请和子进程终止时，就执行前面分析的对应的处理函数。
init进程(pid=1)是Linux系统中用户空间的第一个进程，主要工作如下：
创建一块共享的内存空间，用于属性服务器; 解析各个rc文件，并启动相应属性服务进程; 初始化epoll，依次设置signal、property、keychord这3个fd可读时相对应的回调函数; 进入无限循环状态，执行如下流程： 检查action_queue列表是否为空，若不为空则执行相应的action; 检查是否需要重启的进程，若有则将其重新启动; 进入epoll_wait等待状态，直到系统属性变化事件(property_set改变属性值)，或者收到子进程的信号SIGCHLD，再或者keychord 键盘输入事件，则会退出等待状态，执行相应的回调函数。 可见init进程在开机之后的核心工作就是响应property变化事件和回收僵尸进程。当某个进程调用property_set来改变一个系统属性值时，系统会通过socket向init进程发送一个property变化的事件通知，那么property fd会变成可读，init进程采用epoll机制监听该fd则会 触发回调handle_property_set_fd()方法。回收僵尸进程，在Linux内核中，如父进程不等待子进程的结束直接退出，会导致子进程在结束后变成僵尸进程，占用系统资源。为此，init进程专门安装了SIGCHLD信号接收器，当某些子进程退出时发现其父进程已经退出，则会向init进程发送SIGCHLD信号，init进程调用回调方法handle_signal()来回收僵尸子进程。
