架构设计(二) ~系统调度

1 架构设计

1.1 设计原则

SDK的主旨是打造一套方便用户使用的，稳定、舒适、便捷的解决方案，将用户关心的功能和逻辑进行结构化封装，最大限度地减少用户二次开发的工作量。为此，SDK的设计始终围绕着结构的层次化和功能的模块化两个角度进行架构。

1.2 设计思想

SDK的设计始终围绕着结构的层次化和功能的模块化两个角度进行架构。

• 层次化，即代码在逻辑和功能上进行分层设计，层次叠加，实施严格的层次内部的耦合管理和层次之间的调度管控，避免层次内部耦合调用和层次之间的嵌套使用逻辑，从而最大程度上保证代码的可阅读性、可移植性和稳定性。
• 模块化，即对具有相似逻辑的接口进行封装管理，进而形成诸多模块，层次内部的每个模块之间确保不耦合，从而极大地提高了代码的可扩展性。同时，为了方便用户理解和使用，系统在更高层次上，实现以底层模块为单元的，对各个具有相似功能的模块进行集成，进而实现具有特定功能属性的完整的功能体（功能体在该层中，也是属于该层的一个模块）。

1.3 发展方向

SDK发展方向：统一层级框架 -> 统一调度系统 -> 统一交互系统 -> 功能模块化 -> 应用组装化

2 软件框架

2.1 系统框架

        为了方便用户体验和使用本套系统，系统内含一套私有通信协议，配合专有PC工具，用户可直接使用SDK提供的应用DEMO，即可体验系统的完整功能。

2.2 层级关系

        SDK整体设计层次明确，层级之间不耦合或少耦合。SDK中各个层级按照系统逻辑与设计特色，可以分为三大类，即适配层(Adapter)、平台层(Platform)和用户层(User)。

        适配层(Adapter)是方便用户进行二次开发，而提供的便捷稳定的通用型接口或简易模块，可以极大提高用户的开发效率。

        平台层(Platform)，是系统的核心，

        应用层(App)是系统提供的，面向实体产品的应用例程。用户层主要是将某一功能集成一个模块，然后将多个模块组合形成完整的功能体，最后将多个功能体有序组合，进而性能完善的应用例程。应用层按照层级关系，又可分为MDI(Module Interface)、MMI(Man-Machine Interface)和APP(Application)：MDI，即模块设计接口，对单一功能进行集成和管理，提供一套更加简洁的交互接口，如BT的连接、查询、回连等；MMI，即人机交互接口，是将属于某一类型的功能或功能模块进行封装和集中管理，而形成的，简单的应用DEMO，并且为APP层提供交互接口；APP，即应用程序，是完整版的应用Demo，具有一定的产品功能和形态，用户可以直接在此基础上扩展或添加符合需求的逻辑，进而形成自己的产品。

• APP: Application(应用程序)
• MMI: Man-Machine Interface(人机交互接口)
• MDI: Module Design Interface(模块设计接口)
• API: Application Interface(应用调用接口)
• DEV: Devices(设备层，指驱动的外部设备)
• DRV: Drivers(驱动层，指驱动的驱动程序)

        另外，需要重点说明是层级之间调用的两种关系：一种是向下的逻辑交互关系；另一种是向上的逻辑通信关系。向下的逻辑交互，主要是上一层通过下发命令或直接调用下一层提供的接口，来实现对下一层的直接控制；向上的逻辑通信，主要是下一层通过上一层注册的回调接口，或者以事件的方式，来将自身获取的数据或者状态改变，上报到上一层，从而达到上下层数据和状态的同步。

2.3 模块封装

        SDK采用对象化的设计思想，对各个功能体进行模块化封装。同时，为了减低程序代码的臃肿，系统又引入了单元的概念，对模块又进一步拆分。这样即保证了系统的稳定可靠，又使得代码逻辑清晰，便于移植和拓展。

        如下图所示，简要展示了目前系统中的主要功能(Functive)、模块(Module)和单元(Unit)。目前系统中主要有六大功能体，即系统管理、蓝牙管理、音频管理、文件管理、电话管理和测试管理，分别由系统中的六个进程(Process)驱动。

        需要注意的是，系统中的功能(Functive)、模块(Module)和单元(Unit)是一个相对的关系，并不是绝对的。如下图所示，系统的对象化封装是层层嵌套的，最简单的模式是第一张图所展现的模型，即单纯的由单元组合成模块，再由模块组合成功能，如音频相关的封装逻辑；但是，系统中还包含很多更加复杂的封装逻辑，即第二张图展现的模型，如USB、BT相关的封装逻辑。

3 系统调度

3.1 调度机制

        目前，SDK是按照兼容操作系统和非操作系统两种方式设计的，即系统中有多个主进程，各个主进程既可以单独运行在操作系统的一个任务中（代码在优化迭代中，暂时不支持），又可以多个一起运行在操作系统的一个任务中。进程主要负责调度和运行系统中各个线程，每个进程都可以挂载一个或多个线程/任务。线程主要负责处理对应层次的功能和逻辑，线程是单独的运行主体，是面向用户开发或者用户自己开发的实现某种逻辑的功能集合。多个进程协调，多个线程有序执行，从而构成整个系统运行生态。

        系统调度是保证软件逻辑有序运行的基础，位于平台层下(Platform)的系统管理层(sys/tsk)。

为了兼容操作系统和非操作系统两种运行模式，系统虚拟出进程(Process)和线程/任务(Task)的概念，线程可以通过动态挂载（调用sys_mount()）的形式，嵌入到进程里运行。每个进程都维护一个消息队列和一个适配器：

• 消息队列负责进程间或进程内部的通信交互，是目前系统中唯一支持的通信方式。
• 适配器中维护一张工作队列表和一张定时任务表，适配器是保证系统内部各个线程有序运行的基础。为了保证系统有序高效运行，系统中各个线程需要通过对应进程的适配器获取运行资源。

3.2 定时调度

定时调度是进程按照给定时间间隔和执行次数，自动完成任务调度执行的一种调度方式。定时调度可以减少系统的运行时间，提高MCU的利用率。

系统中定时任务是按照执行时间先后顺序进行排序执行，支持的接口如下：

• 初始化任务，sys_adapt_initTimer，线程里调用该接口，完成自身定时任务的初始化动作。
• 更新任务，sys_adapt_updateTimer，线程里调用该接口，可以对自身调度的时间参数进行更新，并选择性插入到进程的定时任务表中。
• 插入任务，sys_adapt_insertTimer，线程里调用该接口，可以将自身的定时任务插入到进程的定时任务表中。
• 移除任务，sys_adapt_removeTimer，线程里调用该接口，可以将自身的定时任务，从进程的任务列表中移除。（除此方法之外，移除定时任务还有另外一种方法，即在任务执行回调结束后，返回false）

线程中使用进程的定时任务调度机制，需要注意以下几点：

1. 线程中的定时任务，必须插入其所属进程的列表中，否则在支持操作系统模式下，会引发异常。
2. 定时任务的控制结构体，在插入进程列表后，线程本身不能直接操作该结构体中的变量，否则会引发整个系统的异常。
3. 一个线程可以同时向进程列表中，插入一个或多个定时任务，定时任务的时间间隔，确定了该任务调度的频率。（考虑功耗和执行效率的因素，建议该间隔在符合逻辑的情况下，尽可能大一些）

3.3 工作队列

工作队列是将任务推后执行的一种系统调度方式。相较于定时调度，工作队列可以在很大程度上保证任务的及时执行，适用于需要推后执行的重要或紧急的任务。

系统中的队列任务是按照插入的先后顺序执行的，支持的接口如下：

• 初始化任务，sys_adapt_initQueue，线程里调用该接口，完成自身队列任务的初始化动作。
• 插入任务，sys_adapt_appendQueue，系统里调用该接口，可以将自身的队列任务插入到进程的定时任务表中。
• 移除任务，sys_adapt_removeQueue，线程里调用该接口，可以将自身的队列任务，从进程的任务列表中移除。（除此方法之外，移除队列任务还有另外一种方法，即在任务执行回调结束后，返回false）

3.4 消息队列

目前系统调度系统中，只支持一种进程内部和进程间的通信，即消息队列，该队列在进程中维护。该消息队列有两种运行模式，在有操作系统的情况下，以队列缓存执行的方式运行；在非操作系统中，以回调直接执行的方式运行。

系统中通信方式相关的接口如下：

• 发送内部消息，sys_sendInnerMsg，内部消息是原生于系统内部产生的交互消息。
• 发送外部消息，sys_sendOuterMsg，外部消息是原生于系统外部产生的交互消息，比如从串口接收到的控制指令。

4 工作模式

系统定义了两种工作模式，即正常模式和测试模式，正常模式是程序Release的默认公式模式，测试模式是为了验证系统可靠性或者调试系统问题而引入的一种模式。目前系统的测试模式有四种，即认证模式、工厂模式、研测模式和自测模式。

4.1 厂测模式

工厂模式是为工厂生产的场景下的，测试和验证模式。

4.2 认证模式

4.3 研测模式

研测模式是研发端进行测试和验证的模式。