CN113342600A - 一种程序依赖插件的监测方法及装置 - Google Patents

Abstract

本申请实施例提供一种程序依赖插件的监测方法及装置，可用于测试安全技术领域，方法包括：首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号。本申请可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

Description

一种程序依赖插件的监测方法及装置

技术领域

本申请涉及测试安全技术领域及其他领域，具体涉及程序依赖插件的监测方法及装置。

背景技术

在现代前端领域，通常使用npm作为前端工程的依赖管理工具。

npm在包依赖管理上，存在开发依赖和生产依赖两种，npm包管理工具会在工程打包时，无条件打包生产依赖插件，按实际使用打包开发依赖插件(如：代码压缩工具包、单元测试包、代码格式化包、服务器包)。开发依赖包中，提供了工程编译打包的性能提升工具，开发过程中应引入打包优化工具，提升工程在打包过程中的效率。

在实际开发过程中，存在大量的开发依赖错误放置于生产依赖中，导致降低代码可维护性、编译打包机器资源浪费、打包效率降低、打包结果文件内存大、部署无效程序等问题。缺少引入编译打包性能提升工具，则会降低工程打包的运行效率、导致机器资源浪费。

可见，工程中依赖的合理引用，对于工程全流程的每个环节都至关重要。

对于一个企业，管理一个或多个庞大的工程，需要一个自动化的监测工具替代重复的人力劳作，对各个工程中依赖插件的引入进行全面收集、分析、归类、反馈、管理工作。

发明内容

针对现有技术中的问题，本申请提供一种程序依赖插件的监测方法及装置，首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号。本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

本发明的一方面，提供一种程序依赖插件的监测方法，包括：

响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

根据所述待监测依赖插件的状态信息，输出对应的监测信号。

在优选的实施例中，所述对待监测的依赖插件进行检查，生成待监测依赖插件的状态信息，包括：

对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

在优选的实施例中，所述对待监测的依赖插件进行归类检查，生成归类检查结果，包括：

获取所述待监测依赖插件当前所处类别信息；

根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

在优选的实施例中，还包括：建立所述预设的分类规则库。

在优选的实施例中，所述建立所述预设的分类规则库，包括：

设置导入分类规则库中所有依赖插件的作用域类别；

根据所述依赖插件的作用域类别，生成所述分类规则库。

在优选的实施例中，所述依赖插件的特征信息发生变化，包括：

依赖插件的注册入口程序发生修改、分类规则库发生变化。

本发明的又一方面，提供一种程序依赖插件的监测装置，包括：

依赖插件状态生成模块，响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

监测信号输出模块，根据所述待监测依赖插件的状态信息，输出对应的监测信号。

在优选的实施例中，依赖插件状态生成模块，包括：

依赖插件检查单元，对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

状态信息生成单元，若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

在优选的实施例中，所述依赖插件检查单元，包括：

当前类别获取单元，获取所述待监测依赖插件当前所处类别信息；

理想类别生成单元，根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

检查结果确定单元，对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

在优选的实施例中，还包括：分类规则库建立模块，建立所述预设的分类规则库。

在优选的实施例中，所述分类规则库建立模块，包括：

作用域类别设置单元，设置导入分类规则库中所有依赖插件的作用域类别；

分类规则库生成单元，根据所述依赖插件的作用域类别，生成所述分类规则库。

本发明的又一方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的程序依赖插件的监测方法。

本发明的又一方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的程序依赖插件的监测方法。

由上述技术方案可知，本申请提供的一种程序依赖插件的监测方法，方法包括：首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号。本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

附图说明

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

图1是一种程序依赖插件的监测方法流程示意图。

图2是依赖插件状态生成流程示意图。

图3是依赖插件归类检查流程示意图。

图4是分类规则库建立流程示意图。

图5是程序依赖插件的监测装置结构示意图。

图6是本申请实施例中的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请公开的程序依赖插件的监测方法及装置可用于测试安全技术领域，也可用于除测试安全技术领域之外的任意领域，本申请公开的程序依赖插件的监测方法及装置的应用领域不做限定。

在现代前端领域，通常使用npm作为前端工程的依赖管理工具。

npm在包依赖管理上，存在开发依赖和生产依赖两种，npm包管理工具会在工程打包时，无条件打包生产依赖插件，按实际使用打包开发依赖插件(如：代码压缩工具包、单元测试包、代码格式化包、服务器包)。开发依赖包中，提供了工程编译打包的性能提升工具，开发过程中应引入打包优化工具，提升工程在打包过程中的效率。

在实际开发过程中，存在大量的开发依赖错误放置于生产依赖中，导致降低代码可维护性、编译打包机器资源浪费、打包效率降低、打包结果文件内存大、部署无效程序等问题。缺少引入编译打包性能提升工具，则会降低工程打包的运行效率、导致机器资源浪费。

可见，工程中依赖的合理引用，对于工程全流程的每个环节都至关重要。

对于一个企业，管理一个或多个庞大的工程，需要一个自动化的监测工具替代重复的人力劳作，对各个工程中依赖插件的引入进行全面收集、分析、归类、反馈、管理工作。

针对现有技术中的问题，本申请提供一种程序依赖插件的监测方法及装置，首先首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号，从而本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

下面结合附图对本发明提供的程序依赖插件的监测方法及装置进行详细说明。

在具体的实施例中，本申请提供一种程序依赖插件的监测方法，如图1，具体步骤包括：

S1:响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；

具体的，对于整个程序的依赖插件进行自动监测以使得项目程序达到最优和最简并且及时发现依赖插件的使用问题，是程序开发中非常重要的步骤。在具体的实施例中，对依赖插件的检查是由一个监测触发信号触发的，所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成。可以理解的是，若依赖插件的特征信息发生变化，包括：依赖插件的注册入口程序发生修改、分类规则库发生变化，都会使得依赖插件的分类发生变化，故当依赖插件的特征信息发生变化时，需要对程序中的依赖插件进行检查，以便及时发现问题和解决问题。另一方面，若依赖插件没有变更的情况，则进行常态化的定时巡检，以便发现问题，其中定时巡检的时长间隔可以根据系统的处理器使用情况实际设定。

在具体的实施例中，所述对待监测的依赖插件进行检查，生成待监测依赖插件的状态信息，如图2，包括：

S11:对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

具体的，对依赖插件的检查主要包括了三类检查：归类检查、合理性检查和优化检查。其中归类检查是对依赖插件的类别进行检查，在具体的实施例中，对于程序中的依赖插件根据其功能主要分为两大类：生产类和开发类。生产类的依赖插件是与业务相关的依赖插件以及与程序编译打包相关的依赖插件，开发类的依赖插件是程序员在程序开发过程中需要使用到的依赖插件，一般不需要打包入项目的发布版本中。在具体的实施例中，所述对待监测的依赖插件进行归类检查，生成归类检查结果，如图3，包括：

S111:获取所述待监测依赖插件当前所处类别信息；

具体的，在依赖插件导入程序项目中时，会将其放置在插件对应的类别列表中。例如在nmp依赖插件管理中，会将项目中所涉及的所有依赖插件均被放在package.json文件中，文件的具体如下所示：

其中dependencies中含有的是生产类依赖插件，devDependencies为开发类依赖插件。通过查找待监测的依赖插件所处的类别获取其当前所处类别信息。

S112:根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

具体的，在依赖插件的导入注册时，极易将本是生产类的依赖插件归入开发类中，所以需要根据预设的分类规则来对待监测的依赖插件进行重新分类，得到其理想的类别。可以理解，所述分类规则库中包括的分类规则越精准，则分类的效果越好。在具体的实施例中，当对待监测插件进行分类时，首先将依赖插件的各个特征属性与分类规则库中所有的规则进行匹配，若命中某规则，则将该插件归类为规则所对应的分类中。例如一个分类规则为：若插件的作用域类别为production，则将其分类至生产类中。待监测的依赖插件的作用域类别正好为production，则与上述分类规则相吻合，故将其归入生产类中。

在具体的实施例中，所述建立所述预设的分类规则库，如图4，包括：

S1121:设置导入分类规则库中所有依赖插件的作用域类别；

具体的，将依赖插件的作用域属性即scope设置为不同类别，以区分其功能。例如scope可以设置为production(业务类)，dev(开发类)，compile(编译类)，test(测试类)和package(打包类)。对于属性的设置是根据其功能来设置的，开发人员对于每个依赖插件的功能是清晰的，故可以准确进行作用域类别的设置。

S1122:根据所述依赖插件的作用域类别，生成所述分类规则库。

具体的，根据作用域的类别，生成分类规则，例如作用域类别包括production(业务类)，dev(开发类)，compile(编译类)，test(测试类)和package(打包类)，则分类规则可以为若作用域类别为production，则分类为生产类；若作用域类别为dev，则分类为开发类；若作用域类别为compile，则分类为开发类；若作用域类别为test，则分类为开发类；若作用域类别为package，则分类为生产类。

S113:对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

在具体的实施例中，对比所述当前所处类别信息与理想类别信息，若两者不一致，说明该依赖插件的类别出现冲突，存在分类错误的风险，故将归类检查结果确定为异常。

在具体的实施例中，除了归类检查之外还有对依赖插件的合理性检查和优化检查。其中合理性检查是指若工程中出现不合理的插件注册，则将合理性检查结果确定为异常。优化检查是指若工程中未引用归类中的优化依赖插件注册，则将优化检查结果确定为异常。

S12:若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

具体的，若归类检查结果、合理性检查结果和优化检查结果中有一个为异常，说明对应的依赖插件存在异常，需要进行进一步干预。故将待监测依赖插件的状态信息确定为异常，以使后续流程获取该状态信息并进行进一步处理。

S2:根据所述待监测依赖插件的状态信息，输出对应的监测信号。

在具体的实施例中，若状态信息为异常，则输出一监测预警信号，以提示进行人工干预。也可以为若状态为正常，则输出一监测正常信号，当没有正常信号输出时则表示出现异常。

结合一具体的实施场景对本发明作进一步的说明。

某开发人员，于前端工程中引用了前端单元测试依赖插件karma，并错误放置与生产依赖列表中。提交代码，触发依赖插件监测。通过归类检查发现前端单元测试插件karma为开发依赖，则将该依赖插件配置状态信息确定为异常，根据该状态信息输出一个监测预警信号，以使开发人员进行进一步干预。

由以上描述可知，本发明提供的一种程序依赖插件的监测方法，首先首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号，从而本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

从软件层面来说，本申请提供一种用于执行所述程序依赖插件的监测方法中全部或部分内容的程序依赖插件的监测装置的实施例，参见图5，所述程序依赖插件的监测装置具体包含有如下内容：

依赖插件状态生成模块，响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

监测信号输出模块，根据所述待监测依赖插件的状态信息，输出对应的监测信号。

由以上描述可知，本发明提供的程序依赖插件的监测装置，本装置首先首先响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；然后根据所述待监测依赖插件的状态信息，输出对应的监测信号。本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

在具体的实施例中，本申请提供一种程序依赖插件的监测装置，用于执行步骤包括：

S1:响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；

具体的，对于整个程序的依赖插件进行自动监测以使得项目程序达到最优和最简并且及时发现依赖插件的使用问题，是程序开发中非常重要的步骤。在具体的实施例中，对依赖插件的检查是由一个监测触发信号触发的，所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成。可以理解的是，若依赖插件的特征信息发生变化，包括：依赖插件的注册入口程序发生修改、分类规则库发生变化，都会使得依赖插件的分类发生变化，故当依赖插件的特征信息发生变化时，需要对程序中的依赖插件进行检查，以便及时发现问题和解决问题。另一方面，若依赖插件没有变更的情况，则进行常态化的定时巡检，以便发现问题，其中定时巡检的时长间隔可以根据系统的处理器使用情况实际设定。

在具体的实施例中，所述依赖插件状态生成模块，用于执行步骤包括：

S11:对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

具体的，对依赖插件的检查主要包括了三类检查：归类检查、合理性检查和优化检查。其中归类检查是对依赖插件的类别进行检查，在具体的实施例中，对于程序中的依赖插件根据其功能主要分为两大类：生产类和开发类。生产类的依赖插件是与业务相关的依赖插件以及与程序编译打包相关的依赖插件，开发类的依赖插件是程序员在程序开发过程中需要使用到的依赖插件，一般不需要打包入项目的发布版本中。在具体的实施例中，所述依赖插件检查单元，用于执行步骤包括：

S111:获取所述待监测依赖插件当前所处类别信息；

具体的，在依赖插件导入程序项目中时，会将其放置在插件对应的类别列表中。例如在nmp依赖插件管理中，会将项目中所涉及的所有依赖插件均被放在package.json文件中，文件的具体如下所示：

其中dependencies中含有的是生产类依赖插件，devDependencies为开发类依赖插件。通过查找待监测的依赖插件所处的类别获取其当前所处类别信息。

S112:根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

具体的，在依赖插件的导入注册时，极易将本是生产类的依赖插件归入开发类中，所以需要根据预设的分类规则来对待监测的依赖插件进行重新分类，得到其理想的类别。可以理解，所述分类规则库中包括的分类规则越精准，则分类的效果越好。在具体的实施例中，当对待监测插件进行分类时，首先将依赖插件的各个特征属性与分类规则库中所有的规则进行匹配，若命中某规则，则将该插件归类为规则所对应的分类中。例如一个分类规则为：若插件的作用域类别为production，则将其分类至生产类中。待监测的依赖插件的作用域类别正好为production，则与上述分类规则相吻合，故将其归入生产类中。

在具体的实施例中，所述分类规则库建立模块，用于执行步骤包括：

S1121:设置导入分类规则库中所有依赖插件的作用域类别；

具体的，将依赖插件的作用域属性即scope设置为不同类别，以区分其功能。例如scope可以设置为production(业务类)，dev(开发类)，compile(编译类)，test(测试类)和package(打包类)。对于属性的设置是根据其功能来设置的，开发人员对于每个依赖插件的功能是清晰的，故可以准确进行作用域类别的设置。

S1122:根据所述依赖插件的作用域类别，生成所述分类规则库。

具体的，根据作用域的类别，生成分类规则，例如作用域类别包括production(业务类)，dev(开发类)，compile(编译类)，test(测试类)和package(打包类)，则分类规则可以为若作用域类别为production，则分类为生产类；若作用域类别为dev，则分类为开发类；若作用域类别为compile，则分类为开发类；若作用域类别为test，则分类为开发类；若作用域类别为package，则分类为生产类。

S113:对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

在具体的实施例中，对比所述当前所处类别信息与理想类别信息，若两者不一致，说明该依赖插件的类别出现冲突，存在分类错误的风险，故将归类检查结果确定为异常。

在具体的实施例中，除了归类检查之外还有对依赖插件的合理性检查和优化检查。其中合理性检查是指若工程中出现不合理的插件注册，则将合理性检查结果确定为异常。优化检查是指若工程中未引用归类中的优化依赖插件注册，则将优化检查结果确定为异常。

S12:若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

具体的，若归类检查结果、合理性检查结果和优化检查结果中有一个为异常，说明对应的依赖插件存在异常，需要进行进一步干预。故将待监测依赖插件的状态信息确定为异常，以使后续流程获取该状态信息并进行进一步处理。

S2:根据所述待监测依赖插件的状态信息，输出对应的监测信号。

在具体的实施例中，若状态信息为异常，则输出一监测预警信号，以提示进行人工干预。也可以为若状态为正常，则输出一监测正常信号，当没有正常信号输出时则表示出现异常。

结合一具体的实施场景对本发明作进一步的说明。

某开发人员，于前端工程中引用了前端单元测试依赖插件karma，并错误放置与生产依赖列表中。提交代码，触发依赖插件监测。通过归类检查发现前端单元测试插件karma为开发依赖，则将该依赖插件配置状态信息确定为异常，根据该状态信息输出一个监测预警信号，以使开发人员进行进一步干预。

由以上描述可知，本发明提供的一种程序依赖插件的监测装置，包括依赖插件状态生成模块，响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；监测信号输出模块，根据所述待监测依赖插件的状态信息，输出对应的监测信号。本发明可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

从硬件层面来说，本申请提供一种用于实现程序依赖插件的监测方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

图6为本申请实施例的电子设备9600的系统构成的示意框图。如图6所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图6是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在一实施例中，程序依赖插件的监测方法功能可以被集成到中央处理器中。

其中，中央处理器可以被配置为进行如下控制：

S1:响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

S2:根据所述待监测依赖插件的状态信息，输出对应的监测信号。

从上述描述可知，本申请实施例提供的电子设备，可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

在另一个实施方式中，程序依赖插件的监测装置可以与中央处理器9100分开配置，例如可以程序依赖插件的监测装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现程序依赖插件的监测方法功能。

如图6所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图6中所示的所有部件；此外，电子设备9600还可以包括图6中没有示出的部件，可以参考现有技术。

如图6所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的程序依赖插件的监测方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的程序依赖插件的监测方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

S1:响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

S2:根据所述待监测依赖插件的状态信息，输出对应的监测信号。

从上述描述可知，本申请实施例提供的计算机可读存储介质，可以自动化监测工程中涉及的依赖插件，替代人为检查，极大节省了人力成本。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1.一种程序依赖插件的监测方法，其特征在于，包括：

响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

根据所述待监测依赖插件的状态信息，输出对应的监测信号。

2.根据权利要求1所述的一种程序依赖插件的监测方法，其特征在于，所述对待监测的依赖插件进行检查，生成待监测依赖插件的状态信息，包括：

对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

3.根据权利要求2所述的一种程序依赖插件的监测方法，其特征在于，所述对待监测的依赖插件进行归类检查，生成归类检查结果，包括：

获取所述待监测依赖插件当前所处类别信息；

根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

4.根据权利要求3所述的一种程序依赖插件的监测方法，其特征在于，还包括：建立所述预设的分类规则库。

5.根据权利要求4所述的一种程序依赖插件的监测方法，其特征在于，所述建立所述预设的分类规则库，包括：

设置导入分类规则库中所有依赖插件的作用域类别，所述作用域类别包括：生产类别和开发类别；

根据所述依赖插件的作用域类别，生成所述分类规则库。

6.根据权利要求1所述的一种程序依赖插件的监测方法，其特征在于，所述依赖插件的特征信息发生变化，包括：

依赖插件的注册入口程序发生修改、分类规则库发生变化。

7.一种程序依赖插件的监测装置，其特征在于，包括：

依赖插件状态生成模块，响应于一监测触发信号，对待监测依赖插件进行检查，生成待监测依赖插件的状态信息；所述监测触发信号在所述依赖插件的特征信息发生变化之后产生，或者定时生成；

监测信号输出模块，根据所述待监测依赖插件的状态信息，输出对应的监测信号。

8.根据权利要求7所述的一种程序依赖插件的监测装置，其特征在于，依赖插件状态生成模块，包括：

依赖插件检查单元，对待监测的依赖插件进行归类检查、合理性检查和优化检查中的至少一个，生成对应的检查结果；

状态信息生成单元，若所述归类检查结果、合理性检查结果和优化检查结果中至少一个为异常，则将所述待监测依赖插件的状态信息确定为异常。

9.根据权利要求8所述的一种程序依赖插件的监测装置，其特征在于，所述依赖插件检查单元，包括：

当前类别获取单元，获取所述待监测依赖插件当前所处类别信息；

理想类别生成单元，根据一预设的分类规则库，对所述待监测依赖插件进行分类，生成对应的理想类别信息；

检查结果确定单元，对比所述当前所处类别信息与理想类别信息，若两者不一致，则确定对应的归类检查结果为异常。

10.根据权利要求7所述的一种程序依赖插件的监测装置，其特征在于，还包括：分类规则库建立模块，建立所述预设的分类规则库。

11.根据权利要求10所述的一种程序依赖插件的监测装置，其特征在于，所述分类规则库建立模块，包括：

作用域类别设置单元，设置导入分类规则库中所有依赖插件的作用域类别；

分类规则库生成单元，根据所述依赖插件的作用域类别，生成所述分类规则库。

12.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至6任一项所述的程序依赖插件的监测方法。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6任一项所述的程序依赖插件的监测方法。

Images