一种应用程序的组件检测方法、装置和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序的组件检测方法、装置和存储介质。

背景技术

为提升开发效率和扩展应用功能，各种应用程序（如游戏应用和社交应用等）都会接入多种组件，以实现分享、登录、支付、数据上报、信息收集、社区搭建等多类功能，但由于组件来源多样且版本迭代频繁，经常会因组件接入方式不正确或组件不适配引发应用程序功能异常，包括无法安装、卡顿和崩溃等严重问题。现有技术方案通过人工测试排查应用程序的组件风险，但测试排查工作量巨大，涉及人员众多，耗费大量人力和时间，且难以保证风险排查的准确度。因此亟需提供一种能够有效提高应用程序的组件检测效率的方案，以解决上述现有技术中存在的问题。

发明内容

本申请提供了一种应用程序的组件检测方法、装置和存储介质，可以有效提高人工审核效率，降低审核成本。

一方面，本申请提供了一种应用程序的组件检测方法，所述方法包括：

获取待检测应用程序的目标安装文件；

解析所述目标安装文件，得到所述待检测应用程序的目标解析文件；

提取所述目标解析文件中的组件信息和申请权限信息；

根据所述组件信息对应的待检测组件的基础权限，对所述申请权限信息进行组件权限检测，得到所述待检测应用程序的组件权限检测结果；所述组件权限检测结果用于表征所述申请权限信息对应的申请权限中是否包括所述待检测组件的基础权限；

通过组件检测规则库中的组件检测规则对所述目标解析文件进行组件问题检测，得到所述待检测应用程序的组件问题检测结果；所述组件检测规则库为基于样本应用程序及其对应的样本组件问题确定的多条组件检测规则构建得到的。

另一方面提供了一种应用程序的组件检测装置，所述装置包括：

安装文件获取模块：用于获取待检测应用程序的目标安装文件；

安装文件解析模块：用于解析所述目标安装文件，得到所述待检测应用程序的目标解析文件；

信息提取模块：用于提取所述目标解析文件中的组件信息和申请权限信息；

组件权限检测模块：用于根据所述组件信息对应的待检测组件的基础权限，对所述申请权限信息进行组件权限检测，得到所述待检测应用程序的组件权限检测结果；所述组件权限检测结果用于表征所述申请权限信息对应的申请权限中是否包括所述待检测组件的基础权限；

组件问题检测模块：用于通过组件检测规则库中的组件检测规则对所述目标解析文件进行组件问题检测，得到所述待检测应用程序的组件问题检测结果；所述组件检测规则库为基于样本应用程序及其对应的样本组件问题确定的多条组件检测规则构建得到的。

另一方面提供了一种应用程序的组件检测设备，所述设备包括处理器和存储器，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如上述的应用程序的组件检测方法。

另一方面提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如上述的应用程序的组件检测方法。

另一方面提供了一种服务器，所述服务器包括处理器和存储器，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如上述的应用程序的组件检测方法。

本申请提供的应用程序的组件检测方法、装置、设备、存储介质和服务器，具有如下技术效果：

本申请对获取的待检测应用程序的目标安装文件进行解析，得到待检测应用程序的目标解析文件；提取目标解析文件中的组件信息和申请权限信息；根据组件信息对应的待检测组件的基础权限，对组件信息和申请权限信息进行组件权限检测，得到待检测应用程序的组件权限检测结果；通过组件检测规则库中的组件检测规则对目标解析文件进行组件问题检测，得到待检测应用程序的组件问题检测结果，实现了组件权限和组件问题的自动化检测和排查，节省人力时间成本；并且，通过对目标安装文件进行组件权限检测和组件问题检测，有效提高组件检测的精度和准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本申请实施例提供的一种应用环境的示意图；

图2是本申请实施例提供的一种应用程序的组件检测方法的流程示意图；

图3是本申请实施例提供的一种组件权限检测方法的流程示意图；

图4是本申请实施例提供的一种组件问题检测方法的流程示意图；

图5是本申请一个实施例提供的组件检测规则库的构建方法的流程示意图；

图6是本申请一个实施例提供的应用程序的组件检测方法的流程示意图；

图7是本申请实施例提供的一种应用程序的组件检测装置的结构示意图；

图8是本申请实施例提供的一种应用程序的组件检测方法的服务器的硬件结构框图；

图9是本申请实施例提供的一个区块链系统的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

组件：是一个组装单元，它具有约定式规范的接口，以及明确的依赖环境，其构建可以被独立的部署，由第三方组装。

bug：是指程序中的错误、故障或缺陷，会产生意外结果或导致系统意外运行。

AndroidManifest.xml：是Android应用程序的清单文件，是整个Android应用程序的描述文件。每个应用程序安装文件的根目录中都必须包含一个 AndroidManifest.xml文件（且文件名精确无误）。清单文件向Android系统提供应用程序的必要信息，系统必须具有这些信息方可运行应用程序的任何代码。

so文件：一种计算机程序文件，android和linux平台的动态链接库文件。

请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，如图1所示，该应用环境可以至少包括服务器01和终端02。在实际应用中，服务器01和终端02可以通过有线或无线通信方式进行直接或间接地连接，以实现终端02与服务器01间的交互，本申请在此不做限制。

本申请实施例中，终端02可以包括智能手机、台式电脑、平板电脑、笔记本电脑、数字助理等类型的实体设备，也可以包括运行于实体设备中的软体，例如应用程序等。具体的，终端02可以用于为用户提供待检测应用程序的目标安装文件的上传界面，以及用于接收目标安装文件的上传操作和目标安装文件，并响应于上传操作向服务器01发送组件检测请求和目标安装文件。本申请实施例中终端02上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux或windows等。

本申请实施例中，服务器01可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（Content Delivery Network，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器。具体的，服务器可以包括实体设备，可以具体包括有网络通信单元、处理器和存储器等等，也可以包括运行于实体设备中的软体，可以具体包括有应用程序等。

具体的，分布式系统可以包括分布式管理服务器、元数据库和多个代理节点。可以用于分布式集群及其生态相关组件的服务定义、管理、监控等一体化集群管理系统，具体的，本说明书实施例中，分布式系统可以包含一套简单易用的web UI（User Interface，用户界面）和一套规范的RESTful API（Application Programming Interface，应用程序接口）集合。具体的，分布式集群可以包括多个节点，多个节点可以包括客户端，也可以包括服务器。

本说明书实施例中，多个代理节点可以部署于分布式集群的多个节点上，具体的，例如分布式集群的每一节点上部署一个代理节点；相应的，分布式管理服务器可以通过多个代理节点收集分布式集群的多个节点上服务和服务下组件的工作状态，并存储到元数据库；另外，分布式管理服务器也可以收集多个代理节点上服务和服务下组件的工作状态，并将多个代理节点的工作状态存储到元数据库。

具体的，服务器01可以用于接收目标安装文件，并响应于终端发送的组件检测请求对目标安装文件进行组件检测，以生成组件权限检测结果和组件问题检测结果。

在一些实施例中，服务器01还用于根据组件权限检测结果和组件问题检测结果生成组件检测报告，并将组件检测报告发送至终端02。终端02还用于接收并显示组件检测报告。

此外，需要说明的是，图1所示的仅仅是一种应用程序的组件检测方法的应用环境，该应用环境可以包括更多或更少的节点，本申请在此不做限制。

以下基于上述应用环境介绍本申请的一种应用程序的组件检测方法，图2是本申请实施例提供的一种应用程序的组件检测方法的流程示意图，本说明书提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行（例如并行处理器或者多线程处理的环境）。具体的如图2所示，方法可以包括：

S201：获取待检测应用程序的目标安装文件。

本申请实施例中，待检测应用程序可以包括但不限于社交应用、游戏应用、网购应用、地图导航应用和视频播放应用等。举例来说，待检测应用程序可以是用于运行在Android系统中的应用程序，目标安装文件可以为apk文件，apk文件中包括但不限于xml文件、so文件、dex文件和arsc文件等。

在一些实施例中，服务器接收终端发送的组件检测请求和目标安装文件。组件检测请求可以是终端基于用户触发的目标安装文件的上传操作生成的，终端接收用户触发的上传操作和上传的目标安装文件后，将生成的组件检测请求和目标安装文件发送至服务器，以使服务器响应于组件检测请求对待检测应用程序的目标安装文件进行组件检测。

S203：解析目标安装文件，得到待检测应用程序的目标解析文件。

本申请实施例中，目标解析文件可以包括但不限于可执行文件、dex文件、so文件、arsc文件、xml文件、二进制文件和jar文件等。在一些实施例中，可对二进制文件、可执行文件、dex文件、so文件、arsc文件、xml文件和jar文件中的一种或几种文件进行反编译，得到对应的反编译文件，反编译文件可以为源码文件或伪码文件。相应的，目标解析文件中包括该源码文件或伪码文件。需要说明的是，可以基于现有的反编译工具对可执行文件进行反编译操作，本申请在此不做限制。

在一些实施例中，服务器端响应于组件检测请求，解析目标安装文件，以获取用于组件检测的相关文件信息。

S205：提取目标解析文件中的组件信息和申请权限信息。

本申请实施例中，目标解析文件中包括与待检测应用程序的接入组件相关的组件信息，如与接入组件相关的组件名、文件类名和接口函数信息等，以及包括与待检测应用程序的申请权限相关的申请权限信息。举例来说，申请权限可以例如为写入外部存储和读取外部存储等，当待检测应用程序为应用于移动平台的应用程序时，申请权限还可以例如为访问摄像头、访问通讯录、访问账户列表、获取麦克风、读取短信、获取精确位置、获取粗略位置和读取手机状态等。

具体的，可以从目标解析文件中的so文件和jar文件中提取待检测应用程序的组件信息。

具体的，可以从目标解析文件中的AndroidManifest.xml文件中提取待检测应用程序的申请权限信息。

S207：根据组件信息对应的待检测组件的基础权限，对申请权限信息进行组件权限检测，得到待检测应用程序的组件权限检测结果。

本申请实施例中，组件权限检测结果包括组件基础权限的检测结果，相应的，组件权限检测结果可以用于表征申请权限信息对应的申请权限中是否包括待检测组件的基础权限。在一些实施例中，基础权限为待检测组件的必选权限。举例来说，用于实现录音功能的组件的必选权限可以包括但不限于获取麦克风权限，如组件GVoice应用于安卓系统的必选权限包括RECORD_AUDIO；用于实现支付功能的组件的必选权限可以包括但不限于写入外部存储权限，如组件midas应用于安卓系统的必选权限包括WRITE_EXTERNAL_STORAGE。需要说明的是，不同的组件可能包括相同或不同的必选权限，本申请在此不做枚举。

在实际应用中，可以预先构建和存储预设的组件与基础权限的对应关系，该对应关系可以存储在组件检测规则库中，也可单独存储于其他位置。具体的，预设的组件与基础权限的对应关系可以具体为组件标识与基础权限的对应关系。具体的，组件标识可以为组件名或组件代码等。

在实际应用中，组件权限检测结果包括组件基础权限的检测结果，相应的，请参考图3，图3是本申请实施例提供的一种组件权限检测方法的流程示意图，步骤S207可以包括：

S2071：根据组件信息确定待检测应用程序对应的待检测组件列表。

在一些情况下，组件信息中包括待检测应用程序的接入组件的组件名，或通过解析该组件信息可以直接获取接入组件的组件名，进而根据接入组件的组件名确定待检测组件列表。具体的，待检测应用程序中的接入组件为第三方提供的组件。在另一些情况下，可以预先构建组件识别库，组件识别库中包括组件信息与组件的对应关系，如文件类名与组件标识的对应关系、接口函数信息与组件标识的对应关系等，进而根据组件信息与组件的对应关系确定待检测应用程序的组件信息对应的组件，进而构建待检测组件列表。

S2072：根据申请权限信息确定待检测应用程序的申请权限集合。

具体的，根据申请权限信息可以确定待检测应用程序当前已申请的权限，得到该申请权限集合。申请权限集合中包括组件的基础权限，还可以包括组件的非基础权限。在一些实施例中，非基础权限为组件的非必选权限。

S2073：利用预设的组件与基础权限的对应关系确定待检测组件列表中的各待检测组件各自对应的基础权限集合。

具体的，预设的组件与基础权限的对应关系可以如前述的组件标识与组件基础权限的对应关系。遍历检测组件列表中的待检测组件，从预设的组件与基础权限的对应关系中获取各待检测组件各自对应的基础权限，进而生成各基础权限集合，基础权限集合中可以包括各基础权限标识。

S2074：若任一基础权限集合不是申请权限集合的子集，确定对应的待检测组件的组件权限检测结果为组件权限存在缺陷。

具体的，对待检测组件列表中的待检测组件进行基础权限的缺陷遍历检测，判断各待检测组件各自的基础权限集合是否为申请权限集合的子集，若判断结果为是，确定对应的待检测组件的组件权限检测结果为基础权限已全部申请；若任一基础权限集合中存在申请权限集合中不包含的权限，则确定其对应的待检测组件有基础权限未申请，且对应的组件权限检测结果为组件权限存在缺陷，进而根据上述缺陷遍历检测结果生成组件基础权限的检测结果。

在一些实施例中，组件权限检测结果还可以包括非基础权限的检测结果，相应的，组件权限检测结果还可以用于表征申请权限信息对应的申请权限中是否包括冗余权限。步骤S207还可以包括：

S2075：将申请权限集合中除各自对应的基础权限集合之外的权限作为非基础权限。

在实际应用中，将申请权限集合中不属于各待检测组件对应的基础权限集合的目标权限确定为非基础权限。

具体的，可以通过遍历各基础权限集合中的基础权限生成待检测组件对应的总基础权限集合，然后确定属于申请权限集合但不属于总基础权限集合的目标权限，将该目标权限确定为申请权限集合中的非基础权限。

S2076：若任一非基础权限与目标解析文件中的功能信息不匹配，关闭与功能信息不匹配的非基础权限。

在一些实施例中，可以预先构建和存储权限与功能信息的对应关系，基于权限与功能信息的对应关系确定申请权限集合中的各非基础权限各自对应的目标功能信息，通过扫描检测目标解析文件判断其对应的功能信息中是否包括非基础权限对应的目标功能信息，若包括，确定该非基础权限为目标功能权限，非基础权限与目标解析文件中的功能信息匹配；若任一非基础权限对应的目标功能信息均不在目标解析文件中的功能信息中，则该非基础权限与目标解析文件中的功能信息不匹配，即待检测应用程序的各功能模块均用不到该非基础权限，则确定该非基础权限为冗余权限，相应的，关闭该冗余权限或从目标安装文件中删除该冗余权限的相关信息，以精简目标安装文件的安装和应用进程。

在一些情况下，目标解析文件中可包括目标安装文件的可执行文件等对应的源码文件，相应的，权限与功能信息的对应关系可以为权限与功能代码段的对应关系，通过扫描目标解析文件中的相关源码文件，可以确定相关源码文件中是否存在各非基础权限各自对应的功能代码段。

S209：通过组件检测规则库中的组件检测规则对目标解析文件进行组件问题检测，得到待检测应用程序的组件问题检测结果。

本申请实施例中，组件问题检测的方式可以包括但不限于静态检测等，静态检测基于静态分析技术实现。组件检测规则库为基于样本应用程序及对应的样本组件问题确定的多条组件检测规则构建得到的。样本组件问题可以例如为组件更新造成的不适配问题、组件与系统功能不适配问题、组件漏洞问题、组件升级功能与应用程序或系统的不兼容问题等。任一组件检测规则可以对应于至少一个样本组件问题和问题检测项。通过读取组件检测规则库中的组件检测规则，执行对目标解析文件的静态检测，得到各组件检测规则对应的检测结果，进而生成待检测应用程序的组件问题检测结果。

在一些实施例中，步骤S209可以包括：通过遍历组件检测规则库中的组件检测规则对目标解析文件进行静态检测，以得到组件问题检测结果。

具体的，遍历读取和执行组件检测规则库中的组件检测规则，利用组件检测规则库中的每条组件检测规则对目标解析文件进行静态检测，进而得到组件检测结果。在一些情况下，组件检测规则库中存在待检测组件不需要的组件检测规则，则直接标记该检测规则对应的问题检测结果为通过。

在另一些实施例中，请参考图4，图4是本申请实施例提供的一种组件问题检测方法的流程示意图，步骤S209可以包括：

S2091：根据组件信息确定待检测应用程序对应的待检测组件列表。

具体的，步骤S2091的实现方式与前述步骤S2071的实现该方式相类似，在此不再赘述。

S2092：从组件检测规则库中确定与待检测组件列表对应的目标检测规则集合。

具体的，组件检测规则库中还可以包括组件与组件检测规则的映射关系，如组件标识与组件检测规则的映射关系。根据该映射关系从组件检测规则库中筛选与待检测组件列表中的待检测组件对应的组件检测规则，进而生成目标检测规则集合。

S2093：基于目标检测规则集合中的组件检测规则对目标解析文件进行静态检测，以得到组件问题检测结果。

具体的，通过遍历目标检测规则集合中的组件检测规则对目标解析文件进行静态检测，进而得到组件问题检测结果。如此，预先筛选与待检测组件对应的组件检测规则，能够减少冗余问题检测，进一步提高组件检测效率和减少资源浪费。·

需要说明的是，组件权限检测和组件问题检测可以并行执行或先后执行，本申请在此不做限制。

在实际应用中，组件问题检测库中可能未涵盖部分待检测组件对应的组件检测规则，或预设的组件与基础权限的对应关系中可能未包括部分待检测组件与基础权限的对应关系，进而造成待检测组件漏检。因此，在一些实施例中，方法还可以包括：

S211：基于组件与组件检测规则的映射关系确定组件检测规则库对应的参考组件列表。

S213：若待检测组件列表中存在参考组件列表中不包括的目标待检测组件，确定目标待检测组件的组件检测结果为该目标待检测组件为风险组件。

具体的，基于组件与组件检测规则的映射关系能够确定组件检测规则库中各组件检测规则分别对应的参考组件，进而生成参考组件列表。将参考组件列表与待检测组件列表进行比较，以判断参考组件列表中是否包括待检测组件列表中的全部待检测组件，若任一待检测组件不在参考组件列表中，将该待检测组件作为目标待检测组件，进而确定该目标待检测组件为风险组件，并生成风险组件警示信息。

基于上述部分或全部实施方式，本申请实施例中，方法还可以包括：

S215：根据组件问题检测结果和组件权限检测结果生成组件检测报告。

S217：将组件检测报告发送至目标界面，以在目标界面上展示组件检测报告。

在实际应用中，可以将组件检测报告发送至终端的目标界面，以使终端在目标界面上展示组件检测报告，在一个示例中，组件检测报告可以基于表格形式展示。

基于上述部分或全部实施方式，本申请实施例中，请参考图5，图5是本申请一个实施例提供的组件检测规则库的构建方法的流程示意图，在步骤S201之前，方法还可以包括：

S301：获取样本组件的组件说明文档，和样本应用程序运行时出现的样本组件问题对应的问题日志文件。

在实际应用中，可以基于样本组件的发布地址获取组件说明文档，举例来说，可以利用爬取工具基于样本组件的发布地址从相应发布网站资源中爬取组件说明文档，组件说明文档中可以包括组件配置信息，包括但不限于组件接入指引信息、组件配置需求信息和组件基础权限信息等。

在实际应用中，可以根据组件说明文档中的组件配置信息搜集样本组件问题，或者也可以爬取组件变更文档，从组件变更文档中提取组件漏洞问题信息，例如从组件变更文档的漏洞说明文件（如bugfix日志文件）中提取历史漏洞问题信息，基于提取到的历史漏洞问题信息确定样本组件问题，或者还可以基于人工搜集的组件漏洞案例生成样本组件问题。

在实际应用中，样本应用程序可以包括一个或多个应用程序，样本组件问题包括多个组件问题。具体的，可以通过运行存在样本组件问题的样本应用程序生成对应的问题日志文件。

S303：获取基于问题日志文件和组件说明文档确定的样本组件问题对应的多个组件检测规则。

具体的，通过分析问题日志文件中与样本组件问题相关的日志信息以及组件说明文档中的组件配置信息，可以提炼出对应的组件检测规则。该组件检测规则可以人工生成或基于规则提炼工具自动生成。

S305：根据多个组件检测规则构建组件检测规则库。

在一些情况下，基于前述得到的多个组件检测规则生成组件检测规则库。如此，通过预先构建组件检测规则库能够提升组件问题检测的覆盖度和提高组件问题的检测效率。

在另一些情况下，生成的组件检测规则中可能存在执行错误的检测规则，相应的，步骤S305可以包括：

S3051：利用多个组件检测规则对样本应用程序的解析文件进行静态检测，得到各组件检测规则各自对应的参考组件问题检测结果。

S3052：将样本组件问题与参考组件问题检测结果对应的组件问题一致的组件检测规则确定为目标组件检测规则。

S3053：基于目标组件检测规则构建组件检测规则库。

具体的，读取多个组件检测规则，并基于该多个组件检测规则分别执行对解析文件的静态检测，得到对应的多个参考组件问题检测结果。确定每个参考组件问题检测结果对应的参考组件问题，若参考组件问题与对应的样本组件问题一致，则确定该参考组件问题对应的组件检测规则为目标组件检测规则，目标组件检测规则为能够正确实现的检测规则；若参考组件问题与对应的样本组件问题不一致，则确定该参考组件问题对应的组件检测规则不能够正确实现，将相应的组件检测规则标记为问题检测规则，并生成相应的报错信息。

如此，对组件检测规则进行验证和筛选，提高组件检测规则库的准确性，进而提高组件问题检测的准确性。

在实际应用中，组件经常会更新升级，因此需要对组件检测规则库进行更新，以提高组件问题检测的覆盖度，相应的，方法还可以包括：

S307：周期性获取样本组件的组件变更文档。

S309：从组件变更文档中提取样本组件的漏洞问题更新信息。

S311：获取漏洞问题更新信息对应的组件检测规则。

S313：基于漏洞问题更新信息对应的组件检测规则更新组件检测规则库。

在一些实施例中，可以定期爬取样本组件的组件变更文档，提取当前爬取到的组件变更文档中的当前漏洞问题信息，将当前漏洞问题信息与历史漏洞问题信息进行比较，得到漏洞问题更新信息，并获取漏洞问题更新信息对应的组件检测规则，进而实现组件检测规则库的更新和扩展。

综上，本申请的上述技术方案对获取的待检测应用程序的目标安装文件进行解析，得到待检测应用程序的目标解析文件；提取目标解析文件中的组件信息和申请权限信息；根据组件信息对应的待检测组件的基础权限，对组件信息和申请权限信息进行组件权限检测，得到待检测应用程序的组件权限检测结果；通过组件检测规则库中的组件检测规则对目标解析文件进行组件问题检测，得到待检测应用程序的组件问题检测结果，实现了组件权限和组件问题的自动化检测和排查，节省人力时间成本，在检测过程中无需动态运行程序即可便捷高效的实现组件风险挖掘，有效提升组件检测效率，并且，通过对目标安装文件进行组件权限检测和组件问题检测，有效提高组件检测的精度和准确性。

以下结合具体应用介绍本申请的应用程序的组件检测方法，待检测应用程序为适配于Android系统的游戏应用程序，游戏应用程序接入第三方提供的多个待检测组件，请参考图6，图6是本申请一个实施例提供的应用程序的组件检测方法的流程示意图，方法可以包括：

S1：获取样本组件的组件说明文档和样本组件问题对应的问题日志文件。

S2：获取基于问题日志文件和组件说明文档确定的多个组件检测规则。

S3：根据多个组件检测规则构建组件检测规则库。

S4：接收待检测应用程序的目标安装文件。

具体的，可以接收用户在终端通过组件检测平台界面上传的目标安装文件，目标安装文件可为apk文件包。

S5：解析目标安装文件，得到待检测应用程序的目标解析文件。

具体的，解析apk文件包中的AndroidManifest.xml文件、so文件、jar文件、二进制文件和可执行文件等，相应得到的目标解析文件中包括上述各文件对应的反编译文件。

S6：提取目标解析文件中的组件信息和申请权限信息。

具体的，可以从AndroidManifest.xml文件对应的反编译文件中提取申请权限信息，从so文件和jar文件对应的反编译文件中提取组件信息。

S7：根据组件信息确定待检测应用程序对应的待检测组件列表。

具体的，基于从so文件和jar文件对应的反编译文件中提取的组件信息以及预设的组件识别库，识别待检测应用程序接入的组件，生成待检测组件列表。待检测组件列表包括一个或多个待检测组件i。

S8：从组件检测规则库中确定待检测组件列表对应的目标检测规则集合K。

具体的，目标检测规则集合K包括组件检测规则库中各待检测组件i对应的组件检测规则k。

S9：基于各组件检测规则k对目标解析文件进行静态检测。

S10：输出每条组件检测规则k的组件问题检测结果。

S11：根据申请权限信息确定待检测应用程序的申请权限集合A。

具体的，基于从AndroidManifest.xml文件对应的反编译文件中提取的申请权限信息，确定待检测应用程序的各申请权限，生成申请权限集合。

S12：利用预设的组件与基础权限的对应关系确定待检测组件i对应的基础权限集合Bi。

S13：判断基础权限集合Bi是否为申请权限集合A的子集，若是，转至步骤S14，若否，转至步骤S15。

S14：确定待检测组件i的组件权限检测结果为基础权限均已申请。

S15：确定待检测组件i的组件权限检测结果为组件权限存在缺陷。

S16：根据基础权限集合Bi确定申请权限集合A中的非基础权限。

具体的，将申请权限集合中除基础权限集合对应的权限之外的其它权限作为非基础权限，申请权限集合中包括一个或多个非基础权限n。

S17：判断非基础权限n与目标解析文件中的功能信息是否匹配；若匹配，转至步骤S18，若不匹配，转至步骤S19。

S18：确定非基础权限n为目标功能权限。

S19：关闭非基础权限n。

S20：生成组件检测报告。

本实施例中，请参考表一至表三，组件检测报告可以包括表一至表三中的一个或几个。具体的，表一示出了检测项、适用组件和检测结论的相关结果，表一中的检测组件申请权限对应于组件权限检测的相关检测步骤，其它检测项对应组件问题检测的相关检测步骤，每个检测项可以调用组件检测规则库中的一个或几个组件检测规则。

表一

具体的，表二示出了表一中检测结论为不通过的检测项的详细信息。包括不通过检测项的风险等级、风险类型、风险描述信息和相应的信息链接。通过点击信息连接栏中的操作控件（如表二中的查看），可以链接至该检测项的检测信息。

表二

具体的，表三示出了部分待检测应用程序的申请权限，以及相应的申请权限描述、必须申请此权限的组件和可能申请此权限的组件。可以理解的，当待检测组件列表中包括GVoice组件以及WXSDK,QQSDK,midas, GVoice,TGPA和tersafe中的任一组件时，表三中权限RECORD_AUDIO和 WRITE_EXTERNAL_STORAGE为基础权限，权限ACCESS_COARSE_LOCATION，ACCESS_FINE_LOCATION和READ_EXTERNAL_STORAGE为非基础权限。

表三

需要说明的是，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的方法。

本申请实施例还提供了一种应用程序的组件检测装置100，如图7所示，图7是本申请实施例提供的一种应用程序的组件检测装置的结构示意图，装置包括：

安装文件获取模块10：用于获取待检测应用程序的目标安装文件；

安装文件解析模块20：用于解析目标安装文件，得到待检测应用程序的目标解析文件；

信息提取模块30：用于提取目标解析文件中的组件信息和申请权限信息；

组件权限检测模块40：用于根据组件信息对应的待检测组件的基础权限，对申请权限信息进行组件权限检测，得到待检测应用程序的组件权限检测结果；组件权限检测结果用于表征申请权限信息对应的申请权限中是否包括待检测组件的基础权限；

组件问题检测模块50：用于通过组件检测规则库中的组件检测规则对目标解析文件进行组件问题检测，得到待检测应用程序的组件问题检测结果；组件检测规则库为基于样本应用程序及对应的样本组件问题确定的多条组件检测规则构建得到的。

在一些实施例中，组件问题检测模块50包括：

第一组件问题检测单元：用于通过遍历组件检测规则库中的组件检测规则对目标解析文件进行静态检测，以得到组件问题检测结果；

或者，

组件列表确定单元：用于根据组件信息确定待检测应用程序对应的待检测组件列表；

目标检测规则集合确定单元：用于从组件检测规则库中确定与待检测组件列表对应的目标检测规则集合；

第一组件问题检测单元：用于基于目标检测规则集合中的组件检测规则对目标解析文件进行静态检测，以得到组件问题检测结果。

在一些实施例中，组件权限检测模块40包括：

组件列表确定单元：用于根据组件信息确定待检测应用程序对应的待检测组件列表；

申请权限集合确定单元：用于根据申请权限信息确定待检测应用程序的申请权限集合；

基础权限集合确定单元：用于利用预设的组件与基础权限的对应关系确定待检测组件列表中的各待检测组件各自对应的基础权限集合；

组件权限缺陷确定单元：用于若任一基础权限集合不是申请权限集合的子集，确定对应的待检测组件的组件权限检测结果为组件权限存在缺陷。

在一些实施例中，装置还包括：

非基础权限确定模块：用于将申请权限集合中除各自对应的基础权限集合之外的权限作为非基础权限；

非基础权限关闭模块：用于若任一非基础权限与目标解析文件中的功能信息不匹配，关闭与功能信息不匹配的非基础权限。

在一些实施例中，装置还包括：

文件获取模块：用于在获取待检测应用程序的目标安装文件之前，获取样本组件的组件说明文档，和样本应用程序运行时出现的样本组件问题对应的问题日志文件；

组件检测规则获取模块：用于获取基于问题日志文件和组件说明文档确定的样本组件问题对应的多个组件检测规则；

检测规则库构建模块：用于根据多个组件检测规则构建组件检测规则库。

在一些实施例中，检测规则库构建模块包括：

样本应用程序检测单元：用于利用多个组件检测规则对样本应用程序的解析文件进行静态检测，得到各组件检测规则各自对应的参考组件问题检测结果；

目标组件检测规则确定单元：用于将样本组件问题与参考组件问题检测结果对应的组件问题一致的组件检测规则确定为目标组件检测规则；

检测规则库构建单元：用于基于目标组件检测规则构建组件检测规则库。

在一些实施例中，装置还包括：

组件变更文档爬取模块：用于周期性获取样本组件的组件变更文档；

漏洞问题信息提取模块：用于从组件变更文档中提取样本组件的漏洞问题更新信息；

更新检测规则获取模块：用于获取漏洞问题更新信息对应的组件检测规则；

检测规则库更新模块：用于基于漏洞问题更新信息对应的组件检测规则更新组件检测规则库。

在一些实施例中，装置还包括：

检测报告生成模块：用于根据组件问题检测结果和组件权限检测结果生成组件检测报告。

检测报告发送模块：用于将组件检测报告发送至目标界面，以在目标界面上展示组件检测报告。

上述装置实施例中的装置与方法实施例基于同样的申请构思。

本申请实施例提供了一种应用程序的组件检测设备，该应用程序的组件检测设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的应用程序的组件检测方法。

存储器可用于存储软件程序以及模块，处理器通过运行存储在存储器的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、功能所需的应用程序等；存储数据区可存储根据设备的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器还可以包括存储器控制器，以提供处理器对存储器的访问。

本申请实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图8是本申请实施例提供的一种应用程序的组件检测方法的服务器的硬件结构框图。如图8所示，该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（Central Processing Units，CPU）810（处理器810可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置）、用于存储数据的存储器830，一个或一个以上存储应用程序823或数据822的存储介质820（例如一个或一个以上海量存储设备）。其中，存储器830和存储介质820可以是短暂存储或持久存储。存储在存储介质820的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器810可以设置为与存储介质820通信，在服务器800上执行存储介质820中的一系列指令操作。服务器800还可以包括一个或一个以上电源860，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口840，和/或，一个或一个以上操作系统821，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

输入输出接口840可以用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器800的通信供应商提供的无线网络。在一个实例中，输入输出接口840包括一个网络适配器（Network Interface Controller，NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输入输出接口840可以为射频（RadioFrequency，RF）模块，其用于通过无线方式与互联网进行通讯。

本领域普通技术人员可以理解，图8所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器800还可包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。

本申请的实施例还提供了一种存储介质，存储介质可设置于服务器之中以保存用于实现方法实施例中一种应用程序的组件检测方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的应用程序的组件检测方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例中，如本申请所公开的应用程序的组件检测方法或装置可以运行在如图8所述的一个或多个服务器中，其中多个服务器可组成为一区块链，进而可以为应用程序的组件检测方法或装置提供数据存储等服务，如本申请的组件检测规则库、组件问题检测结果、组件权限检测结果、预设的组件与基础权限的对应关系和组件检测报告等中的一种或几种可以存储与上述区块链中，而服务器为区块链上的节点。图9是本申请实施例提供的一个区块链系统的结构示意图。如图9所示，服务器可以为分布式系统910中的一个节点920，其中该分布式系统可以为区块链系统，该区块链系统可以是由多个节点通过网络通信的形式连接形成的分布式系统，节点之间可以组成点对点(P2P，Peer To Peer)网络，任意形式的计算机设备，比如服务器、客户端930等电子设备都可以通过加入该点对点网络而成为该区块链系统中的一个节点，其中区块链包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

其中区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新兴应用模式，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成（账户管理）、密钥管理以及用户真实身份和区块链地址对应关系维护（权限管理）等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置（风控审计）；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理（接口适配），然后通过共识算法将业务信息加密（共识管理），在加密之后完整一致的传输至共享账本上（网络通信），并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上（合约注册），根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。

由上述本申请提供的应用程序的组件检测方法、装置、设备、服务器或存储介质的实施例可见，本申请对获取的待检测应用程序的目标安装文件进行解析，得到待检测应用程序的目标解析文件；提取目标解析文件中的组件信息和申请权限信息；根据组件信息以及预设的组件与基础权限的对应关系，对组件信息和申请权限信息进行组件权限检测，得到待检测应用程序的组件权限检测结果；通过组件检测规则库中的组件检测规则对目标解析文件进行组件问题检测，得到待检测应用程序的组件问题检测结果，实现了组件权限和组件问题的自动化检测和排查，节省人力时间成本，在检测过程中无需动态运行程序即可便捷高效的实现组件风险挖掘，有效提升组件检测效率，并且，通过对目标安装文件进行组件权限检测和组件问题检测，有效提高组件检测的精度和准确性。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指示相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。