插件管理方法、装置、电子设备及计算机可读存储介质与流程

本发明涉及互联网技术领域，尤其涉及一种插件管理方法、装置、电子设备及计算机可读存储介质。

背景技术：

在安卓(android)开发中，插件化和热修复的话题越来越多的被大家提及，同时随着技术的迭代，各种框架的发展更新，插件化和热修复的框架似乎已经日趋成熟，许多开发者也把这两项技术运用到实际开发协作和正式的产品当中。例如，某些应用程序针对不同功能(例如登录功能、拍照功能、推送功能)，实现插件化，即一项功能对应一个插件。

其中，在实现本申请过程中，发明人发现保险行业销售渠道多样，组织架构庞大，业务体系复杂，市面上提供给保险代理人使用的应用程序具有繁琐的业务功能。而且，不同类型的保险代理人使用此种应用程序的业务功能不同，因此，保险代理人在使用此种应用程序时，需要从应用程序提供的众多业务功能中查找自己需要的业务功能，非常不方便。

并且，目前提供给保险代理人使用的应用程序，在安装到客户端上后，会在客户端中存储该应用程序提供的全部业务功能的程序，但是保险代理人使用时却只需要使用其中部分业务，从而浪费了存储空间。

技术实现要素：

本发明实施例提供一种插件管理方法、装置、电子设备及计算机可读存储介质，以解决现有技术中应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

第一方面，本发明实施例提供了一种插件管理方法，应用于服务器，所述方法包括：

接收客户端发送的第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

第二方面，本发明的实施例提供了一种插件管理方法，应用于客户端，所述方法包括：

向服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件；

安装所述第一业务插件。

第三方面，本发明的实施例提供了一种插件管理装置，应用于服务器，所述装置包括：

第一接收模块，用于接收客户端发送的第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

第一发送模块，用于在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

第四方面，本发明的实施例提供了一种插件管理装置，应用于客户端，所述装置包括：

第二发送模块，用于向服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

第二接收模块，用于在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件；

安装模块，用于安装所述第一业务插件。

第五方面，本发明的实施例提供了一种插件管理系统，包括服务器和客户端；

通过所述客户端向所述服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

通过所述服务器接收所述第一请求，并在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件；

通过所述客户端接收所述第一业务插件，并安装所述第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

第六方面，本发明的实施例提供了一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述第一方面所述的插件管理方法的步骤，或者实现上述第二方面所述的插件管理方法的步骤。

第七方面，本发明的实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的插件管理方法的步骤，或者实现上述第二方面所述的插件管理方法的步骤。

本发明实施例中，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

附图说明

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

图1为本发明实施例提供的插件管理方法的步骤流程图之一；

图2为本发明实施例提供的插件管理方法的步骤流程图之二；

图3为本发明实施例中用户在服务器中上传宿主app和插件的操作流程示意图；

图4为本发明实施例中客户端更新插件的流程示意图；

图5为本发明实施例在服务器中上传业务插件的显示界面示意图；

图6为本发明实施例提供的插件管理装置的结构框图之一；

图7为本发明实施例提供的插件管理装置的结构框图之二；

图8为本发明实施例提供的电子设备的结构框图。

具体实施方式

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

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

在本发明的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

参见图1，本发明一实施例提供了一种插件管理方法，应用于服务器，所述方法可以包括以下步骤：

步骤101：接收客户端发送的第一请求。

其中，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息。所述第一请求用于请求服务器中存储的与第一类别对应，且标识信息为所述第一标识信息的业务插件。所述第一标识信息可以为业务插件的名称或者编号等。其中，一个业务插件的标识信息唯一标识一种业务插件。此处需要说明的是，多个业务插件即使版本不同，但名称或编号相同，仍然属于一种业务插件。

另外，第一应用程序的用户的类别是预先根据用户对第一应用程序中的业务的需求划分的，即不同类别的用户对第一应用程序提供的业务的需求不同。

可选的，在第一应用程序为保险行业的某一款应用程序时，第一应用程序的用户可以按照用户所属的公司、保险销售渠道、用户在公司所处的职位等信息进行分类。则本发明的实施例中，针对一个版本业务插件，分别存在一个类别。例如用户在服务器中上传保险销售行业的一个版本的业务插件时，可在图5所示的界面中选择对应的分公司、渠道、选择是否为内勤等，并输入版本号码。

步骤102：在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件。

所述客户端接收到第一业务插件后，在所述客户端上安装所述第一业务插件。

其中，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。另外，将实现一项业务所涉及的代码封装为一个插件，则可以获得该业务的业务插件。

本发明实施例中，在服务器中预先存储有业务插件，以及各个业务插件的标识信息和与标识信息对应的类别。其中，一个标识信息对应哪一个类别，则该标识信息所标识的业务插件属于哪一个类别。

其中，可选的，服务器中还存储有业务插件的版本信息，则在步骤101之前，所述方法还包括：

接收用户在服务器中上传的第四业务插件，并接收用户在服务器中输入的第四业务插件的第三标识信息、与该标识信息对应的第二类别(即第四业务插件所属的类别)、第四业务插件的版本信息；

在服务器中已存储有与第二类别对应，且标识信息为第三标识信息的业务插件，且该业务插件的版本低于第四业务插件的版本时，利用第四业务插件替换该业务插件；

在服务器中未存储与第二类别对应，且标识信息为第三标识信息的业务插件时，则在服务器中存储第四业务插件、第三标识信息、第二类别和第四业务插件的版本信息。

由此可知，用户可以在服务器中上传业务插件，并输入业务插件的标识信息、所属类别、版本信息，以便服务器可以向客户端提供该业务插件。

由上述可知，本发明的实施例，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

具体的，例如针对一个保险销售行业的应用程序，用户在登录界面会有选择分公司和保险销售渠道的入口，完成登录后可以根据其所在的分公司和保险销售渠道去服务器下载对应的插件，而非该分公司和该渠道的用户，则不会去下载该插件，从而实现了了只针对分公司和若干渠道下发业务插件。

可选的，所述服务器中还存储有业务插件的版本信息；

在所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新的情况下，向所述客户端发送第一业务插件之后，所述方法还包括：

与所述客户端进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新；

其中，所述第二业务插件为，所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新后的业务插件。

由此可知，服务器中存储的各个业务插件的版本可能会进行更新，则可以通过客户端与服务器的交互，利用服务器中已更新的最新版本的业务插件，对客户端上安装的业务插件进行更新，从而使得客户端的用户可以及时使用最新版本的业务插件。

可选的，所述与所述客户端进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新，包括：

接收所述客户端发送的第二请求，所述第二请求用于指示请求所述第二业务插件的第一版本信息；

向所述客户端发送所述第一版本信息；

在所述客户端上安装的所述第一业务插件的版本，低于所述第一版本信息所表示的版本时，接收所述客户端发送的第三请求，所述第三请求中携带有所述第一标识信息和所述第一版本信息；

向所述客户端发送所述第二业务插件。

其中，客户端首次登录第一应用程序之后，后续每一次重新登录之后，可以在接收到用户在第一应用程序的显示界面中显示的第二目标业务的第二操作时，触发向服务器发送第二请求的步骤，以向服务器请求服务器中已存储的与第二目标业务的业务插件所属类别对应，且标识信息为第二目标业务的业务插件的标识信息的业务插件的版本信息，从而在客户端确定该版本低于客户端中已安装的第二目标业务的业务插件时，向服务器请求第二目标业务的最新版本的业务插件，以便对本地已安装的第二目标业务的业务插件进行更新。

可选的，所述服务器中还存储有与用户的类别对应的应用程序和应用程序的版本信息，以及与应用程序绑定的公钥，所述公钥用于标识应用程序；

在所述服务器中存储的与所述第一类别对应，且与第一公钥绑定的应用程序进行了版本更新的情况下，接收客户端发送的第一请求之前，所述方法还包括：

与所述客户端进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新；

其中，所述第一公钥为所述客户端中预先存储的用于标识所述第一应用程序的公钥，所述第二应用程序为，所述服务器中存储的与所述第一类别对应，且与所述第一公钥绑定的应用程序进行了版本更新后的应用程序。

其中，在服务器中，一个公钥与一个应用程序绑定，则该公钥用于标识该应用程序。并且，一个公钥用于标识一种应用程序，即使名称相同的不同版本的应用程序，也属于一种应用程序，因此，在服务器中，与名称相同的不同版本的应用程序绑定的公钥为同一个公钥。

另外，客户端接收到第二应用程序后，会利用第二应用程序对第一应用程序进行更新。

由此可知，本发明的实施例中，用户也可以在服务器中上传应用程序，并在服务器中记录应用程序所属的类别、应用程序的版本信息，以及与应用程序绑定的公钥，以便于提供给客户端使用。其中，服务器中存储的各个应用程序的版本可能会进行更新，则可以通过客户端与服务器的交互，利用服务器中已更新的最新版本的应用程序，对客户端上安装的应用程序进行更新，从而使得客户端的用户可以及时使用最新版本的应用程序。

可选的，所述与所述客户端进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新，包括：

接收所述客户端发送的所述第一应用程序的登录请求，所述登录请求中携带有所述第一应用程序的用户的第一类别、所述第一应用程序的版本信息和所述第一公钥；

在所述第一应用程序的版本，低于所述第二应用程序的版本时，向所述客户端发送所述第二应用程序。

由此可知，可以在客户端向服务器请求登录第一应用程序的过程中，携带客户端上安装的第一应用程序的版本信息，以使得服务器可以在客户端上安装的第一应用程序的版本低于其中存储的，与第一类别对应，且与第一公钥绑定的第二应用程序的版本时，向客户端推送第二应用程序，以便客户端对第一应用程序进行更新。

此外，在客户端退出第一类别的用户登录后，若客户端在第一应用程序中以第二类别登录，但是服务器中存储的第二类别对应的应用程序的版本与第一应用程序的版本不一致，则此种情况下，在客户端登录过程中，还可以在登录请求中携带第一应用程序的版本信息、第一应用程序的第二标识信息、所请求登录的用户的第二类别，以便于服务器可以向客户端推送与第二类别对应，且标识信息为第二标识的应用程序，进而使得客户端将第一应用程序更新为与第二类别对应的应用程序。

其中，在服务器中存储的一个应用程序的过程可以包括如下步骤h1～h2：

步骤h1：服务器接收用户在服务器中上传的第四应用程序，并接收用户在服务器中输入的第三类别(即第四应用程序所属的类别)、第四应用程序的版本信息；

步骤h2：在服务器中存储第四应用程序、第三类别和第四应用程序的版本信息，并将第四应用程序与其中预先存储的第二公钥绑定，所述第二公钥为用于标识所述第四应用程序的公钥。

由此可知，用户可以在服务器中上传应用程序，并输入应用程序的版本信息、所属类别，以便服务器可以向客户端提供该应用程序。

其中，本发明的实施例中，用户在服务器中上传一个应用程序时，直接对其进行存储，并不利用上传的这个应用程序替换服务器中已存储的其他版本的应用程序。从而使得服务器中可以存在同一个应用程序的多个版本。例如a1类别的用户对应x1版本的b应用程序，a2类别的用户可以对应x2版本的b应用程序。

进一步的，本发明的实施例中，服务器中还可以存储业务插件所属的应用程序，则一个版本的业务插件可以对应多个版本的应用程序。

由此可见，传统技术中只支持插件和宿主的单一绑定，一个最新的宿主只能对应若干个最高版本的插件，但是在本平台中插件也具有生命周期，一个最高版本的插件可以对应若干个老版本的宿主，这就为老版本宿主插件功能的更新提供了便利。

可选的，所述第一公钥的生成过程包括：

接收所述客户端发送的所述第一应用程序的第二标识信息；

为所述第二标识信息分配第一公钥，并发送给所述客户端。

其中，客户端接收到第一公钥后，会集成一个插件化框架(replugin)，从而在应用程序内部实现插件下载请求的逻辑。

由上述可知，服务器中可以存储不同种类的应用程序，每一种应用程序绑定有一个公钥。其中，服务器中还存储有不同种类的业务插件，而业务插件是应用在应用程序中的，因此，业务插件与应用程序之间存储一定的对应关系。本发明的实施例中，在服务器中，采用公钥来标识不同种类的应用程序，则还可以采用业务插件与公钥绑定的方式，建立业务插件与应用程序之间的对应关系。即将业务插件与用于标识该业务插件所应用的应用程序的公钥绑定，则一个业务插件与哪一个公钥绑定，则该业务插件属于哪一个公钥所标识的应用程序。

从而在客户端与服务器进行交互，以在第一应用程序中安装一个业务插件或者更新一个业务插件时，可以依据用于标识第一应用程序的公钥在服务器中查找属于第一应用程序的业务插件。

此外，在服务器中储有多种应用程序时，在服务器中会存在多个目标区域，每一个目标区域对应有一个公钥，一个目标区域中存储多个版本的一种应用程序，以及属于与这些版本的应用程序的业务插件，且一个目标区域内存储的应用程序和业务插件分别均与该目标区域对应的公钥绑定。则客户端与服务器进行交互时，可以通过公钥找到某个应用程序或者某个业务插件的存储区域的入口。

综上所述，本发明的实施例中，用户在服务器中上传应用程序和业务插件(以保险行业的应用程序和插件为例，用户在服务器中上传应用程序(即宿主app)和插件的操作流程可如图3所示)之后，在服务器中会按照表1所示的对应关系对应用程序和业务插件进行存储。其中，一个公钥对应一种应用程序。

表1应用程序与业务插件的对应关系

例如第一公钥对应的应用程序的名称为“xxx”，则在客户端中首次安装名称为“xxx”的第一应用程序后，会在客户端中存储第一公钥。

此后，在该客户端上用户首次登陆时，会在登录界面中输入该用户所属第一类别，从而由客户端将第一类别、第一公钥、第一应用程序的第版本信息，携带在登录请求中发送给服务器。其中，服务器根据第一公钥、第一类别，可以在其中存储的应用程序中查找第二应用程序，若第二应用程序的版本低于第一应用程序的版本，则服务器将第二应用程序推送给客户端，以使得客户端利用第二应用程序对第一应用程序进行更新，更新完成后，客户端会自动登录，并在成功登录后显示第二应用程序的首页面。

其中，在第二应用程序的首页面和首页面之后的其他页面上会显示第二应用程序可以提供的各项业务，当用户点击第一目标业务时，客户端则会将第一公钥、第一类别、第一目标业务的业务插件的第一标识信息携带在第一请求中，发送给服务器。服务器根据第一公钥、第一类别和第一标识信息，可以在其中存储的应用程序中查找到第一业务插件，从而将第一业务插件发送给客户端进行安装。客户端安装第一业务插件之后，则会进入第一目标业务的显示界面。

另外，在客户端安装第一业务插件之后，每一次用户以第一类别登录时，若用户点击了客户端上显示的第一目标业务，则客户端都会向服务器请求此时服务器中存储的与第一公钥绑定，且属于第一类别下的第一目标业务的业务插件的版本信息，并在服务器返回给客户端的版本信息所表示的版本，低于客户端已安装的第一类别下的第一目标业务的业务插件的版本时，客户端会重新向服务器请求与第一公钥绑定，且属于第一类别下的第一目标业务的最新版本业务插件，并进行更新。

此处，需要说明的是，例如客户端以第一类别登录第一版本的“xxx”应用程序后，客户端上会安装第一业务插件和第二业务插件，但是第一类别的用户的退出后，若以第二类别的用户登录第一版本的“xxx”应用程序，则客户端上会安装第三业务插件。其中，前面虽然安装了第一业务插件和第二业务插件，但是在第二类别的用户登录第一版本的“xxx”应用程序后，其显示界面上，并不会显示第一业务插件和第二业务插件入口。并且，退出第一类别的用户的登录之后，并不会删除第一业务插件和第二业务插件，从而使得后续重新以第一类别登录第一版本的“xxx”应用程序时，不需要重新安装第一业务插件和第二业务插件。

另外，本发明的实施例中，对于一个业务插件的安装与更新，本发明实施例中设置为非静默更新，即以人工触发的方式进行安装与更新。其中，因为业务插件的安装和更新需要“登录的用户的类别”，而静默更新需要用户自动登录，若果用户不自动登录，则无法进行更新。并且，若设计业务插件的静默更新，则在自动登录之后，客户端的前台会显示应用程序的首页，后台会自动更新静默更新的业务插件，在此过程中若用户对首页中实施操作，由于静默更新插件的更新过程，会导致应用程序卡顿。

但是，对于一个应用程序的其他不涉及用户的类别的插件，则可以设置为静默更新。此种插件，则可以在应用程序启动时，自动进行更新，并在更新完成后，进入应用程序的登录页面，或者更新完成后利用之前的登录信息自动登录，并在登录成功后显示应用程序的首页面。

具体地，一个app的静默插件和非静默插件的下载流程可如图4所示。即客户端安装一个app后，点击app的图标，启动app时可以下载对应该app版本的静默更新插件，登录后在首页点击业务功能，即可下载对应业务功能的插件，然后就可以进入该业务功能模块的首页。

参见图2，本发明一实施例提供了一种插件管理方法，应用于客户端，所述方法可以包括以下步骤：

步骤201：向服务器发送第一请求。

其中，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息。所述第一请求用于请求服务器中存储的与第一类别对应，且标识信息为所述第一标识信息的业务插件。所述第一标识信息可以为业务插件的名称或者编号等。其中，一个业务插件的标识信息唯一标识一种业务插件。此处需要说明的是，多个业务插件即使版本不同，但名称或编号相同，仍然属于一种业务插件。

另外，第一应用程序的用户的类别是预先根据用户对第一应用程序中的业务的需求划分的，即不同类别的用户对第一应用程序提供的业务的需求不同。

可选的，在第一应用程序为保险行业的某一款应用程序时，第一应用程序的用户可以按照用户所属的公司、保险销售渠道、用户在公司所处的职位等信息进行分类。

步骤202：在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件。

所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。另外，将实现一项业务所涉及的代码封装为一个插件，则可以获得该业务的业务插件。

本发明实施例中，在服务器中预先存储有业务插件，以及各个业务插件的标识信息和与标识信息对应的类别。其中，一个标识信息对应哪一个类别，则该标识信息所标识的业务插件属于哪一个类别。

由上述可知，本发明的实施例，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

步骤203：安装所述第一业务插件。

可选的，所述向服务器发送第一请求包括：

接收用户输入的所述第一类别；

在接收到用户对所述第一应用程序的显示界面中显示的第一目标业务的第一操作时，将所述第一目标业务的业务插件的标识信息，作为所述第一标识信息，与所述第一类别一同携带在所述第一请求中，发送给所述服务器。

其中，用户可以在第一应用程序的登录界面中输入所述第一类别。上述第一操作，可以为对第一应用程序的显示界面中显示的第一目标业务的点击操作。

由上述可知，本发明的实施例中，客户端可以在登录第一应用程序的过程中，将第一应用程序的用户的第一类别发送给服务器。其中，客户端登录成功之后，会进入第一应用程序的首页面，在首页面中会显示不同业务，此时，用户点击哪项业务，客户端则会向服务器请求下载第一类别下的哪个业务插件。

可选的，所述服务器中还存储有业务插件的版本信息；

在所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新的情况下，安装所述第一业务插件之后，所述方法还包括：

与所述服务器进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新；

其中，所述第二业务插件为，所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新后的业务插件。

由此可知，服务器中存储的各个业务插件的版本可能会进行更新，则可以通过客户端与服务器的交互，利用服务器中已更新的最新版本的业务插件，对客户端上安装的业务插件进行更新，从而使得客户端的用户可以及时使用最新版本的业务插件。

可选的，所述与所述服务器进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新，包括：

在接收到用户对所述第一应用程序的显示界面中显示的第一目标业务的第二操作时，向所述服务器发送第二请求，所述第二请求用于指示请求所述第二业务插件的第一版本信息，所述第一目标业务为所述第一业务插件对应的业务；

接收所述服务器发送的所述第一版本信息；

在所述客户端上安装的所述第一业务插件的版本，低于所述第一版本信息所表示的版本时，向所述服务器发送第三请求，所述第三请求中携带有所述第一标识信息和所述第一版本信息；

接收所述服务器发送的所述第二业务插件；

利用所述第二业务插件，对所述客户端上安装的所述第一业务插件，进行更新。

其中，客户端首次登录第一应用程序之后，后续每一次重新登录之后，可以在接收到用户在第一应用程序的显示界面中显示的第二目标业务的第二操作时，触发向服务器发送第二请求的步骤，以向服务器请求服务器中已存储的与第二目标业务的业务插件所属类别对应，且标识信息为第二目标业务的业务插件的标识信息的业务插件的版本信息，从而在客户端确定该版本低于客户端中已安装的第二目标业务的业务插件时，向服务器请求第二目标业务的最新版本的业务插件，以便对本地已安装的第二目标业务的业务插件进行更新。

可选的，所述服务器中还存储有与用户的类别对应的应用程序和应用程序的版本信息，以及与应用程序绑定的公钥，所述公钥用于标识应用程序；在所述服务器中存储的与所述第一类别对应，且与第一公钥绑定的应用程序进行了版本更新的情况下，向服务器发送第一请求之前，所述方法还包括：

与所述服务器进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新；

其中，所述第一公钥为所述客户端中预先存储的用于标识所述第一应用程序的公钥，所述第二应用程序为，所述服务器中存储的与所述第一类别对应，且与所述第一公钥绑定的应用程序进行了版本更新后的应用程序。

其中，在服务器中，一个公钥与一个应用程序绑定，则该公钥用于标识该应用程序。并且，一个公钥用于标识一种应用程序，即使名称相同的不同版本的应用程序，也属于一种应用程序，因此，在服务器中，与名称相同的不同版本的应用程序绑定的公钥为同一个公钥。

由此可知，本发明的实施例中，用户也可以在服务器中上传应用程序，并在服务器中记录应用程序所属的类别、应用程序的版本信息，以及与应用程序绑定的公钥，以便于提供给客户端使用。其中，服务器中存储的各个应用程序的版本可能会进行更新，则可以通过客户端与服务器的交互，利用服务器中已更新的最新版本的应用程序，对客户端上安装的应用程序进行更新，从而使得客户端的用户可以及时使用最新版本的应用程序。

可选的，所述与所述服务器进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新包括：

向服务器发送所述第一应用程序的登录请求，所述登录请求中携带有所述第一应用程序的用户的第一类别、所述第一应用程序的版本信息和所述第一公钥；

在所述第一应用程序的版本，低于所述第二应用程序的版本时，接收所述服务器发送的所述第二应用程序；

利用所述第二应用程序，对所述客户端上安装的所述第一应用程序进行更新。

由此可知，可以在客户端向服务器请求登录第一应用程序的过程中，携带客户端上安装的第一应用程序的版本信息，以使得服务器可以在客户端上安装的第一应用程序的版本低于其中存储的，与第一类别对应，且与第一公钥绑定的第二应用程序的版本时，向客户端推送第二应用程序，以便客户端对第一应用程序进行更新。

可选的，所述第一公钥的生成过程包括：

向所述服务器发送所述第一应用程序的第二标识信息；

接收所述服务器为所述第二标识信息分配的第一公钥，并进行存储。

其中，客户端接收到第一公钥后，会集成一个replugin框架，从而在应用程序内部实现插件下载请求的逻辑。

由上述可知，服务器中可以存储不同种类的应用程序，每一种应用程序绑定有一个公钥。其中，服务器中还存储有不同种类的业务插件，而业务插件是应用在应用程序中的，因此，业务插件与应用程序之间存储一定的对应关系。本发明的实施例中，在服务器中，采用公钥来标识不同种类的应用程序，则还可以采用业务插件与公钥绑定的方式，建立业务插件与应用程序之间的对应关系。即将业务插件与用于标识该业务插件所应用的应用程序的公钥绑定，则一个业务插件与哪一个公钥绑定，则该业务插件属于哪一个公钥所标识的应用程序。

从而在客户端与服务器进行交互，以在第一应用程序中安装一个业务插件或者更新一个业务插件时，可以依据用于标识第一应用程序的公钥在服务器中查找属于第一应用程序的业务插件。

此外，在服务器中储有多种应用程序时，在服务器中会存在多个目标区域，每一个目标区域对应有一个公钥，一个目标区域中存储多个版本的一种应用程序，以及属于与这些版本的应用程序的业务插件，且一个目标区域内存储的应用程序和业务插件分别均与该目标区域对应的公钥绑定。则客户端与服务器进行交互时，可以通过公钥找到某个应用程序或者某个业务插件的存储区域的入口。

由上述对服务器侧的插件管理方法，以及客户端侧的插件管理方法的综合描述可知，以对保险行业的应用程序的插件管理为例，本发明实施例的插件管理方法，相对于传统技术对插件的管理方法的不同之处，可如表2所示。

表2与传统插件管理方法的对比

由此可见，本发明的实施例，一个最高版本的插件可以对应若干个老版本的宿主app。并且，应用在保险销售行业，可以支持不同公司和不同保险销售渠道分别下发插件。

此外，还需要说明的是，本发明的实施例，相对传统技术而言，还针对业务实现了插件化，即传统技术中一般只是针对不同功能(例如登录功能、拍照功能、推送功能)，实现插件化，即一项功能对应一个插件。而本发明的实施例针对一个业务(例如考勤、组发、区拓、投保、理赔)，实现插件化，即一个业务对应一个插件。

以区拓功能模块的插件化为例，区拓功能作为代理人拜访客户，区部拓展，是保险销售行业迭代最频繁，使用人数最多的功能。其中，在设计区拓模块功能时，会充分考虑客户数据操作，客户关系维护等细节。而针对区拓功能实现插件化，不仅能够方便区扩功能的迭代更新，而且能够很好地实现与客户家族模块、客户保单模块等插件的独立。

并且，针对业务实现插件化，还具有如下优点：

第一方面，在技术层面上将业务功能从宿主app的剥离和抽取，从而生成业务插件，使得插件之间的通信，插件和宿主的通信更为简洁，侧面上降低了代码冗余，提高了架构的复用。

第二方面，针对业务实现插件化，使得业务功能更新时，只需要更新对应的业务插件即可，从而在用户体验层面上降低了宿主app的更新频率，节省了用户流量，也提高了修复线上漏掉的响应速度。

第三方面，针对业务实现插件化，能够在安全层面上实现业务和技术架构的独立，即技术架构放在宿主app，业务数据放在业务插件，则可以针对不同的业务插件使用不同的安全策略。

以上介绍了本发明实施例提供的插件管理方法，下面将结合附图介绍本发明实施例提供的插件管理装置。

参见图6，本发明实施例还提供了一种插件管理装置，应用于服务器，所述插件管理装置包括：

第一接收模块601，用于接收客户端发送的第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

第一发送模块602，用于在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

可选的，所述服务器中还存储有业务插件的版本信息；在所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新的情况下，所述插件管理装置还包括：

第一交互模块，用于与所述客户端进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新；

其中，所述第二业务插件为，所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新后的业务插件。

可选的，所述第一交互模块包括：

第一请求接收子模块，用于接收所述客户端发送的第二请求，所述第二请求用于指示请求所述第二业务插件的第一版本信息；

版本信息发送子模块，用于向所述客户端发送所述第一版本信息；

第二请求接收子模块，用于在所述客户端上安装的所述第一业务插件的版本，低于所述第一版本信息所表示的版本时，接收所述客户端发送的第三请求，所述第三请求中携带有所述第一标识信息和所述第一版本信息；

业务插件发送子模块，用于向所述客户端发送所述第二业务插件。

可选的，所述服务器中还存储有与用户的类别对应的应用程序和应用程序的版本信息，以及与应用程序绑定的公钥，所述公钥用于标识应用程序；

在所述服务器中存储的与所述第一类别对应，且与第一公钥绑定的应用程序进行了版本更新的情况下，所述插件管理装置还包括：

第二交互模块，用于与所述客户端进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新；

其中，所述第一公钥为所述客户端中预先存储的用于标识所述第一应用程序的公钥，所述第二应用程序为，所述服务器中存储的与所述第一类别对应，且与所述第一公钥绑定的应用程序进行了版本更新后的应用程序。

可选的，所述第二交互模块包括：

第三请求接收子模块，用于接收所述客户端发送的所述第一应用程序的登录请求，所述登录请求中携带有所述第一应用程序的用户的第一类别、所述第一应用程序的版本信息和所述第一公钥；

应用程序发送子模块，用于在所述第一应用程序的版本，低于所述第二应用程序的版本时，向所述客户端发送所述第二应用程序。

可选的，所述插件管理装置还包括：

第三接收模块，用于接收所述客户端发送的所述第一应用程序的第二标识信息；

第三发送模块，用于为所述第二标识信息分配第一公钥，并发送给所述客户端。

由上述可知，本发明的实施例，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

参见图7，本发明实施例还提供了一种插件管理装置，应用于客户端，所述插件管理装置包括：

第二发送模块701，用于向服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

第二接收模块702，用于在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件；

安装模块703，用于安装所述第一业务插件。

可选的，所述第二发送模块701包括：

输入接收子模块，用于接收用户输入的所述第一类别；

第一请求发送子模块，用于在接收到用户对所述第一应用程序的显示界面中显示的第一目标业务的第一操作时，将所述第一目标业务的业务插件的标识信息，作为所述第一标识信息，与所述第一类别一同携带在所述第一请求中，发送给所述服务器。

可选的，所述服务器中还存储有业务插件的版本信息；在所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新的情况下，所述插件管理装置还包括：

第三交互模块，用于与所述服务器进行交互，根据第二业务插件的版本信息，对所述客户端上安装的所述第一业务插件进行更新；

其中，所述第二业务插件为，所述服务器中存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件进行了版本更新后的业务插件。

可选的，所述第三交互模块包括：

第二请求发送子模块，用于在接收到用户对所述第一应用程序的显示界面中显示的第一目标业务的第二操作时，向所述服务器发送第二请求，所述第二请求用于指示请求所述第二业务插件的第一版本信息，所述第一目标业务为所述第一业务插件对应的业务；

版本信息接收子模块，用于接收所述服务器发送的所述第一版本信息；

第三请求发送子模块，用于在所述客户端上安装的所述第一业务插件的版本，低于所述第一版本信息所表示的版本时，向所述服务器发送第三请求，所述第三请求中携带有所述第一标识信息和所述第一版本信息；

业务插件接收子模块，用于接收所述服务器发送的所述第二业务插件；

第一更新子模块，用于利用所述第二业务插件，对所述客户端上安装的所述第一业务插件，进行更新。

可选的，所述服务器中还存储有与用户的类别对应的应用程序和应用程序的版本信息，以及与应用程序绑定的公钥，所述公钥用于标识应用程序；

在所述服务器中存储的与所述第一类别对应，且与第一公钥绑定的应用程序进行了版本更新的情况下所述插件管理装置还包括：

第四交互模块，用于与所述服务器进行交互，根据第二应用程序的版本信息，对所述客户端上安装的所述第一应用程序进行更新；

其中，所述第一公钥为所述客户端中预先存储的用于标识所述第一应用程序的公钥，所述第二应用程序为，所述服务器中存储的与所述第一类别对应，且与所述第一公钥绑定的应用程序进行了版本更新后的应用程序。

可选的，所述第四交互模块包括：

第四请求发送子模块，用于向服务器发送所述第一应用程序的登录请求，所述登录请求中携带有所述第一应用程序的用户的第一类别、所述第一应用程序的版本信息和所述第一公钥；

应用程序接收子模块，用于在所述第一应用程序的版本，低于所述第二应用程序的版本时，接收所述服务器发送的所述第二应用程序；

第二更新子模块，用于利用所述第二应用程序，对所述客户端上安装的所述第一应用程序进行更新。

可选的，所述插件管理装置还包括：

第四发送模块，用于向所述服务器发送所述第一应用程序的第二标识信息；

第四接收模块，用于接收所述服务器为所述第二标识信息分配的第一公钥，并进行存储。

由上述可知，本发明的实施例，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。另一方面，本发明的实施例还提供了一种插件管理系统，包括服务器和客户端；

通过所述客户端向所述服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

通过所述服务器接收所述第一请求，并在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件；

通过所述客户端接收所述第一业务插件，并安装所述第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

由此可知，本发明的实施例，在服务器中预先存储业务插件，以及各个业务插件的标识信息和与标识信息对应的类别，从而在服务器接收到客户端发送的第一请求(携带有第一应用程序的用户的第一类别和所要请求的业务插件的第一标识信息)，且经服务器判定服务器中存储的与第一标识信息对应的类别，与第一请求中携带的第一类别相同时，该服务器才向该客户端下发其所请求的业务插件。由此可知，本发明的实施例，客户端向服务器请求属于其用户的类别的业务插件，服务器才会向其下发相应的业务插件，即客户端的用户若不属于其所请求的业务插件在服务器中对应的类别，该客户端则无法从服务器下载其所请求的业务插件。

因此，本发明的实施例，按照用户的分类，对业务插件进行分类管理，从而使得属于某一分类的用户只能从服务器获得其所属类别下的业务插件，达到了为客户端的应用程序只安装用户需要的业务插件的目的，从而解决了应用程序安装所有的插件，但用户只需要使用该应用程序的部分业务时，带来的存储空间浪费，且不便于用户查找所需使用的业务的问题。

另一方面，本发明实施例还提供了一种电子设备，包括存储器、处理器、总线以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述所述的插件管理方法中的步骤。其中，所述电子设备可以为服务器或者客户端。

举个例子如下，图8示出了一种电子设备的实体结构示意图。

如图8所示，该电子设备可以包括：处理器(processor)810、通信接口(communicationsinterface)820、存储器(memory)830和通信总线840，其中，处理器810，通信接口820，存储器830通过通信总线840完成相互间的通信。

其中，处理器810可以调用存储器830中的逻辑指令，以执行如下方法：

向服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件；

安装所述第一业务插件。

或者，处理器810可以调用存储器830中的逻辑指令，以执行如下方法：

接收客户端发送的第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

此外，上述的存储器830中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

再一方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各实施例提供的插件管理方法，例如包括：

接收客户端发送的第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，向所述客户端发送第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件。

或者包括：

向服务器发送第一请求，所述第一请求中携带有第一应用程序的用户的第一类别，以及所要请求的业务插件的第一标识信息；

在所述服务器中预先存储的所述第一标识信息对应的类别，与所述第一类别相同时，接收所述服务器发送的第一业务插件，所述第一业务插件为所述服务器中预先存储的与所述第一类别对应，且标识信息为所述第一标识信息的业务插件；

安装所述第一业务插件。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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