CN111008031A - 组件更新方法和装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供的组件更新方法和装置、电子设备及计算机可读存储介质，涉及组件更新技术领域。在本申请实施例中，首先，根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件。其次，控制所述目标代理组件判断所述目标待更新组件的上下文是否可用。然后，若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理。通过上述方法，可以提高组件更新的效率和安全性。

Description

组件更新方法和装置、电子设备及计算机可读存储介质

技术领域

本申请涉及组件更新技术领域，具体而言，涉及一种组件更新方法和装置、电子设备及计算机可读存储介质。

背景技术

在应用组件进行更新时，若应用组件的上下文不可用，则会发生异常，导致应用崩溃。通常在每一处需要更新应用组件的地方，都要增加上下文是否可用的判断，以避免上下文不可用，导致应用崩溃。

但是，经发明人研究发现，在现有技术中，在每一处应用组件更新的地方，都要手动判断上下文是否可用，从而存在着组件更新的效率低的问题。并且对于上下文是否可用存在误判和漏判，在上下文不可用时进行组件更新使应用崩溃，从而存在着组件更新的安全性低的问题。

发明内容

有鉴于此，本申请的目的在于提供一种组件更新方法和装置、电子设备及计算机可读存储介质，以改善现有技术中存在的问题。

为实现上述目的，本申请实施例采用如下技术方案：

一种组件更新方法，包括：

根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件；

控制所述目标代理组件判断所述目标待更新组件的上下文是否可用；

若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理。

在本申请实施例较佳的选择中，所述方法还包括：

若所述目标待更新组件的上下文不可用，则拒绝对所述目标待更新组件进行更新处理。

在本申请实施例较佳的选择中，所述目标待更新组件包括视图组件，所述控制所述目标代理组件判断所述目标待更新组件的上下文是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件所属的当前页面是否可用。

在本申请实施例较佳的选择中，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件的上下文是否为页面类型；

若所述视图组件的上下文为页面类型，则判断所述视图组件的当前页面是否可用。

在本申请实施例较佳的选择中，所述方法还包括：

若所述视图组件的上下文非页面类型，则获取所述视图组件上下文的页面，判断所述视图组件上下文的页面是否可用。

在本申请实施例较佳的选择中，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件所属的当前页面是否处于正在结束的状态或已销毁的状态。

在本申请实施例较佳的选择中，所述若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理的步骤，包括：

若所述目标待更新组件的上下文可用，则判断所述目标待更新组件是否可用，在所述目标待更新组件可用时，则对所述目标待更新组件进行更新处理。

本申请实施例还提供了一种组件更新装置，包括：

查找模块，用于根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件；

判断模块，用于控制所述目标代理组件判断所述目标待更新组件的上下文是否可用；

更新处理模块，用于在所述目标待更新组件的上下文可用时，对所述目标待更新组件进行更新处理。

本申请实施例还提供了一种电子设备，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现上述的组件更新理方法。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被执行时实现上述组件更新方法的步骤。

本申请实施例提供的组件更新方法和装置、电子设备及计算机可读存储介质，通过与目标待更新组件关联的目标代理组件判断所述目标待更新组件的上下文是否可用，从而在每一处组件更新时自动判断，避免了现有技术中在每一处应用组件更新的地方，都要手动判断上下文是否可用，所导致的组件更新的效率低的问题。

并且在组件更新处理之前，保证所述目标待更新组件的上下文是可用的，避免了现有技术中对于上下文是否可用存在误判和漏判，在上下文不可用时进行组件更新使应用崩溃，所导致的组件更新的安全性低的问题。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的电子设备的结构框图。

图2为本申请实施例提供的组件更新方法的流程示意图。

图3为本申请实施例提供的步骤S120的流程示意图。

图4为本申请实施例提供的组件更新装置的结构框图。

图标：10-电子设备；12-存储器；14-处理器；100-组件更新装置；110-查找模块；120-判断模块；130-更新处理模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

如图1所示，本申请实施例提供了一种电子设备10。其中，所述电子设备10可以包括存储器12、处理器14和组件更新装置100。

详细地，所述存储器12和处理器14之间直接或间接地电性连接，以实现数据的传输或交互。例如，相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述组件更新装置100包括至少一个可以软件或固件(firmware)的形式存储于所述存储器12中的软件功能模块。所述处理器14用于执行所述存储器12中存储的可执行的计算机程序，例如，所述组件更新装置100所包括的软件功能模块及计算机程序等，以实现组件更新方法。

其中，所述存储器12可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

所述处理器14可能是一种集成电路芯片，具有信号的处理能力。上述的处理器14可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)、片上系统(System on Chip，SoC)等。

可以理解，图1所示的结构仅为示意，所述电子设备10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

结合图2，本申请实施例还提供一种可应用于上述电子设备10的组件更新方法。其中，所述组件更新方法有关的流程所定义的方法步骤可以由所述电子设备10实现，下面将对图2所示的具体流程进行详细阐述。

步骤S110，根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件。

在本申请实施例中，在获取所述代理组件与待更新组件之间的关联关系之后，可以根据所述关联关系查找出与目标待更新组件关联的目标代理组件。

步骤S120，控制所述目标代理组件判断所述目标待更新组件的上下文是否可用。

在本申请实施例中，通过步骤S110查找出与所述目标待更新组件关联的目标代理组件之后，可以控制所述目标代理组件判断所述目标待更新组件的上下文是否可用。

步骤S130，对所述目标待更新组件进行更新处理。

在本申请实施例中，通过步骤S120控制所述目标代理组件判断所述目标待更新组件的上下文是否可用，可以在所述目标待更新组件的上下文可用时，对所述目标待更新组件进行更新处理。

通过上述方法，通过与目标待更新组件关联的目标代理组件判断所述目标待更新组件的上下文是否可用，从而在每一处组件更新时自动判断，避免了现有技术中在每一处应用组件更新的地方，都要手动判断上下文是否可用，所导致的组件更新的效率低的问题。

并且在组件更新处理之前，保证所述目标待更新组件的上下文是可用的，避免了现有技术中对于上下文是否可用存在误判和漏判，在上下文不可用时进行组件更新使应用崩溃，所导致的组件更新的安全性低的问题。

在步骤S110之前，所述组件更新方法还可以包括建立关联关系的步骤，建立关联关系的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，建立关联关系的步骤可以包括以下子步骤：

首先，获取代理组件和待更新组件。其次，建立所述代理组件和待更新组件之间的关联关系。

可选地，所述代理组件和待更新组件的对应关系不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述代理组件与所述待更新组件一一对应。代理组件可以包括三个不同的代理组件，分别为代理组件1、代理组件2、代理组件3，待更新组件可以包括三个不同的待更新组件，分别为待更新组件1、待更新组件2和待更新组件3。其中，所述代理组件1与所述待更新组件1对应，所述代理组件2与所述待更新组件2对应，所述代理组件3与所述待更新组件3对应。

又例如，在另一种可以替代的示例中，一个代理组件与多个待更新组件对应。代理组件可以包括代理组件1，待更新组件可以包括三个不同的待更新组件，分别为待更新组件1、待更新组件2和待更新组件3。其中，所述代理组件1与所述待更新组件1、待更新组件2和待更新组件3对应。

对于步骤S110，需要说明的是，通过步骤S110之前的步骤可以建立所述代理组件和所述待更新组件之间的关联关系，可以根据所述关联关系查找出与目标待更新组件关联的目标代理组件。

可选地，所述待更新组件的具体种类不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述待更新组件可以包括视图组件，例如View组件。需要说明的是，可以通过Activity组件对所述View组件进行控制。所述Activity组件是Android应用层开发的四大组件之一，主要负责和用户交互部分，有自己的生命周期，在其上可以布置按钮、文本框等各种控件，简单来说就是Android的UI部分。其中，所述Activity组件与所述View组件存在区别，所述Activity组件是四大组件中唯一一个用来和用户进行交互的组件，可以说所述Activity组件就是Android的视图层。进一步地，所述Activity组件相当于视图层中的控制层，用于控制和管理所述View组件，真正用来显示和处理事件的实际上是View组件。每个所述Activity组件内部都有一个Window对象，Window对象包含了一个DecorView(实际上就是FrameLayout)，通过setContentView给所述Activity组件设置显示的View实际上都是加到了DecorView中。

在现有技术中，所述Activity组件在控制所述View组件更新时，若当前上下文不可用，则会发生异常，导致应用崩溃。通常，在每一处更新视图组件的地方，都需要手动增加上下文是否可用的判断，以避免上下文不可用，所导致应用崩溃的问题。由于每一处更新视图组件的地方，都要手动增加上下文是否可用的判断，频繁增加判断及所增加的判断逻辑不统一等操作，易导致重复判断、错误判断、遗漏判断等问题，进而导致应用程序发生异常，导致应用程序崩溃。

又例如，在另一种可以替代的示例中，所述待更新组件可以包括Activity组件。所述Activity组件(页面)也有对应的上下文，所以所述Activity组件也可以被所述目标代理组件代理。

对于步骤S120，需要说明的是，所述控制所述目标代理组件判断所述目标待更新组件的上下文是否可用的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述目标待更新组件包括视图组件，步骤S120可以包括以下子步骤：

控制所述目标代理组件判断所述视图组件所属的当前页面是否可用。

详细地，一个视图组件不会单独存在，它会依附于一个特定的环境，在该特定环境下完成创建、更新和销毁的过程，这个环境即为上下文。当所述目标待更新组件包括视图组件时，所述视图组件的上下文为所述视图组件所属的当前页面。

其中，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，结合图3，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的步骤可以包括步骤S1211和步骤S1212。

步骤S1211，控制所述目标代理组件判断所述视图组件的上下文是否为页面类型。

步骤S1212，判断所述视图组件的当前页面是否可用。

需要说明的是，在判断所述视图组件所属的当前页面是否可用之前，需要判断所述视图组件的上下文是否为页面类型。当所述视图组件为所述View组件时，所述View组件的当前页面可以认为是Activity活动。进一步地，若所述视图组件的上下文为页面类型，则执行步骤S1212进行判断所述视图组件的当前页面是否可用。也就是说，可以判断所述View组件对应的Activity活动是否可用。

可选地，所述判断所述视图组件的当前页面是否可用的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，所述判断所述视图组件的当前页面是否可用的具体方式可以包括以下子步骤：

控制所述目标代理组件判断所述视图组件所属的当前页面是否处于正在结束的状态或已销毁的状态。

需要说明的是，在当前页面可用时，所述当前页面不能处于正在结束的状态或已销毁的状态。在当前页面处于正在结束或已销毁的状态时，说明当前上下文处于不安全状态，即为不可用状态，此时操作视图层更新，则会产生上下文不可用的异常，导致应用崩溃。

进一步地，在在所述视图组件的上下文非页面类型时，所述组件更新方法还包括以下子步骤：

获取所述视图组件上下文的页面，判断所述视图组件上下文的页面是否可用。

也就是说，若所述视图组件的上下文非页面类型，则获取所述视图组件上下文的页面，判断所述视图组件上下文的页面是否可用。详细地，有些如弹窗的上下文(通过getContext()方法获取，则为ContextWrapper类型)，需要通过递归的方式获取其所依附的页面(Activity活动)。如果最终没有获取到弹窗的上下文的页面(Activity活动)，则直接返回并发送信息表示当前上下文不可用。

其中，通过递归的方式获取弹窗上下文的页面指的是通过弹窗的上下文与页面的对应关系持续查找弹窗上下文的页面。类似地，为了检查A的直系家人(可追溯到祖先)是否有人当过兵，可以采用以下方法步骤：

首先，判断A自己是否当过兵。其次，若A没有当过兵，可以由A追溯到【A的爸爸】，将【A的爸爸】代入上述过程，重复进行判断，判断【A的爸爸】是否当过兵。如果【A的爸爸】没有当过兵，就根据A的直系家人不停的往上追溯，直到没有人可以追溯了或者找到当过兵的直系家人才停止。

对于步骤S130，需要说明的是，所述若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，步骤S130可以包括以下子步骤：

若所述目标待更新组件的上下文可用，则判断所述目标待更新组件是否可用，在所述目标待更新组件可用时，则对所述目标待更新组件进行更新处理。

也就是说，在判断所述目标待更新组件的上下文是否可用之后，还需要判断所述目标待更新组件是否可用，并在所述目标待更新组件可用时，对所述目标待更新组件进行更新处理。

其中，所述判断所述目标待更新组件是否可用的具体方式不受限制，可以根据实际应用需求进行设置。

例如，在一种可以替代的示例中，可以判断mTargetView是否为null，若mTargetView为null，则所述目标待更新组件不可用；若mTargetView不为null，则所述目标待更新组件可用。

需要说明的是，判断所述目标待更新组件是否可用的步骤可以包含于判断所述目标待更新组件的上下文是否可用之中，也就是说，判断所述目标待更新组件的上下文是否可用的步骤包括判断所述目标待更新组件是否可用的步骤。也就是说，所述判断所述目标待更新组件的上下文是否可用的步骤可以包括以下子步骤：

判断所述目标待更新组件是否可用；

若所述目标待更新组件可用，判断所述目标待更新组件的上下文是否可用。

因此，在判定所述目标待更新组件的上下文可用时，可以直接对所述目标待更新组件进行更新处理，不需要再判断所述目标待更新组件是否可用。

进一步地，在所述目标待更新组件的上下文不可用时，所述组件更新方法还可以包括以下子步骤：

拒绝对所述目标待更新组件进行更新处理。

也就是说，若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理；若所述目标待更新组件的上下文不可用，则拒绝对所述目标待更新组件进行更新处理。

进一步地，本申请实施例提供的组件更新方法可以应用于应用于模型-视图-控制器(Model-View-Controller，MVC)模式，为Controller层驱动View层提供安全机制。详细地，业务控制层Controller的持有了该目标视图组件的TargetView层的代理对象ProxyView，当数据变化需要更新视图时，由Controller调用代理对象ProxyView更新视图，此时代理对象ProxyView去检查该TargetView所在的上下文是否安全可用；若可用，则调用TargetView去更新视图。

需要说明的是，MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

其中，Model(模型)表示应用程序核心(比如数据库记录列表)，View(视图)显示数据(数据库记录)，Controller(控制器)处理输入(写入数据库记录)。MVC模式同时提供了对HTML、CSS和JavaScript的完全控制。Model(模型)是应用程序中用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据。View(视图)是应用程序中处理数据显示的部分，通常视图是依据模型数据创建的。Controller(控制器)是应用程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVC分层有助于管理复杂的应用程序，可以在一个时间内专门关注一个方面。例如，可以在不依赖业务逻辑的情况下专注于视图设计，同时也让应用程序的测试更加容易。MVC分层同时也简化了分组开发，不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

本申请实施例提供的组件更新方法还可以应用于模型-视图-表示器(Model-View-Presenter，MVP)模式，为Presenter层驱动View层更新提供安全机制。详细地，业务控制层Presenter持有目标视图组件TargetView的代理对象ProxyView，当数据变化需要更新视图组件时，由Presenter调用代理对象ProxyView更新视图，此时，代理对象ProxyView去检查所述目标视图组件TargetView所在的上下文是否安全可用，若可用，则调用所述目标视图组件TargetView进行视图更新处理。

需要说明的是，MVP从MVC演变而来，通过表示器将视图与模型巧妙地分开。在该模式中，视图通常由表示器初始化，它呈现用户界面(UI)并接受用户所发出命令，但不对用户的输入作任何逻辑处理，而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器，但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器，每个表示器完成该视图的一部分业务处理工作，降低了单个表示器的复杂程度，一个表示器也能被多个有着相同业务需求的视图复用，增加单个表示器的复用度。表示器包含大多数表示逻辑，用以处理视图，与模型交互以获取或更新数据等。模型描述了系统的处理逻辑，模型对于表示器和视图一无所知。

MVP的全称为Model-View-Presenter，Model提供数据，View负责显示，Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。

结合图4，本发明实施例还提供了一种组件更新装置100，可以应用于上述的电子设备10。其中，该组件更新装置100可以包括查找模块110、判断模块120和更新处理模块130。

所述查找模块110，用于根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件。在本实施例中，所述查找模块110可以用于执行图2所示的步骤S110，关于所述查找模块110的相关内容可以参照前文对步骤S110的具体描述。

所述判断模块120，用于控制所述目标代理组件判断所述目标待更新组件的上下文是否可用。在本实施例中，所述判断模块120可以用于执行图2所示的步骤S120，关于所述判断模块120的相关内容可以参照前文对步骤S120的具体描述。

所述更新处理模块130，用于在所述目标待更新组件的上下文可用时，对所述目标待更新组件进行更新处理。在本实施例中，所述更新处理模块130可以用于执行图2所示的步骤S130，关于所述更新处理模块130的相关内容可以参照前文对步骤S130的具体描述。

在本申请实施例中，对应于上述的组件更新方法，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序运行时执行上述组件更新方法的各个步骤。

其中，前述计算机程序运行时执行的各步骤，在此不再一一赘述，可参考前文对所述组件更新方法的解释说明。

综上所述，本申请实施例提供的组件更新方法和装置、电子设备及计算机可读存储介质，通过与目标待更新组件关联的目标代理组件判断所述目标待更新组件的上下文是否可用，从而在每一处组件更新时自动判断，避免了现有技术中在每一处应用组件更新的地方，都要手动判断上下文是否可用，所导致的组件更新的效率低的问题。

并且在组件更新处理之前，保证所述目标待更新组件的上下文是可用的，避免了现有技术中对于上下文是否可用存在误判和漏判，在上下文不可用时进行组件更新使应用崩溃，所导致的组件更新的安全性低的问题。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种组件更新方法，其特征在于，包括：

根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件；

控制所述目标代理组件判断所述目标待更新组件的上下文是否可用；

若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理。

2.如权利要求1所述的组件更新方法，其特征在于，所述方法还包括：

若所述目标待更新组件的上下文不可用，则拒绝对所述目标待更新组件进行更新处理。

3.如权利要求2所述的组件更新方法，其特征在于，所述目标待更新组件包括视图组件，所述控制所述目标代理组件判断所述目标待更新组件的上下文是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件所属的当前页面是否可用。

4.如权利要求3所述的组件更新方法，其特征在于，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件的上下文是否为页面类型；

若所述视图组件的上下文为页面类型，则判断所述视图组件的当前页面是否可用。

5.如权利要求4所述的组件更新方法，其特征在于，所述方法还包括：

若所述视图组件的上下文非页面类型，则获取所述视图组件上下文的页面，判断所述视图组件上下文的页面是否可用。

6.如权利要求3所述的组件更新方法，其特征在于，所述控制所述目标代理组件判断所述视图组件所属的当前页面是否可用的步骤，包括：

控制所述目标代理组件判断所述视图组件所属的当前页面是否处于正在结束的状态或已销毁的状态。

7.如权利要求1所述的组件更新方法，其特征在于，所述若所述目标待更新组件的上下文可用，则对所述目标待更新组件进行更新处理的步骤，包括：

若所述目标待更新组件的上下文可用，则判断所述目标待更新组件是否可用，在所述目标待更新组件可用时，则对所述目标待更新组件进行更新处理。

8.一种组件更新装置，其特征在于，包括：

查找模块，用于根据预先建立的代理组件与待更新组件之间的关联关系，查找出与目标待更新组件关联的目标代理组件；

判断模块，用于控制所述目标代理组件判断所述目标待更新组件的上下文是否可用；

更新处理模块，用于在所述目标待更新组件的上下文可用时，对所述目标待更新组件进行更新处理。

9.一种电子设备，其特征在于，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现权利要求1-7任意一项所述的组件更新方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，该程序被执行时实现权利要求1-7任意一项所述组件更新方法的步骤。

Images