记我的CTS框架研究（2）

上一篇讲了基础框架的启动，在把命令加入到队列中前还有一步命令的解析，接下来我们就来看看命令解析，接着再看看命令的调度和执行。

3 命令解析

console线程负责从控制台读取输入，从Command RegexTrie中取出命令去执行，而其中最重要的就是run命令，需要运行的命令装载并解析并添加到CommandScheduler的命令调度队列中。
命令解析： 简单的说，就是解析其中的配置文件生成配置configuration，然后装载成一个command对象。比如：run cts这个命令，在解析的时候就是去查找cts.xml文件，拿到其中配置的组件的所指定的内容，这个内容一般是各个组件的实现类，将这个实现类保存，后面命令执行的时候使用。
组件： 基础框架是通过一系列组件来组成的，比如CommandScheduler就是GlobalConfiguration中的一个组件，也就是说，框架定义了一系列功能接口，通过这些接口的实现类，协作之后就能完成框架的功能，这些组件主要有命令的解析，调度，执行，设备管理，log的收集等等。基础框架已经提供了默认的组件实现，但是当需要真正的执行测试的时候，就需要跑自己的case，此时就需要使用自己的配置，不过自己不仅仅能定义测试case，还可以重定义组件。而解析配置文件的作用就是为了用xml文件中自定义的组件替换掉默认的组件。

第一篇文章开头就说过支持的全局组件的定义在GlobalConfiguration中，单个命令的组件定义在Configuration中：

在Console线程往CommandScheduler中addCommand时就开始了配置文件的解析

InternalCreateConfigurationFromArgs方法：

获取ConfigurationDef对象：

findConfigName:

loadConfiguration: 完成xml的sax解析

在这个地方解析完成之后，也就拿到了这个配置文件的ConfigurationDef对象，最后就是configDef.createConfiguration()：略

理一下： 整个框架的工作是通过一系列组件完成的，每次命令的执行都会有一个新的configuration出来，其中包含了所有命令执行需要的组件，但是，在解析xml文件的时候，完成了xml文件的sax解析，将其中配置的组件通过反射的方式动态替换掉了configuration中的添加的默认组件，用户组定义了的组件会使用自定义的，没有自定义的就会使用默认的组件，这也就完成了通过自定义xml文件的形式来改变框架的实际工作内容的效果，也就是注入。
回到addcommand的最后：

在验证了configuration的正确性之后，可以看到是通过configuration创建了CommandTracker（命令追踪器）对象，然后添加到了前面说过的CommandScheduler的命令队列中，等待被调度。（可以查看addExecCommandToQueue方法）

小结：对于一条run命令，后面跟着的configuration中配置的组件内容都会动态替换掉默认的组件，没有配置的就使用默认的参数，每个xml文件在经过了xml解析之后，封装成一个ConfigurationDef对象，通过其中的一系列从xml提取出的数据结构构建一个完成的configuration，生成一个command，添加到命令执行队列，进行命令调度。

**

4 命令调度

CommandScheduler本身也是一个线程，是在Console线程启动时启动的，作为命令调度的线程，主要作用就是检查本身的CommandQueue中是不是有需要处理的command，进行调度不至于多命令或者多设备时出现混乱，以及启动真正的命令执行线程。

这里的“每过30s看看是否有需要调度的命令“有待斟酌，实际命令的反馈是很快的，这里的30s的用途应该不在于此。



ProcessReadyCommands：

设备申请allocateDevices:

通过多次跳转，这里的getDeviceRequirements其实对应的是DeviceSelectionOptions这个类：（DeviceRequirements应该是在解析命令时就获取到了）

allocateDevice函数（在ManagedDeviceList.java中找到）：

理解： while里的逻辑是遍历mList(存放所有被管理的测试设备)，如果匹配，return d，并把该设备加到列表mList的后面，这样下次就会优先分配到别的设备，以达到均衡分配的目的

满足的设备都被存入了devices中（map），然后将当前命令从ready的队列移到executing队列中，并且将devices添加到了context中，context是InvocationContext的对象，包含：

记录正在执行的命令到scheduledCommandMap中，并从mUnscheduledWarning中移除。
执行命令

依次从scheduledCommandMap中取出命令，然后开启命令执行的新线程去执行命令 （命令的调度是同步的，但是命令的执行不是，所以不同命令可以同时执行，通过多线程的方式）

StartInvocation:

getSerials:

invocationThread的run方法（节选）：
其实命令执行主要还是把前面封装好的Configuration中的组件拿出来，协作运行，主要还是执行其中最重要的test标签下的类中的模板方法（test组件虽然是自己实现的，但是是遵循了模板接口的）命令的执行本质就是将组件取出来协作运行，然后调用模板方法，也就走到了真正test组件的自定义要执行的方法。
在run方法中，其实做的事情不多，就是调用了初始化时创建的TestInvocation对象的invoke方法：

组件取出运行都在TestInvocation中，这个类功能很多，承担了整个框架的大部分组件的实际运行。

**

5 命令执行

invoke方法： 主要将组件取出来协作运行，然后调用模板方法（还做了shard的操作）。里头最关键的是调用了performInvocation方法：

performInvocation主要做的事：
 首先调用startInvocation方法启动所有监听器,主要是通知作用。
 调用prepareAndRun方法进行CTS测试。
 测试完成之后给出报告结果,并且调用doTeardown进行后续处理。
最重要的方法调用:

prepareAndRun:

doSetup: 因为支持的测试种类很多，通过instanceof关键字去判断需要执行的测试到底是哪种接口的子类，就执行该模板的setup方法。
runTests: 类似与doSetup，根据不同的情况，看需要执行的测试case到底哪种，进行相应的预处理，最后调用接口的run方法。

小结：一般测试case都会实现setup，run，teardown，分别在其中做初始化，执行测试以及最后的收尾工作，通过反射的方式都拿到了测试实例，执行模板接口，所以真正执行case的时候只需要复写模板中定义好的方法即可。
这里我们要做CTS的测试，所以调用的run方法就是CompatibilityTest里的run方法了，这就从基础框架TF回到了我们的CTS中。（这里就可以结合第一篇文章开头画的那个图了）

**

基础框架中的流程图补充：

好了，基础框架就介绍到这儿了，接下来就要回到CTS框架真正执行测试了。