CN106095458B - 一种应用程序中插件的管理方法和装置 - Google Patents

Abstract

本发明公开了一种应用程序中插件的管理方法和装置，用于减少插件的重复下载，并提高插件的使用效率。本发明实施例提供一种应用程序中插件的管理方法，包括：获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识；根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号；根据第一插件标识扫描本地可用的插件文件；若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型；若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。

Description

一种应用程序中插件的管理方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种应用程序中插件的管理方法和装置。

背景技术

随着APP功能越来越强大，每个功能模块插件化也越来越流行，现在移动设备中应用程序(英文全称：APPlication，英文简称：APP)的功能需要越来越多，并且各种APP占用的存储空间也越来越大，但并不是所有的用户都需要用到所有的功能，所以功能模块插件化就可以很好的解决这个问题。例如，有的功能不常用，如果做成插件的话，就不需要直接放在APP中，而是当用户需要时再去下载，从而减少原始安装包的大小。

在目前的插件管理中，每个插件大多会涉及到更新、下载、安装等过程，用户可以根据使用需要，触发相关功能插件的下载，做到使用什么功能才下什么插件，但是目前APP的插件管理体系只能实现简单的插件下载操作，并且从服务器侧下载插件时通过需要下载最新版本的插件。比如用户在使用视频APP播放视频的时候，可以通过APP从服务器侧下载最新版本的解码库，这种功能就是插件下载。

在目前的插件管理中，每次用户需要使用插件时，都需要通过APP从服务器侧下载插件，这就会出现重复下载插件的情况，从而给用户带来不必要的数据流量浪费，而且在插件的版本有更新的情况下，如果旧版本的插件也可以使用的情况下，用户必须要等新的插件下载完成后才能使用，降低了插件的使用效率。

发明内容

本发明实施例提供了一种应用程序中插件的管理方法和装置，用于减少插件的重复下载，并提高插件的使用效率。

为解决上述技术问题，本发明实施例提供以下技术方案：

第一方面，本发明实施例提供一种应用程序中插件的管理方法，包括：

获取应用程序运行过程中调用的插件请求指令，所述插件请求指令包括：在所述应用程序中需要加载的第一插件对应的第一插件标识；

根据所述插件请求指令从插件管理服务器获取到插件列表，根据所述插件列表确定所述第一插件对应的更新版本号；

根据所述第一插件标识扫描本地可用的插件文件；

若从所述本地可用的插件文件中获取到当前版本号对应的第一插件，根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型；

若所述插件更新类型为所述第一插件不需要更新，则将所述当前版本号对应的第一插件加载到所述应用程序中。

第二方面，本发明实施例还提供一种应用程序中插件的管理装置，包括：

指令获取模块，用于获取应用程序运行过程中调用的插件请求指令，所述插件请求指令包括：在所述应用程序中需要加载的第一插件对应的第一插件标识；

插件列表获取模块，用于根据所述插件请求指令从插件管理服务器获取到插件列表，根据所述插件列表确定所述第一插件对应的更新版本号；

本地扫描模块，用于根据所述第一插件标识扫描本地可用的插件文件；

更新类型获取模块，用于若从所述本地可用的插件文件中获取到当前版本号对应的第一插件，根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型；

插件加载模块，用于若所述插件更新类型为所述第一插件不需要更新，则将所述当前版本号对应的第一插件加载到所述应用程序中。

从以上技术方案可以看出，本发明实施例具有以下优点：

在本发明实施例中，首先获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识，接下来根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号，根据第一插件标识扫描本地可用的插件文件，若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型，若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。本发明实施例中从插件请求指令中获取到需要加载的第一插件标识，通过第一插件的更新版本号和当前版本号进行判断该第一插件的插件更新类型，在第一插件不需要更新的情况下，可以直接将当前版本号对应的第一插件加载到应用程序中，从而实现应用程序中安装使用第一插件，本发明实施例中通过对插件更新类型的判断，可以减少插件的重复下载，不需要等待最新插件的下载完成就可以使用本地可用的插件文件，从而提高了插件的使用效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种应用程序中插件的管理方法的流程方框示意图；

图2为本发明实施例提供的插件的更新版本号的获取流程应用场景示意图；

图3为本发明实施例提供的插件的管理流程应用场景示意图；

图4-a为本发明实施例提供的一种应用程序中插件的管理装置的组成结构示意图；

图4-b为本发明实施例提供的另一种应用程序中插件的管理装置的组成结构示意图；

图4-c为本发明实施例提供的另一种应用程序中插件的管理装置的组成结构示意图；

图4-d为本发明实施例提供的另一种应用程序中插件的管理装置的组成结构示意图；

图4-e为本发明实施例提供的另一种应用程序中插件的管理装置的组成结构示意图；

图4-f为本发明实施例提供的一种插件列表获取模块的组成结构示意图；

图5为本发明实施例提供的应用程序中插件的管理方法应用于终端的组成结构示意图。

具体实施方式

本发明实施例提供了一种应用程序中插件的管理方法和装置，用于减少插件的重复下载，并提高插件的使用效率。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域的技术人员所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

本发明实施例提供的应用程序中插件的管理方法可以实现应用程序中插件的管理维护，能够高效地利用插件资源，并尽可能降低用户等待时间，优化用户体验。以下分别进行详细说明。

本发明应用程序中插件的管理方法的一个实施例，具体可以应用于在终端运行的应用程序中模块插件化的管理场景中，请参阅图1所示，本发明一个实施例提供的应用程序中插件的管理方法，可以包括如下步骤：

101、获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识。

在本发明的一些实施例中，应用程序中的功能模块可以通过插件的形式来实现，从而便于用户使用应用程序。当应用程序在终端中运行时可以调用插件请求指令，以期在应用程序中能够实现特定插件对应的功能。举例说明如下，用户使用视频应用程序，当需要解码某种特定格式的视频文件时，就需要调用插件来解码该视频文件，若在应用程序的安装包中没有加载这种插件，此时就可以代用插件请求指令。在插件请求指令中可以需要携带使用哪种类型的指定插件，本发明实施例中将需要使用的指定插件用“第一插件”来表示，该第一插件的插件标识为第一插件标识，则获取到的插件请求指令中就可以包括第一插件标识。

在本发明的一些实施例中，步骤101获取应用程序运行过程中调用的插件请求指令，具体可以包括如下步骤：

A1、获取应用程序运行过程中调用的至少两个插件请求指令。

其中，若在应用程序运行过程中建立有多个进程，则每个进程都可以调用一个插件请求指令，在应用程序中可以调用到至少两个插件请求指令，每个插件请求指令中可以分别携带一个需要加载的指定插件对应的插件标识，则至少两个插件请求指令可以携带相同的插件标识，也可以携带不同的插件标识，具体此处不做限定。

102、根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号。

在本发明实施例中，获取到插件请求指令之后，可以根据该插件请求指令与插件管理服务器进行交互，从插件管理服务器获取到插件列表，该插件列表中可以包括第一插件对应的更新版本号，其中，更新版本号可以是插件管理服务器为第一插件配置的最新版本号，通常情况下每个插件可以有多个版本号，在插件管理服务器中通常保存有最新的版本号。从插件管理服务器获取到第一插件的更新版本号，从而可以确定该第一插件需要在哪种版本类型下加载安装。另外，在本发明的一些实施例中，插件列表中可以包括第一插件对应的更新版本号之外，还可以包括该更新版本号对应的第一插件的下载地址，该下载地址可以由插件管理服务器通过插件列表的形式向应用程序中插件的管理装置进行下发，该下载地址也可以由插件管理服务器单独下发，此处不做限定。

在本发明的一些实施例中，在前述执行步骤A1的实现场景下，步骤102根据插件请求指令从插件管理服务器获取到插件列表，具体可以包括如下步骤：

B1、若至少两个插件请求指令中都包括有第一插件对应的第一插件标识，则将至少两个插件请求指令聚合为一个插件请求指令，并根据聚合后的一个插件请求指令从插件管理服务器获取到第一插件对应的插件列表。

其中，若获取到了至少两个插件请求指令，则对每个插件请求指令中携带的插件标识进行判断，若至少两个插件请求指令中都包括有第一插件对应的第一插件标识，说明多个进程都需要加载的是第一插件，从而为了简化与插件管理服务器的交互，需要将至少两个插件请求指令聚合为一个插件请求指令，从而保证对于需要加载相同插件的多个插件请求指令只需要和插件管理服务器进行一次交互，即可以根据聚合后的一个插件请求指令从插件管理服务器获取到第一插件对应的插件列表，通过事件回调的方式可以响应多个插件请求指令，以减少对同一个插件的重复请求。

进一步的，在本发明的一些实施例中，至少两个插件请求指令分别包括：发起各个插件请求指令的多个请求标识。即每个插件请求指令对应一个请求标识，例如可以是每个线程发起一个插件请求指令。例如应用程序为视频播放程序，则在浏览器场景下可以发起要求加载插件A的插件请求指令1，同时在游戏展示场景下可以发起要求加载插件A的插件请求指令2，则插件请求指令1和插件请求指令2具有不同的请求标识，但是这些请求指令都要求使用相同的插件A。则步骤B1中的将至少两个插件请求指令聚合为一个插件请求指令，可以包括如下步骤：

B11、从至少两个插件请求指令中分别提取到多个请求标识；

B12、将至少两个插件请求指令中分别携带的第一插件标识和各自的请求标识聚合到一个插件请求指令中。

其中，在确定接收到的至少两个插件请求指令都需要加载第一插件的情况下，可以从每个插件请求指令中提取到一个请求标识，该请求标识可以是线程标识，也可以是用户标识。在至少两个插件请求指令进行聚合时，可以将第一插件标识和各自的请求标识聚合到一个插件请求指令中，从而聚合后的插件请求指令中就可以包括多个请求标识，根据聚合后的一个插件请求指令从插件管理服务器获取第一插件对应的插件列表时，可以实时的通过多个请求标识向请求的触发端反馈与插件管理服务器的交互过程，并在下载到第一插件对应的插件列表后向多个请求标识的触发端反馈下载成功。不限定的是，若第一插件是在静默下载中获取到了插件列表，可以不对插件请求指令做出回调。

103、根据第一插件标识扫描本地可用的插件文件。

在本发明实施例中，获取到插件请求指令之后，可以从该插件请求指令中解析到第一插件标识，然后基于该第一插件标识来扫描应用程序中插件的管理装置中的本地可用的插件文件，即需要扫描本地可用的插件文件中是否存在第一插件，通过扫描本地可用的插件文件为后续第一插件是否需要更新做准备。本地可用的插件文件可以是每次静默下载到的插件文件，这些插件文件可以是应用程序在运行时可用的插件。在本地可用的插件文件中对于每个插件都对应有版本号，将在本地可用的插件文件中记录的版本号定义为当前版本号，以区分从插件列表中确定出的更新版本号。

需要说明的是，在本发明的上述实施例中，步骤102和步骤103之间没有时序上的先后顺序之分，示例性的在图1中以先执行步骤102后执行步骤103为例进行说明，但这只是本发明可能的一种实现。另外，本发明实施例中根据第一插件标识扫描本地可用的插件文件会存在如下的多种情况，有可能从本地可用的插件文件中能够成功扫描到第一插件，也可能从本地可用的插件文件中扫描不到任何版本的第一插件，也可能从本地可用的插件文件中扫描到某个旧版本的第一插件，具体实现情况此处不做限定。

104、若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型。

在本发明实施例中，通过步骤103扫描本地可用的插件文件之后，若成功扫描到第一插件，将从本地可用的插件文件中扫描到的第一插件对应的版本号定义为当前版本号，则通过步骤102中得到的第一插件对应的更新版本号和当前版本号可以对第一插件对应的插件更新类型进行判断。从而确定根据插件请求指令需要在应用程序中加载的第一插件属于哪种类型的更新插件。

需要说明的是，在本发明的上述实施例中，通过第一插件的当前版本号和更新版本号的比较分析，可以确定出该第一插件的更新类型属于哪种。进一步的，本发明实施例中，第一插件对应的插件更新类型可以分为：不需要更新，需要非强制更新和需要强制更新这三种更新类型。举例说明如下，对于不需要更新，则说明从本地可用的插件文件中获取到的第一插件是最新版本的插件，可以直接使用该第一插件，例如更新版本号和当前版本号相同。对于需要非强制更新，则表示本地有可用的插件文件，但是当前版本号不是最新的版本。对于需要强制更新，则表示第一插件必须要更新，无论本地是否有可用插件都需要更新版本号的第一插件。在实际应用中，对于插件的具体更新类型可以结合应用场景来实现，例如有的插件涉及大的功能调整，就可以设置为需要强制更新，有的插件只涉及很小的漏洞修改，就可以设置为需要非强制更新。

在本发明的一些实施例中，步骤103根据第一插件标识扫描本地可用的插件文件之后，除了执行步骤104之外，本发明实施例提供的应用程序中插件的管理方法还可以包括如下步骤：

C1、若从本地可用的插件文件中没有扫描到任何版本号对应的第一插件，则确定第一插件对应的插件更新类型为第一插件需要强制更新；

C2、根据插件列表从插件管理服务器下载更新版本号对应的第一插件；

C3、将更新版本号对应的第一插件加载到应用程序中。

其中，步骤104中描述了扫描到第一插件的处理情况，若从本地可用的插件文件中没有扫描到第一插件，即在本地可用的插件文件中没有存储任何版本号对应的第一插件，则说明在本地中不存在可用的第一插件，此时可以确定第一插件对应的插件更新类型为第一插件需要强制更新。第一插件需要强制更新时，需要与插件服务器进行交互，根据插件列表从插件管理服务器下载更新版本号对应的第一插件，即本地中不存在可用的第一插件时就需要从插件管理服务器来获取到第一插件，从而再将更新版本号对应的第一插件加载到应用程序中，满足应用程序运行时按照插件请求指令来加载第一插件，避免第一插件调用失败。

105、若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。

在本发明实施例中，通过步骤104确定出第一插件对应的插件更新类型之后，若插件更新类型为第一插件不需要更新，则说明从本地可用的插件文件中获取到的第一插件是可以安装到应用程序中来运行的，此时可以将当前版本号对应的第一插件加载到应用程序中，从而免去了从插件管理服务器下载第一插件的过程，用户可以直接使用本地可用的插件文件，并且有效保证本地的插件文件也是可用的，避免插件加载失败，同时免去了用户等待下载插件的复杂过程，提高了插件的使用效率。

在本发明的一些实施例中，步骤104根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型之后，本发明实施例步骤105中描述了第一插件不需要更新时的处理方法，接下来请参阅如下记载的应用程序中插件的管理方法，该应用程序中插件的管理方法还可以包括如下步骤：

D1、若插件更新类型为第一插件需要非强制更新，则将当前版本号对应的第一插件加载到应用程序中；

D2、根据插件列表从插件管理服务器静默下载更新版本号对应的第一插件。

其中，插件更新类型为第一插件需要非强制更新，说明从本地获取到第一插件仍然是可用的，将当前版本号对应的第一插件加载到应用程序中，从而省去用户等待下载更新版本号的插件的时间，快速响应用户的插件加载，在步骤D1的执行过程中还可以执行步骤D2根据插件列表从插件管理服务器静默下载更新版本号对应的第一插件。需要说明的是，步骤D2中的静默下载指的是不影响应用程序加载第一插件的情况下，应用程序中插件的管理装置的后台与插件管理服务器进行交互，以下载到更新版本号对应的第一插件，此时下载完成的更新版本号对应的第一插件可以用作本地可用的插件文件，以使下次再需要加载第一插件时可以通过本地的形式加载成功。

在本发明的前述实施例执行步骤C1至C3，或者执行步骤D1至D2的实现场景下，从插件管理服务器下载到更新版本号对应的第一插件之后，该应用程序中插件的管理方法还可以包括如下步骤：

E1、对更新版本号对应的第一插件进行数据校验；

E2、当更新版本号对应的第一插件校验通过后，使用更新版本号对下载到的更新版本号对应的第一插件进行加密处理。

其中，从插件管理服务器下载到更新版本号对应的第一插件之后，为了避免下载好的第一插件被本地防火墙拦截或者下载过程中的出错，还需要执行步骤E1，对下载到的第一插件进行数据校验，其中数据校验的方式可以有多种，此处不做限定，通过数据校验可以保证下载完成的第一插件的安全性。在数据校验通过后，还可以进一步的执行步骤E2，使用更新版本号对下载到的更新版本号对应的第一插件进行加密处理，以避免于下次需要加载第一插件时通过更新版本号可以快速从本地可用的插件文件中确定出更新版本号对应的第一插件。其中可以使用的加密算法有消息摘要算法第五版(英文全称：Message DigestAlgorithm MD5，英文简称：MD5)来对第一插件的名称进行加密。

进一步的，在本发明的一些实施例中，在执行步骤E1对更新版本号对应的第一插件进行数据校验之后，该应用程序中插件的管理方法还可以包括如下步骤：

E3、当更新版本号对应的第一插件校验没有通过时，从插件备份文件中重新获取第一插件。

其中，在步骤E1之后，数据校验没有通过时可以通过插件备份文件来重新下载，该插件备份文件可以存储在应用程序中插件的管理装置的外部存储器中，从而便于第一插件的再次获取，插件备份文件中存储的第一插件可以是多个版本号对应的第一插件，此时可以从插件备份文件中获取到上述多个版本号中的任意一个版本对应的第一插件。在步骤E3执行之后，还可以再次进行数据校验，直至数据校验通过为止，从插件备份文件中重新获取到第一插件之后，该第一插件可以用作本地可用的插件文件，以保证第一插件能够在下次需要加载时直接从本地加载成功。

进一步的，在本发明的一些实施例中，在执行步骤E2使用更新版本号对下载到的更新版本号对应的第一插件进行加密处理之后，该应用程序中插件的管理方法还可以包括如下步骤：

F1、判断更新版本号对应的第一插件是否是静默下载得到；

F2、若更新版本号对应的第一插件是静默下载得到，则存储加密处理完成后的更新版本号对应的第一插件；

F3、若更新版本号对应的第一插件不是静默下载得到，对加密处理完成后的更新版本号对应的第一插件进行解压缩，并生成解密配置信息。

在本发明的一些实施例中，对更新版本号对应的第一插件进行加密处理之后，若该第一插件是静默下载得到，则说明本次不需要使用更新版本号对应的第一插件，执行步骤F2存储加密处理完成后的更新版本号对应的第一插件，以便于下次使用第一插件时直接解压缩即可，而不需要再次从插件管理服务器下载。若该第一插件不是静默下载得到，则说明本次仍需要使用更新版本号对应的第一插件，执行步骤F3对加密处理完成后的更新版本号对应的第一插件进行解压缩，并生成解密配置信息，例如该解密配置信息可以是一个配置文件，解压下载的第一插件时生成，主要内容是第一插件的文件名和该第一插件的内容和更新版本号生成的MD5值，下次使用第一插件时可以通过该解密配置信息来快速查找到第一插件，而不需要再次从插件管理服务器下载。

通过以上实施例对本发明实施例的描述可知，首先获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识，接下来根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号，根据第一插件标识扫描本地可用的插件文件，若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型，若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。本发明实施例中从插件请求指令中获取到需要加载的第一插件标识，通过第一插件的更新版本号和当前版本号进行判断该第一插件的插件更新类型，在第一插件不需要更新的情况下，可以直接将当前版本号对应的第一插件加载到应用程序中，从而实现应用程序中安装使用第一插件，本发明实施例中通过对插件更新类型的判断，可以减少插件的重复下载，不需要等待最新插件的下载完成就可以使用本地可用的插件文件，从而提高了插件的使用效率。

为便于更好的理解和实施本发明实施例的上述方案，下面举例相应的应用场景来进行具体说明。

本发明实施例提供的应用程序中插件的管理方法，如图2和图3所示，图2为本发明实施例提供的插件的更新版本号的获取流程应用场景示意图，图3为本发明实施例提供的插件的管理流程应用场景示意图；可以实现一套插件备份恢复机制，而且局部修改部分插件，应用程序中插件的管理装置具有插件修改的权限，而且可以实现后台静默下载安装功能，并且通过跨进程管理机制，支持多进程数据插件管理。

本发明实施例可以实现一套插件管理体系，支持插件更新、备份、后台静默下载等功能，下面以浏览器的插件管理来举例说明，请参阅图2和图3所示。

在图2所示的更新版本号的获取流程应用场景中，主要包括如下步骤：

S01、用户请求使用插件。

用户可以发送插件请求指令给终端。

S02、多实例管理器接收指令。

其中，终端的多实例管理器用来管理同种插件，不同线程发来的请求，保证在同一个进程内，插件请求任务唯一，同时还能同步通知所有的事件回调。

举例说明，用户请求某一个特定的插件，会在多实例管理器中查找是否有相同的插件请求在运行，如果有则把消息通知回调加入多实例管理器中，用以同步插件使用状态，如果没有则新起一个插件任务，然后执行步骤S03。

S03、等待后台插件列表下发。

其中，若步骤S03执行超时，可以执行步骤S07，可等待30秒后重新执行S04。后台插件列表可以由插件管理服务器发送给终端。本发明实施例中需要依赖插件管理服务器下发的插件列表，所以这里需要等待一下后台反馈的结果信息，等插件列表下拉成功了，则可以进行下一步S04。

S04、扫描本地可用的插件文件。

在终端本地扫描可用的插件文件，将扫描出的插件对应的版本号定义为当前版本号，扫描本地可用文件可以找到本地可用插件。

本发明实施例中，需要查找本地可用的插件文件，该本地扫描为后面判断是否需要更新做了一个准备，同时提供了一个备选方案，一旦不需要立即更新下载插件的情况下，可以直接利用这里找的插件文件。例如，可以结合数据库中找的安装后的插件文件目录，然后根据这个目录下plugin.dat中记录的数据校验md5值和真实的插件文件进行对比，如果一致，表示插件可用，否则插件不可用，同时即使安装后的插件文件有损，因为有备份插件文件在，依然可以恢复回来，因此可以认定是本地可用插件文件。

S05、获取后台下发的更新版本号。

其中，插件的版本号是指每一个插件对应一个版本号，一旦有更新，版本号同步会修改，保证版本号不重复。

S06、触发执行插件的管理流程。

其中，即执行图3所示的插件管理流程。

S07、提示报错。

在图3所示的插件的管理流程应用场景中，主要包括如下步骤：

S11、获取插件的更新版本号和当前版本号。

其中，通过前述图2所示，获取到插件的更新版本号和当前版本号。

S12、获取插件更新类型。

其中，插件更新类型分为：不需要更新，非强制更新和强制更新3种。不需要更新表示本地插件就是最新的，可以直接使用，非强制更新表示本地有可用的插件，但是不是最新的。强制更新表示必须要更新，本地即使有可用插件也忽略。

S13、判断是否需要更新。

其中，若不需要更新，可以触发执行步骤S22，若需要更新触发执行步骤S14。举例说明，是否需要更新可以通过如下方式实现：终端后台配置强制更新，或者本地没有可用插件文件，以及本地可用插件文件的当前版本号和插件列表中下发的更新版本号不一致，在上述情况下，都可以确定需要更新。

S14、有静默下载好的插件。

其中，若插件预先下载完成，可以触发执行步骤S22，若没有下载好则触发执行步骤S15。举例说明，如果需要更新，则先检查插件是否有静默下载好的插件，有则直接解压安装，没有的话，非强制更新，则先加载本地可用插件，并静默下载要更新的插件，下载完成后根据对下载好的插件进行加密处理，便于下次快速查找，同时不解压安装，以待下次使用插件的时候安装，以浏览器来说需要等到重启浏览器的时候才会使用。如果是强制安装，则直接启动下载功能，同时通知用户下载进度，下载完成后先进行加密处理，然后再解压安装，详见后续内容的说明。

S15、是否强制更新。

其中，判断插件的更新类型是否需要强制更新，对于强制更新可以执行步骤S18，对于非强制更新可以执行步骤S16和步骤S17。举例说明如下，强制更新可以由终端后台要求强制更新，或者在终端本地没有可用插件时要求强制更新。

举例说明如下，获取终端更新下来的插件的更新类型，这个类型有2种：强制更新和非强制更新，另外从本地扫描得到的可用插件文件也有一个当前版本号，这个当前版本号和插件列表中下发的更新版本号对比，如果一致，则最终的更新结果是不需要更新，如果版本不一致，则会根据插件管理服务器给定的更新结果来觉得最终的更新类型，如果本地没有找到可用插件文件，则更新结果必然是强制更新。

S16、加载本地可用插件文件。

S17、触发后台静默下载插件文件。

其中，可以通过终端的后台从插件管理服务器下载插件文件。

S18、触发浏览器服务器(英文名称：server)端下载。

其中，浏览器server有一个单独的server进程，用来保证数据唯一性，比如插件下载功能就需要在server端实现，防止同一个插件，不同进程同时下载。例如，浏览器server端从插件管理服务器中获取插件列表，然后根据获取到的插件列表，触发浏览器server端下载到正确的插件文件。

S19、下载完成后数据校验。

其中，S18和S17执行完成后可以执行步骤S19。数据校验可以通过数据校验算法来完成插件的校验。

S20、做MD5重命名处理，方便下次快速访问。

其中，MD5为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。

S21、是否来自静默下载。

若来自静默下载，则执行步骤S22，若不是来自静默下载，则执行步骤S23。举例说明，终端里面会记录当前的插件任务是否是静默的，本身是否是静默的，调用层使用的时候就可以确定插件是否来自静默下载。

S22、解压，并生成解密配置文件。

其中，步骤S22执行之后触发执行步骤S24。例如，解密配置文件可以是plugin.dat文件，用于校验解压后的插件文件是否正确。举例说明，如果插件不需要更新，则直接加载即可。

S23、完成，下次使用插件时直接解压缩，不需要重新下载。

S24、加载并使用插件。

需要说明的是，在本发明实施例中，所有启动下载的过程多是统一在server端处理的，这样就避免了多进程下载同一个插件可能会出现同步等问题。例如，如果A和B同时请求下载一个插件，那么A和B就会同时修改同一个插件文件，这样文件的内容可能会乱掉。

通过本发明实施例提供的前述方法，可以有效的利用已有的插件备份文件，同时考虑插件各种更新类型，减少用户插件下载安装等待时间，增加静默下载功能，可以优化用户体验，提前让用户使用插件功能，支持多实例管理，并且多进程使用插件也能保证稳定性和唯一性。高效的数据查找和数据校验功能，保证用户使用的安全性和高效性，增强了用户体验。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

为便于更好的实施本发明实施例的上述方案，下面还提供用于实施上述方案的相关装置。

请参阅图4-a所示，本发明实施例提供的一种应用程序中插件的管理装置400，可以包括：指令获取模块401、插件列表获取模块402、本地扫描模块403、更新类型获取模块404、插件加载模块405，其中，

指令获取模块401，用于获取应用程序运行过程中调用的插件请求指令，所述插件请求指令包括：在所述应用程序中需要加载的第一插件对应的第一插件标识；

插件列表获取模块402，用于根据所述插件请求指令从插件管理服务器获取到插件列表，根据所述插件列表确定所述第一插件对应的更新版本号；

本地扫描模块403，用于根据所述第一插件标识扫描本地可用的插件文件；

更新类型获取模块404，用于若从所述本地可用的插件文件中获取到当前版本号对应的第一插件，根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型；

插件加载模块405，用于若所述插件更新类型为所述第一插件不需要更新，则将所述当前版本号对应的第一插件加载到所述应用程序中。

在本发明的一些实施例中，请参阅图4-b所示，所述应用程序中插件的管理装置400还包括：插件下载模块406，其中，

所述更新类型获取模块404，还用于所述本地扫描模块403根据所述第一插件标识扫描本地可用的插件文件之后，若从所述本地可用的插件文件中没有扫描到任何版本号对应的第一插件，则确定所述第一插件对应的插件更新类型为所述第一插件需要强制更新；

所述插件下载模块406，用于根据所述插件列表从所述插件管理服务器下载更新版本号对应的第一插件；

所述插件加载模块405，还用于将所述更新版本号对应的第一插件加载到所述应用程序中。

在本发明的一些实施例中，请参阅图4-c所示，所述应用程序中插件的管理装置400还包括：插件静默下载模块407，其中，

所述插件加载模块405，还用于所述更新类型获取模块404根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型之后，若所述插件更新类型为所述第一插件需要非强制更新，则将所述当前版本号对应的第一插件加载到所述应用程序中；

所述插件静默下载模块407，用于根据所述插件列表从所述插件管理服务器静默下载更新版本号对应的第一插件。

在本发明的一些实施例中，请参阅图4-d所示，相对于图4-b或图4-c所示，图4-d中以相对于图4-b为例进行说明，所述应用程序中插件的管理装置400还包括：数据校验模块408和加密模块409，其中，

所述数据校验模块408，用于所述插件静默下载模块或所述插件下载模块406从所述插件管理服务器下载到更新版本号对应的第一插件之后，对所述更新版本号对应的第一插件进行数据校验；

所述加密模块409，还用于当所述更新版本号对应的第一插件校验通过后，使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理。

进一步的，在本发明的一些实施例中，请参阅图4-e所示，相对于图4-d所示，所述应用程序中插件的管理装置400还包括：下载类型判断模块410、插件存储模块411和插件解压缩模块412，其中，

所述下载类型判断模块410，用于所述加密模块409使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理之后，判断所述更新版本号对应的第一插件是否是静默下载得到；

所述插件存储模块411，用于若所述更新版本号对应的第一插件是静默下载得到，则存储加密处理完成后的更新版本号对应的第一插件；

所述插件解压缩模块412，用于若所述更新版本号对应的第一插件不是静默下载得到，对加密处理完成后的更新版本号对应的第一插件进行解压缩，并生成解密配置信息。

在本发明的一些实施例中，所述插件静默下载模块407或所述插件下载模块406，还用于所述数据校验模块408对所述更新版本号对应的第一插件进行数据校验之后，当所述更新版本号对应的第一插件校验没有通过时，从插件备份文件中重新获取第一插件。

在本发明的一些实施例中，所述指令获取模块401，具体用于获取应用程序运行过程中调用的至少两个插件请求指令；

如图4-f所示，所述插件列表获取模块402，包括：指令聚合模块4021和指令执行模块4022，其中，

所述指令聚合模块4021，用于若所述至少两个插件请求指令中都包括有第一插件对应的第一插件标识，则将至少两个插件请求指令聚合为一个插件请求指令；

所述指令执行模块4022，用于根据聚合后的一个插件请求指令从插件管理服务器获取到所述第一插件对应的插件列表。

进一步的，所述至少两个插件请求指令分别包括：发起各个插件请求指令的多个请求标识；所述指令聚合模块4022，具体用于从所述至少两个插件请求指令中分别提取到多个请求标识；将所述至少两个插件请求指令中分别携带的第一插件标识和各自的请求标识聚合到一个插件请求指令中。

通过以上对本发明实施例的描述可知，首先获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识，接下来根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号，根据第一插件标识扫描本地可用的插件文件，若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型，若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。本发明实施例中从插件请求指令中获取到需要加载的第一插件标识，通过第一插件的更新版本号和当前版本号进行判断该第一插件的插件更新类型，在第一插件不需要更新的情况下，可以直接将当前版本号对应的第一插件加载到应用程序中，从而实现应用程序中安装使用第一插件，本发明实施例中通过对插件更新类型的判断，可以减少插件的重复下载，不需要等待最新插件的下载完成就可以使用本地可用的插件文件，从而提高了插件的使用效率。

本发明实施例还提供了另一种终端，如图5所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point ofSales，销售终端)、车载电脑等任意终端设备，以终端为手机为例：

图5示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图5，手机包括：射频(Radio Frequency，RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity，WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解，图5中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图5对手机的各个构成部件进行具体的介绍：

RF电路1010可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1080处理；另外，将设计上行的数据发送给基站。通常，RF电路1010包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，LNA)、双工器等。此外，RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication，GSM)、通用分组无线服务(General Packet RadioService，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1030可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031，输入单元1030还可以包括其他输入设备1032。具体地，其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041，可选的，可以采用液晶显示器(LiquidCrystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1041。进一步的，触控面板1031可覆盖显示面板1041，当触控面板1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图5中，触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1050，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1060、扬声器1061，传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出；另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出处理器1080处理后，经RF电路1010以发送给比如另一手机，或者将音频数据输出至存储器1020以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图5示出了WiFi模块1070，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1080是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1080可包括一个或多个处理单元；优选的，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

手机还包括给各个部件供电的电源1090(比如电池)，优选的，电源可以通过电源管理系统与处理器1080逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明实施例中，该终端所包括的处理器1080还具有控制执行以上由终端执行的应用程序中插件的管理方法流程。

通过以上对本发明实施例的描述可知，首先获取应用程序运行过程中调用的插件请求指令，插件请求指令包括：在应用程序中需要加载的第一插件对应的第一插件标识，接下来根据插件请求指令从插件管理服务器获取到插件列表，根据插件列表确定第一插件对应的更新版本号，根据第一插件标识扫描本地可用的插件文件，若从本地可用的插件文件中获取到当前版本号对应的第一插件，根据第一插件对应的更新版本号和当前版本号获取第一插件对应的插件更新类型，若插件更新类型为第一插件不需要更新，则将当前版本号对应的第一插件加载到应用程序中。本发明实施例中从插件请求指令中获取到需要加载的第一插件标识，通过第一插件的更新版本号和当前版本号进行判断该第一插件的插件更新类型，在第一插件不需要更新的情况下，可以直接将当前版本号对应的第一插件加载到应用程序中，从而实现应用程序中安装使用第一插件，本发明实施例中通过对插件更新类型的判断，可以减少插件的重复下载，不需要等待最新插件的下载完成就可以使用本地可用的插件文件，从而提高了插件的使用效率。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

综上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照上述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对上述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (12)

1.一种应用程序中插件的管理方法，其特征在于，包括：

获取应用程序运行过程中调用的插件请求指令，所述插件请求指令包括：在所述应用程序中需要加载的第一插件对应的第一插件标识；

根据所述插件请求指令从插件管理服务器获取到插件列表，根据所述插件列表确定所述第一插件对应的更新版本号；

根据所述第一插件标识扫描本地可用的插件文件；

若从所述本地可用的插件文件中获取到当前版本号对应的第一插件，根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型；

若所述插件更新类型为所述第一插件不需要更新，则将所述当前版本号对应的第一插件加载到所述应用程序中；

其中，所述根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型之后，所述方法还包括：

若所述插件更新类型为所述第一插件需要非强制更新，则将所述当前版本号对应的本地的第一插件加载到所述应用程序中；

根据所述插件列表从所述插件管理服务器静默下载更新版本号对应的第一插件，以使得后续当需要更新第一插件时，通过安装静默下载得到的第一插件实现更新。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一插件标识扫描本地可用的插件文件之后，所述方法还包括：

若从所述本地可用的插件文件中没有扫描到任何版本号对应的第一插件，则确定所述第一插件对应的插件更新类型为所述第一插件需要强制更新；

根据所述插件列表从所述插件管理服务器下载更新版本号对应的第一插件；

将所述更新版本号对应的第一插件加载到所述应用程序中。

3.根据权利要求2所述的方法，其特征在于，从所述插件管理服务器下载到更新版本号对应的第一插件之后，所述方法还包括：

对所述更新版本号对应的第一插件进行数据校验；

当所述更新版本号对应的第一插件校验通过后，使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理。

4.根据权利要求3所述的方法，其特征在于，所述使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理之后，所述方法还包括：

判断所述更新版本号对应的第一插件是否是静默下载得到；

若所述更新版本号对应的第一插件是静默下载得到，则存储加密处理完成后的更新版本号对应的第一插件；

若所述更新版本号对应的第一插件不是静默下载得到，对加密处理完成后的更新版本号对应的第一插件进行解压缩，并生成解密配置信息。

5.根据权利要求1至2中任一项所述的方法，其特征在于，所述获取应用程序运行过程中调用的插件请求指令，包括：

获取应用程序运行过程中调用的至少两个插件请求指令；

所述根据所述插件请求指令从插件管理服务器获取到插件列表，包括：

若所述至少两个插件请求指令中都包括有第一插件对应的第一插件标识，则将所述至少两个插件请求指令聚合为一个插件请求指令，并根据聚合后的一个插件请求指令从插件管理服务器获取到所述第一插件对应的插件列表。

6.根据权利要求5所述的方法，其特征在于，所述至少两个插件请求指令分别包括：发起各个插件请求指令的多个请求标识；

所述将所述至少两个插件请求指令聚合为一个插件请求指令，包括：

从所述至少两个插件请求指令中分别提取到多个请求标识；

将所述至少两个插件请求指令中分别携带的第一插件标识和各自的请求标识聚合到一个插件请求指令中。

7.一种应用程序中插件的管理装置，其特征在于，包括：

指令获取模块，用于获取应用程序运行过程中调用的插件请求指令，所述插件请求指令包括：在所述应用程序中需要加载的第一插件对应的第一插件标识；

插件列表获取模块，用于根据所述插件请求指令从插件管理服务器获取到插件列表，根据所述插件列表确定所述第一插件对应的更新版本号；

本地扫描模块，用于根据所述第一插件标识扫描本地可用的插件文件；

更新类型获取模块，用于若从所述本地可用的插件文件中获取到当前版本号对应的第一插件，根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型；

插件加载模块，用于若所述插件更新类型为所述第一插件不需要更新，则将所述当前版本号对应的第一插件加载到所述应用程序中；

所述应用程序中插件的管理装置还包括：插件静默下载模块，其中，

所述插件加载模块，还用于所述更新类型获取模块根据所述第一插件对应的更新版本号和当前版本号获取所述第一插件对应的插件更新类型之后，若所述插件更新类型为所述第一插件需要非强制更新，则将所述当前版本号对应的本地的第一插件加载到所述应用程序中；

所述插件静默下载模块，用于根据所述插件列表从所述插件管理服务器静默下载更新版本号对应的第一插件，以使得后续当需要更新第一插件时，通过安装静默下载得到的第一插件实现更新。

8.根据权利要求7所述的装置，其特征在于，所述应用程序中插件的管理装置还包括：插件下载模块，其中，

所述更新类型获取模块，还用于所述本地扫描模块根据所述第一插件标识扫描本地可用的插件文件之后，若从所述本地可用的插件文件中没有扫描到任何版本号对应的第一插件，则确定所述第一插件对应的插件更新类型为所述第一插件需要强制更新；

所述插件下载模块，用于根据所述插件列表从所述插件管理服务器下载更新版本号对应的第一插件；

所述插件加载模块，还用于将所述更新版本号对应的第一插件加载到所述应用程序中。

9.根据权利要求7或8所述的装置，其特征在于，所述应用程序中插件的管理装置还包括：数据校验模块和加密模块，其中，

所述数据校验模块，用于所述插件静默下载模块或所述插件下载模块从所述插件管理服务器下载到更新版本号对应的第一插件之后，对所述更新版本号对应的第一插件进行数据校验；

所述加密模块，还用于当所述更新版本号对应的第一插件校验通过后，使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理。

10.根据权利要求9所述的装置，其特征在于，所述应用程序中插件的管理装置还包括：下载类型判断模块、插件存储模块和插件解压缩模块，其中，

所述下载类型判断模块，用于所述加密模块使用所述更新版本号对下载到的更新版本号对应的第一插件进行加密处理之后，判断所述更新版本号对应的第一插件是否是静默下载得到；

所述插件存储模块，用于若所述更新版本号对应的第一插件是静默下载得到，则存储加密处理完成后的更新版本号对应的第一插件；

所述插件解压缩模块，用于若所述更新版本号对应的第一插件不是静默下载得到，对加密处理完成后的更新版本号对应的第一插件进行解压缩，并生成解密配置信息。

11.根据权利要求7至8中任一项所述的装置，其特征在于，所述指令获取模块，具体用于获取应用程序运行过程中调用的至少两个插件请求指令；

所述插件列表获取模块，包括：指令聚合模块和指令执行模块，其中，

所述指令聚合模块，用于若所述至少两个插件请求指令中都包括有第一插件对应的第一插件标识，则将所述至少两个插件请求指令聚合为一个插件请求指令；

所述指令执行模块，用于根据聚合后的一个插件请求指令从插件管理服务器获取到所述第一插件对应的插件列表。

12.根据权利要求11所述的装置，其特征在于，所述至少两个插件请求指令分别包括：发起各个插件请求指令的多个请求标识；

所述指令聚合模块，具体用于从所述至少两个插件请求指令中分别提取到多个请求标识；将所述至少两个插件请求指令中分别携带的第一插件标识和各自的请求标识聚合到一个插件请求指令中。