基于码云上release3.1分支代码进行分析

1

技术背景

OpenHarmony release3.1版本在2.0的基础之上不仅增加了功能，而且各模块组件的能力也有所增强，本文就3.1版本的init启动子系统模块，在启动引导系统服务方面进行分析。本文档是基于码云上release3.1分支代码进行分析。

启动子系统负责整个系统各个进程运行时环境的构建及进程引导，不同层级的进程有着不同的运行环境，运行环境决定着系统进程的设计。在增强启动子系统能力方面有以下方面：

基础能力增强：进程启动、回收机制增强，维护命令统一以及插件化管理；

并行启动：最大化并行启动，为依赖资源提供同步机制，运行时进行资源获取；

按需启动：无访问不启动，减少常驻内存；

分组启动：可对服务进行灵活组装，提供整机不同的启动级别能力。

2

Init启动功能概述

1.基础能力的增强

进程启动，支持进程的selinux策略配置，扩展AccessToken设置，支持绑核配置；进程回收，支持进程频繁退出抑制机制；维护命令，统一init的维护命令，包括系统参数和进程管理；插件化管理，init部件与周边模块关联度高，通过插件化机制供其它模块扩展。

2.进程分组&并行启动

支持服务分组配置，如支持系统知名group，支持整机开机、重启、关机、待机、充电等模式；支持服务依赖管理，支持并行启动依赖同步机制。

3.按需启动

支持SA类进程按需启动，HDF类进程按需启动，socket类进程的按需启动；支持热插拔事件驱动进程按需启动；支持为按需启动定时启动、进程代持fd等辅助功能。

3

系统能力增强点分析

1.进程启动能力增强

进程启动时，支持在配置文件中配置服务进程的绑核、优先级、selinux策略加载以及AccessToken信息。

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绑核。

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）服务的selinux策略加载

OpenHarmony正在不断完善selinux安全策略，后面对于服务的管控会更加严格。Init启动在服务cfg文件中提供配置进程的Selinux接口，例如updater_sa.cfg文件中配置

“secon” : “uupdater_sa:s0”。 {“services” : [{“name” : “updater_sa”,“path” : [“/system/bin/sa_main”, “/system/profile/updater_sa.xml”],“uid” : “system”,“gid” : [“system”, “shell”],“secon” : “uupdater_sa:s0”}]}

通过JSON解析cfg文件中"secon"属性，获取服务的selinux值。

在init初始时，加载selinux LoadPolicy。

在init fork子进程时，通过SetSecon 设置服务的selinux。

4）配置服务进程AccessToken属性

在服务cfg文件中配置进程的AccessToken，即cfg文件中配置“apl”: “xxx”,设置一串令牌。

通过JSON解析cfg文件中"apl"属性，获取服务的apl值。

在init fork 子进程的时候设置进程的AccessToken.

2.进程启动&回收能力增强

1）进程的启动流程

init启动系统服务进程时都是先fork再execv执行目标服务进程而完成启动。Fork的流程又细分为

pre-fork：即服务进程不需要真正的启动，只是由init做好服务的准备工作，服务被访问时拉起服务；

fork：只要fork成功，init就接着启动下一个进程，即使后面execv执行失败也忽略，最大承担并行启动服务；

execv：fork完成之后需要execv执行成功，才算服务启动完成；

service：在服务启动完成之后，通过setparameter 设置服务启动标志"startup.service.ctl.serviceName" 为SERVICE_STARTED。

2）子进程退出资源回收

init监听到任何子进程退出都需要waitpid回收该进程，避免出现僵尸进程。

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.提供整机状态服务

1）整机状态

各系统服务进程启动后，还需要相应整机提供的重启、关机等请求（对应整机状态变化能够对进程进行相应处理stop、suspend、freeze等）。

重启、shutdown关机：关闭服务进程，通过stop命令关闭服务；
Suspend关机：STR带电低功耗关机，可快速开机，服务可选择的退出或清理资源；
Freeze关机：STD系统快照写到Disk，可完全掉电并快速开机。

通过reboot命令，设置 "startup.device.ctl"参数给外界提供当前整机的状态，系统服务进程可通过ParameterClient的watch机制监听整机的状态变化，处理自己的状态。
Reboot 命令：

2）服务可以通过start/stop来启动停止

通过以下命令可以启动或者停止服务。

start_service servicename --start servicestop_service servicename --stop serviceservice_control start servicename --start serviceservice_control stop servicename --stop service

最终通过SystemSetParameter(“ohos.ctl.start”, nameValue)启动服务，其中nameValue是服务名+服务的参数组合数组。

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）socket进程按需启动

init在pre-fork阶段为socket类进程创建好socket，init中监听创建好的socket上的网络事件，socket上有报文事件后，init拉起socket进程进行报文处理。

socket进程无报文处理后，可以自动退出，退出后init回收该子进程并重新监听socket网络数据。

在服务cfg文件中添加”ondemand” : true 配置，设置socket服务为按需启动。

在fork 子进程的时候，判断服务是ondemand的，则创建socket监听。

通过回调函数ProcessWatchEvent_处理socket按需启动的事件。

4）热插拔服务进程按需启动

配置ueventd.cfg配置文件中设备节点属性，例如，/dev/binder属性配置为 ohos.dev.binder，当设备节点被创建好，param设置ohos.dev.binder属性值为added。

在相应服务的cfg文件中，配置”job”为condition，如下：

“condition” : “ohos.dev.binder=added”

即当条件满足时触发服务拉起。

5）定时拉起&fd代持

定时拉起：服务进程在退出前可根据业务需要预约下次启动的时间。

fd代持：按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可发fd发送给init代持，再次启动后再获取fd。

在服务的cfg配置"timer_start" : 6 ,设置服务6秒后拉起。通过LE_CreateTimer创建定时器，定时时间到达时，触发回调函数，拉起服务。

创建fdhold的socket，注册event loop回调函数ProcessFdHoldEvent监听。

5.并行启动及依赖管理

begetd启动分三个阶段，pre-init和init阶段完成公共依赖部分；后续所有的服务都是并行化启动。服务启动的依赖包括Job和Service。

1）Job

所有的Job由init特权进程完成，可包括：设置全局环境变量，设置特权/proc, /sys节点参数等。

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拉起服务。

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在开源社区中，通过大家的共同努力正在茁长成长，总有一天会长成苍天大树，枝繁叶茂，造福人类。

审核编辑 ：李倩