代码检测方法、装置、电子设备和存储介质与流程

1.本技术涉及代码测试技术领域，具体而言，涉及代码检测方法、装置、电子设备和存储介质。


背景技术：

2.静态代码检查是由具备丰富编码经验并对安全编码原则及应用安全具有深刻理解的安全服务人员对系统的源代码和软件架构的安全性、可靠性进行全面的安全检查。从而让开发人员了解其开发的应用系统可能会面临的威胁，并指导开发人员正确修复程序缺陷。
3.现有的静态代码检测方法包括：基于二进制代码的模式匹配对二进制代码的模式匹配是最早被采用的静态分析方法；基于二进制代码的模式匹配对二进制代码的模式匹配是最早被采用的静态分析方法；基于编译中间代码的分析。现有技术通常都是采用一种静态代码检测工具来对静态代码进行检测，所得到的数据比较单一，对代码的分析不够全面。


技术实现要素：

4.有鉴于此，本技术实施例的目的在于提供代码检测方法、装置、电子设备和存储介质，能够对代码实现全面检测。
5.第一方面，本技术实施例提供了一种方法，包括：
6.部署多个代码检测工具；
7.接收检测任务；
8.根据所述检测任务驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
9.在上述实现过程中，一次性部署多个代码检测工具，利用多个代码检测工具对代码进行检测，实现了对代码的全面检测。通过接收检测任务，根据检测任务驱动多个代码检测工具中的至少一个检测代码对代码进行检测，能够实现对代码的定制化检测。
10.进一步地，所述根据所述检测任务驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果的步骤，包括：
11.根据所述检测任务生成所述至少一个代码检测工具的运行命令行；
12.运行所述运行命令行，驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测，得到所述检测结果。
13.在上述实现过程中，将检测任务转换为运行命令行，通过命令行驱动代码检测工具，实现了驱动方式的统一。
14.进一步地，所述根据所述检测任务生成所述至少一个代码检测工具的运行命令行的步骤之前，包括：
15.获取所述多个代码检测工具的运行命令；
16.将所述运行命令中的配置参数替换为通配符，得到标准运行命令；
17.所述根据所述检测任务生成所述至少一个代码检测工具的运行命令行的步骤，包括：
18.根据所述检测任务生成配置信息；
19.将所述配置信息替换所述标准运行命令中的通配符，得到所述至少一个代码检测工具的运行命令行。
20.在上述实现过程中，提供了一种将得检测任务转换为运行命令行的方法。每个代码检测工具具有对应的运行命令，标准运行命令中包括配置参数，配置参数用于控制代码检测工具的具体执行方式，执行对象，通过利用通配符替换配置参数，能够实现基于检测任务生成对应的运行命令行，从而实现对代码的定制化检测。
21.进一步地，所述根据所述检测任务驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测的步骤，包括：
22.获取所述至少一个代码检测工具对应的进程状态；
23.当所述进程状态为停止中且持续时间超过预设阈值时，在所述进程对应的存储区获取所述检测结果，终止所述进程。
24.在上述实现过程中，由于涉及到多个代码检测工具的运行，因此，对所述至少一个代码检测工具对应的进程状态进行监控，当所述进程状态为停止中时，有可能是正常终止，当进程状态为停止中且持续时间超过预设阈值时，说明此时对应的代码检测可能发生异常或运行错误，直接在进程对应存储区获取检测结果，然后直接终止进程。基于上述实施方式，能够及时释放掉进程占用的资源，也能够保证检测结果不被丢弃。
25.进一步地，所述代码检测任务包括所述至少一个代码检测工具的执行顺序；
26.所述根据所述检测任务驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测的步骤，得到检测结果的步骤，包括：
27.根据所述执行顺序驱动所述至少一个代码检测工具进行代码检测，依次得到所述至少一个代码检测工具的检测结果；
28.响应于每个所述检测结果的生成信号，判断所述检测结果是否符合预设条件，若否，停止驱动所述多个代码检测工具。
29.在上述实现过程中，考虑到有时不需要利用全部检测工具进行代码检测，并且有的时候如果单一的检测工具检测到代码的记过对应的缺陷数据过多，则直接对代码进行修复，不再进行代码检测，因此，提出了检测任务中包括至少一个代码检测工具的检测顺序，如果一个代码检测报告中的检测结果不符合预设条件，则终止检测流程。基于上述实施方式，能够节省检测时间，提高检测效率。
30.进一步地，所述检测结果包括：所述至少一个代码检测工具的检测报告；
31.所述得到检测结果之后，还包括：
32.将所述至少一个代码检测工具的检测报告转换为通用报告。
33.在上述实现过程中，每个检测工具具有对应的检测报告，不同的检测报告具有其对应报告格式，为了提高运维人员以及开发人员的工作效率，将所述至少一个代码检测工具的检测报告转换为通用报告。
34.进一步地，所述将所述至少一个代码检测工具的检测报告转换为通用报告的步骤之前，包括：
35.建立通用报告模板；
36.获取每个代码检测工具的检测报告的标签和所述通用报告模板中的标签的映射关系；
37.所述将所述至少一个代码检测工具的检测报告转换为通用报告的步骤，包括：
38.根据所述映射关系将所述至少一个代码检测工具的检测报告中的标签的属性数据添加到所述通用报告模板的标签中，得到所述通用报告。
39.在上述实现过程中，每个代码检测工具的检测报告都是基于标签的语言进行描述的，因此，为了将多个代码检测工具的检测报告转换为通用的检测报告，可以预先建立通用报告模板，获取每个代码检测工具的检测报告的标签和所述通用报告模板中的标签的映射关系，在获取到多个代码检测工具的报告之后，根据所述映射关系将所述至少一个代码检测工具的检测报告中的标签的属性数据添加到所述通用报告模板的标签中，得到所述通用报告。
40.第二方面，本技术实施例提供了一种代码检测装置，包括：
41.部署模块，用于部署多个代码检测工具；
42.接收模块，用于接收检测任务；
43.检测模块，用于根据所述检测任务驱动所述多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
44.第三方面，本技术实施例提供的一种电子设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面任一项所述的方法的步骤。
45.第四方面，本技术实施例提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，使得所述计算机执行如第一方面任一项所述的方法。
46.本技术公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本技术公开的上述技术即可得知。
47.为使本技术的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
48.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
49.图1为本技术实施例提供的代码检测检测系统的结构示意图；
50.图2为本技术实施例提供的代码检测方法的流程示意图；
51.图3为本技术实施例提供的代码检测方法的流程示意图；
52.图4为本技术实施例提供的代码检测装置的结构示意图；
53.图5为本技术实施例提供的电子设备的结构示意图。
具体实施方式
54.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
55.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
56.实施例1
57.本技术实施例提供一种代码检测检测系统，包括：服务管理模块、数据库、第三方工具、扫描器、通用模型、服务端。其中，服务管理模块包括：代码扫描任务管理单元，用于管理代码扫描任务，下发任务，删除任务查看任务结果等；工具集成单元，用于管理集成工具，提供工具命令配置，工具模板格式配置。
58.第三方工具包括各种辅助工具，如服务部署工具、静态代码扫描工具、结果报告生成工具等；服务部署工具用于将多个代码检测工具进行部署；静态代码扫描单元用于接收服务端的调用，利用第三方代码扫描单元实现对代码的静态扫描；结果报告单单元用于生成静态代码扫描单元的报告。
59.扫描器中包括了各种部署的代码检测工具，如：词法分析、语义分析、抽象语法树、数据流分析、控制流分析、模型加载、结果文件生成等单元，扫描器用于接收到服务端下发的任务，读取静态代码文件，分析、转换之后加载不同代码检测工具模型，由模型进行缺陷检测后，生成检测结果文件上报至服务端。
60.通用模型包括：通用报告数据解析单元，用于对预定义的通用报告格式数据进行解析获取任务结果；缺陷检测单元，用于根据规则对代码中的缺陷进行检测。
61.服务端包括：计算引擎模块，计算引擎模块包括：代码基本信息分析单元，用于对代码的基本信息进行分析，如代码的认知复杂度、圈复杂度等；指标信息计算单元，用于计算代码的指标信息如时间复杂度等；通用报告数据解析单元，用于基于代码基本分析单元和指标信息计算单元生成基本报告单元。
62.服务端还包括：报告解析模块，报告解析模块包括：报告格式管理单元，用于生成通用报告模板；报告格式转换单元，用于调用相关的第三方工具的报告，根据数据库中存储的映射关系将至少一个代码检测工具的报告生成通用报告。
63.服务端还包括：服务调用模块，服务调用模块包括：进程生命周期管理单元，用于监听第三方工具的运行状态，包括初始化、运行中、停止中、已停止等状态；动态生成服务指令单元，根据任务配置和工具配置结合，根据每个任务的信息生成不同的工具调用指令；多服务调度管理单元，依赖于进程生命周期管理单元，获取第三方工具的运行状态，对多个第三方工具进行指定顺序的调度。
64.数据库中存储有各种解析规则，代码检测工具的任务信息，用于生成缺陷数据的缺陷信息、缓存信息、通用报告模板的相关信息、各种代码检测工具的不同服务对应的服务命令信息等，用于解析各种代码检测工具的报告的报告格式信息。
65.实施例2
66.参见图2，本技术实施例提供一种代码检测方法，包括：
67.s201：部署多个代码检测工具；
68.上述实施例，服务端调用第三方工具中的服务部署单元将多个代码检测工具部署
在一个或多个服务器上，或者一个或多个服务器集群中。
69.其中，代码检测工具可以是第三方工具可以是cppcheck、findbugs、checkstyle等。cppcheck是一种c/c++代码缺陷静态检查工具。findbugs是一个静态分析工具，它检查类或者jar文件，将字节码与一组缺陷模式进行对比以发现可能的问题。checkstyle是一款检查java程序代码样式的工具，可以有效的帮助我们检视代码以便更好的遵循代码编写标准，特别适用于小组开发时彼此间的样式规范和统一。
70.s202：接收检测任务；
71.上述实施例中，代码扫描任务管理单元接收检测任务，将检测任务下发到服务端。
72.s203：根据检测任务驱动多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
73.上述实施例中，服务端调用扫描器，利用扫描器中各种功能单元对代码进行检测，得到检测结果。服务器还可以调用第三方工具中的静态代码扫描单元，对代码进行第三方的静态代码扫描。由第三方工具中的结果报告单元生成静态代码扫描单元的结果报告。
74.在上述实现过程中，一次性部署多个代码检测工具，利用多个代码检测工具对代码进行检测，实现了对代码的全面检测。通过接收检测任务，根据检测任务驱动多个代码检测工具中的至少一个检测代码对代码进行检测，能够实现对代码的定制化检测。
75.在一可能的实施方式中，s203包括：根据检测任务生成至少一个代码检测工具的运行命令行；运行运行命令行，驱动多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
76.数据库中存储有各种代码检测工具的标准运行命令，在服务管理模块接收到该任务之后，将该检测任务下发到服务端，服务端的服务调用模块中得到动态生成服务指令单元根据检测任务和数据库中对应的标准运命令行，驱动至少一个代码检测工具。
77.在上述实现过程中，将检测任务转换为运行命令行，通过命令行驱动代码检测工具，实现了驱动方式的统一。
78.在一可能的实施方式中，s203之前，包括：获取多个代码检测工具的运行命令；将运行命令中的配置参数替换为通配符，得到标准运行命令；s203包括：根据检测任务生成配置信息；将配置信息替换标准运行命令中的通配符，得到至少一个代码检测工具的运行命令行。
79.服务端首先接收多个代码检测工具的运行命令，然后将运行命令中的配置参数替换为通配符，得到标准运行命令。在服务端接收到检测任务时，动态生成服务指令单元对检测任务进行解析，得到其中的配置信息，配置信息包括：代码的存储路径，要以何种的方式对代码进行检测，将标准运行命令中的通配符替换为配置信息，得到至少一个代码检测工具的运行命令行，多服务调度管理模块根据至少一个代码检测工具的运行命令行启动至少一个代码检测工具待代码进行检测。
80.在上述实现过程中，提供了一种将得检测任务转换为运行命令行的方法。每个代码检测工具具有对应的运行命令，标准运行命令中包括配置参数，配置参数用于控制代码检测工具的具体执行方式，执行对象，通过利用通配符替换配置参数，能够实现基于检测任务生成对应的运行命令行，从而实现对代码的定制化检测。
81.在一可能的实施方式中，s203包括：获取至少一个代码检测工具的进程状态；当进
程状态为停止中且持续时间超过预设阈值时，在进程对应的存储区获取检测结果，终止进程。
82.在服务端驱动扫描器中的多个单元开始进行代码检测时，服务端调用模块中的进程生命周期管理模块对进程进行监控，程状态分为：初始化、运行中、停止中、强制停止中、已停止。初始化状态是准备阶段，主要是申请计算机资源等，当多服务调度管理单元通过指令调度至少一个代码检测工具后，进程生命周期管理单元获取到进程号，监听至少一个代码检测工具的运行日志，将至少一个代码检测工具对应的进程状态更新为运行中，当至少一个代码检测工具结束运行时，已经产生了检测报告，更新进程状态为停止中，若停止超时则将进程状态更新为强制停止中，通过命令强制终止工具进程。当进程被终止后，更新进程状态为已停止，此时服务端调用通用模型中的通用报告数据解析单元和缺陷测试单元生成报告并基于报告生成缺陷测试结果。
83.在上述实现过程中，提供了一种将得检测任务转换为运行命令行的方法。每个代码检测工具具有对应的运行命令，标准运行命令中包括配置参数，配置参数用于控制代码检测工具的具体执行方式，执行对象，通过利用通配符替换配置参数，能够实现基于检测任务生成对应的运行命令行，从而实现对代码的定制化检测。
84.在一可能的实施方式中，检测任务包括至少一个代码检测工具的执行顺序；s203包括：根据执行顺序驱动至少一个代码检测工具进行代码检测，依次得到至少一个代码检测工具的检测结果；响应于每个检测结果的生成信号，判断检测结果是否符合预设条件，若否，停止驱动多个代码检测工具。
85.多服务调度管理单元在接收到至少一个代码检测工具的指令之后，动态生成服务指令单元生成至少一个代码检测工具的运行命令行，将至少一个代码检测工具的运行命令行转换为指令序列，根据指令序列依次驱动至少一个代码检测工具中的一个代码检测工具，每次一个代码检测工具的检测报告生成之后，通用报告数据解析单元直接对该新生成的代码检测报告进行解析，如果解析出来的缺陷数据过多，则直接重新对代码进行改造，无需再利用其他的代码检测工具对代码进行检测，节省检测时间。
86.在上述实现过程中，由于涉及到多个代码检测工具的运行，因此，对至少一个代码检测工具对应的进程状态进行监控，当进程状态为停止中时，有可能是正常终止，当进程状态为停止中且持续时间超过预设阈值时，说明此时对应的代码检测可能发生异常或运行错误，直接在进程对应存储区获取检测结果，然后直接终止进程。基于上述实施方式，能够及时释放掉进程占用的资源，也能够保证检测结果不被丢弃。
87.在一可能的实施方式中，检测结果包括：至少一个代码检测工具的检测报告；s203之后，还包括：将至少一个代码检测工具的检测报告转换为通用报告。
88.在一可能的实施方式中，将至少一个代码检测工具的检测报告转换为通用报告的步骤之前，包括：建立通用报告模板；获取每个代码检测工具的检测报告的标签和通用报告模板中的标签的映射关系；将至少一个代码检测工具的检测报告转换为通用报告的步骤，包括：根据映射关系将至少一个代码检测工具的检测报告中的标签的属性数据添加到通用报告模板的标签中，得到通用报告。
89.示例性地，参见图3，为通用报告模板的标签示意图；配置报告共4层，第三层的bug标签为缺陷信息，bug标签上的name属性为缺陷名称，type为缺陷类型等，记录报告数据与
缺陷属性的映射关系。而cppcheck生成的检测报告中的xml标签有：results、errors、error、location、symbol。error中的属性有id、severity、msg、verbose、cwe；localtion中的属性有file、line、column、info。报告格式转换单元根据通用数据库中存储的映射关系将至少一个检测工具的检测报告转换为通用报告。
90.在上述实现过程中，每个代码检测工具的检测报告都是基于标签的语言进行描述的，因此，为了将多个代码检测工具的检测报告转换为通用的检测报告，可以预先建立通用报告模板，获取每个代码检测工具的检测报告的标签和通用报告模板中的标签的映射关系，在获取到多个代码检测工具的报告之后，根据映射关系将至少一个代码检测工具的检测报告中的标签的属性数据添加到通用报告模板的标签中，得到通用报告。
91.在生成通用报告之后，还对代码进行基本进行分析、指标信息计算，得到对应的结果报告。
92.根据通用报告和结果报告生成最终的报告，显示该最终的报告，以及将该报告存储在数据库中。
93.在一可能的实施方式中，恶意将该方法应用于web扫描器上，在原有的web扫描器能力上，新增实施例1中的代码检测检测系统和审计模块。web扫描器运行后从web靶场中，对站点进行爬虫，获取到网站html文件和javascript文件。爬虫结束后，代码检测检测系统调用源代码扫描工具，下发静态代码检测任务，调用扫描器加载通用模型后对爬虫文件进行检测。同时审计模块输出网页的web漏洞数据，上报至报告解析模块，报告解析模块根据配置好的web漏洞数据格式，将web漏洞数据解析后，和代码缺陷结果结合，进行结果计算，最后得到代码缺陷和web漏洞融合的结果数据。
94.综上，本技术实施例具有以下有益效果：通过报告文件解析技术，实现了工具集成的可配置化，减少了开发编码流程，非开发人员可以通过新增配置项迅速将第三方检测工具集成。通过通用报告解析模型，提升了工具集成的兼容性，对于不同的工具，根据配置将不同形式的结果数据转换为统一的报告文件格式进行解析入库。通过进程状态监听技术，实现了工具集成的自动化调度，根据进程运行的不同状态，来做后续任务或服务的调度。通过静态代码检查能力，提升了web扫描器能力，对爬取的站点源文件进行检测，得到代码缺陷，丰富了结果数据的类型。
95.实施例2
96.参见图4，本技术实施例提供一种代码检测装置，包括：
97.部署模块1，用于部署多个代码检测工具；
98.接收模块2，用于接收检测任务；
99.检测模块3，用于根据检测任务驱动多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
100.在一种可能的实施方式中，检测模块3还用于根据检测任务生成至少一个代码检测工具的运行命令行；运行运行命令行，驱动多个代码检测工具中的至少一个代码检测工具进行代码检测，得到检测结果。
101.在一种可能的实施方式中，装置还包括：标准运行命令生成模块，用于获取多个代码检测工具的运行命令；检测模块3还用于将运行命令中的配置参数替换为通配符，得到标准运行命令；还用于根据检测任务生成配置信息；将配置信息替换标准运行命令中的通配
符，得到至少一个代码检测工具的运行命令行。
102.在一种可能的实施方式中，检测模块3还用于获取至少一个代码检测工具的进程状态；当进程状态为停止中且持续时间超过预设阈值时，在进程对应的存储区获取检测结果，终止进程。
103.在一种可能的实施方式中，检测任务包括至少一个代码检测工具的执行顺序；检测模块3还用于根据执行顺序驱动至少一个代码检测工具进行代码检测，依次得到至少一个代码检测工具的检测结果；响应于每个检测结果的生成信号，判断检测结果是否符合预设条件，若否，停止驱动多个代码检测工具。
104.在一种可能的实施方式中，装置还包括：转换模块，用于将至少一个代码检测工具的检测报告转换为通用报告。
105.在一种可能的实施方式中，转换模块还用于建立通用报告模板；获取每个代码检测工具的检测报告的标签和通用报告模板中的标签的映射关系；根据映射关系将至少一个代码检测工具的检测报告中的标签的属性数据添加到通用报告模板的标签中，得到通用报告。
106.需要说明的是，装置中的模块还可以执行实施例2提到的各种方法。
107.本技术还提供一种电子设备，请参见图5，图5为本技术实施例提供的一种电子设备的结构框图。电子设备可以包括处理器51、通信接口52、存储器54和至少一个通信总线54。其中，通信总线54用于实现这些组件直接的连接通信。其中，本技术实施例中电子设备的通信接口52用于与其他节点设备进行信令或数据的通信。处理器51可以是一种集成电路芯片，具有信号的处理能力。
108.上述的处理器51可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器51也可以是任何常规的处理器等。
109.存储器54可以是，但不限于，随机存取存储器(random access memory，ram)，只读存储器(read only memory，rom)，可编程只读存储器(programmable read-only memory，prom)，可擦除只读存储器(erasable programmable read-only memory，eprom)，电可擦除只读存储器(electric erasable programmable read-only memory，eeprom)等。存储器54中存储有计算机可读取指令，当计算机可读取指令由处理器51执行时，电子设备可以执行上述方法实施例涉及的各个步骤。
110.可选地，电子设备还可以包括存储控制器、输入输出单元。
111.存储器54、存储控制器、处理器51、外设接口、输入输出单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线54实现电性连接。处理器51用于执行存储器54中存储的可执行模块，例如电子设备包括的软件功能模块或计算机程序。
112.输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。输入输出单元可以是，但不限于，鼠标和键盘等。
113.可以理解，图5所示的结构仅为示意，电子设备还可包括比图5中所示更多或者更
少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。
114.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有指令，当指令在计算机上运行时，计算机程序被处理器执行时实现方法实施例的方法，为避免重复，此处不再赘述。
115.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
116.另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
117.功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
118.以上仅为本技术的实施例而已，并不用于限制本技术的保护范围，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
119.以上，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。
120.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。