CN112698858A - 一种插件更新方法、装置和系统 - Google Patents
一种插件更新方法、装置和系统 Download PDFInfo
- Publication number
- CN112698858A CN112698858A CN202110043451.3A CN202110043451A CN112698858A CN 112698858 A CN112698858 A CN 112698858A CN 202110043451 A CN202110043451 A CN 202110043451A CN 112698858 A CN112698858 A CN 112698858A
- Authority
- CN
- China
- Prior art keywords
- plug
- information
- ins
- updating
- update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
本申请公开了一种插件更新方法、装置和系统，该方法包括：服务端基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对目标应用中的插件进行分类，得到插件配置信息；接收来自客户端的插件更新请求，插件更新请求中包括目标应用中的插件在客户端中的插件信息；从插件配置信息中确定与插件信息适配的插件更新信息，插件更新信息中包括更新状态和待更新的插件组合；将插件更新信息发送给客户端，由客户端进行插件更新。由于客户端在进行插件更新时充分考虑了插件间的关联性，因此可以保证插件成功更新。由于服务端只下发具有关联关系的插件，因此可以减少客户端下载的插件数量，节省客户端流量。
Description
技术领域
本申请涉及计算机技术领域，尤其涉及一种插件更新方法、装置和系统。
背景技术
目前，终端设备中可以安装各种各样的应用程序(Application，App)。在用户使用这些应用程序的过程中，为了满足用户多样化的功能需求，通常需要对应用程序中的插件进行更新。
在对插件进行更新时，通常的方法是进行单插件更新或对应用程序中所有的插件进行全部更新。然而，在实际应用中，单插件更新的方式容易出现更新失败的问题，对插件进行全部更新的方式则会出现插件重复下载的问题，导致客户端的流量消耗较大。由此可见，亟需一种有效地插件更新方案可以解决上述技术问题。
发明内容
本申请实施例提供一种插件更新方法、装置和系统，用于解决目前的插件更新方案容易出现更新失败或客户端流量消耗较大的问题。
为解决上述技术问题，本申请实施例是这样实现的：
第一方面，提出一种插件更新方法，应用于服务端，包括：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
第二方面，提出一种插件更新装置，应用于服务端，包括：
分类单元，基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元，接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
确定单元，从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
发送单元，将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
第三方面，提出一种电子设备，应用于服务端，该电子设备包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
第四方面，提出一种计算机可读存储介质，应用于服务端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
第五方面，提出一种插件更新方法，应用于客户端，包括：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
第六方面，提出一种插件更新装置，应用于客户端，包括：
获取单元，获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
发送单元，向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元，接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
更新单元，基于所述插件更新信息进行插件更新。
第七方面，提出一种电子设备，应用于客户端，该电子设备包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
第八方面，提出一种计算机可读存储介质，应用于客户端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
第九方面，提出一种插件更新系统，包括服务端和客户端，其中：
所述服务端基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
所述客户端获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；向所述服务端发送插件更新请求，所述插件更新请求中包括所述插件信息；
所述服务端从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；将所述插件更新信息发送给所述客户端；
所述客户端接收来自所述服务端的所述插件更新信息；基于所述插件更新信息进行插件更新。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：
服务端可以基于应用程序中插件已有的基准版本、插件之间的关联关系和预先确定的插件的更新状态，对应用程序中的插件进行分类，将具有关联关系的、更新状态一致的且对应同一个基准版本的插件划分为一组，得到插件配置信息。客户端在进行插件更新时，可以将应用程序在本地的插件信息发送给服务端。服务端可以从预先确定的插件配置信息中确定与插件信息适配的插件更新信息，并将插件更新信息下发给客户端，由客户端基于插件更新信息进行插件更新。由于插件更新信息中包括插件的更新状态和待更新的插件组合，插件组合由服务端对插件进行分类后得到，因此客户端在进行插件更新时可以充分考虑插件之间的关联性，将具有关联关系的插件同时进行更新，从而可以保证插件能够成功更新。此外，由于服务端在下发待更新的插件时，只下发具有关联关系的插件，因此针对客户端而言可以减少需要下载的插件数量，从而避免对插件重复下载，有效节省客户端的流量。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请的一个实施例插件更新方法的流程示意图；
图2是本申请的一个实施例插件更新方法的流程示意图；
图3是本申请的一个实施例插件更新方法的流程示意图；
图4是本申请的一个实施例电子设备的结构示意图；
图5是本申请的一个实施例插件更新装置的结构示意图；
图6是本申请的一个实施例电子设备的结构示意图；
图7是本申请的一个实施例插件更新装置的结构示意图；
图8是本申请的一个实施例插件更新系统的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
目前的插件更新方案中，常用的更新方案是单插件更新或全部更新。单插件更新的方式可以理解为哪个插件需要更新就单独更新哪个插件。然而在实际应用中，插件之间往往会存在关联关系，在更新某个插件时，需要同时更新与其存在关联关系的插件才可以保证插件更新成功。即现有的单插件更新方案容易出现更新失败的问题。全部更新可以理解为将应用程序中的所有插件一起打包给客户端，由客户端进行全部下载后更新。然而在实际应用中，应用程序中的全部插件往往不需要同时进行更新，这样就会造成客户端对其中某些插件进行重复下载，导致客户端消耗较多的流量。
由此可见，目前的插件更新方案存在容易更新失败或客户端消耗流量较大的问题。
有鉴于此，本申请实施例提供一种插件更新方法、装置和系统。在该方法应用与服务端的情况下，包括：基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对目标应用中的插件进行分类，得到插件配置信息，插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，更新状态包括升级和召回中的至少一种，插件组合中包括具有关联关系的多个插件的插件标识和版本号；接收来自客户端的插件更新请求，插件更新请求中包括目标应用中的插件在客户端中的插件信息，插件信息包括插件的基准版本、插件的插件标识和版本号；从插件配置信息中确定与所述插件信息适配的插件更新信息，插件更新信息中包括更新状态和待更新的插件组合；将插件更新信息发送给客户端，由客户端基于插件更新信息进行插件更新。
由于插件更新信息中包括插件的更新状态和待更新的插件组合，插件组合由服务端对插件进行分类后得到，因此客户端在进行插件更新时可以充分考虑插件之间的关联性，将具有关联关系的插件同时进行更新，从而可以保证插件能够成功更新。此外，由于服务端在下发待更新的插件时，只下发具有关联关系的插件，因此针对客户端而言可以减少需要下载的插件数量，从而避免对插件重复下载，有效节省客户端的流量。
需要说明的是，在本申请实施例中，针对任一应用程序而言，应用程序中的插件可以具有两种类型的版本，一种是基准版本，另一种是在基准版本下插件自身的版本。基准版本的个数可以是多个，在基准版本下插件自身的版本也可以有多个。比如，应用中包含多个插件，该多个插件具有多个基准版本，比如基准版本1.0、基准版本2.0、基准版本3.0等。在任一基准版本下，每个插件可以有多个版本，比如在基准版本1.0下，插件1可以有1.01版本、1.02版本、1.03版本等(1.01、1.02和1.03为版本号)。在基准版本2.0下，插件1可以有2.01版本、2.02版本、2.03版本等。
以下结合附图，详细说明本申请各实施例提供的技术方案。
图1是本申请的一个实施例插件更新方法的流程示意图。图1所示实施例的执行主体可以是服务端，具体可以包括以下步骤。
S102：基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系。
插件的基准版本可以理解为插件的基本版，在基准版本下可以开发得到插件的多个版本。比如，插件的基准版本可以是1.0，在基准版本1.0下，可以针对插件1可以开发1.01版本、1.02版本和1.03版本等。目标应用中插件已有的基准版本可以理解为从开发目标应用到对目标应用进行不断更新的过程中，目标应用中的插件对应的所有基准版本。该基准版本的个数可以是一个，也可以是多个。比如，插件已有的基准版本可以仅有1.0，也可以包括1.0、2.0和3.0三个基准版本。
插件之间的关联关系可以是更新依赖关系。比如，如果在更新插件1时，需要同时更新插件2才可以成功更新插件1，那么可以认为插件1和插件2具有更新依赖关系。此外，插件之间的关联关系还可以是业务关联关系，或者是插件属于同一个模块等。这里不再一一举例说明。本实施例中，只要是插件之间存在某种关联，就可以认为插件之间具有关联关系。
插件的更新状态可以包括升级和召回中的至少一种。其中，升级具体是将插件更新至更高的版本。召回是将插件更新至当前版本之前的版本，具体可以是更新至当前版本的上一个版本。
需要说明的是，插件的更新状态可以由服务端预先确定得到。比如，若开发人员针对目标应用的某个功能进行了改进，该功能改进涉及到将某些插件更新到更高的版本，则可以确定这些插件的更新状态为升级。再比如，若服务端在对目标应用某个功能所涉及的插件进行更新后，接收到多个客户端针对该功能异常的反馈，或在后续测试过程中发现该功能异常，则可以确定该功能所涉及的插件的更新状态为召回。当然，服务端还可以通过其他方式确定目标应用中插件的更新状态，这里不再一一举例说明。
服务端在已知目标应用中插件已有的基准版本、插件之间的关联关系以及插件的更新状态的情况下，可以对目标应用中的插件进行分类。服务端在分类时，可以将具有关联关系的、更新状态一致的且对应同一个基准版本的插件划分为一组，由此可以到插件配置信息。
本实施例中，插件配置信息可以包括插件的基准版本、更新状态和插件组合之间的对应关系。插件组合中可以包括具有关联关系的多个插件的插件标识和版本号。其中，插件组合中包括的多个插件之间具有的关联关系，可以是直接的关联关系，也可以是间接的关联关系，这里不做具体限定。插件标识可以是插件名，也可以是服务端为插件设置的标识，不同插件的插件标识不同。版本号为插件的更新状态对应的版本号。比如，若插件的更新状态为升级，则版本号为需要升级到的版本号。若插件的更新状态为召回，则版本号为需要进行召回的版本号。
可选地，服务端在得到上述插件配置信息后，可以将插件配置信息以多层map结构进行存储。该多层map结构可以描述插件的基准版本、更新状态和插件组合之间的对应关系。其中，为了清楚描述该对应关系，多层map结构的第一层可以以插件的基准版本为key，第二层可以以插件的更新状态为key，第三层为插件组合。
为了便于理解，可以以以下多层map结构为例进行说明。
插件基准版本：V1.0
更新状态：升级
插件组合：【C1:1.03，C2:1.05，C3:1.08】
更新状态：召回
插件组合：【C1:1.03，C2:1.01，C3:1.02】
插件基准版本：V2.0
更新状态：升级
插件组合：【C1:2.03，C2:2.04，C3:2.05】
更新状态：召回
插件组合：【C1:2.02，C2:2.03，C3:2.04】
从上述map结构可以看出，在插件配置信息中，插件的基准版本有两个，一个是V1.0，一个是V2.0。每个基准版本分别对应两种更新状态，在每种更新状态下都有对应的插件组合。以基准版本V1.0下更新状态为升级的插件组合为例，插件组合中的C1、C2和C3为插件标识，1.03、1.01和1.02分别为插件C1、C2和C3的需要升级到的版本号。
需要说明的是，上述map结构中，每个基准版本的一种更新状态下仅示出了一个插件组合，在其他实现方式中，可以有多个插件组合，这里不再一一举例说明。
S104：接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息。
在S104中，客户端可以获取目标应用中的插件在客户端本地中的插件信息，并将插件信息携带在插件更新请求中发送给服务端。此时，服务端可以接收到来自客户端的插件更新请求。其中，插件信息中可以包括插件的基准版本、插件的插件标识和版本号，该基准版本、插件标识和版本号均可以由客户端在目标应用的安装目录或更新目录中收集得到。
在一种实现方式中，客户端可以在启动运行目标应用时获取上述插件信息并发送插件更新请求。或者，也可以是客户端在安装目标应用后，每隔设定时间(此时客户端可以正在运行目标应用，或者未运行目标应用)获取上述插件信息并发送插件更新请求，这里不做具体限定。
S106：从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合。
本实施例中，由于插件的更新状态可以是升级或召回，因此在将插件信息与插件配置信息进行适配时，可以分别在升级和召回的情况下进行适配。以下将针对升级和召回两种更新状态分别进行说明。
在第一种实现方式中，在更新状态为升级的情况下，从插件配置信息中确定与插件信息适配的插件更新信息，可以包括以下步骤：
首先，从插件配置信息中确定与插件信息中的基准版本对应的且更新状态为升级的多个插件组合。
具体地，可以以插件信息中的基准版本和更新状态“升级”作为关键词，与插件配置信息中的基准版本和更新状态进行匹配，确定与插件信息中的基准版本和更新状态“升级”适配的多个插件组合。
其次，从多个插件组合中确定目标插件组合。
目标插件组合中的插件的插件标识与插件信息中的部分或全部插件的插件标识相同。在确定目标插件组合时，针对任一插件组合，可以将插件组合中包括的插件的插件标识和插件信息中包括的插件标识进行对比，确定插件组合中的插件是否包含在插件信息中。若是，则可以确定该插件组合为目标插件组合，否则可以确定该插件组合不是目标插件组合。
比如，插件信息中包括的插件为插件1、插件2和插件3。针对其中一个插件组合，在进行插件标识对比后，若确定插件组合中包括插件1和插件2，则该插件组合为目标插件组合。若插件组合中包括插件1和插件4，或包括插件4和插件5，则该插件组合不是目标插件组合。
这里需要说明的是，目标插件组合中包括的多个插件中，至少一个插件的版本号需要高于其在客户端本地的插件信息中的版本号，这样才可以便于后续进行插件升级。
最后，将更新状态为升级以及上一步骤中确定的目标插件组合确定为插件更新信息。该更新状态“升级”即为插件更新信息中的更新状态，该目标插件组合即为插件更新信息中的待更新的插件组合。
可选地，上述在确定目标插件组合时，确定得到目标插件组合可能为多个。在这种情况下，可以确定多个目标插件组合各自的优先级，并将更新状态为升级以及具有最高优先级的目标插件组合确定为插件更新信息。这样，可以便于客户端基于最优的插件组合进行插件更新。
上述目标插件组合的优先级可以由服务端根据实际情况自行设置。或者，也可以由服务端根据客户端的设备信息确定得到(这种情况需要客户端在发送插件更新请求时携带客户端的设备信息)。比如目标插件组合1适合设备信息为A的设备，目标插件组合2适合设备信息为B的设备，若客户端的设备信息为A，那么目标插件组合1的优先级高与目标插件组合2。当然，在其他实现方式中，还可以通过其他方法确定得到目标插件组合的优先级，这里不再一一举例说明。
可选地，为了便于服务端可以快速匹配到优先级最高的目标插件组合，服务端在从多个插件组合中确定目标插件组合时，可以按照多个插件组合的优先级进行适配。一旦适配到相匹配的目标插件组合就可以调出匹配逻辑，不再处理其他插件组合的适配。
可选地，若上述适配过程中没有得到匹配的目标插件组合，则可以视为目标插件组合为空。相应的，与更新状态“升级”对应的插件更新信息也为空。此时可以说明客户端中目标应用的插件不需要升级。
在第二种实现方式中，在更新状态为召回的情况下，从插件配置信息中确定与插件信息适配的插件更新信息，可以包括以下步骤：
首先，从插件配置信息中确定与插件信息中的基准版本对应的且更新状态为召回的多个插件组合。
具体地，可以以插件信息中的基准版本和更新状态“召回”作为关键词，与插件配置信息中的基准版本和更新状态进行匹配，确定与插件信息中的基准版本和更新状态“召回”适配的多个插件组合。
其次，从多个插件组合中确定目标插件组合。
目标插件组合中的插件的插件标识和版本号与插件信息中的部分或全部插件的插件标识和版本号相同。在确定目标插件组合时，针对任一插件组合，可以将插件组合中包括的插件的插件标识与插件信息中包括的插件标识进行对比，确定插件组合中的插件是否包含在插件信息中。若否，则可以确定插件组合不是目标插件组合。若是，则可以进一步确定这些插件的版本号是否与其在插件信息中的版本号一致。若一致，则可以确定该插件组合为目标插件组合，若不一致，则可以确定该插件组合不是目标插件组合。
比如，插件信息中包括的插件为插件1、插件2和插件3，版本号分别为1.01、1.02和1.03。针对其中一个插件组合，在进行插件标识对比后，若确定插件组合中包括插件1和插件2，且版本号分别为1.01、1.02，则该插件组合为目标插件组合。若插件组合中包括插件1和插件4，则该插件组合不是目标插件组合，或者，插件组合中包括插件1和插件2，但版本号不是1.01、1.02，则该插件组合不是目标插件组合。
最后，将更新状态为召回以及目标插件组合确定为插件更新信息。该更新状态“召回”即为插件更新信息中的更新状态，该目标插件组合即为插件更新信息中的待更新的插件组合。
可选地，上述在确定与“召回”对应的目标插件组合时，确定得到目标插件组合也可能为多个。在这种情况下，服务端可以将更新状态为召回以及具有最高优先级的目标插件组合确定为插件更新信息，具体实现方式可以参见上述第一种实现方式中相应步骤的具体实现，这里不再重复说明。
可选地，若上述适配过程中没有得到匹配的目标插件组合，则可以视为目标插件组合为空。相应的，与更新状态“召回”对应的插件更新信息也为空。此时可以说明客户端中目标应用的插件不需要召回。
S108：将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
服务端在基于S106中记载的方法确定得到插件更新信息后，可以将插件更新信息下发给客户端。客户端在接收到插件更新信息后，可以基于插件更新信息进行插件更新。客户端进行插件更新的具体实现方式可以参见图2所示实施例中相应步骤的具体实现，这里不再重复说明。
由于插件更新信息中包括插件的更新状态和待更新的插件组合，插件组合由服务端对插件进行分类后得到，因此客户端在进行插件更新时可以充分考虑插件之间的关联性，将具有关联关系的插件同时进行更新，从而可以保证插件能够成功更新。此外，由于服务端在下发待更新的插件时，只下发具有关联关系的插件，因此针对客户端而言可以减少需要下载的插件数量，从而避免对插件重复下载，有效节省客户端的流量。
为了便于理解本申请实施例提供的技术方案，以下将举例说明。
假设目标应用在客户端中的插件对应的基准版本为1.0，插件包中包含3个插件，版本号分别为1.2、1.1和1.3，插件信息表示为："a:1.2、b:1.1、c:1.3"。其中，已知插件c:1.4的更新需要依赖插件a:1.3，服务端的插件配置信息中，针对基准版本1.0，可以配置更新状态为升级的插件组合为【"a:1.3、c:1.4"】和【"a:1.3、b:1.2、c:1.4"】，配置更新状态为召回的插件组合为【"a:1.3、b:1.3、c:1.4"】。服务端在得到插件配置信息后，可以在内存中存储为多层Map结构。具体可以如下所示。
CACHE缓存信息:
可选地，服务端在存储插件配置信息时，可以按照插件配置信息插件组合的优先级倒序进行排序后加载到缓存CACHE中。这样，可以便于后续优先匹配优先级高的插件组合并下发。
客户端在进行插件更新时，向服务端发送插件更新请求，插件更新请求中携带插件基准版本1.0以及插件信息"a:1.2、b:1.1、c:1.3"。服务端收到客户端的插件更新请求后，根据基准版本1.0加载对应的更新状态和插件组合，并根据优先级进行MATCH匹配下发插件更新信息。
具体的，针对更新状态为“升级”的插件组合，服务端循环处理升级组合适配逻辑，按照优先级进行适配，匹配到一条下发逻辑后即跳出循环，不再处理后续插件组合。其中，基于服务端预存的插件配置信息可知，匹配的插件组合为："a:1.3、c:1.4"。在匹配得到"a:1.3、c:1.4"后，即跳出循环。可选地，如果循环完未匹配到插件组合，则升级插件组合为空。
针对更新状态为“召回”的插件组合，服务端循环处理召回组合适配逻辑，按照优先级进行适配，匹配到一条下发逻辑后即跳出循环，不再处理后续插件组合。其中，基于服务端预存的插件配置信息可知，无法匹配到适配的插件组合，即召回插件组合为空。
服务端在进行上述适配后，可以得到更新状态为“升级”，目标插件组合为"a:1.3、c:1.4"的插件更新信息。之后，服务端可以将该插件更新信息下发给客户端，由客户端进行插件更新。
需要说明的是，在实际应用中，在服务端确定得到的插件更新信息不为空的情况下，针对同一组待更新的插件，插件更新信息中的更新状态可以是升级，也可以是召回。在一种可能的实现方式中，该更新状态还可以同时包括升级和召回。在这种情况下，服务端可以根据实际情况将其中一种更新状态作为最终的更新状态下发给客户端，或者，服务端将两种更新状态都下发给客户端，由客户端根据实际需求选择其中一种更新状态进行更新。优选地，为了保证客户端在进行插件更新后能够正常地运行目标应用，服务端和客户端优先选择“召回”的更新状态进行插件更新。
仍以上述客户端中的插件信息为"a:1.2、b:1.1、c:1.3"为例。假设服务端中的插件配置信息中，更新状态“召回”对应的插件组合为"a:1.2、b:1.1、c:1.3"，则服务端可以得到如下插件更新信息：升级插件组合"a:1.3、c:1.4"，召回插件组合"a:1.2、b:1.1、c:1.3"。服务端可以选择召回插件组合"a:1.2、b:1.1、c:1.3"作为插件更新信息下发。或者，服务端可以将升级插件组合"a:1.3、c:1.4"和召回插件组合"a:1.2、b:1.1、c:1.3"同时下发给客户端，由客户端基于召回插件组合"a:1.2、b:1.1、c:1.3"进行插件更新。
图2是本申请的一个实施例插件更新方法的流程示意图。图2所示实施例的执行主体为上述客户端。图2所示的实施例包括以下步骤。
S202：获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号。
客户端在需要进行插件更新时，可以获取已安装的目标应用在本地的插件信息。其中，客户端可以在启动运行目标应用时获取插件信息。或者，也可以是客户端在安装目标应用后，每隔设定时间(此时客户端可以正在运行目标应用，或者未运行目标应用)获取插件信息。插件信息中包括插件的基准版本、插件的插件标识和版本号。
S204：向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息。
客户端在获取到插件信息后，可以将插件信息携带在插件更新请求中发送给服务端，以便由服务端确定插件更新信息。
本实施例中，服务端预先存储有插件配置信息，该插件配置信息由服务端基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对目标应用中的插件进行分类得到。插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，更新状态包括升级和召回中的至少一种，插件组合中包括具有关联关系的多个插件的插件标识和版本号。服务端确定插件配置信息的具体实现方式可以参见图1所示实施例中相应步骤的具体实现，这里不再详细说明。
S206：接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合。
服务端在接收到客户端的插件更新请求后，可以将插件信息与预先确定的插件配置信息进行适配，得到插件更新信息。具体实现方式可以参见图1所示实施例中相应步骤的具体实现，这里不再重复说明。插件更新信息中包括更新状态和待更新的插件组合。
服务端在得到插件更新信息后，可以将插件更新信息发送给客户端。此时客户端可以接收到来自服务端的插件更新信息。
S208：基于所述插件更新信息进行插件更新。
客户端在接收到插件更新信息后，可以基于插件更新信息进行插件更新。
在第一种实现方式中，在插件更新信息中的更新状态为升级的情况下，客户端基于插件更新信息进行插件更新，可以包括：
首先，确定待更新的插件组合中包括的多个目标插件的版本号。
由于插件组合中包括插件的版本号，因此，通过对插件更新信息进行解析，可以确定插件组合中包括的多个插件的版本号。这里为了便于区分，可以将插件组合中的插件称为目标插件。
其次，将多个目标插件的版本号与多个目标插件在本地的版本号进行对比，确定版本号不一致的目标插件。
这里对比版本号的目的是确定哪些目标插件需要升级。
最后，从服务端下载版本号不一致的目标插件，并基于下载的目标插件进行插件升级。
在确定版本号不一致的目标插件后，可以确定这些插件是需要更新的插件，为了节省客户端流量，可以仅对版本号不一致的目标插件进行下载。在下载这些目标插件后，可以基于已下载的目标插件进行更新。
在一种更为具体的实现方式中，客户端接收到插件更新信息后，将插件更新信息的插件组合中的插件与客户端现有插件进行比对，若客户端的插件与服务端下发的插件的版本相同，则跳过这个插件，否则可以按照服务端的插件版本进行插件下载。在对需要下载的插件全部下载完成后，根据服务端的插件顺序进行加载启动，进而实现插件更新。
可选地，客户端在对目标插件进行升级后，可以将目标插件升级前的版本存储在本地。这样可以便于后续召回。
为了便于理解，可以以图1所示实施例中服务端下发的插件更新信息为例进行说明。在该示例中，服务端下发的插件更新信息为：升级插件组合"a:1.3、c:1.4"。客户端将本地的插件信息"a:1.2、b:1.1、c:1.3"与插件更新信息进行对比后，确认需要下载："a:1.3、c:1.4"。客户端下载插件后，当下载完成时，按顺序依次加载"a:1.3、c:1.4"，实现插件更新。插件更新后，客户端的插件信息变更为："a:1.3、b:1.1、c:1.4"。此外，客户端还可以将之前的版本"a:1.2、b:1.1、c:1.3"进行记录，以便后续召回使用。
在第二种实现方式中，在插件更新信息中的更新状态为召回的情况下，客户端基于插件更新信息进行插件更新，可以包括：
首先，确定待更新的插件组合中包括的多个目标插件的插件标识。
由于插件组合中包括插件的插件标识，因此，通过对插件更新信息进行解析，可以确定插件组合中包括的多个插件的版本号。这里为了便于区分，可以将插件组合中的插件称为目标插件。
其次，基于多个目标插件的插件标识，从本地查找多个目标插件上一次正常初始化时的版本。
本实施例中，客户端在每次进行插件更新后，都可以将之前的版本进行保存。这样，可以基于多个目标插件的插件标识，从本地查找得到多个目标插件上一次正常初始化时的版本。
最后，将多个目标插件降级至在本地查找到的版本。
为了便于理解，可以以图1所示实施例中服务端下发的插件更新信息为例进行说明。在该示例中，假设服务端下发的插件更新信息为：召回插件组合"a:1.2、b:1.1、c:1.3"，则客户端在对插件更新信息进行解析后，可以在本地查找得到上一次成功加载的插件版本，假设该插件版本为"a:1.1、b:1.1、c:1.3"，则客户端可以回退到插件版本"a:1.1、b:1.1、c:1.3"。
从上述客户端的插件更新可以看出，本实施例中客户端在进行插件更新时可以充分考虑插件之间的关联性，将具有关联关系的插件同时进行更新，从而可以保证插件能够成功更新。此外，由于服务端在下发待更新的插件时，只下发具有关联关系的插件，因此针对客户端而言可以减少需要下载的插件数量，从而避免对插件重复下载，有效节省客户端的流量。特别是在服务端下发的插件更新信息中的更新状态为召回的情况下，由于客户端可以直接基于本地的插件版本进行插件召回，因此可以无需对插件进行下载，进而无需消耗客户端的流量。
图3是本申请的一个实施例插件更新方法的流程示意图。图3所示的实施例是从图1所示的服务端和图2所示的客户端交互的角度说明本申请实施例提供的技术方案。图3所示的实施例包括以下步骤。
S301：服务端基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对目标应用中的插件进行分类，得到插件配置信息。
插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，更新状态包括升级和召回中的至少一种，插件组合中包括具有关联关系的多个插件的插件标识和版本号。
S302：客户端获取已安装的目标应用在本地的插件信息。
插件信息中包括插件的基准版本、插件的插件标识和版本号。
S303：客户端向服务端发送插件更新请求，插件更新请求中包括插件信息。
S304：服务端从插件配置信息中确定与插件信息适配的插件更新信息，插件更新信息中包括更新状态和待更新的插件组合。
S305：服务端将插件更新信息发送给客户端。
S306：客户端基于插件更新信息进行插件更新。
上述S301至S306的具体实现方式可以参见图1和图2所示实施例中相应步骤的具体实现，这里不再详细说明。
本申请的上述实施例提供的技术方案中，服务端可以基于应用程序中插件已有的基准版本、插件之间的关联关系和预先确定的插件的更新状态，对应用程序中的插件进行分类，将具有关联关系的、更新状态一致的且对应同一个基准版本的插件划分为一组，得到插件配置信息。客户端在进行插件更新时，可以将应用程序在本地的插件信息发送给服务端。服务端可以从预先确定的插件配置信息中确定与插件信息适配的插件更新信息，并将插件更新信息下发给客户端，由客户端基于插件更新信息进行插件更新。由于插件更新信息中包括插件的更新状态和待更新的插件组合，插件组合由服务端对插件进行分类后得到，因此客户端在进行插件更新时可以充分考虑插件之间的关联性，将具有关联关系的插件同时进行更新，从而可以保证插件能够成功更新。此外，由于服务端在下发待更新的插件时，只下发具有关联关系的插件，因此针对客户端而言可以减少需要下载的插件数量，从而避免对插件重复下载，有效节省客户端的流量。
上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
图4是本申请的一个实施例电子设备的结构示意图。请参考图4，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成插件更新装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
上述如本申请图4所示实施例揭示的插件更新装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
该电子设备还可执行图1的方法，并实现插件更新装置在图1和图3所示实施例中的功能，本申请实施例在此不再赘述。
当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1和图3所示实施例的方法，并具体用于执行以下操作：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
图5是本申请的一个实施例插件更新装置50的结构示意图。请参考图5，在一种软件实施方式中，所述插件更新装置50可包括：分类单元51、接收单元52、确定单元53和发送单元54，其中：
分类单元51，基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元52，接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
确定单元53，从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
发送单元54，将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
可选地，所述分类单元51在得到所述插件配置信息后，将所述插件配置信息以多层map结构进行存储，其中，所述多层map结构的第一层以插件的基准版本为key，第二层以插件的更新状态为key，第三层为插件组合。
可选地，在所述更新状态包括升级的情况下，所述确定单元53从所述插件配置信息中确定与所述插件信息适配的插件更新信息，包括：
从所述插件配置信息中确定与所述插件信息中的基准版本对应的且更新状态为升级的多个插件组合；
从所述多个插件组合中确定目标插件组合，所述目标插件组合中的插件的插件标识与所述插件信息中的部分或全部插件的插件标识相同；
将更新状态为升级以及所述目标插件组合确定为所述插件更新信息。
可选地，若所述目标插件组合的个数为多个，则所述确定单元53将更新状态为升级以及所述目标插件组合确定为所述插件更新信息，包括：
确定多个所述目标插件组合的优先级；
将更新状态为升级以及具有最高优先级的目标插件组合确定为所述插件更新信息。
可选地，在所述更新状态包括召回的情况下，所述确定单元53从所述插件配置信息中确定与所述插件信息适配的插件更新信息，包括：
从所述插件配置信息中确定与所述插件信息中的基准版本对应的且更新状态为召回的多个插件组合；
从所述多个插件组合中确定目标插件组合，所述目标插件组合中的插件的插件标识和版本号与所述插件信息中的部分或全部插件的插件标识和版本号相同；
将更新状态为召回以及所述目标插件组合确定为所述插件更新信息。
本申请实施例提供的插件更新装置50还可执行图1和图3的方法，并实现插件更新装置在图1和图3所示实施例的功能，本申请实施例在此不再赘述。
图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成插件更新装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
上述如本申请图6所示实施例揭示的插件更新装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
该电子设备还可执行图2的方法，并实现插件更新装置在图2和图3所示实施例中的功能，本申请实施例在此不再赘述。
当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图2和图3所示实施例的方法，并具体用于执行以下操作：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
图7是本申请的一个实施例插件更新装置70的结构示意图。请参考图7，在一种软件实施方式中，所述插件更新装置70可包括：获取单元71、发送单元72、接收单元73和更新单元74，其中：
获取单元71，获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
发送单元72，向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元73，接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
更新单元74，基于所述插件更新信息进行插件更新。
可选地，在所述插件更新信息中的更新状态包括升级的情况下，所述更新单元74基于所述插件更新信息进行插件更新，包括：
确定所述待更新的插件组合中包括的多个目标插件的版本号；
将所述多个目标插件的版本号与所述多个目标插件在本地的版本号进行对比，确定版本号不一致的目标插件；
从所述服务端下载所述版本号不一致的目标插件，并基于下载的目标插件进行插件升级。
可选地，所述更新单元74在对目标插件进行升级后，将所述目标插件升级前的版本存储在本地。
可选地，在所述插件更新信息中的更新状态包括召回的情况下，所述更新单元74基于所述插件更新信息进行插件更新，包括：
确定所述待更新的插件组合中包括的多个目标插件的插件标识；
基于所述多个目标插件的插件标识，从本地查找所述多个目标插件上一次正常初始化时的版本；
将所述多个目标插件降级至在本地查找到的所述版本。
本申请实施例提供的插件更新装置70还可执行图2和图3的方法，并实现插件更新装置在图2和图3所示实施例的功能，本申请实施例在此不再赘述。
图8是本申请的一个实施例插件更新系统的结构示意图。请参考图8，在一种软件实施方式中，所述插件更新系统80可包括：服务端81和客户端82，其中：
所述服务端81基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
所述客户端82获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；向所述服务端81发送插件更新请求，所述插件更新请求中包括所述插件信息；
所述服务端81从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；将所述插件更新信息发送给所述客户端82；
所述客户端82接收来自所述服务端81的所述插件更新信息；基于所述插件更新信息进行插件更新。
本实施例中，服务端81可以实现图1至图3所示实施例中服务端所实现的功能，客户端82可以实现图1至图3所示实施例中客户端所实现的功能，这里不再详细说明。
总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (16)
1.一种插件更新方法，其特征在于，应用于服务端，包括：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
2.如权利要求1所述的方法，其特征在于，在得到所述插件配置信息后，所述方法还包括：
将所述插件配置信息以多层map结构进行存储，其中，所述多层map结构的第一层以插件的基准版本为key，第二层以插件的更新状态为key，第三层为插件组合。
3.如权利要求1所述的方法，其特征在于，在所述更新状态包括升级的情况下，从所述插件配置信息中确定与所述插件信息适配的插件更新信息，包括：
从所述插件配置信息中确定与所述插件信息中的基准版本对应的且更新状态为升级的多个插件组合；
从所述多个插件组合中确定目标插件组合，所述目标插件组合中的插件的插件标识与所述插件信息中的部分或全部插件的插件标识相同；
将更新状态为升级以及所述目标插件组合确定为所述插件更新信息。
4.如权利要求3所述的方法，其特征在于，若所述目标插件组合的个数为多个，则将更新状态为升级以及所述目标插件组合确定为所述插件更新信息，包括：
确定多个所述目标插件组合的优先级；
将更新状态为升级以及具有最高优先级的目标插件组合确定为所述插件更新信息。
5.如权利要求1所述的方法，其特征在于，在所述更新状态包括召回的情况下，从所述插件配置信息中确定与所述插件信息适配的插件更新信息，包括：
从所述插件配置信息中确定与所述插件信息中的基准版本对应的且更新状态为召回的多个插件组合；
从所述多个插件组合中确定目标插件组合，所述目标插件组合中的插件的插件标识和版本号与所述插件信息中的部分或全部插件的插件标识和版本号相同；
将更新状态为召回以及所述目标插件组合确定为所述插件更新信息。
6.一种插件更新方法，其特征在于，应用于客户端，包括：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
7.如权利要求6所述的方法，其特征在于，在所述插件更新信息中的更新状态包括升级的情况下，基于所述插件更新信息进行插件更新，包括：
确定所述待更新的插件组合中包括的多个目标插件的版本号；
将所述多个目标插件的版本号与所述多个目标插件在本地的版本号进行对比，确定版本号不一致的目标插件；
从所述服务端下载所述版本号不一致的目标插件，并基于下载的目标插件进行插件升级。
8.如权利要求7所述的方法，其特征在于，所述方法还包括：
在对目标插件进行升级后，将所述目标插件升级前的版本存储在本地。
9.如权利要求6所述的方法，其特征在于，在所述插件更新信息中的更新状态包括召回的情况下，基于所述插件更新信息进行插件更新，包括：
确定所述待更新的插件组合中包括的多个目标插件的插件标识；
基于所述多个目标插件的插件标识，从本地查找所述多个目标插件上一次正常初始化时的版本；
将所述多个目标插件降级至在本地查找到的所述版本。
10.一种插件更新装置，其特征在于，应用于服务端，包括：
分类单元，基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元，接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
确定单元，从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
发送单元，将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
11.一种电子设备，其特征在于，应用于服务端，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
12.一种计算机可读存储介质，其特征在于，应用于服务端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：
基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自客户端的插件更新请求，所述插件更新请求中包括所述目标应用中的插件在所述客户端中的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；
将所述插件更新信息发送给所述客户端，由所述客户端基于所述插件更新信息进行插件更新。
13.一种插件更新装置，其特征在于，应用于客户端，包括：
获取单元，获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
发送单元，向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收单元，接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
更新单元，基于所述插件更新信息进行插件更新。
14.一种电子设备，其特征在于，应用于客户端，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
15.一种计算机可读存储介质，其特征在于，应用于客户端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：
获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；
向服务端发送插件更新请求，所述插件更新请求中包括所述插件信息，所述服务端预先存储有插件配置信息，所述插件配置信息由所述服务端基于所述目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类得到，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
接收来自所述服务端的与所述插件信息适配的插件更新信息，所述插件更新信息由所述服务端从所述插件配置信息中确定得到，所述插件更新信息中包括更新状态和待更新的插件组合；
基于所述插件更新信息进行插件更新。
16.一种插件更新系统，其特征在于，包括服务端和客户端，其中：
所述服务端基于目标应用中插件已有的基准版本、插件之间的关联关系以及预先确定的插件的更新状态，对所述目标应用中的插件进行分类，得到插件配置信息，所述插件配置信息中包括插件的基准版本、更新状态和插件组合之间的对应关系，所述更新状态包括升级和召回中的至少一种，所述插件组合中包括具有关联关系的多个插件的插件标识和版本号；
所述客户端获取已安装的目标应用在本地的插件信息，所述插件信息包括插件的基准版本、插件的插件标识和版本号；向所述服务端发送插件更新请求，所述插件更新请求中包括所述插件信息；
所述服务端从所述插件配置信息中确定与所述插件信息适配的插件更新信息，所述插件更新信息中包括更新状态和待更新的插件组合；将所述插件更新信息发送给所述客户端；
所述客户端接收来自所述服务端的所述插件更新信息；基于所述插件更新信息进行插件更新。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110043451.3A CN112698858B (zh) | 2021-01-13 | 2021-01-13 | 一种插件更新方法、装置和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110043451.3A CN112698858B (zh) | 2021-01-13 | 2021-01-13 | 一种插件更新方法、装置和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112698858A true CN112698858A (zh) | 2021-04-23 |
| CN112698858B CN112698858B (zh) | 2023-02-07 |
Family
ID=75514405
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110043451.3A Active CN112698858B (zh) | 2021-01-13 | 2021-01-13 | 一种插件更新方法、装置和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112698858B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117056115A (zh) * | 2023-10-10 | 2023-11-14 | 腾讯科技（深圳）有限公司 | 应用程序的修复方法和装置、存储介质及电子设备 |
Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011060232A (ja) * | 2009-09-14 | 2011-03-24 | Ricoh Co Ltd | 管理装置、管理システム、管理方法、及び管理プログラム |
| CN102262544A (zh) * | 2010-05-24 | 2011-11-30 | 腾讯科技（深圳）有限公司 | 软件升级的方法和装置 |
| CN102546708A (zh) * | 2010-12-27 | 2012-07-04 | 阿里巴巴集团控股有限公司 | 插件获取方法、系统及相关装置 |
| US20150286489A1 (en) * | 2014-04-04 | 2015-10-08 | Avid Technology, Inc. | Automatic detection and loading of missing plug-ins in a media composition application |
| CN106155739A (zh) * | 2016-06-30 | 2016-11-23 | 北京奇虎科技有限公司 | 一种插件控量方法、服务器、客户端及控量平台 |
| CN106330936A (zh) * | 2016-08-31 | 2017-01-11 | 广州品唯软件有限公司 | 一种插件数据传输方法、客户端和服务端 |
| CN106375567A (zh) * | 2016-08-31 | 2017-02-01 | 广州品唯软件有限公司 | 一种插件发布方法、系统、客户端和服务端 |
| CN106502757A (zh) * | 2016-12-27 | 2017-03-15 | 北京恒华伟业科技股份有限公司 | 一种插件管理方法及装置 |
| US20170168807A1 (en) * | 2015-12-14 | 2017-06-15 | Le Holdings (Beijing) Co., Ltd. | Method and electronic device for updating application program |
| CN108037941A (zh) * | 2017-12-27 | 2018-05-15 | 掌阅科技股份有限公司 | 基于公共插件的应用程序更新方法、电子设备、存储介质 |
| CN110543324A (zh) * | 2019-08-27 | 2019-12-06 | 贝壳技术有限公司 | 一种应用程序的插件增量更新方法及装置 |
| CN111722857A (zh) * | 2019-03-20 | 2020-09-29 | 北京柏林互动科技有限公司 | 软件开发工具包的更新方法、装置、电子设备及存储介质 |
| CN111857862A (zh) * | 2020-06-19 | 2020-10-30 | 泰康保险集团股份有限公司 | 插件管理方法、装置、电子设备及计算机可读存储介质 |
-
2021
- 2021-01-13 CN CN202110043451.3A patent/CN112698858B/zh active Active
Patent Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011060232A (ja) * | 2009-09-14 | 2011-03-24 | Ricoh Co Ltd | 管理装置、管理システム、管理方法、及び管理プログラム |
| CN102262544A (zh) * | 2010-05-24 | 2011-11-30 | 腾讯科技（深圳）有限公司 | 软件升级的方法和装置 |
| CN102546708A (zh) * | 2010-12-27 | 2012-07-04 | 阿里巴巴集团控股有限公司 | 插件获取方法、系统及相关装置 |
| US20150286489A1 (en) * | 2014-04-04 | 2015-10-08 | Avid Technology, Inc. | Automatic detection and loading of missing plug-ins in a media composition application |
| US20170168807A1 (en) * | 2015-12-14 | 2017-06-15 | Le Holdings (Beijing) Co., Ltd. | Method and electronic device for updating application program |
| CN106155739A (zh) * | 2016-06-30 | 2016-11-23 | 北京奇虎科技有限公司 | 一种插件控量方法、服务器、客户端及控量平台 |
| CN106375567A (zh) * | 2016-08-31 | 2017-02-01 | 广州品唯软件有限公司 | 一种插件发布方法、系统、客户端和服务端 |
| CN106330936A (zh) * | 2016-08-31 | 2017-01-11 | 广州品唯软件有限公司 | 一种插件数据传输方法、客户端和服务端 |
| CN106502757A (zh) * | 2016-12-27 | 2017-03-15 | 北京恒华伟业科技股份有限公司 | 一种插件管理方法及装置 |
| CN108037941A (zh) * | 2017-12-27 | 2018-05-15 | 掌阅科技股份有限公司 | 基于公共插件的应用程序更新方法、电子设备、存储介质 |
| CN111722857A (zh) * | 2019-03-20 | 2020-09-29 | 北京柏林互动科技有限公司 | 软件开发工具包的更新方法、装置、电子设备及存储介质 |
| CN110543324A (zh) * | 2019-08-27 | 2019-12-06 | 贝壳技术有限公司 | 一种应用程序的插件增量更新方法及装置 |
| CN111857862A (zh) * | 2020-06-19 | 2020-10-30 | 泰康保险集团股份有限公司 | 插件管理方法、装置、电子设备及计算机可读存储介质 |
Non-Patent Citations (3)
| Title |
|---|
| 冯烨: "插件技术在计算机软件中的应用", 《数码世界》 * |
| 吴越等: "一种面向服务的插件框架", 《中国仪器仪表》 * |
| 马丽娜等: "基于插件技术的远程自动升级系统的研究", 《西南民族大学学报(自然科学版)》 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117056115A (zh) * | 2023-10-10 | 2023-11-14 | 腾讯科技（深圳）有限公司 | 应用程序的修复方法和装置、存储介质及电子设备 |
| CN117056115B (zh) * | 2023-10-10 | 2024-03-15 | 腾讯科技（深圳）有限公司 | 应用程序的修复方法和装置、存储介质及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112698858B (zh) | 2023-02-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9092286B2 (en) | System to automatically process components on a device | |
| CN111381858B (zh) | 一种应用程序升级方法、服务器及终端设备 | |
| US20090144719A1 (en) | Using system fingerprints to accelerate package dependency resolution | |
| CN108681459B (zh) | 一种智能硬件设备的固件更新方法、装置及系统 | |
| CN108874426B (zh) | 一种应用程序更新方法、装置及可读存储介质 | |
| CN108540509B (zh) | 一种终端浏览器的处理方法、装置及服务器、智能终端 | |
| CN106951284B (zh) | 基于安卓系统应用的用户界面升级方法、装置及智能终端 | |
| US20240111549A1 (en) | Method and apparatus for constructing android running environment | |
| CN108920691B (zh) | 前端静态资源的管理方法、装置、计算机设备及存储介质 | |
| WO2017186066A1 (zh) | 软件管理方法及装置 | |
| CN112698858B (zh) | 一种插件更新方法、装置和系统 | |
| CN113835713B (zh) | 源码包下载方法、装置、计算机设备和存储介质 | |
| CN115145605A (zh) | 一种车载应用软件升级方法、系统、电子设备及存储介质 | |
| CN112199099B (zh) | 应用更新方法、装置、服务器及存储介质 | |
| CN113094077B (zh) | 一种系统差分升级方法、装置、智能终端及存储介质 | |
| CN116303099B (zh) | 自动化测试环境跨平台快速部署方法、装置、介质及设备 | |
| CN111488483A (zh) | 曲库更新方法、装置、终端和非临时性计算机可读存储介质 | |
| CN111291012A (zh) | 一种规则文件部署系统、方法、设备及介质 | |
| CN109697072A (zh) | 信息处理方法、装置及设备 | |
| CN111176693B (zh) | 一种数字电视系统的升级方法 | |
| CN113590179A (zh) | 插件检测方法、装置、电子设备及存储介质 | |
| CN115185553A (zh) | 更新用户的设备固件的方法及其相关设备 | |
| CN114610331A (zh) | 软件安装方法和系统 | |
| CN111427603A (zh) | 应用程序的升级方法及装置 | |
| CN112379943A (zh) | Electron应用程序的插件应用方法及装置、存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |