CN113204483A - 应用检测方法、装置、服务器、检测程序组件以及存储介质 - Google Patents

Abstract

本公开关于一种应用检测方法、装置、服务器、检测程序组件以及存储介质。涉及检测技术领域。该方法应用于服务器，该方法包括：接收针对待检测的至少一个目标移动应用的检测请求；基于检测请求生成检测指令；检测请求包括目标移动应用的应用信息；分别向至少两个检测程序组件发送检测指令；其中，检测程序组件基于检测指令生成检测任务；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。能够通过多个检测程序组件从不同的问题角度来对目标移动应用进行不同类型的检测，检测结果更加全面。

Description

应用检测方法、装置、服务器、检测程序组件以及存储介质

技术领域

本公开涉及检测技术领域，尤其涉及应用检测方法、装置、服务器、检测程序组件以及存储介质。

背景技术

随着移动电子设备的发展，移动应用承载的业务与数据越来越多，移动应用的安全风险也越来越重要，因此需要对移动应用进行风险检测，从而保证移动应用的安全可靠运行。

在相关技术中，对移动应用的检测方式，多是所采用的是单个检测程序组件对单一检测类型进行检测，这种检测方式下，检测项目容易覆盖不全，导致无法获取到移动应用的全局风险信息，检测结果不够全面。

发明内容

本公开提供一种应用检测方法、装置、服务器、检测程序组件以及存储介质，以至少解决相关技术中检测结果不够全面的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种应用检测方法，应用于服务器，所述方法包括：

接收针对待检测的至少一个目标移动应用的检测请求；

基于所述检测请求生成检测指令；所述检测请求包括所述目标移动应用的应用信息；

分别向至少两个检测程序组件发送所述检测指令；其中，所述检测程序组件基于所述检测指令生成检测任务；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

一种可选的实施例中，所述方法还包括：

接收输入的程序组件注册信息；其中，所述程序组件注册信息包括：新增检测程序组件对应的检测插件信息，所述新增检测程序组件的属性信息，所述新增检测程序组件的对应的第一程序组件的数量；

根据所述程序组件注册信息，配置与所述服务器连接的所述新增检测程序组件。

一种可选的实施例中，分别向至少两个检测程序组件发送检测指令，包括：

基于插件识别信息，在至少两个检测程序组件中确定发送对象；

向发送对象发送检测指令。

一种可选的实施例中，所述方法还包括：

接收所述检测程序组件发送的新增插件的插件识别信息；

保存所述插件识别信息，其中，所述服务器用于识别包含所述插件识别信息的检测请求。

根据本公开实施例的第二方面，提供一种应用检测方法，应用于检测程序组件，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件；所述方法包括：

所述第二程序组件接收服务器发送的检测指令；所述检测指令包括目标移动应用的应用信息；

所述第二程序组件基于所述检测指令生成检测任务；

所述第二程序组件根据各个所述第一程序组件的工作状态，选择至少一个所述第一程序组件作为目标程序组件；

所述第二程序组件将所述检测任务加入所述目标程序组件的目标任务队列；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

一种可选的实施例中，所述第二程序组件将所述检测任务加入所述目标程序组件的目标任务队列之后，还包括：

所述目标程序组件从第一数据库获取所述应用安装包；

所述目标程序组件从所述检测任务中获取所述目标检测项；

所述目标程序组件基于所述应用安装包，对所述目标移动应用执行所述目标检测项对应的检测操作。

一种可选的实施例中，所述方法还包括：

所述第二程序组件接收针对新增插件的插件注册信息；

所述第二程序组件控制完成当前任务的目标第一程序组件暂停后续任务，并依据所述插件注册信息向所述目标第一程序组件的插件库内添加所述新增插件；

所述第二程序组件在将所述新增插件添加至所述目标第一程序组件的插件库的情况下，恢复所述目标第一程序组件的后续任务的执行，并向所述服务器发送所述新增插件的插件识别信息；

所述服务器对所述插件识别信息进行保存，其中，所述服务器用于识别包含所述插件识别信息的检测请求。

一种可选的实施例中，所述第二程序组件根据各个所述第一程序组件的工作状态，选择至少一个所述第一程序组件作为目标程序组件，包括：

所述第二程序组件根据各个所述第一程序组件的工作状态，查找当前未进行任务处理的所述第一程序组件；

在存在当前未进行任务处理的所述第一程序组件的情况下，所述第二程序组件将所述当前未进行任务处理的所述第一程序组件作为所述目标程序组件；

在全部所述第一程序组件均处于任务处理期间的情况下，所述第二程序组件计算每个所述第一程序组件的可用可能性，将所述可用可能性最高的所述第一程序组件作为所述目标程序组件。

一种可选的实施例中，所述第二程序组件计算每个所述第一程序组件的可用可能性，包括：

所述第二程序组件计算每个所述第一程序组件已完成检测的应用的平均大小；

所述第二程序组件获取每个所述第一程序组件当前正在检测的应用大小；

所述第二程序组件计算每个所述第一程序组件已完成检测的应用的平均执行时间；

所述第二程序组件获取每个所述第一程序组件当前正在检测的应用的执行时间；

所述第二程序组件根据所述平均大小与所述应用大小的第一差值以及所述平均执行时间与所述执行时间的第二差值，计算每个所述第一程序组件的可用可能性。

一种可选的实施例中，所述方法还包括：

所述第二程序组件计算自身所属的目标检测程序组件的程序组件可用性；

所述第二程序组件在所述程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充所述目标检测程序组件包含的第一程序组件的数量；

所述第二程序组件间隔第一预设时长后重复上述操作，直至所述目标检测程序组件的所述程序组件可用性不低于所述第一预设阈值。

一种可选的实施例中，所述第二程序组件计算自身所属的目标检测程序组件的程序组件可用性，包括：

所述第二程序组件计算所述目标检测程序组件的平均等待时间和平均恢复执行时间；其中，所述平均等待时间为所述目标检测程序组件的对应的全部等待任务的等待时间总和与所述等待任务的总数之间的比值；所述平均恢复执行时间为各个所述等待任务对应的时间差之和与所述等待任务的总数之间的比值，时间差为每个所述等待任务从创建到开始执行之间的时间差值；

所述第二程序组件计算所述平均等待时间与所述平均恢复执行时间之和，得到第一和值；

所述第二程序组件计算所述平均等待时间与所述第一和值的比值，得到所述程序组件可用性。

一种可选的实施例中，所述预设配置项包括扩充时长以及扩充步长，所述第二程序组件在所述程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充所述目标检测程序组件包含的第一程序组件的数量，包括：

在所述程序组件可用性低于所述第一预设阈值的情况下，所述第二程序组件开始计时；

在计时时长未达到所述扩充时长的过程中，所述第二程序组件按照所述扩充步长扩充所述第一程序组件的数量。

一种可选的实施例中，所述第二程序组件计算所述检测程序组件的程序组件可用性之后，还包括：

在所述程序组件可用性高于第二预设阈值的情况下，所述第二程序组件将所述目标检测程序组件包含的第一程序组件的个数恢复至初始数值；其中，所述第二预设阈值大于所述第一预设阈值。

一种可选的实施例中，所述目标程序组件从所述检测任务中获取所述目标检测项之后，还包括：

在所述目标程序组件不支持所述目标检测项中的任意一项的情况下，所述目标程序组件返回退回响应至所述第二程序组件，所述退回响应用于告知所述第二程序组件所述检测任务未处理；

所述对所述应用安装包执行所述目标检测项对应的检测操作，包括：

在所述目标程序组件支持所述目标检测项中的至少一项的情况下，所述目标程序组件基于所述应用安装包，对所述目标移动应用执行自身支持的目标检测项对应的检测操作

一种可选的实施例中，所述目标程序组件基于自身支持的目标检测项，对所述目标移动应用进行检测，包括：

在所述检测程序组件为静态扫描程序组件的情况下，所述目标程序组件解析自身支持的所述目标检测项对应的插件依赖项；

解析完毕后，所述目标程序组件反编译所述目标移动应用的安装包的目标组成部分，得到反编译结果；

所述目标程序组件解析自身支持的所述目标检测项对应的插件扫描逻辑；

解析得到所述插件扫描逻辑后，所述目标程序组件执行自身支持的所述目标检测项对应的扫描代码，对所述反编译结果进行检测。

一种可选的实施例中，所述目标程序组件基于自身支持的目标检测项，对所述目标移动应用进行检测，包括：

在所述检测程序组件为动态扫描程序组件的情况下，所述目标程序组件解析自身支持的所述目标检测项对应的插件配置项；

解析完毕后，所述目标程序组件启动真机资源/模拟器资源，创建动态沙箱环境；

在完成创建后，所述目标程序组件在所述动态沙箱环境内启动所述目标移动应用；

所述目标程序组件解析自身支持的所述目标检测项对应的插件扫描逻辑；

解析得到所述插件扫描逻辑后，所述目标程序组件执行自身支持的所述目标检测项对应的扫描代码，对所述目标移动应用进行检测。

一种可选的实施例中，所述目标程序组件基于自身支持的目标检测项，对所述目标移动应用进行检测，包括：

在所述检测程序组件为病毒检测程序组件的情况下，所述目标程序组件解析自身支持的所述目标检测项对应的插件配置项；

所述目标程序组件加载目标病毒检测程序组件资源，并创建病毒扫描运行环境；

在完成创建后，所述目标程序组件解析自身支持的所述目标检测项对应的插件扫描逻辑；

所述目标程序组件在所述病毒扫描运行环境内运行所述目标移动应用，并同步执行病毒扫描逻辑对所述目标移动应用进行检测。

根据本公开实施例的第三方面，提供一种应用检测装置，应用于服务器，所述装置包括：

请求接收模块，用于接收针对待检测的至少一个目标移动应用的检测请求；

指令生成模块，用于基于所述检测请求生成检测指令；所述检测请求包括所述目标移动应用的应用信息；

指令发送模块，用于分别向至少两个检测程序组件发送所述检测指令；其中，所述检测程序组件基于所述检测指令生成检测任务；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

一种可选的实施例中，所述应用检测装置还包括：

第一注册信息接收模块，用于接收输入的程序组件注册信息；其中，所述程序组件注册信息包括：新增检测程序组件对应的检测插件信息，所述新增检测程序组件的属性信息，所述新增检测程序组件的对应的第一程序组件的数量；

程序组件配置模块，用于根据所述程序组件注册信息，配置与所述服务器连接的所述新增检测程序组件。

一种可选的实施例中，所述指令发送模块包括：

发送对象确定模块，被配置为执行基于所述插件识别信息，在所述至少两个检测程序组件中确定发送对象；

检测指令发送模块，被配置为执行向所述发送对象发送所述检测指令。

一种可选的实施例中，所述应用检测装置还包括：

插件接收模块，用于接收所述检测程序组件发送的新增插件的插件识别信息；

插件保存模块，用于保存所述插件识别信息，其中，所述服务器用于识别包含所述插件识别信息的检测请求。

根据本公开实施例的第四方面，提供一种应用检测装置，应用于检测程序组件，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件；所述装置包括应用于所述第二程序组件的第一子装置以及应用于所述第一程序组件的第二子装置；所述第一子装置包括：

指令接收模块，用于接收服务器发送的检测指令；所述检测指令包括目标移动应用的应用信息；

任务生成模块，用于基于所述检测指令生成检测任务；

程序组件选择模块，用于根据各个所述第一程序组件的工作状态，选择至少一个所述第一程序组件作为目标程序组件；

队列加入模块，用于将所述检测任务加入所述目标程序组件的目标任务队列；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

一种可选的实施例中，所述第二子装置包括：

安装包获取模块，用于从第一数据库获取所述应用安装包；

检测项获取模块，用于从所述检测任务中获取所述目标检测项；

检测模块，用于基于所述应用安装包，对所述目标移动应用执行所述目标检测项对应的检测操作。

一种可选的实施例中，所述第一子装置还包括：

插件注册接收模块，用于接收针对新增插件的插件注册信息；

插件新增模块，用于控制完成当前任务的目标第一程序组件暂停后续任务，并依据所述插件注册信息向所述目标第一程序组件的插件库内添加所述新增插件；

插件识别信息发送模块，用于在将所述新增插件添加至所述目标第一程序组件的插件库的情况下，恢复所述目标第一程序组件的后续任务的执行，并向所述服务器发送所述新增插件的插件识别信息；其中，所述服务器用于对所述插件识别信息进行保存，且所述服务器能够识别包含所述插件识别信息的检测请求。

一种可选的实施例中，所述程序组件选择模块包括：

查找单元，用于根据各个所述第一程序组件的工作状态，查找当前未进行任务处理的所述第一程序组件；

第一目标确认单元，用于在存在当前未进行任务处理的所述第一程序组件的情况下，将所述当前未进行任务处理的所述第一程序组件作为所述目标程序组件；

第二目标确认单元，用于在全部所述第一程序组件均处于任务处理期间的情况下，计算每个所述第一程序组件的可用可能性，将所述可用可能性最高的所述第一程序组件作为所述目标程序组件。

一种可选的实施例中，所述第二目标确认单元包括：

平均大小计算单元，用于计算每个所述第一程序组件已完成检测的应用的平均大小；

应用大小计算单元，用于获取每个所述第一程序组件当前正在检测的应用大小；

平均时间计算单元，用于计算每个所述第一程序组件已完成检测的应用的平均执行时间；

执行时间计算单元，用于获取每个所述第一程序组件当前正在检测的应用的执行时间；

可用可能性计算单元，用于根据所述平均大小与所述应用大小的第一差值以及所述平均执行时间与所述执行时间的第二差值，计算每个所述第一程序组件的可用可能性，将所述可用可能性最高的所述第一程序组件作为所述目标程序组件。

一种可选的实施例中，所述第一子装置还包括：

程序组件可用性计算模块，用于计算自身所属的目标检测程序组件的程序组件可用性；

扩充模块，用于在所述程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充所述目标检测程序组件包含的第一程序组件的数量。

一种可选的实施例中，所述程序组件可用性计算模块包括：

时间计算单元，用于计算所述目标检测程序组件的平均等待时间和平均恢复执行时间；其中，所述平均等待时间为所述目标检测程序组件的对应的全部等待任务的等待时间总和与所述等待任务的总数之间的比值；所述平均恢复执行时间为各个所述等待任务对应的时间差之和与所述等待任务的总数之间的比值，时间差为每个所述等待任务从创建到开始执行之间的时间差值；

和值计算单元，用于计算所述平均等待时间与所述平均恢复执行时间之和，得到第一和值；

比值计算单元，用于计算所述平均等待时间与所述第一和值的比值，得到所述程序组件可用性。

一种可选的实施例中，所述预设配置项包括扩充时长以及扩充步长，所述扩充模块包括：

计时单元，用于在所述程序组件可用性低于所述第一预设阈值的情况下，所述第二程序组件开始计时；

数量扩充单元，用于在计时时长未达到所述扩充时长的过程中，所述第二程序组件按照所述扩充步长扩充所述第一程序组件的数量。

一种可选的实施例中，所述第一子装置还包括：

数量恢复模块，用于在所述程序组件可用性高于第二预设阈值的情况下，所述第二程序组件将所述目标检测程序组件包含的第一程序组件的个数恢复至初始数值；其中，所述第二预设阈值大于所述第一预设阈值。

一种可选的实施例中，所述第二子装置还包括：

退回响应模块，用于在所述目标程序组件不支持所述目标检测项中的任意一项的情况下，所述目标程序组件返回退回响应至所述第二程序组件，所述退回响应用于告知所述第二程序组件所述检测任务未处理；

所述检测模块具体用于：在所述目标程序组件支持所述目标检测项中的至少一项的情况下，基于所述应用安装包，对所述目标移动应用执行自身支持的目标检测项对应的检测操作。

一种可选的实施例中，在所述检测程序组件为静态扫描程序组件的情况下，所述检测模块包括：

依赖项解析单元，用于解析自身支持的所述目标检测项对应的插件依赖项；

反编译单元，用于解析完毕后，反编译所述目标移动应用的安装包的目标组成部分，得到反编译结果；

第一扫描逻辑解析单元，用于解析自身支持的所述目标检测项对应的插件扫描逻辑；

第一代码执行单元，用于解析得到所述插件扫描逻辑后，执行自身支持的所述目标检测项对应的扫描代码，对所述反编译结果进行检测。

一种可选的实施例中，在所述检测程序组件为动态扫描程序组件的情况下，所述检测模块具体包括：

第一配置项解析单元，用于解析自身支持的所述目标检测项对应的插件配置项；

资源启动单元，用于解析完毕后，启动真机资源/模拟器资源，创建动态沙箱环境；

应用启动单元，用于在完成创建后，在所述动态沙箱环境内启动所述目标移动应用；

第二扫描逻辑解析单元，用于解析自身支持的所述目标检测项对应的插件扫描逻辑；

第二代码执行单元，用于解析得到所述插件扫描逻辑后，执行自身支持的所述目标检测项对应的扫描代码，对所述目标移动应用进行检测。

一种可选的实施例中，在所述检测程序组件为病毒检测程序组件的情况下，所述检测模块具体包括：

第二配置项解析单元，用于解析自身支持的所述目标检测项对应的插件配置项；

环境构建单元，用于加载目标病毒检测程序组件资源，并创建病毒扫描运行环境；

第三扫描逻辑解析单元，用于在完成创建后，解析自身支持的所述目标检测项对应的插件扫描逻辑；

逻辑执行单元，用于在所述病毒扫描运行环境内运行所述目标移动应用，并同步执行病毒扫描逻辑对所述目标移动应用进行检测。

根据本公开实施例的第五方面，提供一种服务器，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的应用检测方法。

根据本公开实施例的第六方面，提供一种检测程序组件，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件，所述第二程序组件和所述第一程序组件分别包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第二方面所述的应用检测方法。

根据本公开实施例的第七方面，提供一种计算机程序产品，包括程序或指令，其中，程序或指令被执行时，实现如第一方面或第二方面所述的应用检测方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开实施例中，服务器在接收到针对目标移动应用的检测请求后，会生成对应的检测指令，之后将检测指令分别发送至自身关联的多个检测程序组件，各个检测程序组件会基于检测指令生成检测任务，检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息，其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同，因此各个检测程序组件会同步对目标移动应用进行不同类型的检测。即本公开实施例中，能够通过多个检测程序组件从不同的问题角度来对目标移动应用进行不同类型的检测，使得后续能够得到针对不同维度的检测结果，检测结果更加全面，基于该检测结果也能够对目标移动应用进行更加准确的判断。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种应用检测***的框图。

图2是根据一示例性实施例示出的一种应用检测方法的流程图。

图3是根据一示例性实施例示出的一种应用于服务器的应用检测方法的流程图。

图4是根据一示例性实施例示出的一种应用于检测程序组件的应用检测方法的流程图。

图5是根据一示例性实施例示出的一种应用于服务器的应用检测装置的框图。

图6是根据一示例性实施例示出的一种应用于检测程序组件的应用检测装置的框图。

图7是根据一示例性实施例示出的一种服务器的框图。

图8是根据一示例性实施例示出的一种程序组件的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

如背景技术，相关技术中对移动应用进行检测时，多数所采用的方式是依赖单一 程序组件进行检测，例如静态扫描程序组件、动态扫描程序组件、病毒扫描程序组件等，但是不同的检测程序组件具有不同的检测方式和检测内容，例如静态扫描程序组件通过利用漏洞静态代码特征定位风险位置，动态扫描程序组件用于检测畸形Intent导致的崩溃问题，而病毒扫描程序组件可以针对特定的的病毒特征进行扫描等。因此，单一类型的程序组件检测方式缺少对于移动端应用的全局风险信息掌握，检测项目覆盖不全，检测结果不够全面。

为了解决上述技术问题，本公开实施例提供了一种应用检测***，应用检测***包括服务器110、至少两个检测程序组件120。参见图1，图1是根据一示例性实施例示出的一种应用检测***的框图。其中，

服务器110用于接收外界发送的、针对待检测的至少一个目标移动应用的检测请求，并基于检测请求生成检测指令；后续分别向各个检测程序组件120发送检测指令。

其中，服务器110可以对外提供检测服务的接口，使得外界通过该接口输入检测请求。目标检测应用可以为一个或多个，即服务器110可以同时接收多个目标移动应用对应的检测请求。此外，可选的，上述服务器110还可以用于实时监控检测程序组件120的整体可用性等。

这里的服务器110可以是web服务器110或者云端服务器110等，本申请实施例不限定服务器110的具体类型。

可选的，应用检测***还可以包含浏览器130，服务器110可以接收通过浏览器130发送的检测请求。这里的检测请求可以包括目标移动应用的应用信息，该应用信息可以包含应用名称等信息，或者应用信息也可以包含目标移动应用的应用数据包等。本申请实施例不限定检测请求的具体内容。

检测程序组件120，用于基于检测指令生成检测任务；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件120生成的检测任务中包含的目标检测项不同。后续，检测程序组件120还用于对应用安装包执行目标检测项对应的检测操作，并将检测结果返回服务器110。

上述各个检测程序组件120分别用于执行不同检测类型的检测操作，例如检测程序组件120可以为静态扫描程序组件、动态扫描程序组件、病毒扫描程序组件中的任意一个，因此，不同检测程序组件120包含的检测项不同，不同的检测程序组件120基于检测指令确定的目标检测项也不同。本申请实施例不限定***中所包含的各个检测程序组件120的类型。

本公开实施例中，服务器110在接收到针对目标移动应用的检测请求后，会生成对应的检测指令，之后将检测指令分别发送至自身关联的多个检测程序组件120，各个检测程序组件120会基于检测指令生成检测任务，检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息，其中，不同的检测程序组件120生成的检测任务中包含的目标检测项不同，因此各个检测程序组件120会同步对目标移动应用进行不同类型的检测。即本公开实施例中，能够通过多个检测程序组件120从不同的问题角度来对目标移动应用进行不同类型的检测，使得后续能够得到针对不同维度的检测结果，检测结果更加全面，基于该检测结果也能够对目标移动应用进行更加准确的判断。

在另一些实施例中，上述应用检测***还可以包括：

与服务器110连接的第一数据库140，用于存储目标移动应用的应用安装包。可选的，第一数据库140可以接收服务器110发送的目标移动应用的应用安装包进行存储，即服务器110可以接收浏览器130上传的目标移动应用的应用安装包，并将安装包发送至第一数据库140。或者第一数据库140内也可以预先存储有各个移动应用的安装包。后续，检测程序组件120在接收到检测指令后，可以向第一数据库140获取目标移动应用的应用安装包，从而基于应用安装包来对目标移动应用进行检测。

本实施例为移动应用的应用安装包设置了专门的数据库进行存储，方便了后续检测程序组件120对目标移动应用的应用安装包的下载。并且也避免了应用安装包对服务器110存储空间的占用。

在再一些实施例中，上述应用检测***还可以包括：

与服务器110连接的第二数据库150，用于接收服务器110发送的检测结果，并对检测结果进行保存。

本实施例为检测结果设置了专门的数据库进行存储，方便了后续用户对检测结果的查询和浏览。并且也避免了检测结果对服务器110存储空间的占用。

为方便理解，以下以应用检测***包括静态扫描程序组件、动态扫描程序组件和病毒扫描程序组件为例，进行介绍。

服务器110接收通过浏览器130发送的移动应用A的应用安装包，服务器110将该应用安装包发送至第一数据库140保存，并生成对应的检测指令，将检测指令分别发送静态扫描程序组件、动态扫描程序组件和病毒扫描程序组件。静态扫描程序组件、动态扫描程序组件和病毒扫描程序组件分别确定检测指令对应的目标检测项，并从第一数据库140下载上述应用安装包，对应用安装包执行自身确定的目标检测项对应的检测操作。检测完成后，静态扫描程序组件、动态扫描程序组件和病毒扫描程序组件分别将检测结果发送至服务器110，服务器110将检测结果发送至第二数据库150进行保存，这样，后续工作人员可以根据第二数据库150保存的检测结果判断移动应用A的风险状态。

此外，上述检测程序组件120采用swarm模式，每个检测程序组件120均包括一个第二程序组件和至少两个第一程序组件，第二程序组件作为master，负责与服务器110进行交互，并对服务器110下发的检测任务进行调度以及管理各个第一程序组件；第一程序组件作为worker，负责执行具体的检测操作。其中当一个master宕机,那么余下的worker中的一个会升级为master,直至原有的master恢复。

其中，第二程序组件，用于接收服务器110发送的检测指令，基于检测指令生成检测任务，检测任务包括目标移动应用的应用信息以及该检测指令对应的目标检测项；后续根据各个第一程序组件的工作状态，选择至少一个第一程序组件作为目标程序组件，并将该检测任务加入目标程序组件的目标任务队列；汇总各个目标程序组件发送的目标检测结果后，向服务器110发送汇总结果。

目标程序组件，用于从第一数据库140获取目标移动应用的应用安装包，从检测任务中获取目标检测项，并对应用安装包执行目标检测项对应的检测操作，得到目标检测结果并发送至第二程序组件。目标程序组件会根据自身目标任务队列中的任务排序，依次执行目标任务队列中的各个任务。

需要注意的是，同一个第二程序组件对应的各个第一程序组件所包含的检测项可以相同，也可以不同。例如，若每个第二程序组件对应的各个第一程序组件包含的检测项是相同的，则第二程序组件可以仅选择一个第一程序组件作为目标程序组件，从而避免出现重复检测的情况，提高检测效率。

或者，若每个第二程序组件对应的各个第一程序组件包含的检测项不同，则第一程序组件可以在接收到检测任务后，将检测任务包含的目标检测项与自身包含的检测项进行比对，若自身未包含任意一个目标检测项，则返回退回响应告知第二程序组件，由第二程序组件选择其他第一程序组件作为目标程序组件。这种情况下，目标程序组件可能包含多个第一程序组件，各个第一程序组件分别执行不同的检测项对应的检测操作，第二程序组件汇总各个第一程序组件的返回结果后，才能够得到完整的检测结果。

基于上述应用检测***，本申请实施例还提供了一种应用检测方法，图2是根据一示例性实施例示出的一种应用检测方法的流程图，如图2所示，该方法包括以下步骤。

在步骤S210中，服务器接收针对待检测的至少一个目标移动应用的检测请求，并基于检测请求生成检测指令；检测请求包括目标移动应用的应用信息。

服务器接收到用户或前端发送的检测请求后，会根据检测请求中的应用信息生成检测指令。这里的检测指令也需要包含目标移动应用的应用信息，用于告知检测程序组件需要进行检测的对象。检测指令中的主体信息与检测请求中的主体信息可以是相同的，也可以是不同的，检测指令中还可以包含一些其他的信息，例如目标移动应用的应用安装包的下载路径等。本申请实施例不限定检测指令的具体内容。

在步骤S220中，服务器分别向各个检测程序组件发送检测指令。

为了方便后续服务器汇总各个检测程序组件的检测结果，服务器可以同时发送检测指令至各个检测程序组件。

在步骤S230中，检测程序组件基于检测指令生成检测任务。

这里的检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息。其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。

由于每个检测程序组件对应于不同的检测类型，因此每个检测程序组件内预先设置有多个检测插件，每个检测插件用于对一个检测项进行检测。这种情况下，在接收到检测指令后，检测程序组件根据自身所包含的检测插件(或者说自身所包含的检测项)，即能够确定本次检测任务中包含的目标检测项。检测任务中包含应用信息，是为了方便检测程序组件在后续执行检测任务时，能够获取该目标移动应用的应用安装包。这里的应用信息可以为目标移动应用的标识，后续检测程序组件根据该标识下载对应的应用安装包；或者，应用信息也可以直接包含应用安装包。

由于检测指令可能包含多个目标移动应用的应用信息，也即，可能对多个目标移动应用进行检测，而检测程序组件同一时间可能无法同时对全部目标移动应用进行检测，因此，可以分别为每个目标移动应用生成一个检测任务，并将各个检测任务添加至检测程序组件的任务队列中，从而方便后续检测程序组件依次处理各个检测任务。

可选的，在检测指令包含多个目标移动应用的应用信息的情况下，也可以仅生成一个检测任务，该检测任务用于对多个目标移动应用进行检测。本申请实施例不限定检测任务的生成方式。

本公开实施例中，服务器在接收到针对目标移动应用的检测请求后，会生成对应的检测指令，之后将检测指令分别发送至自身关联的多个检测程序组件，各个检测程序组件会基于检测指令生成检测任务，检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息，其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同，因此各个检测程序组件会同步对目标移动应用进行不同类型的检测。即本公开实施例中，能够通过多个检测程序组件从不同的问题角度来对目标移动应用进行不同类型的检测，使得后续能够得到针对不同维度的检测结果，检测结果更加全面，基于该检测结果也能够对目标移动应用进行更加准确的判断。

在一些实施例中，上述S230可以包括：

S231，第二程序组件接收服务器发送的检测指令，基于检测指令生成检测任务；

S233，第二程序组件根据各个第一程序组件的工作状态，选择至少一个第一程序组件作为目标程序组件，并将检测任务加入目标程序组件的目标任务队列。

本实施例中，由检测程序组件中的第二程序组件来接收检测指令、生成检测任务以及选择第一程序组件进行，即第二程序组件作为任务调度者，来负责检测任务的生成以及调度。这种情况下，可以通过第二程序组件来控制检测任务的分配，从而使得分配给各个第一程序组件的检测任务能够较为均衡，避免出现检测任务等待时间过长的情况，提高了任务处理的效率。

可选的，在上述S230之后，还可以包括：

目标程序组件从第一数据库获取目标移动应用的应用安装包。

目标程序组件基于应用安装包，对目标移动应用执行目标检测项对应的检测操作，得到目标检测结果。

其中，目标程序组件在对目标移动应用进行检测时，可以首先通过应用安装包安装目标移动应用，并对安装后的目标移动应用执行目标检测项对应的检测操作。或者，目标程序组件也可以直接对应用安装包执行目标检测项对应的检测操作。具体采用哪种检测方式，取决于检测程序组件对应的目标检测项的需求，本申请实施例对此不做限定。

本实施例中，目标程序组件能够从第一数据库中获取目标移动应用的应用安装包，即应用安装包存储于第一数据库中，这种情况下，使得服务器不需要存储并下发应用安装包，从而减少了应用安装包对服务器的存储空间的占用。

可选的，上述得到目标检测结果之后，还可以包括：

目标程序组件向第二程序组件发送目标检测结果；

第二程序组件汇总各个目标程序组件发送的目标检测结果后，向服务器发送汇总结果。

本实施例中，在各个目标程序组件完成检测操作后，会将自身得到的目标检测结果发送至第二程序组件，由第二程序组件进行汇总，例如第二程序组件可以按照“检测项：检测结果”的对应关系进行汇总，或者第二程序组件还可以通过其他方式进行汇总，本申请实施例不限定汇总方式。后续第二程序组件将汇总结果发送至服务器，这样，后续工作人员可以对汇总结果进行查看。这种反馈结果的方式，使得服务器不需要执行结果汇总的操作，并且，汇总后的检测结果相比分散的检测结果，也更方便用户的查看。

在另一些实施例中，上述S233具体可以包括：

第二程序组件根据各个第一程序组件的工作状态，查找当前未进行任务处理的第一程序组件；

在存在当前未进行任务处理的第一程序组件的情况下，第二程序组件将当前未进行任务处理的第一程序组件作为目标程序组件；

在全部第一程序组件均处于任务处理期间的情况下，第二程序组件计算每个第一程序组件的可用可能性，将可用可能性最高的第一程序组件作为目标程序组件。

本实施例中，第二程序组件在接收到检测指令后，会先根据各个第一程序组件的工作状态,找到至少一个当前没有任务处理的第一程序组件，这种情况下，使得检测任务分配后，作为目标程序组件的第一程序组件能够快速开始对检测任务进行处理，尽可能避免检测任务需要等待一段时间的情况，提高检测效率。另外，在所有第一程序组件都正在处理任务的情况下，第二程序组件需要从中选择一个可能最快完成已有任务的第一程序组件作为目标程序组件，其中，本实施例中，通过可用可能性来量化各个第一程序组件完成已有任务的效率高低，从而使得最终选择的目标程序组件能够尽快开始检测任务的处理。

在进一步的实施例中，上述第二程序组件计算每个第一程序组件的可用可能性，可以包括以下步骤：

第二程序组件计算每个第一程序组件已完成检测的应用的平均大小；

第二程序组件获取每个第一程序组件当前正在检测的应用大小；

第二程序组件计算每个第一程序组件已完成检测的应用的平均执行时间；

第二程序组件获取每个第一程序组件当前正在检测的应用的执行时间；

第二程序组件根据平均大小与应用大小的第一差值以及平均执行时间与执行时间的第二差值，计算每个第一程序组件的可用可能性。

其中，可以通过以下关系式表示可用可能性的计算过程：

可用可能性＝(1+(|X1-X2|))/(R1*(|Y1-Y2|))

其中，X1为第一程序组件已完成检测的应用的平均大小，X2为第一程序组件当前正在检测的应用大小；Y1为第一程序组件已完成检测的应用的平均执行时间；Y2为第一程序组件当前正在检测的应用的执行时间；R1为目标移动应用大小与执行时间的相关系数；其中，该相关系数由用户自定义设置。

本实施例中，利用第一程序组件已经检测过的应用的平均大小以及平均执行时间，与第一程序组件当前检测的应用的大小与执行时间进行比较，来得到第一程序组件的可用可能性，该可用可能性越大，表示该第一程序组件完成当前检测任务的速度可能越快，因此将检测任务分配给该第一程序组件后，该第一程序组件完成检测任务的速度也可能越快，从而尽可能提高了检测效率。

在一些情况中，对于热部署的插件,一些第一程序组件还来不及更新插件，导致这些第一程序组件中的原有插件无法执行上述目标检测项，这种情况下，在其他一些实施例中，上述向目标程序组件发送检测指令之后，还可以包括：

在目标程序组件不支持目标检测项中的任意一项的情况下，目标程序组件返回退回响应至第二程序组件，退回响应用于告知第二程序组件检测指令未处理；

上述对应用安装包执行目标检测项对应的检测操作，可以包括：

在目标程序组件支持目标检测项中的至少一项的情况下，目标程序组件基于自身支持的目标检测项，对目标移动应用进行检测。

本实施例中，目标程序组件在接收到检测任务后，会判断自身是否支持该检测任务中的目标检测项，判断过程可以直接将目标检测项与自身包含的检测项进行比对，或者也可以将目标检测项对应的插件与自身包含的插件进行比对。如果不支持目标检测项中的任意一项，则表明该目标程序组件无法执行检测任务，因此将该检测任务退回,并告知第二程序组件该检测任务未处理，由第二程序组件再分配到其他第一程序组件中处理，如果当前目标程序组件支持至少一个目标检测项，则目标程序组件开始进行检测处理。通过上述方式，能够实现检测任务分配过程中的自动纠错，而非直接报错，从而提高了应用检测过程中的可靠性。

在进一步的实施例中，以android平台应用检测为例，以下分别介绍各个类型的检测程序组件中的目标程序组件，基于自身支持的目标检测项，对目标移动应用进行检测的步骤。

一、在检测程序组件为静态扫描程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件依赖项；

解析完毕后，目标程序组件反编译目标移动应用的安装包的目标组成部分，得到反编译结果；

目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

解析得到插件扫描逻辑后，目标程序组件执行自身支持的目标检测项对应的扫描代码，对反编译结果进行检测。

本实施例中，静态扫描程序组件中的主要检测流程为:

解析插件依赖项->反编译apk相应组成部分->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

二、在检测程序组件为动态扫描程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件配置项；

解析完毕后，目标程序组件启动真机资源/模拟器资源，创建动态沙箱环境；

在完成创建后，目标程序组件在动态沙箱环境内启动目标移动应用；

目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

解析得到插件扫描逻辑后，目标程序组件执行自身支持的目标检测项对应的扫描代码，对目标移动应用进行检测。

本实施例中，动态扫描程序组件的主要检测流程为:

解析插件配置项->启动真机资源/模拟器资源->创建动态沙箱环境->启动被测试应用->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

三、在检测程序组件为病毒检测程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件配置项；

目标程序组件加载目标病毒检测程序组件资源，并创建病毒扫描运行环境；

在完成创建后，目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

目标程序组件在病毒扫描运行环境内运行目标移动应用，并同步执行病毒扫描逻辑对目标移动应用进行检测。

本实施例中，病毒检测程序组件的主要检测流程为:

解析插件配置项->加载特定病毒检测程序组件资源->创建病毒扫描运行时环境->加载插件扫描逻辑->运行被测试样本->同步执行病毒扫描逻辑->得到扫描结果。

在相关技术中，由于检测程序组件对于移动应用的扫描时间与该移动应用的容量大小成正比，当检测程序组件需要对大量的移动应用进行扫描检测时，检测任务的执行效率会存在较大幅度的下降，程序组件处理能力遭遇瓶颈，导致检测任务的排队时间增加。另外动态检测的耗时一般时较长，需要长时间占用一个第一程序组件的处理工作，此时如果所有的第一程序组件都被占用，那么新增的检测任务就会被挂起，直至前面的检测任务完成才能开始进行检测，进而导致整体检测任务时间增加。

为了解决上述技术问题，在另一些实施例中，上述方法还可以包括：

第二程序组件计算自身所属的目标检测程序组件的程序组件可用性；

第二程序组件在程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充目标检测程序组件包含的第一程序组件的数量；

第二程序组件间隔第一预设时长后重复上述操作，直至目标检测程序组件的程序组件可用性不低于第一预设阈值。

本实施例中，第二程序组件会计算自身所属的目标检测程序组件的程序组件可用性,计算出的程序组件可用性值如果低于设定的第一预设阈值，例如0.6，表明当前目标检测程序组件包含的第一程序组件的数量无法满足过多的检测任务，因此需要按照配置项扩充第一程序组件的数量，如果程序组件可用性值不低于第一预设阈值，则表明当前目标检测程序组件包含的第一程序组件的数量能够满足检测任务，因此不需要扩充第一程序组件的数量。在扩充过程中，可以每隔第一预设时长后，即计算一次程序组件可用性，若程序组件可用性不低于第一预设阈值，则停止扩充，如果依旧低于第一预设阈值，则继续扩充第一程序组件。这种方式，使得本申请实施例支持动态化的第一程序组件的扩展，提高了检测程序组件的高可用性，从而提高了检测程序组件的检测效率，减少了检测任务被长时间挂起的情况，避免了检测性能上遭遇瓶颈问题，保障了检测程序组件整体性能的稳定性。

可选的，在扩充第一程序组件的过程中，也可以在每扩充一个第一程序组件后，即计算一次程序组件可用性值。计算程序组件可用性值的周期，本申请实施例不做限定。

在进一步的实施例中，上述预设配置项包括扩充时长以及扩充步长，上述第二程序组件在程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充目标检测程序组件包含的第一程序组件的数量，可以包括：

在程序组件可用性低于第一预设阈值的情况下，第二程序组件开始计时；

在计时时长未达到扩充时长的过程中，第二程序组件按照扩充步长扩充第一程序组件的数量。

本实施例中，会在扩充时长内，按照特定的扩充步长扩充第一程序组件的数量。例如配置项为(0.6,1,30)，则表示程序组件可用性低于0.6,则会按照步长为1的扩充速度进行扩充,扩充时间持续30s，即每秒增加一个第一程序组件。这种情况下，可以在计时时长达到扩充时长后，再二次计算程序组件可用性，即第一预设时长可以等于扩充时长。这种扩充方式，每次增加相同数量的第一程序组件，能够使得第一程序组件的扩充过程较为稳定。或者，配置项中还可以限定扩充间隔，例如每隔2s增加一个第一程序组件，持续时间30s。

可选的，预设配置项也可以仅包含增加数量，例如5个，则同时扩充5个第一程序组件。具体采用哪种扩充方式，本申请实施例不做限定。

在一些实施例中，上述第二程序组件计算自身所属的目标检测程序组件的程序组件可用性，可以包括：

第二程序组件计算目标检测程序组件的平均等待时间和平均恢复执行时间；其中，平均等待时间为目标检测程序组件的对应的全部等待任务的等待时间总和与等待任务的总数之间的比值；平均恢复执行时间为各个等待任务对应的时间差之和与等待任务的总数之间的比值，时间差为每个等待任务从创建到开始执行之间的时间差值；

第二程序组件计算平均等待时间与平均恢复执行时间之和，得到第一和值；

第二程序组件计算平均等待时间与第一和值的比值，得到程序组件可用性。

其中，可以通过以下关系式表示程序组件可能性的计算过程：

程序组件可用性＝T1/(T1+T2)

其中，T1为目标检测程序组件的对应的全部等待任务的等待时间总和/等待任务的总数；T2为各个等待任务从创建到开始执行之间的时间差之和/等待任务的总数之间的比值。

本实施例中，利用目标检测程序组件的对应的各个等待任务的等待时间和等待任务的数量进行程序组件可用性的计算，由于等待时间越长，等待任务越多，即越表明当前第一程序组件的数量不够支持检测任务的执行。因此，基于上述参数进行程序组件可用性的计算，即能够使得计算得到的程序组件可用性，能够反映是否存在扩充第一程序组件的需求，从而使得第二程序组件能够自在合适的情况下，对第一程序组件的数量进行扩充，保证整个检测程序组件的检测效率以及任务检测过程中的稳定性。

在另一些实施例中，第二程序组件计算检测程序组件的程序组件可用性之后，还可以包括：

在程序组件可用性高于第二预设阈值的情况下，第二程序组件将目标检测程序组件包含的第一程序组件的个数恢复至初始数值；其中，第二预设阈值大于第一预设阈值。

本实施例中，当程序组件可用性大于第二预设阈值的情况下，例如大于0.95，则表示当前第一程序组件的处理能力明显大于任务数量的需求，存在第一程序组件过剩的情况，因此本实施例控制第一程序组件的数量恢复到初始设置，从而再保证基础运行能力的情况下，提高第一程序组件的利用效率。

在相关技术中，由于应移动端应用检测平台的设计和运营问题，大多数检测平台***均以设计当下所需重点发现的问题和检测项目作为检测平台的固定检测流程，当对应的条件发生改变时或***平台停止运营，其固定的检测流程并不能完全适用于当下的用户所需的检测项目。即目前常见的移动端应用检测方案，均使用特定的检测流程，即对固定的检测类型以及检测项进行检测，具体检测类型以及检测项无法由用户定制，针对性差，并且使得检测过程中可能存在非必要的检测项，浪费了检测时间。

基于上述技术问题，在再一些实施例中，上述方法还可以包括：

服务器接收输入的程序组件注册信息；其中，程序组件注册信息包括：新增检测程序组件对应的检测插件信息，新增检测程序组件的属性信息(例如新增检测程序组件提供的能力支持范围)，新增检测程序组件的对应的第一程序组件的数量；

服务器根据程序组件注册信息，配置与服务器连接的新增检测程序组件。

服务器配置完成后，可以发送初始化信息至新增检测程序组件，其中，新增检测程序组件可以初始化自身对应的第一程序组件。

本实施例中，用户可以在新的检测程序组件开发完成后，向服务器注册该检测程序组件，新增检测程序组件完成注册之后，则会开始初始化自身的第一程序组件，使得在初始化完成后，该新增检测程序组件能够投入使用。这种方式下，使得用户能够根据自身需求增加检测程序组件的类型以及数量，从而实现定制化检测程序组件的目的，丰富了移动应用检测时的检测类型组合。

在又一些实施例中，上述方法还可以包括：

第二程序组件接收针对新增插件的插件注册信息；

第二程序组件控制完成当前任务的目标第一程序组件暂停后续任务，并依据插件注册信息向目标第一程序组件的插件库内添加新增插件；

第二程序组件在将新增插件添加至目标第一程序组件的插件库的情况下，恢复目标第一程序组件的后续任务的执行，并向服务器发送新增插件的插件识别信息。

服务器对插件识别信息进行保存，其中，服务器可以识别包含插件识别信息的检测请求。

其中，检测程序组件并不需要全部第一程序组件均更新完成才能使用该新增插件,只要有一个第一程序组件完成更新，就可以使用该新增插件。

在本实施例中，在完成新插件的开发后，用户可以向该插件所属的检测程序组件中的第二程序组件申请注册，而第二程序组件会将该插件注册信息自动同步推送到服务器中保存，以确保服务器能够识别并接收包含该新插件的检测任务。同时，第二程序组件会在第一程序组件完成当前任务的情况下，先挂起该第一程序组件的后续任务，并更新该第一程序组件的插件库，由此该新插件就已经可以在外部无感知的情况下，加入该第一程序组件的插件库。重复该操作，直至全部第一程序组件的插件库均更新完毕。这种情况下，使得用户能够根据需求在检测程序组件中，自定义注册插件，从而增加检测程序组件中的检测项，即实现检测项的定制化，提高了移动应用检测时检测项的灵活性。

基于上述应用于应用检测***的方法实施例，以下对应用于服务器的应用检测方法进行介绍。如图3所示，图3是根据一示例性实施例示出的一种应用于服务器的应用检测方法的流程图，该方法包括以下步骤。

在步骤S310中，接收针对待检测的至少一个目标移动应用的检测请求；

在步骤S320中，基于检测请求生成检测指令；检测请求包括目标移动应用的应用信息；

在步骤S330中，分别向至少两个检测程序组件发送检测指令；其中，检测程序组件可以基于检测指令生成检测任务；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。

本公开实施例中，服务器在接收到针对目标移动应用的检测请求后，会生成对应的检测指令，之后将检测指令分别发送至自身关联的多个检测程序组件，各个检测程序组件会基于检测指令生成检测任务，检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息，其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同，因此各个检测程序组件会同步对目标移动应用进行不同类型的检测。即本公开实施例中，能够通过多个检测程序组件从不同的问题角度来对目标移动应用进行不同类型的检测，使得后续能够得到针对不同维度的检测结果，检测结果更加全面，基于该检测结果也能够对目标移动应用进行更加准确的判断。

在一些实施例中，上述方法还可以包括：

接收输入的程序组件注册信息；其中，程序组件注册信息包括：新增检测程序组件对应的检测插件信息，新增检测程序组件的属性信息，新增检测程序组件的对应的第一程序组件的数量；

根据程序组件注册信息，配置与服务器连接的新增检测程序组件；

配置完成后，发送初始化信息至新增检测程序组件，其中，新增检测程序组件初始化自身对应的第一程序组件。

一种可选的实施例中，在分别向至少两个检测程序组件发送检测指令时，可以基于插件识别信息，在至少两个检测程序组件中确定发送对象，进而，向发送对象发送检测指令。从而可以确定向哪个检测程序组件发送检测指令，提供了一种确定发送对象的实施方式。

本实施例中，用户可以在新的检测程序组件开发完成后，向服务器注册该检测程序组件，新增检测程序组件完成注册之后，则会开始初始化自身的第一程序组件，使得在初始化完成后，该新增检测程序组件能够投入使用。这种方式下，使得用户能够根据自身需求增加检测程序组件的类型以及数量，从而实现定制化检测程序组件的目的，丰富了移动应用检测时的检测类型组合。

在另一些实施例中，上述方法还可以包括：

接收检测程序组件发送的新增插件的插件识别信息；

保存插件识别信息，其中，服务器可以识别包含插件识别信息的检测请求。

在本实施例中，在完成新插件的开发后，用户可以向该插件所属的检测程序组件中的第二程序组件申请注册，而第二程序组件会将该插件注册信息自动同步推送到服务器中保存，以确保服务器能够识别并接收包含该新插件的检测任务。同时，第二程序组件会在第一程序组件完成当前任务的情况下，先挂起该第一程序组件的后续任务，并更新该第一程序组件的插件库，由此该新插件就已经可以在外部无感知的情况下，加入该第一程序组件的插件库。重复该操作，直至全部第一程序组件的插件库均更新完毕。这种情况下，使得用户能够根据需求在检测程序组件中，自定义注册插件，从而增加检测程序组件中的检测项，即实现检测项的定制化，提高了移动应用检测时检测项的灵活性。

基于上述应用于应用检测***的方法实施例，以下对应用于检测程序组件的应用检测方法进行介绍。检测程序组件包括一个第二程序组件和至少两个第一程序组件。如图4所示，图4是根据一示例性实施例示出的一种应用于检测程序组件的应用检测方法的流程图，该方法包括以下步骤。

在步骤S410中，第二程序组件接收服务器发送的检测指令；检测指令包括目标移动应用的应用信息；

在步骤S420中，第二程序组件基于检测指令生成检测任务；

在步骤S430中，第二程序组件根据各个第一程序组件的工作状态，选择至少一个第一程序组件作为目标程序组件；

在步骤S440中，第二程序组件将检测任务加入目标程序组件的目标任务队列；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。

本实施例中，由检测程序组件中的第二程序组件来接收检测指令、生成检测任务以及选择第一程序组件进行，即第二程序组件作为任务调度者，来负责检测任务的生成以及调度。这种情况下，可以通过第二程序组件来控制检测任务的分配，从而使得分配给各个第一程序组件的检测任务能够较为均衡，避免出现检测任务等待时间过长的情况，提高了任务处理的效率。

在一些实施例中，上述S440之后，还可以包括：

目标程序组件从第一数据库获取应用安装包；

目标程序组件从检测任务中获取目标检测项；

目标程序组件基于应用安装包，对目标移动应用执行目标检测项对应的检测操作。

本实施例中，目标程序组件能够从第一数据库中获取目标移动应用的应用安装包，即应用安装包存储于第一数据库中，这种情况下，使得服务器不需要存储并下发应用安装包，从而减少了应用安装包对服务器的存储空间的占用。

在另一些实施例中，上述S430可以包括：

第二程序组件根据各个第一程序组件的工作状态，查找当前未进行任务处理的第一程序组件；

在存在当前未进行任务处理的第一程序组件的情况下，第二程序组件将当前未进行任务处理的第一程序组件作为目标程序组件；

在全部第一程序组件均处于任务处理期间的情况下，第二程序组件计算每个第一程序组件的可用可能性，将可用可能性最高的第一程序组件作为目标程序组件。

本实施例中，第二程序组件在接收到检测指令后，会先根据各个第一程序组件的工作状态,找到至少一个当前没有任务处理的第一程序组件，这种情况下，使得检测任务分配后，作为目标程序组件的第一程序组件能够快速开始对检测任务进行处理，尽可能避免检测任务需要等待一段时间的情况，提高检测效率。另外，在所有第一程序组件都正在处理任务的情况下，第二程序组件需要从中选择一个可能最快完成已有任务的第一程序组件作为目标程序组件，其中，本实施例中，通过可用可能性来量化各个第一程序组件完成已有任务的效率高低，从而使得最终选择的目标程序组件能够尽快开始检测任务的处理。

在进一步的实施例中，上述第二程序组件计算每个第一程序组件的可用可能性，可以包括：

第二程序组件计算每个第一程序组件已完成检测的应用的平均大小；

第二程序组件获取每个第一程序组件当前正在检测的应用大小；

第二程序组件计算每个第一程序组件已完成检测的应用的平均执行时间；

第二程序组件获取每个第一程序组件当前正在检测的应用的执行时间；

第二程序组件根据平均大小与应用大小的第一差值以及平均执行时间与执行时间的第二差值，计算每个第一程序组件的可用可能性。

本实施例中，利用第一程序组件已经检测过的应用的平均大小以及平均执行时间，与第一程序组件当前检测的应用的大小与执行时间进行比较，来得到第一程序组件的可用可能性，该可用可能性越大，表示该第一程序组件完成当前检测任务的速度可能越快，因此将检测任务分配给该第一程序组件后，该第一程序组件完成检测任务的速度也可能越快，从而尽可能提高了检测效率。

在其他一些实施例中，上述目标程序组件从检测任务中获取目标检测项之后，还可以包括：

在目标程序组件不支持目标检测项中的任意一项的情况下，目标程序组件返回退回响应至第二程序组件，退回响应用于告知第二程序组件检测任务未处理；

对应用安装包执行目标检测项对应的检测操作，包括：

在目标程序组件支持目标检测项中的至少一项的情况下，目标程序组件基于应用安装包，对目标移动应用执行自身支持的目标检测项对应的检测操作。

本实施例中，目标程序组件在接收到检测任务后，会判断自身是否支持该检测任务中的目标检测项，判断过程可以直接将目标检测项与自身包含的检测项进行比对，或者也可以将目标检测项对应的插件与自身包含的插件进行比对。如果不支持目标检测项中的任意一项，则表明该目标程序组件无法执行检测任务，因此将该检测任务退回,并告知第二程序组件该检测任务未处理，由第二程序组件再分配到其他第一程序组件中处理，如果当前目标程序组件支持至少一个目标检测项，则目标程序组件开始进行检测处理。通过上述方式，能够实现检测任务分配过程中的自动纠错，而非直接报错，从而提高了应用检测过程中的可靠性。

在进一步的实施例中，以android平台应用检测为例，以下分别介绍各个类型的检测程序组件中的目标程序组件，基于自身支持的目标检测项，对目标移动应用进行检测的步骤。

一、在检测程序组件为静态扫描程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件依赖项；

解析完毕后，目标程序组件反编译目标移动应用的安装包的目标组成部分，得到反编译结果；

目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

解析得到插件扫描逻辑后，目标程序组件执行自身支持的目标检测项对应的扫描代码，对反编译结果进行检测。

本实施例中，静态扫描程序组件中的主要检测流程为:

解析插件依赖项->反编译apk相应组成部分->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

二、在检测程序组件为动态扫描程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件配置项；

解析完毕后，目标程序组件启动真机资源/模拟器资源，创建动态沙箱环境；

在完成创建后，目标程序组件在动态沙箱环境内启动目标移动应用；

目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

解析得到插件扫描逻辑后，目标程序组件执行自身支持的目标检测项对应的扫描代码，对目标移动应用进行检测。

本实施例中，动态扫描程序组件的主要检测流程为:

解析插件配置项->启动真机资源/模拟器资源->创建动态沙箱环境->启动被测试应用->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

三、在检测程序组件为病毒检测程序组件的情况下，目标程序组件解析自身支持的目标检测项对应的插件配置项；

目标程序组件加载目标病毒检测程序组件资源，并创建病毒扫描运行环境；

在完成创建后，目标程序组件解析自身支持的目标检测项对应的插件扫描逻辑；

目标程序组件在病毒扫描运行环境内运行目标移动应用，并同步执行病毒扫描逻辑对目标移动应用进行检测。

本实施例中，病毒检测程序组件的主要检测流程为:

解析插件配置项->加载特定病毒检测程序组件资源->创建病毒扫描运行时环境->加载插件扫描逻辑->运行被测试样本->同步执行病毒扫描逻辑->得到扫描结果。

在另一些实施例中，上述方法还可以包括：

第二程序组件计算自身所属的目标检测程序组件的程序组件可用性；

第二程序组件在程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充目标检测程序组件包含的第一程序组件的数量；

第二程序组件间隔第一预设时长后重复上述操作，直至目标检测程序组件的程序组件可用性不低于第一预设阈值。

本实施例中，第二程序组件会计算自身所属的目标检测程序组件的程序组件可用性,计算出的程序组件可用性值如果低于设定的第一预设阈值，例如0.6，表明当前目标检测程序组件包含的第一程序组件的数量无法满足过多的检测任务，因此需要按照配置项扩充第一程序组件的数量，如果程序组件可用性值不低于第一预设阈值，则表明当前目标检测程序组件包含的第一程序组件的数量能够满足检测任务，因此不需要扩充第一程序组件的数量。在扩充过程中，可以每隔第一预设时长后，即计算一次程序组件可用性，若程序组件可用性不低于第一预设阈值，则停止扩充，如果依旧低于第一预设阈值，则继续扩充第一程序组件。这种方式，使得本申请实施例支持动态化的第一程序组件的扩展，提高了检测程序组件的高可用性，从而提高了检测程序组件的检测效率，减少了检测任务被长时间挂起的情况，避免了检测性能上遭遇瓶颈问题，保障了检测程序组件整体性能的稳定性。

在一些实施例中，上述第二程序组件计算自身所属的目标检测程序组件的程序组件可用性，可以包括：

第二程序组件计算目标检测程序组件的平均等待时间和平均恢复执行时间；其中，平均等待时间为目标检测程序组件的对应的全部等待任务的等待时间总和与等待任务的总数之间的比值；平均恢复执行时间为各个等待任务对应的时间差之和与等待任务的总数之间的比值，时间差为每个等待任务从创建到开始执行之间的时间差值；

第二程序组件计算平均等待时间与平均恢复执行时间之和，得到第一和值；

第二程序组件计算平均等待时间与第一和值的比值，得到程序组件可用性。

本实施例中，利用目标检测程序组件的对应的各个等待任务的等待时间和等待任务的数量进行程序组件可用性的计算，由于等待时间越长，等待任务越多，即越表明当前第一程序组件的数量不够支持检测任务的执行。因此，基于上述参数进行程序组件可用性的计算，即能够使得计算得到的程序组件可用性，能够反映是否存在扩充第一程序组件的需求，从而使得第二程序组件能够自在合适的情况下，对第一程序组件的数量进行扩充，保证整个检测程序组件的检测效率以及任务检测过程中的稳定性。

在进一步的实施例中，上述预设配置项包括扩充时长以及扩充步长，第二程序组件在程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充目标检测程序组件包含的第一程序组件的数量，可以包括：

在程序组件可用性低于第一预设阈值的情况下，第二程序组件开始计时；

在计时时长未达到扩充时长的过程中，第二程序组件按照扩充步长扩充第一程序组件的数量。

本实施例中，会在扩充时长内，按照特定的扩充步长扩充第一程序组件的数量。例如配置项为(0.6,1,30)，则表示程序组件可用性低于0.6,则会按照步长为1的扩充速度进行扩充,扩充时间持续30s，即每秒增加一个第一程序组件。这种情况下，可以在计时时长达到扩充时长后，再二次计算程序组件可用性，即第一预设时长可以等于扩充时长。这种扩充方式，每次增加相同数量的第一程序组件，能够使得第一程序组件的扩充过程较为稳定。或者，配置项中还可以限定扩充间隔，例如每隔2s增加一个第一程序组件，持续时间30s。

在另一些实施例中，第二程序组件计算检测程序组件的程序组件可用性之后，还可以包括：

在程序组件可用性高于第二预设阈值的情况下，第二程序组件将目标检测程序组件包含的第一程序组件的个数恢复至初始数值；其中，第二预设阈值大于第一预设阈值。

本实施例中，当程序组件可用性大于第二预设阈值的情况下，例如大于0.95，则表示当前第一程序组件的处理能力明显大于任务数量的需求，存在第一程序组件过剩的情况，因此本实施例控制第一程序组件的数量恢复到初始设置，从而再保证基础运行能力的情况下，提高第一程序组件的利用效率。

在再一些实施例中，上述方法还可以包括：

第二程序组件接收针对新增插件的插件注册信息；

第二程序组件控制完成当前任务的目标第一程序组件暂停后续任务，并依据插件注册信息向目标第一程序组件的插件库内添加新增插件；

第二程序组件在将新增插件添加至目标第一程序组件的插件库的情况下，恢复目标第一程序组件的后续任务的执行，并向服务器发送新增插件的插件识别信息；

服务器对插件识别信息进行保存，其中，服务器可以识别包含插件识别信息的检测请求。

在本实施例中，在完成新插件的开发后，用户可以向该插件所属的检测程序组件中的第二程序组件申请注册，而第二程序组件会将该插件注册信息自动同步推送到服务器中保存，以确保服务器能够识别并接收包含该新插件的检测任务。同时，第二程序组件会在第一程序组件完成当前任务的情况下，先挂起该第一程序组件的后续任务，并更新该第一程序组件的插件库，由此该新插件就已经可以在外部无感知的情况下，加入该第一程序组件的插件库。重复该操作，直至全部第一程序组件的插件库均更新完毕。这种情况下，使得用户能够根据需求在检测程序组件中，自定义注册插件，从而增加检测程序组件中的检测项，即实现检测项的定制化，提高了移动应用检测时检测项的灵活性。

基于上述方法实施例，本申请实施例还提供了一种应用检测装置，应用于服务器，图5是根据一示例性实施例示出的一种应用于服务器的应用检测装置的框图。参照图5，该装置包括请求接收模块510，指令生成模块520和指令发送模块530。

请求接收模块510，用于接收针对待检测的至少一个目标移动应用的检测请求；

指令生成模块520，用于基于检测请求生成检测指令；检测请求包括目标移动应用的应用信息；

指令发送模块530，用于分别向至少两个检测程序组件发送检测指令；其中，检测程序组件可以基于检测指令生成检测任务；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。

本公开实施例中，服务器在接收到针对目标移动应用的检测请求后，会生成对应的检测指令，之后将检测指令分别发送至自身关联的多个检测程序组件，各个检测程序组件会基于检测指令生成检测任务，检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息，其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同，因此各个检测程序组件会同步对目标移动应用进行不同类型的检测。即本公开实施例中，能够通过多个检测程序组件从不同的问题角度来对目标移动应用进行不同类型的检测，使得后续能够得到针对不同维度的检测结果，检测结果更加全面，基于该检测结果也能够对目标移动应用进行更加准确的判断。在不同的实施例中，无需重复撰写相同内容。

在一些实施例中，上述应用检测装置还可以包括：

第一注册信息接收模块，用于接收输入的程序组件注册信息；其中，程序组件注册信息包括：新增检测程序组件对应的检测插件信息，新增检测程序组件的属性信息，新增检测程序组件的对应的第一程序组件的数量；

程序组件配置模块，用于根据程序组件注册信息，配置与服务器连接的新增检测程序组件；

初始化模块，用于配置完成后，发送初始化信息至新增检测程序组件，其中，新增检测程序组件可以初始化自身对应的第一程序组件。

本实施例中，用户可以在新的检测程序组件开发完成后，向服务器注册该检测程序组件，新增检测程序组件完成注册之后，则会开始初始化自身的第一程序组件，使得在初始化完成后，该新增检测程序组件能够投入使用。这种方式下，使得用户能够根据自身需求增加检测程序组件的类型以及数量，从而实现定制化检测程序组件的目的，丰富了移动应用检测时的检测类型组合。

在另一些实施例中，上述应用检测装置还可以包括：

插件接收模块，用于接收检测程序组件发送的新增插件的插件识别信息；

插件保存模块，用于保存插件识别信息，其中，服务器可以识别包含插件识别信息的检测请求。

在本实施例中，在完成新插件的开发后，用户可以向该插件所属的检测程序组件中的第二程序组件申请注册，而第二程序组件会将该插件注册信息自动同步推送到服务器中保存，以确保服务器能够识别并接收包含该新插件的检测任务。同时，第二程序组件会在第一程序组件完成当前任务的情况下，先挂起该第一程序组件的后续任务，并更新该第一程序组件的插件库，由此该新插件就已经可以在外部无感知的情况下，加入该第一程序组件的插件库。重复该操作，直至全部第一程序组件的插件库均更新完毕。这种情况下，使得用户能够根据需求在检测程序组件中，自定义注册插件，从而增加检测程序组件中的检测项，即实现检测项的定制化，提高了移动应用检测时检测项的灵活性。

基于上述方法实施例，本申请实施例还提供了一种应用检测装置，应用于检测程序组件，检测程序组件包括一个第二程序组件和至少两个第一程序组件；图6是根据一示例性实施例示出的一种应用于检测程序组件的应用检测装置的框图。参照图6，该装置包括应用于第二程序组件的第一子装置以及应用于第一程序组件的第二子装置；第一子装置包括：

指令接收模块610，用于接收服务器发送的检测指令；检测指令包括目标移动应用的应用信息；

任务生成模块620，用于基于检测指令生成检测任务；

程序组件选择模块630，用于根据各个第一程序组件的工作状态，选择至少一个第一程序组件作为目标程序组件；

队列加入模块640，用于将检测任务加入目标程序组件的目标任务队列；检测任务包括目标移动应用的目标检测项以及目标移动应用的应用信息；其中，不同的检测程序组件生成的检测任务中包含的目标检测项不同。

本实施例中，由检测程序组件中的第二程序组件来接收检测指令、生成检测任务以及选择第一程序组件进行，即第二程序组件作为任务调度者，来负责检测任务的生成以及调度。这种情况下，可以通过第二程序组件来控制检测任务的分配，从而使得分配给各个第一程序组件的检测任务能够较为均衡，避免出现检测任务等待时间过长的情况，提高了任务处理的效率。

在一些实施例中，第二子装置可以包括：

安装包获取模块，用于从第一数据库获取应用安装包；

检测项获取模块，用于从检测任务中获取目标检测项；

检测模块，用于基于应用安装包，对目标移动应用执行目标检测项对应的检测操作。

本实施例中，目标程序组件能够从第一数据库中获取目标移动应用的应用安装包，即应用安装包存储于第一数据库中，这种情况下，使得服务器不需要存储并下发应用安装包，从而减少了应用安装包对服务器的存储空间的占用。

在另一些实施例中，上述程序组件选择模块630可以包括：

查找单元，用于根据各个第一程序组件的工作状态，查找当前未进行任务处理的第一程序组件；

第一目标确认单元，用于在存在当前未进行任务处理的第一程序组件的情况下，将当前未进行任务处理的第一程序组件作为目标程序组件；

第二目标确认单元，用于在全部第一程序组件均处于任务处理期间的情况下，计算每个第一程序组件的可用可能性，将可用可能性最高的第一程序组件作为目标程序组件。

本实施例中，第二程序组件在接收到检测指令后，会先根据各个第一程序组件的工作状态,找到至少一个当前没有任务处理的第一程序组件，这种情况下，使得检测任务分配后，作为目标程序组件的第一程序组件能够快速开始对检测任务进行处理，尽可能避免检测任务需要等待一段时间的情况，提高检测效率。另外，在所有第一程序组件都正在处理任务的情况下，第二程序组件需要从中选择一个可能最快完成已有任务的第一程序组件作为目标程序组件，其中，本实施例中，通过可用可能性来量化各个第一程序组件完成已有任务的效率高低，从而使得最终选择的目标程序组件能够尽快开始检测任务的处理。

在进一步的实施例中，上述第二目标确认单元可以包括：

平均大小计算单元，用于计算每个第一程序组件已完成检测的应用的平均大小；

应用大小计算单元，用于获取每个第一程序组件当前正在检测的应用大小；

平均时间计算单元，用于计算每个第一程序组件已完成检测的应用的平均执行时间；

执行时间计算单元，用于获取每个第一程序组件当前正在检测的应用的执行时间；

可用可能性计算单元，用于根据平均大小与应用大小的第一差值以及平均执行时间与执行时间的第二差值，计算每个第一程序组件的可用可能性，将可用可能性最高的第一程序组件作为目标程序组件。

本实施例中，利用第一程序组件已经检测过的应用的平均大小以及平均执行时间，与第一程序组件当前检测的应用的大小与执行时间进行比较，来得到第一程序组件的可用可能性，该可用可能性越大，表示该第一程序组件完成当前检测任务的速度可能越快，因此将检测任务分配给该第一程序组件后，该第一程序组件完成检测任务的速度也可能越快，从而尽可能提高了检测效率。

在其他一些实施例中，上述第二子装置还可以包括：

退回响应模块，用于在目标程序组件不支持目标检测项中的任意一项的情况下，目标程序组件返回退回响应至第二程序组件，退回响应用于告知第二程序组件检测任务未处理；

检测模块具体用于：在目标程序组件支持目标检测项中的至少一项的情况下，基于应用安装包，对目标移动应用执行自身支持的目标检测项对应的检测操作。

本实施例中，目标程序组件在接收到检测任务后，会判断自身是否支持该检测任务中的目标检测项，判断过程可以直接将目标检测项与自身包含的检测项进行比对，或者也可以将目标检测项对应的插件与自身包含的插件进行比对。如果不支持目标检测项中的任意一项，则表明该目标程序组件无法执行检测任务，因此将该检测任务退回,并告知第二程序组件该检测任务未处理，由第二程序组件再分配到其他第一程序组件中处理，如果当前目标程序组件支持至少一个目标检测项，则目标程序组件开始进行检测处理。通过上述方式，能够实现检测任务分配过程中的自动纠错，而非直接报错，从而提高了应用检测过程中的可靠性。

在其他一些实施例中，一、在检测程序组件为静态扫描程序组件的情况下，检测模块包括：

依赖项解析单元，用于解析自身支持的目标检测项对应的插件依赖项；

反编译单元，用于解析完毕后，反编译目标移动应用的安装包的目标组成部分，得到反编译结果；

第一扫描逻辑解析单元，用于解析自身支持的目标检测项对应的插件扫描逻辑；

第一代码执行单元，用于解析得到插件扫描逻辑后，执行自身支持的目标检测项对应的扫描代码，对反编译结果进行检测。

本实施例中，静态扫描程序组件中的主要检测流程为:

解析插件依赖项->反编译apk相应组成部分->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

二、在检测程序组件为动态扫描程序组件的情况下，检测模块具体包括：

第一配置项解析单元，用于解析自身支持的目标检测项对应的插件配置项；

资源启动单元，用于解析完毕后，启动真机资源/模拟器资源，创建动态沙箱环境；

应用启动单元，用于在完成创建后，在动态沙箱环境内启动目标移动应用；

第二扫描逻辑解析单元，用于解析自身支持的目标检测项对应的插件扫描逻辑；

第二代码执行单元，用于解析得到插件扫描逻辑后，执行自身支持的目标检测项对应的扫描代码，对目标移动应用进行检测。

本实施例中，动态扫描程序组件的主要检测流程为:

解析插件配置项->启动真机资源/模拟器资源->创建动态沙箱环境->启动被测试应用->解析插件扫描逻辑->执行具体扫描代码->得到扫描结果。

三、在检测程序组件为病毒检测程序组件的情况下，检测模块具体包括：

第二配置项解析单元，用于解析自身支持的目标检测项对应的插件配置项；

环境构建单元，用于加载目标病毒检测程序组件资源，并创建病毒扫描运行环境；

第三扫描逻辑解析单元，用于在完成创建后，解析自身支持的目标检测项对应的插件扫描逻辑；

逻辑执行单元，用于在病毒扫描运行环境内运行目标移动应用，并同步执行病毒扫描逻辑对目标移动应用进行检测。

本实施例中，病毒检测程序组件的主要检测流程为:

解析插件配置项->加载特定病毒检测程序组件资源->创建病毒扫描运行时环境->加载插件扫描逻辑->运行被测试样本->同步执行病毒扫描逻辑->得到扫描结果。

在另一些实施例中，上述第一子装置还可以包括：

程序组件可用性计算模块，用于计算自身所属的目标检测程序组件的程序组件可用性；

扩充模块，用于在程序组件可用性低于第一预设阈值的情况下，按照预设配置项扩充目标检测程序组件包含的第一程序组件的数量。

本实施例中，第二程序组件会计算自身所属的目标检测程序组件的程序组件可用性,计算出的程序组件可用性值如果低于设定的第一预设阈值，例如0.6，表明当前目标检测程序组件包含的第一程序组件的数量无法满足过多的检测任务，因此需要按照配置项扩充第一程序组件的数量，如果程序组件可用性值不低于第一预设阈值，则表明当前目标检测程序组件包含的第一程序组件的数量能够满足检测任务，因此不需要扩充第一程序组件的数量。在扩充过程中，可以每隔第一预设时长后，即计算一次程序组件可用性，若程序组件可用性不低于第一预设阈值，则停止扩充，如果依旧低于第一预设阈值，则继续扩充第一程序组件。这种方式，使得本申请实施例支持动态化的第一程序组件的扩展，提高了检测程序组件的高可用性，从而提高了检测程序组件的检测效率，减少了检测任务被长时间挂起的情况，避免了检测性能上遭遇瓶颈问题，保障了检测程序组件整体性能的稳定性。

在一些实施例中，上述程序组件可用性计算模块可以包括：

时间计算单元，用于计算目标检测程序组件的平均等待时间和平均恢复执行时间；其中，平均等待时间为目标检测程序组件的对应的全部等待任务的等待时间总和与等待任务的总数之间的比值；平均恢复执行时间为各个等待任务对应的时间差之和与等待任务的总数之间的比值，时间差为每个等待任务从创建到开始执行之间的时间差值；

和值计算单元，用于计算平均等待时间与平均恢复执行时间之和，得到第一和值；

比值计算单元，用于计算平均等待时间与第一和值的比值，得到程序组件可用性。

本实施例中，利用目标检测程序组件的对应的各个等待任务的等待时间和等待任务的数量进行程序组件可用性的计算，由于等待时间越长，等待任务越多，即越表明当前第一程序组件的数量不够支持检测任务的执行。因此，基于上述参数进行程序组件可用性的计算，即能够使得计算得到的程序组件可用性，能够反映是否存在扩充第一程序组件的需求，从而使得第二程序组件能够自在合适的情况下，对第一程序组件的数量进行扩充，保证整个检测程序组件的检测效率以及任务检测过程中的稳定性。

在进一步的实施例中，上述预设配置项包括扩充时长以及扩充步长，扩充模块包括：

计时单元，用于在程序组件可用性低于第一预设阈值的情况下，第二程序组件开始计时；

数量扩充单元，用于在计时时长未达到扩充时长的过程中，第二程序组件按照扩充步长扩充第一程序组件的数量。

本实施例中，会在扩充时长内，按照特定的扩充步长扩充第一程序组件的数量。例如配置项为(0.6,1,30)，则表示程序组件可用性低于0.6,则会按照步长为1的扩充速度进行扩充,扩充时间持续30s，即每秒增加一个第一程序组件。这种情况下，可以在计时时长达到扩充时长后，再二次计算程序组件可用性，即第一预设时长可以等于扩充时长。这种扩充方式，每次增加相同数量的第一程序组件，能够使得第一程序组件的扩充过程较为稳定。或者，配置项中还可以限定扩充间隔，例如每隔2s增加一个第一程序组件，持续时间30s。

在另一些实施例中，第一子装置还可以包括：

数量恢复模块，用于在程序组件可用性高于第二预设阈值的情况下，第二程序组件将目标检测程序组件包含的第一程序组件的个数恢复至初始数值；其中，第二预设阈值大于第一预设阈值。

本实施例中，当程序组件可用性大于第二预设阈值的情况下，例如大于0.95，则表示当前第一程序组件的处理能力明显大于任务数量的需求，存在第一程序组件过剩的情况，因此本实施例控制第一程序组件的数量恢复到初始设置，从而再保证基础运行能力的情况下，提高第一程序组件的利用效率。

在再一些实施例中，上述第一子装置还可以包括：

插件注册接收模块，用于接收针对新增插件的插件注册信息；

插件新增模块，用于控制完成当前任务的目标第一程序组件暂停后续任务，并依据插件注册信息向目标第一程序组件的插件库内添加新增插件；

插件识别信息发送模块，用于在将新增插件添加至目标第一程序组件的插件库的情况下，恢复目标第一程序组件的后续任务的执行，并向服务器发送新增插件的插件识别信息；其中，服务器可以对插件识别信息进行保存，且服务器能够识别包含插件识别信息的检测请求。

在本实施例中，在完成新插件的开发后，用户可以向该插件所属的检测程序组件中的第二程序组件申请注册，而第二程序组件会将该插件注册信息自动同步推送到服务器中保存，以确保服务器能够识别并接收包含该新插件的检测任务。同时，第二程序组件会在第一程序组件完成当前任务的情况下，先挂起该第一程序组件的后续任务，并更新该第一程序组件的插件库，由此该新插件就已经可以在外部无感知的情况下，加入该第一程序组件的插件库。重复该操作，直至全部第一程序组件的插件库均更新完毕。这种情况下，使得用户能够根据需求在检测程序组件中，自定义注册插件，从而增加检测程序组件中的检测项，即实现检测项的定制化，提高了移动应用检测时检测项的灵活性。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种服务器的框图。参照图7，装置700可以包括以下一个或多个组件：处理组件702，存储器704，电力组件706，多媒体组件708，音频组件710，输入/输出接口(I/O)712，传感器组件714，以及通信组件716。

处理组件702通常控制装置700的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在设备700的操作。这些数据的示例包括用于在装置700上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为装置700的各种组件提供电力。电源组件706可以包括电源管理***，一个或多个电源，及其他与为装置700生成、管理和分配电力相关联的组件。

本公开实施例还提供了一种检测程序组件，该检测程序组件包括第二程序组件和至少两个第一程序组件，第二程序组件和第一程序组件均可以参照图8，图8是根据一示例性实施例示出的一种程序组件的框图，该电子设备801包括处理组件8011，其进一步包括一个或多个处理器，以及由存储器8013所代表的存储器资源，用于存储可由处理组件8011的执行的指令，例如应用程序。存储器8013中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件8011被配置为执行指令，以执行上述任一实施例所述的直播互动方法。

该电子设备801还可以包括一个电源组件8015被配置为执行电子设备801的电源管理，一个有线或无线网络接口8017被配置为将电子设备801连接到网络，和一个输入/输出接口(I/O)8019。电子设备801可以操作基于存储在存储器8013的操作***，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在本公开一些实施例中，还提供了一种存储介质，当该存储介质中的指令由上述服务器或检测程序组件的处理器执行时，使得服务器或检测程序组件能够执行上述任一实施例所述的应用检测方法。

可选地，该存储介质可以是非临时性计算机可读存储介质，示例性的，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种应用检测方法，应用于服务器，其特征在于，所述方法包括：

接收针对待检测的至少一个目标移动应用的检测请求；

基于所述检测请求生成检测指令；所述检测请求包括所述目标移动应用的应用信息；

分别向至少两个检测程序组件发送所述检测指令，其中，所述检测指令用于指示检测程序组件生成检测任务；所述检测任务至少用于记录所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

2.一种应用检测方法，应用于检测程序组件，其特征在于，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件；所述方法包括：

所述第二程序组件接收服务器发送的检测指令；所述检测指令包括目标移动应用的应用信息；

所述第二程序组件基于所述检测指令生成检测任务；

所述第二程序组件根据各个所述第一程序组件的工作状态，选择至少一个所述第一程序组件作为目标程序组件；

所述第二程序组件将所述检测任务加入所述目标程序组件的目标任务队列；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

3.根据权利要求2所述的方法，其特征在于，所述第二程序组件将所述检测任务加入所述目标程序组件的目标任务队列之后，还包括：

所述目标程序组件从第一数据库获取所述应用安装包；

所述目标程序组件从所述检测任务中获取所述目标检测项；

所述目标程序组件基于所述应用安装包，对所述目标移动应用执行所述目标检测项对应的检测操作。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述第二程序组件接收针对新增插件的插件注册信息；

所述第二程序组件控制完成当前任务的目标第一程序组件暂停后续任务，并依据所述插件注册信息向所述目标第一程序组件的插件库内添加所述新增插件；

所述第二程序组件在将所述新增插件添加至所述目标第一程序组件的插件库的情况下，恢复所述目标第一程序组件的后续任务的执行，并向所述服务器发送所述新增插件的插件识别信息；

所述服务器对所述插件识别信息进行保存，其中，所述服务器用于识别包含所述插件识别信息的检测请求。

5.一种应用检测装置，应用于服务器，其特征在于，所述装置包括：

请求接收模块，被配置为执行接收针对待检测的至少一个目标移动应用的检测请求；

指令生成模块，被配置为执行基于所述检测请求生成检测指令；所述检测请求包括所述目标移动应用的应用信息；

指令发送模块，被配置为执行分别向至少两个检测程序组件发送所述检测指令；其中，所述检测程序组件基于所述检测指令生成检测任务；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

6.一种应用检测装置，应用于检测程序组件，其特征在于，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件；所述装置包括应被配置为执行所述第二程序组件的第一子装置以及应用于所述第一程序组件的第二子装置；所述第一子装置包括：

指令接收模块，被配置为执行接收服务器发送的检测指令；所述检测指令包括目标移动应用的应用信息；

任务生成模块，被配置为执行基于所述检测指令生成检测任务；

程序组件选择模块，被配置为执行根据各个所述第一程序组件的工作状态，选择至少一个所述第一程序组件作为目标程序组件；

队列加入模块，被配置为执行将所述检测任务加入所述目标程序组件的目标任务队列；所述检测任务包括所述目标移动应用的目标检测项以及所述目标移动应用的应用信息；其中，不同的所述检测程序组件生成的所述检测任务中包含的目标检测项不同。

7.一种服务器，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1所述的应用检测方法。

8.一种检测程序组件，其特征在于，所述检测程序组件包括一个第二程序组件和至少两个第一程序组件，所述第二程序组件和所述第一程序组件分别包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求2至4中任一项所述的应用检测方法。

9.一种存储介质，其特征在于，当所述存储介质中的指令由服务器的处理器执行时，使得服务器能够执行如权利要求1所述的应用检测方法。

10.一种存储介质，其特征在于，当所述存储介质中的指令由检测程序组件的处理器执行时，使得检测程序组件能够执行如权利要求2至4中任一项所述的应用检测方法。

Images