CN116737672B - 嵌入式操作系统中文件系统的调度方法、设备及存储介质 - Google Patents

Abstract

本申请提供了一种嵌入式操作系统中文件系统的调度方法、设备及存储介质。该方法通过引入优先级，并根据用户的实际使用情况动态调整所遵循的文件服务调度策略中规定的优先级，从而使嵌入式操作系统中的文件系统能够得到合理调度，既能使紧迫的任务可以优先调度文件系统，又能兼顾快要饿死的任务能够及时被调度，避免线程饿死。

Description

嵌入式操作系统中文件系统的调度方法、设备及存储介质

技术领域

本申请涉及嵌入式操作系统技术领域，尤其涉及一种嵌入式操作系统中文件系统的调度方法、设备及存储介质。

背景技术

随着嵌入式操作系统的飞速发展，嵌入式操作系统中的文件系统(下文称为；嵌入式文件系统)作为嵌入式操作系统的重要组成部分，对于实现嵌入式系统中大量数据的存储和各种操作的管理，有着不可替代的作用。

由于嵌入式操作系统资源有限、处理能力有限，因此在启动多线程执行不同任务时，可能会同时或小间隔的调用嵌入式文件系统，如果不加保护或处理，可能会导致触发不同任务的应用程序之间发生冲突，进而造成卡顿；或者某些应用程序的调度被不断延迟，导致不能及时调度，更甚者由于得不到调度导致线程饿死，最终导致设备死机重启等。

发明内容

为了解决上述技术问题，本申请提供一种嵌入式操作系统中文件系统的调度方法、设备及存储介质，通过引入优先级，并根据用户的实际使用情况动态调整优先级，从而使嵌入式操作系统中的文件系统能够得到合理调度，既能使紧迫的任务可以优先调度文件系统，又能兼顾快要饿死的任务能够及时被调度，避免线程饿死。

第一方面，本申请提供一种嵌入式操作系统中文件系统的调度方法，应用于第一电子设备，第一电子设备集成了嵌入式操作系统，嵌入式操作系统包括文件系统。该方法包括：基于第一文件服务调度策略，根据获取到的第一任务的消息请求和第二任务的消息请求对文件系统进行调度，第一文件服务调度策略规定了第二任务的优先级高于第一任务的优先级；在基于第一文件服务调度策略对文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据；采用预设方式对应的预设传输方式，将DFT数据传输给第二电子设备；获取第二电子设备根据DFT数据对第一文件服务调度策略进行调整得到的第二文件服务调度策略；基于第二文件服务调度策略对文件系统进行调度，第二文件服务调度策略规定了第二任务的优先级低于或等于第一任务的优先级。

其中，第一文件服务调度策略，例如下文所说的文件服务调度策略V1.0。

相应地，第二文件服务调度策略，例如下文所说的文件服务调度策略V2.0。

可理解的，不论是第一文件服务调度策略，还是第二文件服务调度策略，在实际应用中，均可规定下文所说的，按照时间先后顺序，或者按照任务对应的优先级顺序，或者根据收集的可测性设计数据分析获得的顺序，将不同任务的消息请求添加到队列中的优先级策略表。

即，第一文件服务调度策略和第二文件服务策略中规定了不同任务的优先级。具体到本申请中，以第一文件服务调度策略规定了第一任务和第二任务的优先级，且第二任务的优先级高于第一任务的优先级为例。即，在有第二任务对应的消息请求和第一任务对应的信息请求等待调度时，优先响应第二任务的消息请求。

相应地，基于收集的DFT数据，确定实际使用中，期望第一任务的消息请求优先响应的期望值更高，基于该DFT数据，通过对第一文件服务调度策略进行调整，可以使得第二文件服务调度策略中规定的第二任务的优先级低于或等于第一任务的优先级，这样后续基于第二文件服务调度策略进行文件系统的调度时，会优先响应第一任务的消息请求。

由此，通过引入优先级，并根据用户的实际使用情况动态调整所遵循的文件服务调度策略中规定的优先级，从而使嵌入式操作系统中的文件系统能够得到合理调度，既能使紧迫的任务可以优先调度文件系统，又能兼顾快要饿死的任务能够及时被调度，避免线程饿死。

根据第一方面，基于第一文件服务调度策略，根据获取到的第一任务的消息请求和第二任务的消息请求对文件系统进行调度，包括：在第一时刻获取到第一任务的第一消息请求，第一消息请求包括第一文件操作指令；在第二时刻获取到第一任务的第二消息请求，第二消息请求包括第二文件操作指令，第二时刻晚于第一时刻；响应于第一消息请求，执行第一文件操作指令；在执行第二文件操作指令之前，在第三时刻获取到第二任务的第三消息请求，第三消息请求包括第三文件操作指令，第三时刻晚于第二时刻；基于第一文件服务调度策略，选择第三消息请求，执行第三文件操作指令；在执行第三文件操作指令之后，执行第二文件操作指令。

其中，第一任务例如下文所说的task1，第二任务例如下文所说的task2。

示例性的，对于第一消息请求和第二信息请求来自task1，第三消息请求来自task2的场景，第一消息请求例如下文所说的Req1，第二消息请求例如下文所说的Req2，第三消息请求例如下文所说的Req4。

示例性的，在实际应用中，第一任务还可以包括其他消息请求，如下文所说的Req3，甚至更多，第二任务也可以包括其他消息请求如下文所说的Req5，甚至更多。

此外，可以理解的，在实际应用中，还可以接收更多任务提供的消息请求。

其中，第一文件操作指令、第二文件操作指令、第三文件操作指令，可以是下文所说的由封装模块封装的读操作、写操作、打开操作、关闭操作、删除操作、获取文件属性状态操作、移动操作等文件操作中的任意一种。

示例性的，在一些实现方式中，执行第一文件操作指令和获取第二消息请求的顺序，例如可以是先执行第一文件操作指令，在执行第一文件操作指令的过程中获取第二消息请求；也可以是先获取第二消息请求，在获取到第二消息请求后或获取第二消息请求的过程中，执行第一文件操作指令。

关于第一任务和第二任务的优先级的确定，例如示通过对应的消息请求中携带的任务标识号，在第一文件服务调度策略指示的优先级策略表中查表确定的。

由此，通过引入优先级的概念，并将每一个访问文件系统服务的任务中的文件操作指令封装为一个消息请求，在有多个任务的多个消息请求时，通过对这些消息请求按照优先级排序，确定合理的响应序列，使得不同任务提供的不同消息请求能够得到合理的响应，进而根据对应的消息请求中的文件操作指令对文件系统进行合理调度。

根据第一方面，在执行第三文件操作指令之前，方法还包括：当第一消息请求中包括操作结果通知信号量参数，且操作结果通知信号量参数指示下一个要执行的文件操作指令的来源为第一任务时，执行第二文件操作指令；当第一消息请求中包括操作结果通知信号量参数，且操作结果通知信号量参数指示下一个要执行的文件操作指令的来源为第二任务时，执行第三文件操作指令的步骤；当第一消息请求中不包括操作结果通知信号量参数时，执行第三文件操作指令的步骤。

通过下文描述可知，消息请求可以结构体的形式在嵌入式操作系统中传递，而本申请中，由封装模块封装的结构体中会根据任务之间的关联性确定是否封装操作结果通知信号量参数，并对其赋值。

关于基于上述参数实现具有关联性的两个任务的消息请求的执行顺序的调度，可以参见下文，此处不再赘述。

由此，对于具有关联性的两个任务，通过根据关联性指示的顺序选择对应的消息请求，执行对应的文件操作指令，从而更加贴合实际应用场景。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：当第二任务的优先级低于或等于第一任务的优先级时，在执行第一文件操作指令之后，执行第二文件操作指令。

由此，根据提供消息请求的任务的优先级，确定是优先响应新接收到的消息请求，还是之前接收到的消息请求，这样既可以优先响应高优先级的任务提供的消息请求，也可以保证低优先级的消息请求中的文件操作指令能够被调度。

根据第一方面，或者以上第一方面的任意一种实现方式，在第三时刻获取到第二任务的第三消息请求之后，方法还包括：将第三消息请求添加到第一队列中，第一队列中还包括等待调度的第二消息请求；在执行第一文件操作指令的过程，记录第二消息请求在第一队列中等待调度的第二饥饿时间，以及第三消息请求在第一队列中等待调度的第三饥饿时间；当第二饥饿时间未达到对应的第二饥饿时间阈值，第三饥饿时间达到对应的第三饥饿时间阈值时，将第三消息请求从第一队列中移动到第二队列，第二消息请求继续在第一队列，第二队列的优先级高于第一队列的优先级，第二队列当前仅包括第三消息请求。

其中，第一队列例如下文所说的普通队列。

其中，第二队列例如为下文所说的VIP队列，即队列整体优先级高于普通队列的队列。

由此，通过记录第一队列中未被调度的消息请求的饥饿时间，从而能够获知已经进入第一队列的消息请求等待被调度的时间，在饥饿时间达到该消息请求对应的饥饿时间阈值时，通过将其移动到优先级高的第二队列，以便下次文件调度所选择的消息请求是来自第二队列的，进而避免已经接收到的消息请求长时间处于等待状态导致软够超时。

也就是说，根据每一个消息请求对应的饥饿时间和饥饿时间阈值，实现了消息请求从第一队列移动到第二队列，从而实现对了消息请求执行优先级的调整，使得当前的文件操作指令执行完后，能够优先选择第二队列中的消息请求，这样即便被移动的消息请求优先级低，由于第二队列的整体优先级高于第一优先级，也可以使低优先级的消息请求被调用，即基于本申请提供的技术方案，既能兼顾高优先级的消息请求被及时调度，又能保证低优先级的消息请求被调度，有效避免软狗超时的现象发生。

根据第一方面，或者以上第一方面的任意一种实现方式，在执行第二文件操作指令之前，方法还包括：当第二队列中存在第三消息请求时，从第二队列选择第三消息请求，执行第三文件操作指令；当第二队列中不存在第三消息请求时，从第一队列选择第二消息请求，执行第二文件操作指令的步骤。

由此，通过设置不同优先级的两个队列，如上文中的普通队列(低优先级)和VIP队列(高优先级)，在当前的文件操作指令执行完后，当第三消息从第一队列移动到第二队列时，便可以确定第三消息请求的优先级高于第二消息请求的优先级，这样即便第三消息请求触发的时间晚于第二消息请求，或者提供第三消息请求的第二任务的优先级低于提供第二消息请求的第一任务的优先级，也可以优先响应第三消息请求，从而使得消息请求能够对文件系统服务进行合理调度，既能使紧迫的任务可以优先调度文件系统，又能兼顾快要饿死的任务能够及时被调度，避免线程饿死。

根据第一方面，或者以上第一方面的任意一种实现方式，从第二队列选择第三消息请求，执行第三文件操作指令之后，所述方法还包括：当第二队列对应的喂饱时间达到第二队列对应的喂饱时间阈值时，从第一队列中选择第二消息请求，执行第二文件操作指令，喂饱时间指示第二队列中所有消息请求被调度的时间总和。

由此，通过为第二队列设置一个喂饱时间阈值，在第二队列中消息请求的调度时间达到喂饱时间阈值时，停止从第二队列中选择消息请求，而是从第一队列选择，从而平衡了不同优先级的消息请求都可以被调度，使得文件系统服务的调度更加合理。

根据第一方面，或者以上第一方面的任意一种实现方式，从第二队列选择第三消息请求，执行第三文件操作指令之后，所述方法还包括：当第二队列对应的喂饱时间未达到第二队列对应的喂饱时间阈值，第二队列没有等待调度的消息请求时，从第一队列中选择第二消息请求，执行第二文件操作指令。

由此，通过第二队列对应的喂饱时间阈值，以及当前队列中是否存在等待调度的消息请求的情况，确定接下来要执行的文件指令是来自第二队列还是第一队列，从而实现了在第一队列和第二队列之间进行合理切换，使得选择的消息请求更加适合当前调度场景。

根据第一方面，或者以上第一方面的任意一种实现方式，从第二队列选择第三消息请求，执行第三文件操作指令的过程中，方法还包括：在第六时刻获取到第三任务的第六消息请求，第六消息请求包括第六文件操作指令，第六时刻晚于第三时刻；将第六消息请求添加到第一队列中，第一队列中还包括等待调度的第二消息请求；记录第六消息请求在第一队列中等待调度的第六饥饿时间，以及继续记录第二消息请求在第一队列中等待调度的第二饥饿时间；当第二饥饿时间未达到对应的第二饥饿时间阈值，第六饥饿时间达到对应的第六饥饿时间阈值时，将第六消息请求从第一队列中移动到第二队列。

由此，通过实时或定期判断每一个消息请求的饥饿时间是否大于其对应的饥饿时间阈值，从而能够将达到饥饿时间阈值的消息请求及时从第一队列移动到第二队列，以便下次能够优先调度。

根据第一方面，或者以上第一方面的任意一种实现方式，在执行第三文件操作指令之后，方法还包括：当第二队列对应的喂饱时间未达到第二队列对应的喂饱时间阈值，第二队列中包括第六消息请求时，从第二队列中选择第六消息请求，执行第六文件操作指令。

由此，能够在第一队列和第二队列之间进行合理切换，使得选择的目标消息请求更加适合当前调度场景。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：当第二饥饿时间未达到对应的第二饥饿时间阈值，第三饥饿时间未达到对应的第三饥饿时间阈值时，第二消息请求和第三消息请求继续在第一队列中等待调度；当第二任务的优先级低于或等于第一任务的优先级时，在执行第一文件操作指令之后，执行第二文件操作指令，包括：从第一队列中选择第二消息请求，执行第二文件操作指令。

根据第一方面，或者以上第一方面的任意一种实现方式，基于第二文件服务调度策略对文件系统进行调度，包括：在第四时刻获取到第一任务的第四消息请求，第四消息请求包括第四文件操作指令，第五时刻晚于第四时刻；在第五时刻获取到第二任务的第五消息请求，第五消息请求包括第五文件操作指令；基于第二文件服务调度策略，选择第四消息请求，执行第四文件操作指令；在执行第四文件操作指令之后，执行第五文件操作指令。

由此，根据新得到的第二文件服务调度策略，从而可以将原本优先级高的第二任务，调整为低于或等于第一任务，进而优先响应先接收到的第一任务的第四消息请求，执行第四文件操作指令，实现了不同任务的优先级的动态调整，使得对文件系统的调度能够更好的适用于实际的使用需求。

根据第一方面，或者以上第一方面的任意一种实现方式，在基于第一文件服务调度策略对文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：在执行第一文件操作指令、第二文件操作指令和第三文件操作指令的过程中，采用预设方式收集DFT数据。

即，在每响应一个消息请求，执行一次文件操作指令的过程中，均进行DFT数据的收集，从而能够确保DFT数据可以精准的反映用户的使用习惯，以及嵌入式操作系统中文件系统的调度情况，进而保证后续基于DFT数据对第一文件服务调度策略进行调整获得的第二文件服务调度策略更加符合用户的使用需求。

根据第一方面，或者以上第一方面的任意一种实现方式，根据DFT数据对第一文件服务调度策略进行调整，包括：根据DFT数据中的调用者统计信息、文件请求次数、预设时间内请求最多的上层应用、上层应用对应的消息请求失败的次数，对第一文件服务调度策略中针对业务合理性的参数、针对不同任务的优先级进行调整。

关于上述调整，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据DFT数据对第一文件服务调度策略进行调整，包括：根据DFT数据中上层应用对应的消息请求失败的次数、上层应用触发消息请求到处理完的响应时长，对第一文件服务调度策略中针对上层应用的消息请求对应的超时时间的参数进行调整。

关于上述调整，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据DFT数据对第一文件服务调度策略进行调整，包括：根据DFT数据中每个消息请求在第一队列的饥饿时间，对第一文件服务调度策略中针对不同任务对应的消息请求的饥饿时间阈值的参数进行调整，第一队列用于存储在不同时刻获取到的消息请求。

关于上述调整，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据DFT数据对第一文件服务调度策略进行调整，包括：根据DFT数据中第二队列的总运行时长，对第一文件服务调度策略中针对第二队列的喂饱时间阈值的参数进行调整，第二队列用于存放从第一队列中饥饿时间达到饥饿时间阈值的消息请求，第二队列的优先级高于第一队列。

根据第一方面，或者以上第一方面的任意一种实现方式，根据DFT数据对第一文件服务调度策略进行调整，包括：根据DFT数据中被调用最多的应用编程接口、被访问最多的文件，对第一文件服务调度策略中对被调度的文件在存储器存放位置的参数进行调整。

关于上述调整，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，在采用预设传输方式，将DFT数据传输给第二电子设备之前，方法还包括：判断是否与第二电子设备建立了预设传输方式对应的通信连接；当与第二电子设备建立了预设传输方式对应的通信连接时，执行采用预设传输方式，将DFT数据传输给第二电子设备的步骤；当未与第二电子设备建立了预设传输方式对应的通信连接时，根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

由此，在第一电子设备与第二电子设备之间不存在通信连接时，由第一电子设备自己根据收集到的DFT数据对第一文件服务策略进行调整，从而使得离线状态下，第一电子设备也可以根据用户在历史时间内使用其进行文件系统调度过程中产生的DFT数据对已有的第一文件服务调度策略进行调整，从而使得接下来更能适合实际使用需求的第二文件服务调度策略。

根据第一方面，或者以上第一方面的任意一种实现方式，预设方式为大数据看板方式，预设传输方式为云端传输方式；在基于第一文件服务调度策略对文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：在基于第一文件服务调度策略对文件系统进行调度的过程中，通过设定的接口将调度过程中产生的DFT数据集成到大数据看板中；采用预设方式对应的预设传输方式，将DFT数据传输给第二电子设备，包括：通过嵌入式操作系统中的视图系统，调用设定的接口，将集成到大数据看板中的DFT数据输出；通过视图系统提供的用于记录数据的接口，将DFT数据写入到离线的视图系统；通过云端传输方式，将写入离线的视图系统的DFT数据传输给第二电子设备。

关于大数据看板的DFT数据传输方式的具体实现细节，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，预设方式为日志方式，预设传输方式为存储芯片获取方式；在基于第一文件服务调度策略对文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：在基于第一文件服务调度策略对文件系统进行调度的过程中，生成日志文件；将日志文件存储到存储芯片；采用预设方式对应的预设传输方式，将DFT数据传输给第二电子设备，包括：按照预设周期，从存储芯片中读取日志文件，并将读取到的日志文件传输给第二电子设备。

关于存储芯片的DFT数据传输方式的具体实现细节，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，预设方式为日志方式，预设传输方式为总线输入方式；在基于第一文件服务调度策略对文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：在基于第一文件服务调度策略对文件系统进行调度的过程中，生成日志文件；将日志文件存储到存储芯片；采用预设方式对应的预设传输方式，将DFT数据传输给第二电子设备，包括：通过连接第一电子设备与第二电子设备的总线，将日志文件实时传输给第二电子设备。

关于总线方式的DFT数据传输方式的具体实现细节，可以参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二文件服务调度策略由第二电子设备生成时，方法还包括：将每一个第一电子设备收集的DFT数据进行融合；根据融合后的DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

由此，通过将多个第一电子设备收集到的DFT数据进行融合，进而根据融合后的DFT数据对第一文件服务调度策略进行调整，生成同一份第二文件服务调度策略，从而能够避免存储多个相同的第二文件服务调度策略，进入避免冗余，降低对资源的浪费。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二文件服务调度策略由第二电子设备生成时，方法还包括：对于每一个第一电子设备，根据第一电子设备收集的DFT数据，对第一文件服务调度策略进行调整，得到第一电子设备对应的第二文件服调度策略。

由此，根据每一个第一电子设备，如智能手表收集的DFT数据对第一文件服务调度策略进行调整，进而生成仅针对该设备的第二文件服务调度策略，实现了因设备而异，因用户使用行为而异，从而可以更好的满足用户的定制化需求，使得不同用户使用的嵌入式操作系统的电子设备所遵循的第二文件服务调度策略能够更好的满足用户需求。

第二方面，本申请提供了一种电子设备。该电子设备集成了嵌入式操作系统，嵌入式操作系统中包括文件系统，电子设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述电子设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1a～图1d为示例性示出的嵌入式操作系统中不同读、写场景的示意图；

图2a、图2b为示例性示出集成嵌入式操作系统的智能手表触发多线程多任务的场景示意图；

图3为示例性示出的基于本申请实施例提供的嵌入式操作系统中文件系统的调用方法对智能手表触发多线程多任务的场景示意图；

图4为示例性示出的集成嵌入式操作系统的电子设备的软件结构示意图；

图5为示例性示出的本申请实施例在底层软件服务中新增的文件系统调度服务与原生的文件系统服务之间的交互示意图；

图6为示例性示出的本申请实施例提供的嵌入式操作系统中文件系统的调用方法的流程示意图；

图7a～图7d为示例性示出的调度模块根据调度策略调整普通队列和VIP队列中的消息请求的示意图；

图8a为示例性示出的基于本申请实施例提供的嵌入式操作系统中文件系统的调度方法对文件系统进行调度执行文件操作的示意图；

图8b为示例性示出的对原生文件系统进行调度执行文件操作的示意图；

图9a～图9c为示例性示出的申请实施例在底层软件服务中新增的文件系统调度服务中引入可测性设计DFT数据收集模块的示意图；

图10a～图10d为示例性示出的收集DFT数据生成文件服务调度策略的示意图；

图11为示例性示出的本申请实施例提供的嵌入式操作系统中文件系统的调用方法的流程示意图；

图12为示例性示出的DFT数据与文件服务调度策略中参数之间关联性的示意图；

图13为示例性示出的本申请实施例提供的嵌入式操作系统中文件系统的调用方法的流程示意图；

图14为示例性示出的本申请实施例提供的嵌入式操作系统中文件系统的调用方法的流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

随着嵌入式操作系统的飞速发展，嵌入式操作系统中的文件系统(下文称为；嵌入式文件系统)作为嵌入式操作系统的重要组成部分，对于实现嵌入式系统中大量数据的存储和各种操作的管理，有着不可替代的作用。

对于嵌入式操作系统，它具备的一个特性是能够通过不同线程完成不同任务，该特性可以复用到嵌入式操作系统中的文件系统(可以称为嵌入式文件系统，也即下文所说的文件系统服务)。具体到实际应用中，线程执行对应任务的顺序实质是根据任务对应的消息请求到达的先后顺序确定的。

为了便于理解，以下结合实例，分别以两个读任务、两个写任务、一个读任务一个写任务的场景，对目前多线程多任务的嵌入式操作系统中的文件系统的处理逻辑进行说明。

参见图1a，示例性的示出子线程Thread1-read执行的读任务1先触发，子线程Thread2-read执行的读任务2后触发，即读任务1的触发时间早于读任务2的触发时间。基于上述前提，子线程Thread1-read会先执行其对应的读任务1，在一些实现方式中，读任务1例如包括图1a中示出的r1、r2、r3、r4这4个文件操作指令，而子线程Thread2-read需要在子线程Thread1-read执行完读任务1包括的4个文件操作指令后，才会执行其对应的读任务2，在一些实现方式中，读任务2例如包括图1a中示出的r1、r2、r3、r4这4个文件操作指令。

继续参见图1a，集成嵌入式操作系统，且具备文件系统服务的电子设备启动创建主线程Main-Thread后，Main-Thread会创建第一子线程和第二子线程。由于本场景为针对不同时间触发的读任务的场景，故而创建的两个子线程均为用于执行读任务的子线程，为了区分，本实施例以第一子线程为Thread1-read，第二子线程为Thread2-read。

继续参见图1a，在Thread1-read和Thread2-read创建后，如果Main-Thread接收到了读任务1，而读任务1包括r1、r2、r3、r4这4个文件操作指令，Main-Thread会通知Thread1-read依次根据r1、r2、r3、r4这4个文件操作指令进行文件调度，即对文件系统服务进行调度操作。

由于图1a所示的场景为读任务的场景，故而上述所说的r1、r2、r3、r4这4个文件操作指令具体是与读任务相关的文件操作指令。具体到本申请中，r1可以为直接读取指令(Read)，r2可以为偏移读取指令(Seek-Read)，r3可以为反向读取指令(Backward-Read)，r4可以为随机读取指令(Random-Read)。

继续参见图1a，由于Thread1-read抢占了任务锁，因此在Thread1-read执行r1、r2、r3、r4指令对应的操作时，Thread2-read需要等待，待Thread1-read执行完最后一个文件操作指令，即r4，释放任务锁后，Thread2-read才能够抢占任务锁，进而执行读任务2包括的r1、r2、r3、r4指令对应的操作，待Thread2-read执行完最后一个文件操作指令，即r4，释放任务锁后，通知Main-Thread。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，Thread1-read要执行的读任务1所包括的文件操作指令，可以是上述所说的r1、r2、r3、r4中的任意一个或几个，具体根据实际业务确定，本申请对此不作限制。相应地，Thread2-read要执行的读任务2所包括的文件操作指令，也可以是上述所说的r1、r2、r3、r4中的任意一个或几个，本申请对此不作限制。

此外，需要说明的是，本申请各实施例中所说的任务，如上文所说的读任务1、读任务2，以及下文所说的写任务1、写任务2等，具体是指所要做的事情。这些要做的事情由文件操作指令来标识，即文件系统服务在响应于上述任务，实现文件调度时具体是根据任务对应的文件操作指令进行的。

例如上文所说，在读任务1包括r1、r2、r3、r4这4个文件操作指令时，响应于读任务1，文件系统服务进行的文件调度，会依次根据r1、r2、r3、r4这4个文件操作指令进行文件调度。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

参见图1b，示例性的示出子线程Thread2-write执行的写任务2先触发，子线程Thread1-write执行的写任务1后触发，即写任务2的触发时间早于写任务1的触发时间。基于上述前提，子线程Thread2-write会先执行其对应的写任务2，在一些实现方式中，写任务2例如包括图1b中示出的w1、w2、w3、w4这4个文件操作指令，而子线程Thread1-write需要在子线程Thread2-write执行完写任务2包括的4个文件操作指令后，才会执行其对应的写任务1，在一些实现方式中，写任务1例如包括图1b中示出的w1、w2、w3、w4这4个文件操作指令。

继续参见图1b，集成嵌入式操作系统，且具备文件系统服务的电子设备启动创建主线程Main-Thread后，Main-Thread会创建第一子线程和第二子线程。由于本场景为针对不同时间触发的写任务的场景，故而创建的两个子线程均为用于执行写任务的子线程，为了区分，本实施例以第一子线程为Thread1-write，第二子线程为Thread2-write。

继续参见图1b，在Thread1-write和Thread2-write创建后，如果Main-Thread接收到了写任务2，而写任务2包括w1、w2、w3、w4这4个文件操作指令，Main-Thread会通知Thread2-write依次根据w1、w2、w3、w4这4个文件操作指令进行文件调度。

由于图1b所示的场景为写任务的场景，故而上述所说的w1、w2、w3、w4这4个文件操作指令具体是与写任务相关的文件操作指令。具体到本申请中，w1为直接写指令(Write)，w2为重写指令(Re-Write)，w3为随机写指令(Random-Write)，w4为随机重写指令(Random-Re-Write)。

继续参见图1b，由于Thread2-write抢占了任务锁，因此在Thread2-write执行w1、w2、w3、w4指令对应的操作时，Thread1-write需要等待，待Thread2-write执行完最后一个指令，即w4，释放任务锁后，Thread1-write才能够抢占任务锁，进而执行写任务1包括的w1、w2、w3、w4指令对应的操作，待Thread1-write执行完最后一个指令，即w4，释放任务锁后，通知Main-Thread。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，Thread1-write要执行的写任务1所包括的文件操作指令，可以是上述所说的w1、w2、w3、w4中的任意一个或几个，具体根据实际业务确定，本申请对此不作限制。相应地，Thread2-write所包括的文件操作指令，也可以是上述所说的w1、w2、w3、w4中的任意一个或几个，本申请对此不作限制。

参见图1c，示例性的示出子线程Thread2-write执行的写任务2先触发，子线程Thread1-read执行的读任务1后触发，即写任务2的触发时间早于读任务1的触发时间。基于上述前提，子线程Thread2-write会先执行其对应的写任务2，而子线程Thread1-read需要在子线程Thread2-write执行完对应的写任务2包括的文件操作指令后，才会执行其对应的读任务1。

继续参见图1c，集成嵌入式操作系统，且具备文件系统服务的电子设备启动创建主线程Main-Thread后，Main-Thread会创建第一子线程和第二子线程。由于本场景为先写后读场景，故而创建的两个子线程一个是用于执行读任务的，一个是用于执行写任务的，为了区分，本实施例以第一子线程为Thread1-read，第二子线程为Thread2-write。

继续参见图1c，在Thread1-read和Thread2-write创建后，如果Main-Thread接收到了写任务2，而写任务2包括w1、w2、w3、w4这4个文件操作指令，Main-Thread会通知Thread2-write依次根据w1、w2、w3、w4这4个文件操作指令进行文件调度。

继续参见图1c，由于Thread2-write抢占了任务锁，因此在Thread2-write执行w1、w2、w3、w4指令对应的操作时，Thread1-read需要等待，待Thread2-write执行完最后一个指令，即w4，释放任务锁后，Thread1-read才能够抢占任务锁，进而执行读任务1包括的r1、r2、r3、r4指令对应的操作，待Thread1-read执行完最后一个指令，即r4，释放任务锁后，通知Main-Thread。

参见图1d，示例性的示出子线程Thread1-read执行的读任务1先触发，子线程Thread2-write执行的写任务2后触发，即读任务1的触发时间早于写任务2的触发时间。基于上述前提，子线程Thread1-read会先执行其对应的读任务1，而子线程Thread2-write需要在子线程Thread1-read执行完对应的读任务1包括的文件操作指令后，才会执行其对应的写任务2。

继续参见图1d，集成嵌入式操作系统，且具备文件系统服务的电子设备启动创建主线程Main-Thread后，Main-Thread会创建第一子线程和第二子线程。由于本场景为先读后写场景，故而创建的两个子线程一个是用于执行读任务的，一个是用于执行写任务的，为了区分，本实施例以第一子线程为Thread1-read，第二子线程为Thread2-write。

继续参见图1d，在Thread1-read和Thread2-write创建后，如果Main-Thread接收到了读任务1，而读任务1包括r1、r2、r3、r4这4个文件操作指令，Main-Thread会通知Thread1-read依次根据r1、r2、r3、r4这4个文件操作指令进行文件调度。

继续参见图1d，由于Thread1-read抢占了任务锁，因此在Thread1-read执行r1、r2、r3、r4指令对应的操作时，Thread2-write需要等待，待Thread1-read执行完最后一个指令，即r4，释放任务锁后，Thread2-write才能够抢占任务锁，进而执行写任务2包括的w1、w2、w3、w4指令对应的操作，待Thread2-write执行完最后一个指令，即w4，释放任务锁后，通知Main-Thread。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，主线程Main-Thread启动后，创建的子线程个数可以根据应用程序层安装的应用程序的数量和/应用程序框架层提供的服务创建，即子线程的数量不并不局限于上述所说的第一子线程和第二子线程，同理不同子线程执行的任务可以不局限于上述示例中所说的读、写，还可以涉及其他业务，本申请对此不作限定。

通过上述场景描述不难发现，由于目前对嵌入式文件系统的调度顺序，是基于不同线程要处理的任务被触发的时间确定的，因此不同的任务无法合理调度，只能按照时间先后顺序进行响应，先触发的执行完后，后触发的才能执行，因此后触发的可能会因为延迟处理，导致对应的软狗(Watchdog)超时。

此外，需要说明的是，对于上述所说的集成了嵌入式操作系统，且具备文件系统服务的电子设备，通常为物联网(Internet of Things，IoT)设备，例如有车载设备、手写笔(触控笔)、穿戴式音频类的设备等，此处不再一一列举，本申请对此不作限制。

示例性的，对于上述所说的穿戴式音频类的设备，例如有智能手表/手环、智能眼镜、真正无线立体声(True Wireless Stereo，TWS)耳机等，此处不再一一列举，本申请对此不作限制。

为了便于说明，本申请以集成了嵌入式操作系统的电子设备为智能手表为例，基于上述场景描述，对智能手表通过多线程执行多任务时，由于同时或小间隔的调用文件系统服务，容易出现的问题进行说明。

参见图2a中(1)所示，示例性的示出智能手表100的一种音乐播放界面。其中，音乐播放界面包括一个或多个控件，如用于切换到上一首音乐的控件、用于切换到下一首音乐的控件、用于暂停当前播放的音乐的控件、用于设置播放模式，如顺序播放、单曲循环、随机播放等的控件、用于调节音量的控件、用户查看音乐列表的控件等。

继续参见图2a中(1)所示在音乐播放界面播放音乐(可以理解为执行音频任务)时，如果用户不断采用设置的滑动手势(可以理解为触发了传感器任务)，如从底部向上滑的手势，需要进入消息通知界面查看短信、日程等消息时，会加载消息通知界面的资源(可以理解为触发了显示任务)，如字库、图片等控件，由于嵌入式操作系统资源有限、处理能力有限，这种同时触发多任务，如上所说的音频任务、传感器任务、显示任务的操作，很可能会导致播放音乐的应用程序与显示消息通知的应用程序产生冲突，进而出现卡顿，如当前播放的音乐出现卡顿，或者不能及时切换到消息通知界面。

更严重的，由于卡顿严重，切换到消息通知界面的操作一直得不到响应，会导致执行切换的线程饿死，进而智能手表100出现死机重启，如从音乐播放界面闪退，回到图2a中(2)所示的主界面。

更严重的，对于一些恶意应用程序，如后台运行的获取智能手表100中数据、文件的应程序，不断抢占资源，会导致智能手表100的系统奔溃，严重影响用户使用。

为了尽可能减少上述异常的出现，目前常用的一种操作方式是，提醒用户减少频繁切换，或者在从音乐播放界面切换到消息通知界面时，先通过图2b中(1)所示的音乐播放界面中用于暂停当前播放的音乐的控件，暂停当前播放的音乐，即主动释放任务锁，在用于暂停当前播放的音乐的控件变为图2b中(2)所示的样式后，再采用设置的滑动手势，如从底部向上滑的手势，这样智能手表100响应于用户的手势，就会从图2b中(2)所示的界面切换为图2a中(3)所示的消息通知界面。

然而，这种方式需要用户主动触发任务锁的释放，如果用户没有按照上述逻辑执行，依旧会导致触发不同任务的应用程序之间发生冲突，进而造成卡顿；或者某些应用程序的调度被不断延迟，导致不能及时调度，更甚者由于得不到调度导致线程饿死，最终导致设备死机重启等的现象发生。

有鉴于此，本申请提供了一种嵌入式操作系统中文件系统的调度方法，通过引入优先级的概念，并将每一个访问文件系统服务的任务中的文件操作指令封装为一个消息请求，同时对这些消息请求按照优先级排序，确定合理的响应序列，使得不同任务的不同文件操作指令能够对文件系统进行合理调度；通过引入调度策略，配合优先级，能够确保优先级高的消息请求及时得到响应，优先级低的消息请求也能得到响应，而非一直延迟，从而避免低优先级的线程被饿死。

此外，需要说明的是，本申请实施例提供的技术方案主要针对嵌入式操作系统，即上述技术问题主要存在于嵌入式操作系统中，对于非嵌入式操作系统，比如安卓(Android)系统、微软视窗操作系统(Micorsoft Windows)等，由于其处理任务的过程是并行执行，即多个子线程并行处理各自的任务，而非上述嵌入式操作系统中顺序执行，加上非嵌入式操作系统的处理能力较强，性能好，因此对于多任务的处理响应快，处理及时，故而不存在上述嵌入式操作系统中文件系统调度时存在的问题。

基于本申请提供的嵌入式操作系统中文件系统的调度方法，在智能手表100当前正在执行播放音乐的任务的过程中，如果用户通过特定的手势触发了查看消息通知界面中某一消息，由于引入了优先级的概念，故而通过判断播放音乐和查看消息通知界面中某一消息这两个任务中各个文件操作指令的优先级，就可以确定当前优先响应于哪一个任务中的哪一个文件操作指令。

示例性的，如果查看消息通知界面中的消息的优先级高于播放音乐的优先级，则当智能手表100处于图3中(1)所示的音乐播放界面，即执行播放音乐的线程在工作时，当智能手表100识别到用户触发进入消息通知界面的手势时，确定该手势对应的消息请求的优先级高于播放音乐的优先级，执行播放音乐的线程释放任务锁，打开消息通知界面的线程抢占任务锁，智能手表100响应于该手势，从图3中(1)所示的音乐播放界面切换到图3中(2)所述的消息通知界面。这样，即便用户不暂停音乐播放，也可以直接切换到消息通知界面，提升了用户体验。

此外，需要说明的是，为了实现上述技术效果，具体到本申请中，在集成了嵌入式操作系统，且具备文件系统服务的电子设备的应用程序框架层中新增了实现本申请提供的嵌入式操作系统中文件系统的调度方法的文件系统调度服务。

为了更好的理解本申请实施例提供的技术方案，以下结合图4对集成了嵌入式操作系统的电子设备的软件架构，以及新增文件系统调度服务与原有功能模块的交互逻辑进行具体说明。

具体到本实施例中，用于实现本申请各实施例提供的技术方案的嵌入式操作系统，例如可以是Liteos系统(面向物联网领域开发的一个基于实时内核的轻量级操作系统)、实时多任务操作系统(Real Time multi-tasking Operation System，RTOS，也可以称为UCOS)、FreeRTOS(一种小型实时操作系统内核)等，此处不再一一列举，本申请对此不作限制。

参见图4，集成嵌入式操作系统的电子设备的软件系统采用的是分层架构。其中，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将嵌入式操作系统分为四层，从上至下分别为应用程序层，应用程序框架层，算法和内部库，以及内核层。

其中，应用程序层可以包括一系列应用程序包。以集成嵌入式操作系统，且具备文件系统服务的电子设备为上文所说的智能手表为例，如图4所示，应用程序包可以包括地图应用、通信应用、应用播放器等。

可理解的，上述所说的通信应用，例如包括信息应用、通话记录应用、联系人应用、通话应用等。

此外，还可以理解的是，在实际应用中，应用程序包还可以包括一些系统应用，如指南针应用、计时器应用、天气应用、闹钟应用、秒表应用等，此处不再一一列举，本申请对此不作限制。

此外，还可以理解的是，在实际应用中，由于智能手表等嵌入式操作系统的电子设备同样支持安装新的应用程序，因此应用程序包还可以包括一些第三方应用，如微信。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

其中，应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架(Framework)，即应用程序层通过Framework API访问/调用应用程序框架层提供的服务。在一些实现方式中，通过Framework API访问的应用程序框架层的服务，例如包括图4所示的系统基本能力服务、硬件服务、底层软件服务等。

具体到本实施例中，为了实现嵌入式操作系统中文件系统的合理性调度，新增的文件系统调度服务具体可以集成在底层软件服务中，即与原本处于底层软件服务中的文件系统服务(即本申请所说的文件系统)是处于同一级别，并且二者之间通过消息服务请求的方式实现通信。当然，文件系统调度服务也可以被独立设置在应用程序框架层、算法和内部库或内核层等，本申请实施例对此不作任何限制。

示例性的，基于上述结构，当上层的应用程序层触发对应的任务，或者应用程序框架层中的其他服务触发对应的任务时，由于该任务一般会包括一个或多个文件操作指令，因此，在本申请实施例中，可以文件操作指令为粒度，对该任务的每个文件操作指令发起对应的消息请求。例如，任务A包括文件操作指令1、文件操作指令2和文件操作指令3，应用可将文件操作指令1携带在消息请求1中，将文件操作指令2携带在消息请求2中，将文件操作指令3携带在消息请求3中，并将消息请求1、消息请求2和消息请求3发送给文件系统调度服务。

后续，这些消息请求会先由文件系统调度服务进行优先级和合理性的调度，进而筛选出一个最紧迫的消息请求，并将筛选出的消息请求发送给文件系统服务，由文件系统服务根据消息请求中携带的文件操作指令进行文件调度。

相应地，当文件系统服务完成调度，得到对应的结果后，会将得到的结果通过与文件系统调度服务之间的接口传输给文件系统调度服务，进而由文件系统调度服务返回给消息请求的提供者，即对应的任务。

关于文件系统调度服务的内部的具体处理逻辑以及与文件息服务的交互细节，详见下文，此处不再赘述。

可理解的，除了上述所说的文件系统服务、文件系统调度服务，底层软件服务中还可以包括内容管理服务、日志服务、传感器管理服务、蓝牙管理服务等，此处不再一一列举，本申请对此不作限制。

此外，需要说明的是，上述所说的系统基本能力服务，例如可以包括上述所说的信息应用对应的消息服务、通话应用对应的通话服务、联系人应用对应的联系人服务等。

此外，还需要说明的是，上述所说的硬件服务，例如可以包括上述所说的地图应用或者其他涉及定位功能的应用对应的定位业务服务、蓝牙服务等。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

其中，算法和内部库用于管理各种算法，如活体检测算法、手势算法、佩戴检测算法、调光算法等，各种基础库，如安全类、条形码、支付类的基础库，以及芯片厂商提供的协议栈，如传统蓝牙协议栈、低功耗协议栈等。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

其中，内核层包括内核核心、硬件抽象层(HAL)、硬件驱动层。具体到实际应用中，内核核心可以通过微控制器软件接口标准(Cortex Microcontroller SoftwareInterface Standard，CMSIS)API与上层进行交互，硬件抽象层可以通过HAL API与上层进行交互。

关于集成了嵌入式操作系统的电子设备的软件结构就介绍到此，可以理解的是，图4示出的软件结构中的层以及各层中包含的部件，并不构成对该类电子设备的具体限定。在本申请另一些实施例中，集成了嵌入式操作系统的电子设备可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

关于上述所说的文件系统调度服务，在接收到对文件系统调度的消息请求后，根据调度策略对消息请求进行排序，从而筛选出当前最紧迫的消息请求发送给文件系统进行操作的具体实现逻辑，以下结合图5进行具体说明。

参见图5，在本实施例中，文件系统调度服务可包括封装模块、调度模块和执行模块。

其中，封装模块用于从来自不同任务，如图5中的任务1、任务2、任务3、任务4等的消息请求中提取文件操作指令，及任务标识号等，并按照设定的格式封装程结构体(struct)，使得消息请求以结构体的形式在嵌入式操作系统中传递。

可理解的，在实际应用中，封装模块也可以根据设定在消息请求中增加某些参数信息，具体详见下文，此处不再赘述。为了便于说明，下文将进入封装模块，以及从分钟模块中出去内容称为消息请求进行说明，即下文中信息请求就是结构体的形式，或者是增加了某些参数信息的消息请求，即经封装模块处理后的。

继续参见图5，调度模块用于根据调度策略对消息请求进行排序，例如，将优先级低的消息请求添加到普通队列中，将优先级高的消息请求调整到VIP(very importantperson，高级会员)队列中；执行模块用于对普通队列和VIP队列中的消息请求进行遍历，从中筛选出当前最紧迫的消息请求，并将筛选出的消息请求发送给文件系统文件进行处理。

需要说明的是，封装模块接收到的消息请求的提供者，即上述所说的任务，在一些实现方式中，例如可以是来自应用程序层的，也可以是来自应用程序框架层中的其他服务的。

为了便于理解，以下结合实际场景进行说明。示例性的，在一种实现场景中，例如上文所说的播放音乐的音频任务场景下，任务即为应用程序层中当前被打开进行播放音乐的播放器触发的。

相应地，对于上文所说的通过特定的手势触发了查看消息通知界面中的消息的任务，在一些实现方式中可以涉及传感器任务，用于实现手势检测；以及显示任务，用于在消息通知界面中显示消息。其中，传感器任务，例如是由应用程序框架层中硬件服务中涉及的有关传感器的硬件服务触发，显示任务则由应用程序框架层中系统基本能力服务中的视图系统触发。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图5，示例性的，在一些实现方式中，封装模块提供的API封装能力包括读操作、写操作、打开操作、关闭操作、删除操作、获取文件属性状态操作、移动操作等文件操作。这些API封装能力与原生的文件系统服务支持的能力一一对应，为了便于区分，在一些实现方式中可以将文件系统调度服务中封装模块提供的API封装能力添加特定标识号，如Fs。

基于此，上述所说的封装模块提供的API封装能力读操作可以表示为FsRead、写操作FsWrite、打开操作FsOpen、关闭操作FsClose、删除操作FsUnlink、获取文件属性状态操作FsStat、移动操作FsSeek等。

相应地，文件系统服务中提供的上述能力，如读操作可以表示为Read、写操作Write、打开操作Open、关闭操作Close、删除操作Unlink、获取文件属性状态操作Stat、移动操作Seek等。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，经过封装模块处理后的消息请求中，不仅包括上述任意一项文件操作指令(OperaCmd)，还会包括文件对象结构体(FIP)、文件信息结构体(FILINF)、当前调度的状态(EnuFlag)、上层应用的任务标识号(TsakId)、文件名(FileName)、文件操作返回结果(FileOperaErr)、超时等待时间(WaitTime)、饥饿时间阈值(HungtryTime)等。

其中，FIP、FILINF、OperaCmd、TsakId、FileName、WaitTime的赋值是在封装模块接收到不同任务对应的消息请求，即图5中的①后，对接收到的消息请求进行处理时直接完成的。

也就是说，封装模块输出的消息请求，即图5中的②，FIP、FILINF、OperaCmd、TsakId、FileName、WaitTime这几个参数是有具体的内容的，而EnuFlag、FileOperaErr、HungtryTime这几个参数是没有具体信息的。

可理解的，上述所说的WaitTime具体是指消息请求进入封装模块之前，等待的时间；HungtryTime具体是指每个消息请求在普通队列中等待时间的最大时间阈值。

继续参见图5，示例性的，关于调度模块中设置的普通队列和VIP队列可以支持存放的消息请求的数量，在一些实现方式中，可以依据系统性能、同时支持的任务(对应的线程)数量来确定。例如，可以将其设置为创建的子线程的数量，或者当前排队等待处理的任务(task)的数量。

继续参见图5，步骤②中，经封装模块处理得到的消息请求到达调度模块后，会先存入调度模块中的普通队列，并开始记录在普通队列中等待的时间，即饥饿时间。当普通队列中出现任意一条或几条消息请求对应的饥饿时间达到其对应饥饿时间阈值(需要考虑进入封装模块之前的WaitTime)后，调度模块会将这些达到饥饿时间阈值的消息请求移动到VIP队列中。

为了避免执行模块筛选出的最紧迫的消息请求始终是位于VIP队列中的，进而导致普通队列中的消息请求得不到响应，本实施例还为VIP队列设置了吃饱时间阈值，即VIP队列中所有消息请求的执行时间总和对应的最大时长。基于此，在有消息请求移入VIP队列，执行模块选择VIP队列中的消息请求给文件系统服务进行调度执行时，调度模块会统计VIP队列中消息请求的执行时间总和。

可理解的，为了保证用户体验，避免被触发的消息请求出现长时间无响应，具体到本实施例中如长时间不被调度，造成软狗超时，同时避免长时间没有被调度的消息请求一直占用系统资源，导致系统奔溃。通常在生成消息请求的时候会为其赋值一个超时时间，即等待被调度的最大时间，具体到本实施例中每一个消息请求的饥饿时间阈值可以根据其对应的超时时间进行设置，如设置饥饿时间阈值+吃饱时间阈值小于会等于超时时间。而在实际应用中，封装模块对每一任务对应的消息请求的处理也是按序进行的，即在消息请求触发后，到消息请求进入封装模块的过程中，存在排队等待的过程。通过上述对饥饿时间阈值、超时时间、喂饱时间阈值之间关系的描述可知，该过程对应的时间即上述所说的WaitTime，也需要考虑，即消息请求在普通队列中等待的饥饿时间包括在普通队列记录的实际时长和排队进入封装模块的WaitTime。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，在统计的时间总和(喂饱时间)大于或等于喂饱时间阈值时，可停止从VIP队列中选取消息请求给文件系统服务进行调度处理，而是从普通队列中选取。

也就是说，图5中，步骤③，实质是由执行模块对调度模块中的普通队列和VIP队列中的消息请求进行遍历，进而由执行模块确定出最紧迫的消息请求，并将确定的消息请求发送给文件系统服务，即执行步骤④。

继续参见图5，示例性的，文件系统服务在接收到文件系统调度服务中执行模块发送的消息请求后，根据该消息请求中携带的文件操作指令进行文件调度，在得到处理结果后，会将处理结果发送给执行模块，即执行步骤⑤。关于文件系统服务根据文件操作指令进行文件调度的具体实现逻辑，与现有文件系统服务进行文件调度的逻辑相同，此处不再赘述。本实施例中仅是将上层应用或其他服务触发的任务提供的消息请求(封装模块未处理的)先经文件系统调度服务进行处理，进而从接收到的多个消息请求(可能是来自同一个任务的，也能是不同任务)中确定一个最紧迫的消息请求，文件系统服务进行文件调度的过程不做调整。

此外，需要说明的是，关于上述所说的处理结果，例如可以是针对消息请求中文件操作指令进行文件调度处理，如上文所说的w1操作后得到的具体结果，例如可以用约定的状态码来标识是否成功。

示例性的，对于读操作指令，如上文所说的r1、r2、r3、r4中的任意一项或几项，返回的处理结果例如可以是实际读取到的数据。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，还需要说明的是，文件系统服务在得到上述处理结果后，例如可以按照约定将其封装为对应的应答/响应/反馈格式，然后发送给执行模块进行后续处理。

示例性的，对于约定的封装格式，例如可以是超文本传输协议(Hyper TextTransfer Protocol，HTTP)、JSON(JavaScript Object Notation,JS对象简谱)等，此处不再一一列举，本实施例对此也不作限制。

基于上述描述可知，本次具体调度哪一个消息请求，是由调度模块确定的，故而EnuFlag的赋值过程是在调度模块中实现的，而经文件系统服务处理得到的处理结果是由执行模块发送给封装模块，即图5中的步骤⑥，再由封装模块返回给对应的任务，即图5中的步骤⑦，故而FileOperaErr是在执行模块得到文件系统服务返回的处理结果后，由执行模块实现赋值的。

此外，还需要说明的是，由于实际应用中任务之间可能存在关联性，比如任务2对应的消息请求必须要在任务1对应的消息请求处理后才可以执行，为了避免任务1对应的消息请求和任务2对应的消息请求经封装模块处理进入调度模块后，因为优先级和调度策略，导致任务2对应的消息请求先于任务1对应的消息请求处理完，每一个经封装模块处理的消息请求还可以包括操作结果通知信号量(pSemFileOperaResult)，这一用于标识关联任务操作结果的参数。

具体到这种应用场景中，pSemFileOperaResult的赋值是在封装模块接收到执行模块反馈的文件系统服务的处理结果，即图5中的⑥后，在封装模块中完成赋值的。

为了更好的理解，以下结合实例对操作结果通知信号量的具体使用进行说明。

示例性的，以打开音乐播放器这一任务为Task1，使用音乐播放器播放音乐这一任务为Task2。其中，Task1与Task2具有强关联性，如Task2必须是在Task1处理得到处理结果(如打开)后才能执行。对于这一场景，例如可以约定文件系统服务完成Task1对应的消息请求的处理，向执行模块反馈音乐播放器已打开的处理结果后，封装模块根据执行模块反馈的该处理结果对Task1对应的消息请求中的操作结果通知信号量进行赋值，如赋值为“0001”后，将本次文件系统服务针对Task1对应的消息请求的处理结果，根据该消息请求中携带的TaskId返回给Task1后，同时通知Task2，Task1的消息请求已经执行完毕，此时Task2对应的消息请求才会进入封装模块。

此外，还需要说明的是，为了使将先执行的Task1对应的操作结果通知信号量被Task2获得，在一些实现方式中，Task1对应的消息请求中的TaskId可以包括Task1对应的Id，以及与其关联的下一个需要执行的任务的，如Task2的Id。

相应地，如果还包括执行顺序在Task2完成后执行的，与Task2有强关联性的Task3，则Task2对应的消息请求中的TaskId可以包括Task2对应的Id，以及与其关联的下一个需要执行的任务的如Task3的Id。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，对pSemFileOperaResult完成赋值后，上述所说的OperaCmd，FIP、FILINF、EnuFlag、TsakId、FileName、FileOperaErr、WaitTime、HungtryTime等参数均有对应的赋值信息，此时可以执行图5中的⑦，即将最终的调度处理结果反馈给对应的任务。

为了更好的理解基于图5所示结构实现的嵌入式操作系统中文件系统的调度方法，以下结合图6对嵌入式操作系统中文件系统的调度方法进行具体说明。

参见图6，本实施例提供的嵌入式操作系统中文件系统的调度方法，具体包括：

S101，对要调度文件系统服务的任务的消息请求进行处理。

参见图5可知，步骤S101中所说的对调度文件系统服务的任务的消息请求进行处理，具体是指在有需要调度文件系统服务的任务对应的消息请求到达文件系统调度服务中的封装模块时，由封装模块对齐进行处理，使其包括上述罗列的参数，并对需要在封装模块完成赋值的参数进行赋值。

S102，将处理后的消息请求添加到普通队列，并开始记录消息请求在普通队列的等待的饥饿时间。

示例性的，在一些实现方式中，调度模块所遵循的调度策略，例如可以是根据每一个消息请求(或者提供消息请求的任务)对应的生存周期(Time To Live，TTL)生成。故而，调度模块也可以称为TTL调度模块。

此外，通过上述描述可知，每一个消息请求都会对应一个饥饿时间阈值，该时间阈值可以与其他消息请求的相同，也可以不相同，具体可以根据实际触发的任务的特性进行合理设置，本实施例对此不作限制。

此外，还需要说明的是，调度模块在将封装模块提供的消息请求添加到普通队列后，会对该消息请求在普通队列等待(未被调用执行)的时间进行计时，即记录消息请求在普通队列等待的饥饿时间。考虑到消息请求到达普通队列前，其对应的任务在触发后已经在封装模块外排队进行了等待，因此累计的饥饿时间需要考虑经封装模块处理后，消息请求中超时等待时间参数对应的时间。

S103，普通队列中每一消息请求的饥饿时间是否达到饥饿时间阈值。

可理解的，在消息请求添加到普通队列后，如果该消息请求没有及时得到调度执行，其对应的饥饿时间是不断进行累加的，因此在原本的消息请求处理完后，调度模块会遍历普通队列中的消息请求，判断每一个消息请求当前记录的饥饿时间是否达到(大于或等于)其对应的饥饿时间阈值。

相应地，如果存在饥饿时间达到其对应的饥饿时间阈值的消息请求，则将这些饥饿时间达到对应的饥饿时间阈值的消息请求从普通队列中移动到VIP队列，即执行步骤S104；否则，执行步骤S105。

可理解的，执行每一个消息请求的子线程均会对应有软狗超时时间，为了避免出现软狗超时，本实施例中所为消息请求中的饥饿时间阈值赋值的具体时间要小于软狗超时时间，这样就可以确保在软狗超时前，就完成对该消息请求的调度，进而避免出现软狗超时。

S104，将达到饥饿时间阈值的消息请求从普通队列移动到VIP队列。

这样，就可以将原本位于普通队列中实时性要求低，一直没有得到调度的消息请求添加到优先级高的VIP队列中，以便后续筛选最紧迫的消息请求时能够从VIP队列中选择该消息请求，使得该消息请求能够被调度执行。

相应地，在将达到饥饿时间阈值的消息请求从普通队列移动到VIP队列后，可以继续执行步骤S106。

S105，VIP队列是否为空。

即，判断VIP队列中是否存在从普通队列中移动过来的消息请求。

相应地，若VIP队列是空的，即不存在消息请求，则执行步骤S108；反之执行步骤S106。

S106，VIP队列对应的喂饱时间是否达到喂饱时间阈值。

可理解的，由于VIP队列的调动优先级要高于普通队列的，因此为了避免长时间调度VIP队列中的消息请求，本实施例中过为VIP队列设置喂饱时间阈值，使得执行模块筛选最紧迫的消息请求时，通过判断VIP队列当前的喂饱时间是否达到(大于或等于)喂饱时间阈值即可确定究竟从普通队列筛选最紧迫的消息请求，还是从VIP队列中筛选最紧迫的消息请求。

相应地，在VIP队列的当前的喂饱时间达到喂饱时间阈值时，确定从普通队列最筛选最紧迫的消息请求，即执行步骤S108；反之则从VIP队列中筛选最紧迫的消息请求，即执行步骤S107。这样，既能够兼顾VIP队列中优先级高的消息请求得到及时调度执行，又能够兼顾普通队列中实时性要求低的消息请求得到调度执行。

S107，从VIP队列中筛选一个满足要求的消息请求，作为目标消息请求。

S108，从普通队列中筛选一个满足要求的消息请求，作为目标消息请求。

可理解的，在本实施例中，步骤S107和步骤S108中所说的目标消息请求，即上文所说的最紧迫的消息请求。

此外，上述所说目标消息请求所满足的要求，在一些实现方式中，例如是根据普通队列、VIP队列中存放的消息请求对应的优先级，选取的优先级最高的一个消息请求。

示例性的，在另一些实现方式中，上述所说目标消息请求所满足的要求，也可以是直接从普通队列、VIP队列中选取排在队首的消息请求。

由此，本实施例提供的嵌入式操作系统中文件系统的调度方法，通过设置不同优先级的两个队列，如上文中的普通队列(低优先级)和VIP队列(高优先级)，并以时间，如饥饿时间，实现消息请求在普通队列和VIP队列的移动，以喂饱时间实现目标消息请求的来源的确定，从而使得消息请求能够对文件系统服务进行合理调度，既能使紧迫的任务的消息请求可以优先调度文件系统，又能兼顾快要饿死的任务的消息请求能够及时被调度，避免线程饿死。

进一步地，为了使得普通队列和VIP队列中的消息请求相互之间也存在优先级的顺序，使得每次从普通队列，或者VIP队列中选择的目标消息请求更加贴合实际使用需求，还可以为普通队列、VIP队列中存放的消息请求设置对应的优先级。

示例性的，在一种可行的实现方式中，为普通队列、VIP队列中每一个消息请求设置的优先级，可以是根据上层应用对文件系统服务的依赖程度确定的，例如对于空中下载任务、音频任务、导航类(如全球定位系统(Global Positioning System，GPS))任务等依赖性高的任务，可以为其对应的消息请求设置相对较高的优先级，而输入/输出任务、能力任务(如蓝牙传输任务、平台中各驱动的任务)等依赖性低的任务，可以为其对应的消息请求设置相对低的优先级。

示例性的，在另一种可行的实现方式中，为普通队列、VIP队列中每一个消息请求设置的优先级，可以是根据消息请求的实时性要求确定的，例如传感器任务对应的消息请求、显示任务对应的消息请求等实时性要求高的优先级高，而对于获取系统/程序运行过程中产生的日志信息的日志任务对应的消息请求等实时性要求低的优先级低。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，在实际应用中，为了便于根据为不同任务对应的消息请求分配合适的优先级，进而根据优先级调整消息请求在普通队列、VIP队列中的顺序，在根据上述设置优先级的方式确定不同任务对应的消息请求的优先级后，可以以表格的形式，或者可扩展标记语言(Extensible Markup Language，XML)等能够体现二者关系的形式记录。为了便于说明，本实施例以表格为例，给出几种类型的任务对应的优先级。

表1优先级策略表

可理解的，表1中记录的不同任务对应的优先级，仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，可以约定同一类任务，如传感器任务中不同传感器任务对应的所有消息请求的优先级都相同，也可以约定同一类任务，如传感器任务中不同传感器任务对应的消息请求的优先级不相同，具体根据实际业务需要设置即可，本实施例对此不作限制。

此外，需要说明的是，通过上述对消息请求(封装模块处理后的)包括的参数信息的描述可知，消息请求携带了TsakId，其可以标识该消息请求的唯一性，因此结合表1中记录的每一个任务对应的TaskId和普通队列、VIP队列中每一个消息请求中携带的TaskId，就可以精准定位每一个消息请求对应的优先级，进而根据确定的优先级按照从高到低的顺序，对普通队列、VIP队列中的消息请求进行排序，这样就可以保证每次从队首取出的消息请求都是优先级最高的。

此外，还需要说明的是，当有新的消息请求需要添加到普通队列，或VIP队列时，根据上述优先级策略表，可以直接确定需要添加的消息请求的位置，进而将其插入到合适的位置中。

相应地，插入新的消息请求后，原本处于该位置的消息请求，以及该位置后的信息请求顺序后移即可。

此外，还需要说明的是，在一些实现方式中，普通队列和VIP队列可以共用同一张优先级策略表，这样维护一张优先级策略表，即可实现对两个队列中消息请求位置的调整。

示例性的，在另一些实现方式中，普通队列和VIP队列可以分别对应不同的优先级策略表，从而使得普通队列和VIP队列中的消息请求的调度能够更加合理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

通过上述对不同任务优先级设置的描述，不同任务对应的消息请求中配置的饥饿时间阈值也可以根据优先级来设置，例如优先级越高的，说明实时性要求越高，其饥饿时间阈值可以越小，而优先级低的，说明实时性要求越低，其饥饿时间阈值可以越大。基于这一原理，为不同任务对应的消息请求配置的饥饿时间阈值，可以如表2所示。

表2饥饿时间阈值策略表

可理解的，表2中记录的不同优先级的任务对应的饥饿时间阈值，仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，饥饿时间阈值策略可以以表格，或者XML等任意能够体现优先级与饥饿时间阈值二者关系的形式记录。

为了更好的理解本实施例提供的嵌入式操作系统中文件系统的调度方法，以下结合图7a～图7d对一种应用场景进行说明。

参见图7a中(1)所示，初始情况下，即没有需要调度执行的消息请求时，普通队列和VIP队列都是空的。当调度模块接收到来自task1的消息请求Req1、Req2、Req3时，由于这3个消息请求来自同一个任务，一种实现方式中，它们的优先级可以是相同的，对于这种场景可以按照这3个消息请求之间接收到的先后顺序，如按照先Req1，然后Req2，接着Req3的顺序，顺序添加到普通队列中，VIP队列依旧是空的，即如图7a中(2)所示。

示例性的，在另一些实现方式中，在将同一个任务的多个消息请求添加到普通队列时，也可以根据他们之间的执行顺序，比如在Req1需要在Req2执行后才执行，Req3则需要在Req1执行后在执行，这3个消息请求在普通队列的顺序例如可以是Req2、Req1、Req3。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。为了便于说明，本实施例以图7a中(2)所示的顺序为例进行说明，后续来自同一个任务的多个消息请求均默认优先级相同，按照接收到的先后顺序添加到队列。

参见图7a中(2)所示，在普通队列中有Req1～Req3这3个消息请求，而VIP队列为空的情况下，执行模块会从普通队列选择Req1作为目标消息请求，即从普通队列中取出Req1传递给文件系统服务，进而由文件系统服务会根据Req1执行文件操作(进行文件调度)，而Req2和Req3则在普通队列中进入等待时间，即开始记录Req2对应的饥饿时间和Req3对应的饥饿时间。

继续参见图7a中(2)所示，当文件系统服务根据Req1执行文件操作的过程中，如果调度模块接收到来自task2的消息请求Req4和Req5，一种实现方式中，可以不考虑Req4、Req5与依旧排在普通队列等待被调度的Req2和eq3各自的优先级先后顺序，直接将Req4、Req5按照先后顺序添加到普通队列中Req3后，如图7a中(3)所示；另一种实现方式中，可以根据上述所说优先级策略表确定提供Req4和Req5的task2的优先级与提供Req2和Req3的task1的优先级，如果task1的优先级高于task2的，则Req3和Req5添加到普通队列后，普通队列中Req2、Req3、Req4和Req5这4个消息请求的顺序依旧如图7a中(3)所示，反之则Req4会位于图7a中(3)所示的Req2所在的位置，Req5会位于图7a中(3)所示的Req3所在的位置，而Req2则会位于图7a中(3)所示的Req4所在的位置，Req3则会位于图7a中(3)所示的Req5所在的位置。本实施例以图7a中(3)所示的顺序为例。

参见图7a中(3)所示，当Req4和Req5添加到普通队列中，由于其优先级低于Req2和Req3的优先级，在Req1调度完成后，由于VIP队列依据为空，下一个被确定为目标消息请求的消息请求依旧来自普通队列，具体为位于队首的Req2。这种情况下Req3、Req4和Req4在普通队列中都处于等待被调度的状态，即开始记录Req4对应的饥饿时间、Req5对应的饥饿时间，同时继续记录Req3对应的饥饿时间。

继续参见图7a中(3)所示，当文件系统服务根据Req2执行文件操作的过程中，如果调度模块接收到来自task3的消息请求Req6，在一种实现方式中，可以不考虑Req3、Req4、Req5、Req6各自的优先级先后顺序，直接将Req6添加到普通队列中Req5后，如图7a中(4)所示；另一种实现方式中，可以根据上述所说优先级策略表确定task1、task2、task3的优先级，进而按照确定的优先级顺序将调整不同任务提供的消息请求在普通队列中的顺序，例如在优先级满足task3>task1>task2时，task3提供的Req6将被添加到普通队列的队首，而Req3、Req4和Req5则顺序后移，添加Req6后的普通队列例如图7b中(4)所示。本实施例以图7a中(4)所示的顺序为例。

参见图7a中(4)所示，当Req6添加到普通队列中，在Req2没有被调度完成时，会继续记录普通队列中等待被调度的各个消息请求对应的饥饿时间。

此外，需要说明的是，在记录每一个消息请求对应的饥饿时间的过程中，还会实时或者按照设定的时间，将每一个消息请求对应的饥饿时间与其对应的饥饿时间阈值进行比较。

示例性的，如果通过将饥饿时间与饥饿时间阈值进行比较后，确定普通队列中Req4和Req5各自的饥饿时间均达到了各自对应的饥饿时间阈值，而Req3和Req6没有，这种情况下调度模块会将Req4和Req5从普通队列中移动到VIP队列中，Req3和Req6继续停留在普通队列中，则进行调整后的普通队列和VIP队列如图7a中(5)所示。对于这种情况，在文件调度系统执行完Req2后，执行模块会从VIP队列中选择目标消息请求，由于VIP队列中Req4位于队首，故而接下来被确定为目标消息请求的为VIP队列中的Req4。

可理解的，对于图7b中(4)所示，如图通过判断同样确定通队列中Req4和Req5各自的饥饿时间均达到了各自对应的饥饿时间阈值，而Req3和Req6没有，这种情况下调度模块会将Req4和Req5从普通队列中移动到VIP队列中，Req3和Req6继续停留在普通队列中，则进行调整后的普通队列和VIP队列如图7b中(5)所示。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，对于VIP队列，当添加的消息请求大于一个时，在一些实现方式中，同样可以不考虑每一个消息请求各自的优先级先后顺序，直接将后加入的消息请求添加到先添加的消息请求之后。

如图7c中(1)所示，当文件系统服务根据VIP队列中的Req4执行文件操作的过程中，如果调度模块接收到来自task4的消息请求Req7，可以不考虑普通队列中Req3与Req6各自的优先级先后顺序，直接将Req7添加到普通队列中Req6后，添加后的普通队列中消息请求的顺序如图7c中(2)所示。

参见图7c中(2)所示，当Req7添加到普通队列中，由于其优先级低于Req3和Req6的优先级，在VIP队列中的Req5，以及普通队列中的Req3和Req6没有被调度完成，VIP队列的喂饱时间没有达到喂饱时间阈值时，执行模块确定的目标消息请求依旧来自VIP队列，这种情况下Req3、Req6和Req7在普通队列中都处于等待时间，即开始记录Req7对应的饥饿时间，同时继续记录Req3对应的饥饿时间和Req6对应的饥饿时间。

相应地，如果通过将Req3对应的饥饿时间与其对应的饥饿时间阈值进行比较，确定Req3的饥饿时间达到对应的饥饿时间阈值，而Req6对应的饥饿时间没有达到其对应的饥饿时间阈值，Req7对应的饥饿时间也没有达到其对应的饥饿时间阈值，调度模块会将Req3从普通队列中移动到VIP队列中，Req6和Req7继续停留在普通队列中，则进行调整后的普通队列和VIP队列如图7c中(3)所示。对于这种情况，在文件调度系统执行完Req4后，如果VIP队列的喂饱时间还未达到喂饱时间阈值，则执行模块接下来确定的目标消息请求依旧来自VIP队列，具体为位于队首的Req5。

可理解的，基于实施例提供的嵌入式操作系统中文件系统的调度方法，当VIP队列中的Req5执行完后，如果VIP队列的喂饱时间还未达到喂饱时间阈值，则执行模块接下来确定的目标消息请求依旧来自VIP队列，具体为Req3；如果VIP队列的喂饱时间达到喂饱时间阈值，则执行模块接下来确定的目标消息请求来自普通队列，具体为普通队列的Req6，待后续有新的消息请求移动到VIP队列后，VIP队列重新开始记录喂饱时间，按照上述执行逻辑进行处理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

示例性的，在另一些实现方式中，可以根据上述所说优先级策略表确定每一个消息请求的优先级，进而按照确定的优先级顺序将需要移动到VIP队列的消息请求插入合适的位置。

如图7d中(1)所示，当文件系统服务根据VIP队列中的Req4执行文件操作的过程中，如果调度模块接收到来自task4消息请求Req7，根据上述所说优先级策略表确定Req7、Req3与Req6的优先级，进而按照确定的优先级顺序将Req7添加到普通队列中，例如在优先级满足Req3>Req6>Req7时，Req7将被添加到普通队列的队尾，即Req6后，添加Req7后的普通队列例如图7d中(2)所示。

参见图7d中(2)所示，当Req7添加到普通队列中，由于其优先级低于Req3和Req6的优先级，在VIP队列中的Req5，以及普通队列中的Req3和Req6没有被调度完成，VIP队列的喂饱时间没有达到喂饱时间阈值时，执行模块确定的目标消息请求依旧来自VIP队列，这种情况下Req3、Req6和Req7在普通队列中都处于等待时间，即开始记录Req7对应的饥饿时间，同时继续记录Req3对应的饥饿时间和Req6对应的饥饿时间。

相应地，如果通过将Req3对应的饥饿时间与其对应的饥饿时间阈值进行比较，确定Req3的饥饿时间达到对应的饥饿时间阈值，而Req6对应的饥饿时间没有达到其对应的饥饿时间阈值，Req7对应的饥饿时间也没有达到其对应的饥饿时间阈值，调度模块会将Req3从普通队列中移动到VIP队列中，Req6和Req7继续停留在普通队列中。根据上述所说优先级策略表确定Req3和Req5的优先级，进而按照确定的优先级顺序将Req3添加到VIP队列中，例如在优先级满足提供Req3的task1的优先级高于提供Req5的task2低优先级，即Req3>Req5时，Req3将被添加到VIP队列的队首，而Req5则顺序后移，添加Req3后的VIP队列例如图7d中(3)所示。

对于这种情况，在文件调度系统执行完Req4后，如果VIP队列的喂饱时间还未达到喂饱时间阈值，则执行模块接下来确定的目标消息请求依旧来自VIP队列，具体为位于队首的Req3。

可理解的，基于实施例提供的嵌入式操作系统中文件系统的调度方法，当VIP队列中的Req3执行完后，如果VIP队列的喂饱时间还未达到喂饱时间阈值，则执行模块确定接下来确定的目标消息请求依旧来自VIP队列，具体为Req5；如果VIP队列的喂饱时间达到喂饱时间阈值，则执行模块接下来确定的目标消息请求来自普通队列，具体为普通队列的Req6，待后续有新的消息请求移动到VIP队列后，VIP队列重新开始记录喂饱时间，按照上述执行逻辑进行处理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

以上述图7a、图7c示出的消息请求Req1～Req7在普通队列和VIP队列的调整逻辑为例，在Req1～Req3来自task1，Req4和Req5来自task2，Req6来自task3，Req7来自task4的情况下，基于上述场景，参见图8a，集成嵌入式操作系统的电子设备启动创建主线程Main-Thread后，Main-Thread会创建对应task1的子线程Tread-task1、对应task2的子线程Tread-task2、对应task3的子线程Tread-task3、对应task4的子线程Tread-task4。

继续参见图7a和图8a，示例性的，当调度模块接收到Req1、Req2和Req3，并将Req1、Req2和Req3添加到普通队列后，执行模块会确定目标消息请求为Req1，并将Req1发送给文件系统服务，这种情况下，Tread-task1抢占任务锁，根据Req1执行Req1中的文件操作指令，如图8a中的“1”。

继续参见图7a和图8a，示例性的，在Tread-task1根据Req1进行文件调度的过程中，如执行图8a中“1”的过程中，调度模块接收到了来自task2的Req4和Req5，由于task2的优先级低于task1，故而task2提供的Req4和Req5的优先级整体低于task1提供的Req2和Req3优先级，Req4和Req5按先后顺序被添加到普通队列中Req3后，在Tread-task1执行完“1”后，如果普通独立中所有等待被调度的消息请求，如Req2～Req5的饥饿时间都没有达到各自对应的饥饿时间阈值，无需向VIP队列移动消息请求，执行模块确定的目标消息请求依旧来自普通队列，具体为Req2，则Tread-task1根据Req2执行Req2中的文件操作指令，如图8a中的“2”，同时调度模块会继续记录在普通队列中每一个等待被调度的消息请求的等待时间，即饥饿时间。

继续参见图7a、7c和图8a，示例性的，在Tread-task1执行“2”的过程中，调度模块接收到了来自task3的Req6，由于task3的优先级低于task2，故而task3提供的Req6的优先级低于task2提供的Req5的优先级，Req6被添加到普通队列的队尾，此时如果确定Req4和Req5的饥饿时间达到其对应的饥饿时间阈值，调度模块将Req4和Req5从普通队列移动到VIP队列。由于VIP队列整体的优先级要高于普通队列，且VIP队列的喂饱时间没有达到喂饱时间阈值，在Tread-task1执行完“2”后，执行模块确定的目标消息请求变更为VIP队列中的Req4，此时Tread-task1释放任务锁，Tread-task2抢占任务锁，根据Req4执行Req4中的文件操作指令，如图8a中的“4”。

相应地，如果在Tread-task2执行“4”的过程中，普通队列中Req3的饥饿时间达到其对应的饥饿时间阈值，Req6，以及后接收到的来自task4的Req7的饥饿时间没有达到各自对应的饥饿时间阈值，则调度模块将Req3从普通队列移动到VIP队列，如图7c中(3)所示。

继续参见图7a、7c和图8a，示例性的，按照上述逻辑，如果Tread-task2执行完“4”后，VIP队列的喂饱时长未达到喂饱时长阈值，执行模块会继续从VIP队列中选择目标消息请求，如Req5，并将Req5发送给文件系统服务，这种情况下Tread-task2根据Req5执行Req5中的文件操作指令，如图8a中的“5”。

相应地，在Tread-task2执行“5”的过程中，调度模块会继续记录普通队列中等待被调度的消息请求，如Req6和Req7的饥饿时间，并确定是否达到各自对应的饥饿时间阈值，以及记录VIP队列的喂饱时间。

相应地，如果这个过程中，普通队列中的Req6和Req7的饥饿时间均没有达到各自对应的饥饿时间阈值，则继续待在普通队列，反之则将其移动到VIP队列。本实施例以继续待在普通队列为例。

继续参见图7a、7c和图8a，示例性的，按照上述逻辑，如果Tread-task2执行完“5”后，VIP队列的喂饱时长达到喂饱时长阈值，执行模块会从普通队列中选择一个消息请求作为目标消息请求，本实施例中具体为将普通队列中的Req6作为目标消息请求，并将Req6发送给文件系统服务，这种情况下Tread-task2释放任务锁，Tread-task3抢占任务锁，根据Req6执行Req6中的文件操作指令，如图8a中的“6”。

参见图7a、7c和图8a，示例性的，在Tread-task3执行完“6”后，由于VIP队列不为空，还有等待调度的Req3，故而执行模块会将VIP队列中的Req3确定为目标消息请求，进而将Req3发送给文件系统服务，这种情况下Tread-task3释放任务锁，Tread-task1抢占任务锁，根据Req3执行Req3中的文件操作指令，如图8a中的“3”。

继续参见图7a、7c和图8a，示例性的，按照上述逻辑，如果Tread-task1执行完“3”后，VIP队列中没有其他可被调度的消息请求，而普通队列依旧有，则执行模块从普通队列中选择位于队首的消息请求Req7作为目标消息请求，并将Req7发送给文件系统服务，这种情况下Tread-task1释放任务锁，Tread-task4抢占任务锁，根据Req7执行Req7中的文件操作指令，如图8a中的“7”。

继续参见图7a、7c和图8a，示例性的，后续如果没有接收到新的消息请求，Tread-task4会一直抢占任务锁，直达执行完“7”，释放任务锁，通知主线程。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，创建的子线程数量不局限于上述式例，参与执行文件操作的子线程也不局限于上述示例，且每个子线程执行文件操作所依旧的消息请求中包括的文件操作指令也不局限于上述示例，可以是上述例举的FsRead、FsWrite、FsOpen、FsClose、FsUnlink、FsStat、FsSeek任意一种或几种。

相较于本实施例提供的嵌入式操作系统中文件系统的调度方法，基于原生的文件服务系统对先后到达顺序为Req1、Req2、Req3、Req4、Req5、Req6和Req7的文件系统调度场景，其调度逻辑如图8b所示，即会按照时间顺序，在每一个在先的消息请求执行完毕后，才会执行下一个，这种调度方式很可能会因为task3的Req6和task4的Req7长时间没有得到响应，进而导致task3和task4出现超时，导致task3和task4不被执行，影响用户体验。更甚者，用户长时间得到不到task3和task4的处理结果，可能会在短时间内重复触发执行task3和task4的事件，进而导致task3和task4占用大量系统资源，进而导致系统奔溃。

由此，本实施例提供的嵌入式操作系统中文件系统的调度方法，通过利用两个队列能够巧妙的筛选出最紧迫的消息请求，从而使得快饿死的任务在下次调度时间点能够得到及时调度，避免了软狗超时现象的发生，既能使得优先级高的消息请求被及时调度，又能保证低优先级的消息请求被调度。

此外，通过根据消息请求的优先级配置对应的饥饿时间阈值，从而能够更加灵活的满足不同应用场景的需求。

此外，通过为不同的消息请求配置不同的优先级，让本无优先级概念的文件系统服务能够具备优先级的能力，从而使得对文件系统服务的调度更加合理。

进一步地，在上述新增文件系统调度服务的基础上，为了使文件系统调度服务能够更加合理的确定目标消息请求，提升文件系统服务的调度能力，上述所说的为普通队列、VIP队列中每一个消息请求设置的优先级，可以是根据用户使用该电子设备期间收集到的可测性设计(Design For Test，DFT)数据请确定的。

此外，需要说明的是，在实际应用中，除了可以利用DFT数据实现对不同消息请求对应的优先级的设置，还可以根据DFT数据实现对文件系统调度中涉及的一些参数进行优化，例如对应上文所说的饥饿时间阈值、喂饱时间阈值等，此处不再一一列举，本实施例对此不作限制。

可理解的，在本实施例中DFT数据，包括但不限于调用者统计信息(记录调用API接口的上层应用的TaskId或应用名)、文件请求次数(记录每个文件被调用的次数)、预设时间内，如1秒内请求最多的上层应用、上层应用对应的消息请求失败的次数、上层应用触发消息请求到处理完的响应时长、每个消息请求在普通队列的等待时长，即饥饿时间、VIP队列的总运行时长、被调度最大的API接口、被访问最大的文件等。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

基于电子设备使用期间收集的DFT数据确定不同消息请求的优先级，使得确定的优先级能够更好的满足用户的实际使用需求。

此外，对于基于DFT数据确定不同消息请求的优先级的方式，后续使用过程中，还可以根据新收集到的DFT数据更新已有的优先级，使得不同消息请求的优先级能够根据用户的使用需求动态变化。

为了实现对上述DFT数据的收集，从而根据收集到的DFT数据更新文件系统调度服务所遵循的文件服务调度策略，本实施例在上述文件系统调度服务的结构中，引入了DFT数据收集模块。

示例性的，在一些实现方式中，DFT数据收集模块可以为一个；在另一些实现方式中，DFT数据收集模块也可以是多个。通过上述罗列的DFT数据中收集的内容可知，对于调用者统计信息、文件请求次数是在文件系统调度服务中的封装模块处获取的，而其他信息则可以在调度模块获取，也可以在封装模块获取。

故而，对于DFT数据收集模块只有一个的实现方式中，该DFT数据收集模块例如可以集成在封装模块内部，如图9a所示，或者集成在文件系统调度服务中，独立于调度模块、封装模块和执行模块，如图9b所示。

此外，应当理解的是，根据上述描述可知DFT数据主要来源于调度模块和封装模块，故而，对于DFT数据收集模块有多个的实现方式，具体可以设置2个，一个集成于封装模块中9(该模块中设置的DFT数据收集模块需要能够收集调用者统计信息、文件请求次数)，一个集成于调度模块，具体形式如图9c所示。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，也可以根据不同DFT数据与文件服务调度策略中参数的关联性，设置对应的DFT数据收集模块，从而便于根据不同DFT数据收集模块收集的DFT数据调整对应的参数，即能够选择性的处理某一类DFT数据，实现定制化的文件服务调度策略更新、调优。

此外，可理解的是，关于上述所说的根据电子设备收集到的DFT数据进行分析处理生成新版本的文件服务调度策略的具体实现，在一些实现方式中，可以由远端数据库/服务器完成，也可以由电子设备自身实现。

对于由远端数据库/服务器完成的实现方式，由DFT数据收集模块收集到DFT数据可以采用多种方式传输给远端数据库/服务器；对于由电子设备自身完成的实现方式，例如可以在电子设备中集成对应的分析处理算法。

考虑到嵌入式操作系统的电子设备资源、性能有限，本实施例以由远端数据库/服务器完成的实现方式为例，结合图10a、图10b进行说明。

参见图10a，以集成图9a～图9c中任意一种嵌入式操作系统软件架构的智能手表100为例，示例性的，初始情况下智能手表100中文件系统调度服务所遵循的文件服务调度策略为1.0版本，即图10a中示出的文件服务调度策略V1.0。可理解的，在一些实现方式中，文件服务调度策略V1.0例如可以是由技术人员根据测试阶段的数据确定的，其可以包括针对业务合理性的参数、针对上文所说的优先级策略表的参数、针对上层应用的消息请求对应的超时时间的参数、针对不同任务对应的消息请求的饥饿时间阈值的参数、针对被调度的文件在存储器存放位置的参数等。

继续参见图10a，示例性的，在智能手表100响应于对文件系统服务进行调度的消息请求时，基于文件服务调度策略V1.0按照上述实施例中示出的调度方法对合理调整消息请求在普通队列、VIP队列的位置，进而筛选合适的消息请求对文件系统服务进行调度。在此处过程中，集成在文件系统调度服务中的DFT数据收集模块会对调度过程中产生的DFT数据进行收集，并通过云端传输方式，或者存储芯片获取方式，或者总线输入方式，将收集到的DFT数据传输至远端数据库/服务器200。

其中，对于云端传输方式，例如可以是通过大数据看板(也可以称为：数据可视化看板)获取文件系统调度时收集到的DFT数据。对于这种方式，技术人员可以直观的看到上述罗列的不同类型的DFT数据。

示例性的，在一些实现方式中，可以将获取DFT数据的功能集成到大数据看板中已有的用于打印错误码的接口，如ErrorCodePrint中，也可以单独封装一个打印DFT数据的接口。本实施例以使用ErrorCodePrint接口为例。具体可以通过嵌入式操作系统中的视图系统(SystemView)调用该接口将DFT数据打印输出，并通过SystemView提供的用于记录数据的接口，如SEGGER_SYSVIEW_Error，将打印输出的DFT数据写入到离线的SystemView。

其中，对于存储芯片获取方式，是指智能手表100在使用过程中，按照上述参数类型生成对应的日志文件，保存在智能手表100本地的存储芯片中，然后按照预设周期，定期向远端数据库/服务器200传输以离线流水日志埋点形式产生的DFT数据。

示例性的，在一些实现方式中，上述所说的存储芯片例如可以是闪存(FlashEEPROM)、嵌入式多媒体卡(Embedded Multi Media Card，emmc)等，本实施例对此不作限制。在具体实现中，可以通过打印日志的接口，如LogPrint将DFT数据写入到离线流水日志埋点信息，即日志中，进而存储到存储芯片。

其中，总线输入方式，是指直接通过通信总线，如通用串行总线(UniversalSerial Bus，USB)、或者其他串口，将智能手表100与远端数据库/服务器200，或者技术人员的电子设备，如电脑连接，从而将文件系统调度时实时产生的DFT数据进行传输。

对于上述三种获取DFT数据的方式，在实际应用中，可以选择其中一种或几种进行组合，本实施例对此不作限制。

继续参见图10a，示例性的，远端数据库/服务器200在获取到智能手表100提供的DFT数据后，对DFT数据进行分析处理，进而得到文件服务调度策略V2.0版本。

示例性的，对于云端传输方式，例如是通过对应的大数据看板网站，打开大数据看板，进而获取需要的DFT数据，如上述罗列的任意一种或几种，进行在线分析处理，或者导出离线日志，使用SystemView工具加载SystemView文件，进而解析出记录在SystemView文件中的DFT数据进行分析处理。

示例性的，对于存储芯片获取方式，例如是导出离线日志，通查找DFT数据中的关键词对其进行分析处理。

示例性的，对于总线输入方式，例如是利用电脑串口/USB读取智能手表100的实时日志，进而通查找DFT数据中的关键词对其进行分析处理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

参见图10b，在得到文件服务调度策略V2.0后，一种实现方式中，可以将文件服务调度策略V2.0上传到对应的云端，以便接入该云端的智能手表100能够主动从云端获取文件服务调度策略V2.0，进而将本地的文件服务调度策略V1.0更新为文件服务调度策略V2.0，即从图10b中的智能手表100变更为智能手表100’，也可以由云端在检测到有新版本的文件服务调度策略，如文件服务调度策略V2.0时，主动将文件服务调度策略V2.0推送给智能手表100。

此外，在另一些实现方式中，上文所说的文件服务调度策略V2.0也可以时由云端主动推送给与智能手表100关联的电子设备，如手机、平板电脑等，进而由手机、平板电脑等与其关联的电子设备通过蓝牙、近场通信(Near Field Communication，NFC)、网络等方式传输给智能手表100。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，在一些实现方式中，为了避免冗余，导致资源浪费，可以将多个嵌入式操作系统的电子设备，如图10c中的智能手表100A、智能手表100A、智能手表100C提供的DFT数据进入融合，进而对所有嵌入式操作系统的电子设备提供的DFT数据进行分析处理，得到适用于这些电子设备的文件服务调度策略V2.0，即这种实现方式中，所有嵌入式操作系统的电子设备后续获取到的文件服务调度策略V2.0是相同的。

此外，还需要说明的是，在另一些实现方式中，为了满足用户的定制化需求，使得不同用户使用的嵌入式操作系统的电子设备所遵循的文件服务调度策略能够更好的满足用户，可以根据每一个嵌入式操作系统的电子设备，如图10d中的智能手表100A、智能手表100B、智能手表100C提供的DFT，分别进行分析处理，进而生成各自对应的文件服务调度策略V2.0，如图10d中的根据智能手表100A提供的DFT数据1生成的适合智能手表100A的文件服务调度策略V2.0_100，根据智能手表100B提供的DFT数据2生成的适合智能手表100B的文件服务调度策略V2.0_200，根据智能手表100C提供的DFT数据3生成的适合智能手表100C文件服务调度策略V2.0_300。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

关于上述所说的由其他设备对DFT数据进行分析处理，调整已有文件服务调度策略的实现流程，以下结合图11进行说明。

需要说明的是，在图11中，为了便于描述，以第一电子设备表示嵌入式操作系统的电子设备(如上文中的智能手表)，以第二电子设备表示用户对DFT数据进行分析处理，调整已有文件服务调度策略的电子设备(如上文中的远端数据库/服务器/电脑等)。

参见图11，本实施例提供的嵌入式操作系统中文件系统的调度方法，具体包括：

S201，在基于第一文件服务调度策略对文件系统进行调度的过程中，收集DFT数据。

示例性的，第一文件服务调度策略，例如为上文所说的文件服务调度策略V1.0。

相应地，下文所说的第二文件服务调度策略，例如为上文所说的文件服务调度策略V2.0。

关于嵌入式操作系统的电子设备基于第一文件服务调度策略对文件系统进行调度的处理逻辑，例如图6所对应的实施例所述，具体实现细节此处不再赘述。

此外，关于收集DFT数据的操作，具体由上述集成在文件系统调度服务中的DFT数据收集模块进行收集，收集的具体数据包括但不限于上文所例举的种类。

此外，需要说明的是，为了确保DFT数据收集模块能够收集到DFT数据，需要确保是否开启了触发DFT数据收集模块收集DFT数据的功能。

示例性的，在一些实现方式中，可以采用静态开关的方式，即直接通过代码逻辑，使用如宏开关的方式，将集成在文件系统调度服务中DFT数据收集模块默认设置为开启状态，这样在第一电子设备采用该架构的嵌入式操作系统后，当需要完成不同任务对文件系统的调度时，文件系统调度服务中的封装模块按照上述实施例所说的方式进行消息请求的封装，并根据上述所说的第一文件服务调度策略中携带的信息，完成对该阶段的赋值处理，如根据第一文件服务调度策略中携带的用于调整上层应用请求超时时间的信息，调整上层应用默认的请求超时时间。在封装模块封装的消息请求达到调度模块后，调度模块可以先根据上述所说的第一文件服务调度策略中携带的信息，完成对该阶段的赋值处理，如根据第一文件服务调度策略中携带用于调整优先级策略表的信息对优先级策略表进行更新，如修改某些任务的优先级，或者删除某些任务及对应的优先级，或者新增某些任务及对应的优先级；根据第一文件服务调度策略中携带用于调整每一个消息请求的饥饿时间阈值的参数调整其对应的饥饿时间阈值；根据第一文件服务调度策略中携带用于调整VIP队列的喂饱时间阈值的信息调整VIP队列的喂饱时间阈值等。

由此，在基于第一文件服务调度策略完成上述调整后，待有消息请求需要进行调度时，就可以根据调整后的优先级信息、饥饿时间阈值、喂饱时间阈值等筛选合适的消息请求交由文件系统服务进行文件操作。

由于DFT数据收集模块采用静态方式默认开启，在进行上述操作的过程中，DFT数据收集模块就会进行DFT数据的收集。

此外，还需要说明的是，在另一些实现方式中，为了能够让用户有更好的用户体验，还可以提供用户操作入口，由用户选择是否开启DFT数据收集功能。

示例性的，对于这种方式，在一些实施例中，例如可以在用户界面提供专门用于开启DFT数据收集功能的应用程序，用户通过操作该应用程序中提供的功能控件实现DFT数据收集功能的开启或关闭。

示例性的，在另一些实现方式中，也可以将开启DFT数据收集功能的入口集成于第一电子设备已有的应用程序中，如设置应用中。这样，用户通过从设置应用中查找到该功能对应的控件，就可以实现DFT数据收集功能的开启或关闭。

示例性的，在另一些实现方式中，还可以提供一些快捷方式，如通过设置指定手势、语音指令等。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S202，采用预设传输方式，将收集到的DFT数据传输给第二电子设备。

关于本实施例中所说的预设传输方式，例如为上文所说的云端传输方式、存储芯片获取方式、总线输入方式中的任意一种或几种，本实施例对此不作限制。关于这些传输方式的具体实现细节，可以参见上文，此处不再赘述。

S203，根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

示例性的，关于第二电子设备根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略，例如可以如图12所示，根据DFT数据中的调用者统计信息、文件请求次数、预设时间内请求最多的上层应用、上层应用对应的消息请求失败的次数等，对第一文件服务调度策略中针对业务合理性的参数、针对上文所说的优先级策略表的参数进行调整，如将指定调用者的优先级设置为最高优先级，将文件请求次数增多的消息请求的优先级调高等，此处不再一一例举，本实施例对此不作限制。

示例性的，对于将指定调用者的优先级设置为最高优先级的场景，例如可以是在DFT数据中记录的内容为在1秒内，调用者A(如音乐播放器应用)发起的文件请求次数最多，为3次，失败次数为3次，并且在后续几秒内，调用者A发起的请求依旧呈现增加趋势，且失败次数也随着增加时，为了避免该调用者A发起的请求一直得不到响应，用户一直触发该调用者发起请求，进而影响用户体验，并对系统资源造成影响，可以将调用者A的优先级设置为最高优先级，这样当用户再次通过调用者A发起请求后，由于调整后的优先级最高，调用者A本次发起的请求就会被优先调度。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图12，还可以根据DFT数据中上层应用对应的消息请求失败的次数、上层应用触发消息请求到处理完的响应时长等，对第一文件服务调度策略中针对上层应用的消息请求对应的超时时间的参数进行调整，如根据响应时间缩短超时时间等，此处不再一一例举，本实施例对此不作限制。

示例性的，对于根据响应时间缩短超时时间的场景，以上文所说的播放音乐同时对屏幕进行滑动，打开消息通知界面的场景进行说明。通过上述说明可知，这一场景涉及三个任务，分别是音频任务、显示任务和传感器任务，由于传感器任务自身的优先级已经是最高的，故而在一些实现方式中无需对其对应的超时时间进行调整，为了保证这一场景的顺利，可以将音频任务和显示任务对应的超时时间缩短，这样在还有其他任务对应的消息请求需要被调度的场景下，这两个应用的任务的消息请求就可以优先被调度。

示例性的，对于根据响应时间缩短超时时间的场景，对于同时使用GPS类应用和测试心率的应用，由于这两个功能的实现都需要对文件系统服务进行读写访问，因此可以将这两个应用对应的任务的超时时间缩短，这样在还有其他任务对应的消息请求需要被调度的场景下，这两个应用的任务的消息请求就可以优先被调度。

例如可以是在DFT数据中记录的内容为某一应用对应的消息请求失败的次数为小于某一阈值，或者失败次数为0时，且每一次处理完成的响应时长都要小于为其设置的超时时间时，为了让其他消息请求能够更好的被调度，在保证该消息请求能够被调度，且能够在

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图12，还可以根据DFT数据中每个消息请求在普通队列的饥饿时长等，对第一文件服务调度策略中针对不同任务对应的消息请求的饥饿时间阈值的参数进行调整。

示例性的，对于调整不同任务对应的消息请求的饥饿时间阈值的场景，例如可以是在DFT数据中记录的某些任务对应的消息请求在普通队列的等待时间，即饥饿时间每次都超过了对应的饥饿时间阈值，则可以将此类消息请求对应的饥饿时间阈值增大，反之则缩小。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图12，还可以根据DFT数据中VIP队列的总运行时长等，对第一文件服务调度策略中针对VIP队列的喂饱时间阈值的参数进行调整。

示例性的，对于调整VIP队列的喂饱时间阈值的场景，例如可以是在DFT数据中记录的VIP队列中等待执行的消息请求大于某一阈值时，可以将喂饱时间阈值调大，以便已经超过饥饿时间阈值的消息请求被移动到VIP队列的消息请求，能够尽快被调度。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图12，还可以根据DFT数据中被调用最多的API接口、被访问最多的文件等，对第一文件服务调度策略中对被调度的文件在存储器存放位置的参数进行调整。

示例性的，对于调整被调度的文件在存储器存放位置的的场景，例如可以是在DFT数据中记录的对位置A的文件A调度次数增多，但是处理的响应时长较长，为了提升用户体验，使得原本存放在位置A的文件A的调度速度能够变化，可以将文件A从位置A移动到访问速度更快的位置B，例如从位于外部存储器的位置A中移动到位于内存中的位置B。由于内存的访问速度要快于外部存储器，因此将文件A从位置A移动到位置B后，后续的响应实时会大大缩短。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，还需要说明的是，上述各个示例中，涉及对时间调整的，其调整后的时间不大于系统的软狗超时时间，以及硬狗的喂狗时间，即在避免出现软狗超时，甚至硬狗超时的情况下，能够尽快完成VIP队列、普通队列中的消息请求的调度处理。

此外，可理解的，本实施例中，根据DFT数据对第一文件服务调度策略进行调整的过程，例如可以是根据多个第一电子设备提供的DFT数据对第一文件服务调度策略进行调整，也可以时根据一个第一电子设备提供的DFT数据对该电子设备对应的第一文件服务调度策略进行调整。具体的实现逻辑可以参见上文，此处不再赘述。

此外，需要说明的是，关于第二电子设备根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略的操作，在一些实现方式中例如可以是在接收到的DFT数据满足设置的数量时触发；在另一些实现方式中例如可以是在接收DFT数据的时间满足设置的时间时触发。即，可以按时和/或按量来确定合适触发第二电子设备执行上述步骤S203。

关于上述所依据的时间和数量，可以根据第一电子设备对文件系统的调度频率、用户群体特性等合理设置。比如，对于调度频率高、用户群体年轻化喜欢同时进行多任务触发的，可以将调整时间设置的短些。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，在得到第二文件服务调度策略户，根据上文所说可知，在一些实现方式中，可以将得到的第二文件服务调度策略上传至第一电子设备能够访问的云端，以便云端在确定有第二文件服务调度策略时，主动向第一电子设备推送第二文件服务调度策略，也可以由第一电子设备按照周期主动向第二电子设备发起请求，以获取第二文件服务调度策略。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S204，基于第二文件服务调度策略对文件系统进行调度。

关于第一电子设备基于第二文件服务调度策略对文件系统进行调度的细节，与上述基于第一文件服务调度策略对文件系统进行调度的过程类似，此处不再赘述。

此外，可理解的，在DFT数据收集功能开启的情况下，第一电子设备在基于第二文件服务调度策略对文件系统进行调度的过程中，同样会收集DFT数据，并将收集的DFT数据采用预设传输方式传输给第二电子设备。

相应地，第二电子设备也会根据基于第二文件服务调度策略对文件系统进行调度过程中收集到的DFT数据对第二文件服务调度策略进行调整，进而得到第三文件服务调度策略。

即，在DFT数据收集功能开启的状态下，会按照上述逻辑循环执行上述操作，从而得到满足各个场景需求的文件服务调度策略。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本实施例提供的嵌入式操作系统中文件系统的调度方法，通过收集嵌入式操作系统的电子设备基于已有文件服务调度策略对文件系统进行调度过程中的DFT数据，由其他电子设备根据DFT数据对已有的文件服务调度策略进行调整优化，并将调整后的文件服务调度策略发布给嵌入式操作系统的电子设，通过这种不断优化调整文件服务调度策略的方式，使文件系统调度服务能够筛选出更加合理的消息请求对文件系统进行调度，进一步保障了文件系统的调度合理性。

此外，通过其他电子设备，如上文的第二电子设备对文件服务调度策略进行优化调整，能够有效减少对第一电子设备资源和性能的占用。

关于上述所说的由其嵌入式操作系统的电子设备自身对DFT数据进行分析处理，调整已有文件服务调度策略的实现流程，以下结合图13进行说明。

S301，在基于第一文件服务调度策略对文件系统进行调度的过程中，收集DFT数据。

S302，根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

S303，基于第二文件服务调度策略对文件系统进行调度。

不难发现，本实施例中根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略的操作具体是由嵌入式操作系统的电子设备在本地实现的，其具体处理逻辑与上述实施例中由第二电子设备完成的逻辑大致相同，此处不再赘述。

由此，本实施例提供的嵌入式操作系统中文件系统的调度方法，嵌入式操作系统的电子设备通过收集基于已有文件服务调度策略对文件系统进行调度过程中的DFT数据，并根据收集到的DFT数据在本地实现对已有的文件服务调度策略进行调整优化，通过这种不断优化调整文件服务调度策略的方式，使文件系统调度服务能够筛选出更加合理的消息请求对文件系统进行调度，进一步保障了文件系统的调度合理性。

此外，通过嵌入式操作系统的电子设备对文件服务调度策略进行优化调整，使得嵌入式操作系统的电子设备即便处于离网状态，也可以对文件服务调度策略进行离线调整优化。

进一步地，在实际应用中，也可以同时融入上述两种获得第二文件服务调度策略的方式，具体流程如图14。

参见图14，示例性的，在本实施例中，嵌入式操作系统中文件系统的调度方法包括：

S401，在基于第一文件服务调度策略对文件系统进行调度的过程中，收集DFT数据。

S402，是否与第二电子设备建立通信连接。

即，第一电子设备是否第二电子设备建立了上文所说的对应云端传输方式、存储芯片获取方式、总线输入方式中任意一种或几种的通信连接。

相应地，在第一电子设备与第二电子设备建立了通信连接时，将收集到的DFT数据传输给第二电子设备，并由第二电子设备根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略，即执行步骤S405；反之，则直接有第一电子设备在本地完成对第一文件服务调度策略的调整，即执行步骤S403。

S403，根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

S404，基于第二文件服务调度策略对文件系统进行调度。

S405，根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略。

由于本实施例是将上述两种方式融合在了一起，未在本实施例描述的细节可以参见上文，此处不再赘述。

由此，本实施例提供的嵌入式操作系统中文件系统的调度方法，在第一电子设备与第二电子设备之间建立通信连接时，由第二电子设备根据DFT数据对第一文件服务调度策略进行调整，得到第二文件服务调度策略，从减少了对第一电子设备资源和性能的占用；在第一电子设备与第二电子设备之间未建立通信连接时，由第一电子设备对文件服务调度策略进行优化调整，使得第一电子设备即便处于离网状态，也可以对文件服务调度策略进行离线调整优化。

此外，可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

此外，还应当理解的是，本申请各实施例中所说的集成嵌入式操作系统的电子设备，均为具备文件系统服务的电子设备，因此上述各电子设备均能实现本申请提供的嵌入式操作系统中文件系统的调度方法。

此外，需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的嵌入式操作系统中文件系统的调度方法，也可以由电子设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的嵌入式操作系统中文件系统的调度方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的嵌入式操作系统中文件系统的调度方法。

另外，本申请的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的嵌入式操作系统中文件系统的调度方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

此外，通过上述描述可知，本申请实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (15)

1.一种嵌入式操作系统中文件系统的调度方法，其特征在于，应用于第一电子设备，所述第一电子设备集成了嵌入式操作系统，所述嵌入式操作系统包括文件系统，所述方法包括：

基于第一文件服务调度策略，根据获取到的第一任务的消息请求和第二任务的消息请求对所述文件系统进行调度，所述第一文件服务调度策略规定了所述第二任务的优先级高于所述第一任务的优先级；其中，在获取到所述第一任务的消息请求和所述第二任务的消息请求后，将所述第一任务的消息请求和所述第二任务的消息请求添加到第一队列，记录每一个消息请求在所述第一队列的饥饿时间，将每一个消息请求的饥饿时间与对应的饥饿时间阈值进行比较，将饥饿时间达到对应的饥饿时间阈值的消息请求从所述第一队列移动到第二队列，所述饥饿时间为消息请求在所述第一队列中等待调度的时间，所述第二队列在初始情况下为空队列，所述第二队列的优先级高于所述第一队列；

在所述第二队列存在消息队列的情况下，基于所述第一文件服务调度策略优先从所述第二队列中获取消息请求，根据从所述第二队列中获取到的消息请求对所述文件系统进行调度，并记录所述第二队列的喂饱时长，所述喂饱时长为所述第二队列的总运行时长；

在所述第二队列的喂饱时长达到喂饱时间阈值的情况下，基于所述第一文件服务调度策略从所述第一队列中获取消息请求，根据从所述第一队列中获取到的消息请求对所述文件系统进行调度；

所述方法还包括：

在基于第一文件服务调度策略对所述文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据；

采用所述预设方式对应的预设传输方式，将所述DFT数据传输给第二电子设备；

获取所述第二电子设备根据所述DFT数据对所述第一文件服务调度策略进行调整得到的第二文件服务调度策略；

基于所述第二文件服务调度策略对所述文件系统进行调度，所述第二文件服务调度策略规定了所述第二任务的优先级低于或等于所述第一任务的优先级；

其中，所述根据所述DFT数据对所述第一文件服务调度策略进行调整，包括：

根据所述DFT数据中每个消息请求在第一队列的饥饿时间，对所述第一文件服务调度策略中针对不同任务对应的消息请求的饥饿时间阈值的参数进行调整，所述第一队列用于存储在不同时刻获取到的消息请求；

所述根据所述DFT数据对所述第一文件服务调度策略进行调整，还包括：

根据所述DFT数据中第二队列的总运行时长，对所述第一文件服务调度策略中针对第二队列的喂饱时间阈值的参数进行调整，所述第二队列用于存放从第一队列中饥饿时间达到饥饿时间阈值的消息请求。

2.根据权利要求1所述的方法，其特征在于，所述基于第一文件服务调度策略，根据获取到的第一任务的消息请求和第二任务的消息请求对所述文件系统进行调度，包括：

在第一时刻获取到所述第一任务的第一消息请求，所述第一消息请求包括第一文件操作指令；

在第二时刻获取到所述第一任务的第二消息请求，所述第二消息请求包括第二文件操作指令，所述第二时刻晚于所述第一时刻；

响应于所述第一消息请求，执行所述第一文件操作指令；

在执行所述第二文件操作指令之前，在第三时刻获取到所述第二任务的第三消息请求，所述第三消息请求包括第三文件操作指令，所述第三时刻晚于所述第二时刻；

基于所述第一文件服务调度策略，选择所述第三消息请求，执行所述第三文件操作指令；

在执行所述第三文件操作指令之后，执行所述第二文件操作指令。

3.根据权利要求2所述的方法，其特征在于，所述基于所述第二文件服务调度策略对所述文件系统进行调度，包括：

在第四时刻获取到所述第一任务的第四消息请求，所述第四消息请求包括第四文件操作指令；

在第五时刻获取到所述第二任务的第五消息请求，所述第五消息请求包括第五文件操作指令，所述第五时刻晚于所述第四时刻；

基于所述第二文件服务调度策略，选择所述第四消息请求，执行所述第四文件操作指令；

在执行所述第四文件操作指令之后，执行所述第五文件操作指令。

4.根据权利要求2所述的方法，其特征在于，所述在基于第一文件服务调度策略对所述文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：

在执行所述第一文件操作指令、所述第二文件操作指令和所述所述第三文件操作指令的过程中，采用预设方式收集所述DFT数据。

5.根据权利要求1所述的方法，其特征在于，所述根据所述DFT数据对所述第一文件服务调度策略进行调整，还包括：

根据所述DFT数据中的调用者统计信息、文件请求次数、预设时间内请求最多的上层应用、上层应用对应的消息请求失败的次数，对所述第一文件服务调度策略中针对业务合理性的参数、针对不同任务的优先级进行调整。

6.根据权利要求1所述的方法，其特征在于，所述根据所述DFT数据对所述第一文件服务调度策略进行调整，还包括：

根据所述DFT数据中上层应用对应的消息请求失败的次数、上层应用触发消息请求到处理完的响应时长，对所述第一文件服务调度策略中针对上层应用的消息请求对应的超时时间的参数进行调整。

7.根据权利要求1所述的方法，其特征在于，所述根据所述DFT数据对所述第一文件服务调度策略进行调整，还包括：

根据所述DFT数据中被调用最多的应用编程接口、被访问最多的文件，对所述第一文件服务调度策略中对被调度的文件在存储器存放位置的参数进行调整。

8.根据权利要求1所述的方法，其特征在于，在所述采用预设传输方式，将所述DFT数据传输给第二电子设备之前，所述方法还包括：

判断是否与所述第二电子设备建立了所述预设传输方式对应的通信连接；

当与所述第二电子设备建立了所述预设传输方式对应的通信连接时，执行所述采用预设传输方式，将所述DFT数据传输给第二电子设备的步骤；

当未与所述第二电子设备建立了所述预设传输方式对应的通信连接时，根据所述DFT数据对所述第一文件服务调度策略进行调整，得到所述第二文件服务调度策略。

9.根据权利要求1至8任一项所述的方法，其特征在于，所述预设方式为大数据看板方式，所述预设传输方式为云端传输方式；

所述在基于第一文件服务调度策略对所述文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：

在基于第一文件服务调度策略对所述文件系统进行调度的过程中，通过设定的接口将调度过程中产生的DFT数据集成到大数据看板中；

所述采用所述预设方式对应的预设传输方式，将所述DFT数据传输给第二电子设备，包括：

通过嵌入式操作系统中的视图系统，调用所述设定的接口，将集成到所述大数据看板中的所述DFT数据输出；

通过所述视图系统提供的用于记录数据的接口，将所述DFT数据写入到离线的视图系统；

通过云端传输方式，将写入离线的视图系统的所述DFT数据传输给所述第二电子设备。

10.根据权利要求1至8任一项所述的方法，其特征在于，所述预设方式为日志方式，所述预设传输方式为存储芯片获取方式；

所述在基于第一文件服务调度策略对所述文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：

在基于第一文件服务调度策略对所述文件系统进行调度的过程中，生成日志文件；

将所述日志文件存储到存储芯片；

所述采用所述预设方式对应的预设传输方式，将所述DFT数据传输给第二电子设备，包括：

按照预设周期，从所述存储芯片中读取所述日志文件，并将读取到的所述日志文件传输给所述第二电子设备。

11.根据权利要求1至8任一项所述的方法，其特征在于，所述预设方式为日志方式，所述预设传输方式为总线输入方式；

所述在基于第一文件服务调度策略对所述文件系统进行调度的过程中，采用预设方式收集可测性设计DFT数据，包括：

在基于第一文件服务调度策略对所述文件系统进行调度的过程中，生成日志文件；

将所述日志文件存储到存储芯片；

所述采用所述预设方式对应的预设传输方式，将所述DFT数据传输给第二电子设备，包括：

通过连接所述第一电子设备与所述第二电子设备的总线，将所述日志文件实时传输给所述第二电子设备。

12.根据权利要求1至8任一项所述的方法，其特征在于，在所述第二文件服务调度策略由所述第二电子设备生成时，所述方法还包括：

将每一个所述第一电子设备收集的所述DFT数据进行融合；

根据融合后的所述DFT数据对所述第一文件服务调度策略进行调整，得到所述第二文件服务调度策略。

13.根据权利要求1至8任一项所述的方法，其特征在于，在所述第二文件服务调度策略由所述第二电子设备生成时，所述方法还包括：

对于每一个所述第一电子设备，根据所述第一电子设备收集的所述DFT数据，对所述第一文件服务调度策略进行调整，得到所述第一电子设备对应的所述第二文件服务调度策略。

14.一种电子设备，其特征在于，所述电子设备集成了嵌入式操作系统，所述嵌入式操作系统中包括文件系统，所述电子设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至13任意一项所述的嵌入式操作系统中文件系统的调度方法。

15.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至13任意一项所述的嵌入式操作系统中文件系统的调度方法。