如何将RTOS系统启动时间做到“毫秒级”？AliOS Things是这样做的

1、背景

    随着人工智能的迅速发展，智能家居的时代已经到来，除了智能安全防盗门、智能门锁，智能音箱等市场快速增长外，智能猫眼行业异军突起，成为智能家居板块的重要品类。房门作为每个房子的入口，其智能化改进空间远不止门锁。智能入户安全是一套解决方案，不仅门锁需要智能化，猫眼这个需求本身也是和入户安全息息相关，或许会是智能家居最主要的入口之一。

    据新思界产业研究中心发布的《2019-2025年中国智能猫眼行业市场深度评估及市场前景预测报告》[1]，2017年全球智能家居设备在市场上的销售量为6.63亿台，预计到2023年，智能家居设备销售量将达到19.4亿台，超过智能手机销售量。自2014年以来，在智能家居市场的驱动下，智能猫眼市场膨胀速度惊人。据数据显示，2016年中国智能猫眼出货量超过60万台，同比增速超过40%，到2017年智能猫眼出货量超过110万台。

    单从这个数据来看倒也不用大惊小怪，但是如果我们换个角度从时间的维度来分析就会发现从2015年线上销售20万台到2017年的110万台，短短两年的时间整个销售数据却增加了5倍还多。而目前国内真正具有研发生产能力的电子猫眼厂家却屈指可数，整个市场已经出现了供不应求的局面，可见电子猫眼行业目前正处于红利期与爆发期。

    目前的智能猫眼一般具有红外夜视、移动侦测、Wi-Fi控制等。红外夜视功能是在子机内置了红外夜视灯，这样在晚上也能清晰的看清来访者。移动侦测即PIR人体感应当有人经过门前时会自动启动拍照或者录像功能记录来访者。Wi-Fi功能则可以实现手机与猫眼的远程连接，配合移动侦测功能当有人在门外移动时会自动推送信息到主人的手机上，但是目前具有Wi-Fi功能电子猫眼的功耗普遍较高，待机时间偏短，一个月可能就需要更换一次电池。

    智能猫眼的待机功耗主要是红外摄像头及其相应的电路，而移动侦测功能检测到有人经过门前时会自动启动猫眼内的摄像头进行拍摄或者录像功能记录来访者图像或视频，并且并且还要显示在屏幕上；因此，启动速度将会是影响功耗的重要原因。另外，为了实现防盗或安防的目的，当人体经过时需要即时完成启动并抓拍图像；人体经过摄像头的时间通常可能小于2秒钟，因此对启动速度提出了更高的要求。传统的Linux操作系统虽然全球通用，但也有其难以弥补的缺陷。Linux操作系统有庞大的内核，对任何中断指令的响应都需要一个复杂的处理过程，对一些需要快速响应的场合显得有些力不从心，系统重启更需要好几十秒。而RTOS实时操作系统内核小巧，对任何中断指令都可以做到马上响应，系统启动时间则只有几秒钟。因此如智能猫眼类的IPC（IP Camera）领域大量采用RTOS实时操作系统来保证系统的快速响应与高可靠性。

采用了RTOS实时操作系统的IPC设备可以在无需工作时进入深度休眠，一旦需要再快速启动，这种真待机功能为IPC设备大大降低功耗，提高IPC设备的待机时间。

2、竞品分析

    传统的RTOS操作系统相较于Linux系统具备快速启动的优势，启动时间可以达到1秒以内，如RTT Smart启动时间可以做到500 ms [2]。但这对于大多电池供电的IPC设备而言，启动时间仍然过长；因为IPC设备启动过程的电流高达几百毫安，因此启动时间的长短将对IPC设备的电池更换或充电频率仍然带来相当严重的影响。

图2-1 Linux

    传统RTOS的启动流程如图2-2所示，启动过程分成若干阶段，每个阶段完成不同的初始化操作。设备上电或重启或唤醒首先进入RESET入口函数，完成必要的CPU工作模式和系统栈初始化操作，接着进入RTOS内核入口再完成一系列硬件初始化操作；这些操作全部串行进行，如图2-2中完成pre_hw_1_init的初始化操作之后，再进行pre_hw_2_init的初始化操作；另外，硬件的初始化操作大部分都是需要一定时间来等待硬件电路的真正初始化完成，如pre_hw_1_init完成对应硬件寄存器写入操作之后，还需要等待对应的硬件真正完成初始化之后才可以进行后续硬件pre_hw_2_init的初始化操作，即使pre_hw_1_init和pre_hw_2_init没有依赖关系。传统的RTOS启动模型导致启动时间的进一步优化相当困难，因为硬件必须要确保真正完成初始化之后才可以进行相关操作，否则会带来不确定的错误。

图2-2 RTOS

    如果需要进一步降低RTOS的启动速度，进而降低IPC设备的待机时间，提高IPC设备的用户体验，传统RTOS的初始化模型将举步维艰。微内核AliOS Things引入了一种新的系统启动模型，启动时间相较于传统RTOS的启动时间降低一个数量级。

3、AliOS Things启动加速引擎

    传统RTOS的串行化启动模型，导致不同的初始化过程只能一个接一个的初始化，系统启动的总时间等于所有操作和等待硬件完成相关设置的时间，如图2-2中的，而其中大部分时间都是等待硬件完成相关设置的时间。而阶段内部的大部分初始化操作都是不相关的，完成可以并行化操作，也即pre_hw_1_init完成相关寄存器的读写操作后，在等待与pre_hw_1_init相关硬件完成具体设置的过程中进行pre_hw_2_init的初始化操作，这样与pre_hw_1_init和pre_hw_2_init相关具体硬件设置等待时间就可以重合，阶段的总用时就可以由降低为，模型如图3-1所示。

 图3-1 AliOS Things Bengine模型图

    Bengine提高初始化注册接口供系统按照不同的优先级注册初始化函数，相同优先级的初始化函数之间没有依赖关系，相同优先级的初始化函数由Bengine根据具体的执行时间负责分组，保证不同不同组之间的初始化函数的总用时均匀分布，同时确保所有高优先级的初始化函数执行完毕之后才会执行次优先级初始化例程。

图3-2 AliOS Things Bengine架构图

• init mgmt: 提供初始化例程的注册功能，注册时可以根据时间需要指定初始化例程的优先级；

• init grouping: 对相同优先级或相同阶段的初始化例程按照执行时间进行分组，保证每个组内的初始化例程总用时基本相同；

• grp scheduler: 对不同的分组启动多任务调度，同时保证所有的分组都执行完毕之后，再去处理次优先级的初始化阶段；

• grp schuduler: 不同的分组调度到不同的任务执行；
• grp sync: 不同分组的任务执行完组内的初始化例程之后，完成与调度器之间的同步，便于调度器处理次优先级的初始化例程；

• lockfree ipc: 采用高速并行化的IPC通信机制，保证初始化任务之间的高速并行，相互之间无干扰；

• bengine stat: 性能统计和初始化例程的执行时间统计；

    相较于传统的RTOS启动流程，Bengine的启动模型需要相关驱动进行简单的修改，但不牵涉到具体算法和驱动框架的修改，只是在驱动需要等待硬件完成相关设置时，主动让出CPU的执行权限（如图3-3中的红色标注的 sleep或者 sw_wait_for_sem操作），以便于让其他初始化获得执行的机会，具体改造示例如图3-3所示。

图3-3 Bengine代码示例

4、测试数据

    采用Bengine加速引擎的微内核AliOS Things与某厂商合作的IPC设备系统启动时间如图4-1所示，整个内核+驱动的启动总用时为57ms左右，相较于传统RTOS启动耗时500 ms基本降低了一个数量级；

图4-1 AliOS ThingsBengine

开发者支持

如需更多技术支持，可加入钉钉开发者群，或者关注微信公众号。

更多技术与解决方案介绍，请访问HaaS官方网站https://haas.iot.aliyun.com