上图中JobLevel优先级为4的标红任务（左侧y轴高度值为14），是多个竞争同一公共资源的多个设备之间的快速任务联动。各个任务之间，没有宽度为一个扫描周期的间隔缝隙，任务是相对紧凑执行的。

任务的参与数量是按照当前在线的设备数量来变化的。如有设备上线，任务就会加入，如果设备下线，任务就退出了。

JobLevel级别为2的任务（左侧y轴高度值为12），也是按照设备数量变化。区别是，各个任务之间有宽度为一个扫描周期的间隔缝隙。也就是它会回过头执行，并不按照实例代码扫描的先后次序。

这里仅展示一个具体应用个例。相同的调度策略，可以用于给定且持续变化的约束边界范围内的多对象动态行为规划。现实中具有类似抽象本质的功能需求，还是有一些的。

把一个模块的全部功能需求，按照不同的优先级进行分类。采用通用架构，在模块内部实现。让共性和个性元素，得到充分隔离，便于随意扩展和包含丰富的健壮性考量，便于诊断。

上图中大多数任务的JobLevel级别为1（左侧y轴值11）。上图中并未包含JobLevel级别为3的任务（y轴值13），本例中L3级别任务不具有周期性。

另注：一个任务存在不同等级的JobLevel，并不代表它在条件满足的前提下，一定会获得实际优先执行的权力。

可以人为设定：即便是高优先级别的任务，在一些特定场景下，照样按照低级别来执行。第二张图即表明了这个问题。Job Level不一定等于User Level。

这就是调度的灵活性，任何东西都不必必须固定为某种不变的模式。一切都可以动态调整。