OpenHarmony release3.1版本启动子系统功能分析 原创 精华
作者：润和软件 孙凡
1.技术背景
OpenHarmony release3.1版本在2.0的基础之上不仅增加了功能，而且各模块组件的能力也有所增强，本文就3.1版本的init启动子系统模块，在启动引导系统服务方面进行分析。本文档是基于码云上release3.1分支代码进行分析。
启动子系统负责整个系统各个进程运行时环境的构建及进程引导，不同层级的进程有着不同的运行环境，运行环境决定着系统进程的设计。在增强启动子系统能力方面有以下方面：
基础能力增强：进程启动、回收机制增强，维护命令统一以及插件化管理；
并行启动：最大化并行启动，为依赖资源提供同步机制，运行时进行资源获取；
按需启动：无访问不启动，减少常驻内存；
分组启动：可对服务进行灵活组装，提供整机不同的启动级别能力。
2.Init启动功能概述
2.1.基础能力的增强
进程启动，支持进程的selinux策略配置，扩展AccessToken设置，支持绑核配置；进程回收，支持进程频繁退出抑制机制；维护命令，统一init的维护命令，包括系统参数和进程管理；插件化管理，init部件与周边模块关联度高，通过插件化机制供其它模块扩展。
2.2.进程分组&并行启动
支持服务分组配置，如支持系统知名group，支持整机开机、重启、关机、待机、充电等模式；支持服务依赖管理，支持并行启动依赖同步机制。
2.3.按需启动
支持SA类进程按需启动，HDF类进程按需启动，socket类进程的按需启动；支持热插拔事件驱动进程按需启动；支持为按需启动定时启动、进程代持fd等辅助功能。
3.系统能力增强点分析
3.1.进程启动能力增强
进程启动时，支持在配置文件中配置服务进程的绑核、优先级、selinux策略加载以及AccessToken信息。
3.1.1.配置服务进程绑核能力
在服务的cfg配置文件中，配置绑核，例如param_watcher服务。系统启动之后通过taskset -p pid，查看服务绑核情况，例如 current affinity mask: 3，即表示param_watcher服务运行在两个cpu上切换。
“services” : [{
“name” : “param_watcher”,
…
“cpucore” : [0,1]
},
通过CJSON解析 cfg 文件，获取属性”cpucore”属性值的数组，然后通过接口CPU_SET设置进程的CPU.
在init，fork()服务子进程时设置CPU绑核。
3.1.2.配置服务进程优先级
在服务cfg文件中配置进程的优先级，例如appspawn.cfg中配置"importance" : -20，即设置appspawn的优先级为-20。
{
"services" : [{
"name" : "appspawn",
"path" : ["/system/bin/appspawn"],
"importance" : -20,
"uid" : "root",
"gid" : ["root"],
"start-mode" : "boot"
}
]
}
代码中通过CJSON解析cfg文件中”importance”属性，得到服务的优先级，同时通过SetImportantValue回调函数保存优先级属性。
在ServiceExec执行进程命令之前通过setpriority
设置服务的优先级。
3.1.3.服务的selinux策略加载
OpenHarmony正在不断完善selinux安全策略，后面对于服务的管控会更加严格。Init启动在服务cfg文件中提供配置进程的Selinux接口，例如updater_sa.cfg文件中配置
“secon” : “u:r:updater_sa:s0”。
{
“services” : [{
“name” : “updater_sa”,
“path” : [“/system/bin/sa_main”, “/system/profile/updater_sa.xml”],
“uid” : “system”,
“gid” : [“system”, “shell”],
“secon” : “u:r:updater_sa:s0”
}
]
}
通过JSON解析cfg文件中"secon"属性，获取服务的selinux值。
在init初始时，加载selinux LoadPolicy。
在init fork子进程时，通过SetSecon 设置服务的selinux。
3.1.4.配置服务进程AccessToken属性
在服务cfg文件中配置进程的AccessToken，即cfg文件中配置
“apl”: “xxx”,设置一串令牌。
通过JSON解析cfg文件中"apl"属性，获取服务的apl值。
在init fork 子进程的时候设置进程的AccessToken.
3.2.进程启动&回收能力增强
3.2.1.进程的启动流程
init启动系统服务进程时都是先fork再execv执行目标服务进程而完成启动。Fork的流程又细分为
pre-fork：即服务进程不需要真正的启动，只是由init做好服务的准备工作，服务被访问时拉起服务；
fork：只要fork成功，init就接着启动下一个进程，即使后面execv执行失败也忽略，最大承担并行启动服务；
execv：fork完成之后需要execv执行成功，才算服务启动完成；
service：在服务启动完成之后，通过setparameter 设置服务启动标志"startup.service.ctl.serviceName" 为SERVICE_STARTED。
3.2.2.子进程退出资源回收
init监听到任何子进程退出都需要waitpid回收该进程，避免出现僵尸进程。
3.2.3.设置服务启动特殊模式
通过在服务的cfg文件中配置Once、Disabled、Critical属性值设置服务启动的特殊方式。
Default：默认情况下服务退出之后，init会再次拉起服务；
Once：服务是单次启动模式，退出之后init不再拉起；
Disabled：服务是被禁用的，退出后也不会拉起；
Critical：服务失败后需要重新拉起，但是失败N次之后，系统就会重启，默认是4次。
常驻服务进程如果一直异常退出，为了避免频繁尝试拉起该服务，增加抑制机制，默认3秒内连续退出超过5次则不再自动拉起该服务。
核心服务进程如果一直异常退出，为了避免系统不可用，尝试系统重启；默认20秒内连续退出超过4次则不再自动拉起该服务。
例如 “critical” : [1, 1, 60], 代表有critical attribute，同时60秒内重启1次，就系统重启。通过GetCritical函数解析critical 属性，通过CalculateCrashTime函数判断是否需要重启服务，或是reboot系统。
3.3.提供整机状态服务
3.3.1.整机状态
各系统服务进程启动后，还需要相应整机提供的重启、关机等请求（对应整机状态变化能够对进程进行相应处理stop、suspend、freeze等）。
重启、shutdown关机：关闭服务进程，通过stop命令关闭服务；
Suspend关机：STR带电低功耗关机，可快速开机，服务可选择的退出或清理资源；
Freeze关机：STD系统快照写到Disk，可完全掉电并快速开机。
通过reboot命令，设置 "startup.device.ctl"参数给外界提供当前整机的状态，系统服务进程可通过ParameterClient的watch机制监听整机的状态变化，处理自己的状态。
Reboot 命令：
3.3.2.服务可以通过start/stop来启动停止
通过以下命令可以启动或者停止服务。
start_service servicename --start service
stop_service servicename --stop service
service_control start servicename --start service
service_control stop servicename --stop service
最终通过SystemSetParameter(“ohos.ctl.start”, nameValue)启动服务，其中nameValue是服务名+服务的参数组合数组。
3.4.按需启动
3.4.1.SA进程按需启动
需要按需启动的SA服务，通过在cfg文件配置”dynamic” : true，设置此SA服务为按需启动，即init在start service的时候解析到此属性，不直接拉起服务；而是通过client端触发samgr拉起服务。
动态加载系统服务进程及SystemAbility, 系统进程无需开机启动，而是在SystemAbility被访问的时候按需拉起，并加载指定SystemAbility。继承SystemAbilityLoadCallbackStub类，并覆写OnLoadSystemAbilitySuccess(int32_t systemAbilityId, const sptr& remoteObject)、OnLoadSystemAbilityFail(int32_t systemAbilityId)方法。
调用samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)。
Samgr通过调用init提供的ServiceControlWithExtra接口，拉起服务。
3.4.2.UHDF进程按需启动
同上SA服务的按需启动的分析，只是在HUDF服务中调用ServiceControlWithExtra接口，拉起服务。
3.4.3.socket进程按需启动
init在pre-fork阶段为socket类进程创建好socket，init中监听创建好的socket上的网络事件，socket上有报文事件后，init拉起socket进程进行报文处理。
socket进程无报文处理后，可以自动退出，退出后init回收该子进程并重新监听socket网络数据。
在服务cfg文件中添加”ondemand” : true 配置，设置socket服务为按需启动。
在fork 子进程的时候，判断服务是ondemand的，则创建socket监听。
通过回调函数ProcessWatchEvent_处理socket按需启动的事件。
3.4.4.热插拔服务进程按需启动
配置ueventd.cfg配置文件中设备节点<parameter> 属性，例如，/dev/binder <parameter> 属性配置为 ohos.dev.binder，当设备节点被创建好，param设置ohos.dev.binder属性值为added。
在相应服务的cfg文件中，配置”job”为condition，如下
“condition” : “ohos.dev.binder=added”
即当条件满足时触发服务拉起。
3.4.5.定时拉起&fd代持
定时拉起：服务进程在退出前可根据业务需要预约下次启动的时间。
fd代持：按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可发fd发送给init代持，再次启动后再获取fd。
在服务的cfg配置"timer_start" : 6 ,设置服务6秒后拉起。通过LE_CreateTimer创建定时器，定时时间到达时，触发回调函数，拉起服务。
创建fdhold的socket，注册event loop回调函数ProcessFdHoldEvent监听。
3.5.并行启动及依赖管理
begetd启动分三个阶段，pre-init和init阶段完成公共依赖部分；后续所有的服务都是并行化启动。服务启动的依赖包括Job和Service。
3.5.1.Job
所有的Job由init特权进程完成，可包括：设置全局环境变量，设置特权/proc, /sys节点参数等。
3.5.2.Service
Service依赖的前置条件可在启动脚本里指定Job完成。例如在service 中配置
“service”:
“jobs” : {
“on-start” : “services:console”
}
“job”:
{
“name” : “services:console”,
“cmds” : [
“chmod 0773 /data/misc/trace”,
“chmod 0775 /data/misc/wmtrace”
]
}
即在fork子进程的时候执行job相关的命令。
通过cfg文件设置服务的”start-mode”来管理正常启动还是并行启动。
“start-mode” : “boot”
“start-mode” : “normal”
“start-mode” : “condition”
其中boot、normal 模式是并行启动，service不写start-mode默认也是normal。Condition模式必须通过 start service 来拉起。
Start-mode通过注册钩子函数，通过trigger拉起服务。
3.6.分组管理
系统服务可以按照分组进行管理，设备级知名group用于完成整机的开机、待机、充电等功能。默认的整机开机是放到GROUP_BOOT中，GROUP_CHARING是充电模式。
以charging group举例说明。
配置device.charing.group.cfg 里面设置需要的jobs、services以及groups。
解析group 的cfg文件。
通过hash表保存group的配置。
通过cmdline获取当前的group 模式，从而启动进入不同的group，系统进入不同的模式。
4.总结
Release3.1 版本在OpenHarmony2.0的基础上各方面能力都有所提升，性能和稳定性方面有所改善。Init组件中加入selinux配置，增强了系统的安全模式，按需启动模式节约系统的内存资源，并行启动增加了系统的启动效率，分组启动模式为后期系统进入不同状态模式提供有效的接口。总之OpenHarmony在开源社区中，通过大家的共同努力正在茁长成长，总有一天会长成苍天大树，枝繁叶茂，造福人类。
发现宝藏，要是代码能复制就好了！
专业！写的很详细，也很透彻。
膜拜大神！