应用程序处理方法、装置、设备及介质

技术领域

本申请的实施例涉及计算机技术领域，尤其涉及一种应用程序处理方法、装置、设备及介质。

背景技术

随着前端的技术发展和项目规模的增大，在前端技术中，基于微服务，将较大规模的项目拆分多个相互关联的子项目，并为多个相互关联的子项目提供统一的访问入口成为必然。例如，在基于微服务实现的全球广域网(World wide Web，简称Web)应用程序中，包括多个子应用程序(即小型前端应用程序，呈现形式为单页面应用程序)和主应用程序(又称为主站或者Portal站，为多个子应用提供统一的访问入口)。

在Web应用程序中，主应用程序提供的服务与子应用程序提供的服务之间、不同的子应用程序提供的服务之间可能存在重合。目前，用户在主应用程序和子应用程序上使用相同的服务时，主应用程序和子应用程序分别加载该服务对应的用户界面(UserInterface，简称UI)组件；或者，用户在不同的子应用程序上使用相同的服务时，不同的子应用程序分别加载该服务对应的UI组件。因此，主应用程序与子应用程序之间、不同的子应用程序之间存在共用的UI组件。

针对上述现象，如何进行Web应用程序中UI组件的处理，以提高子应用程序的页面显示效率，是亟需解决的问题。

发明内容

本申请的实施例提供一种应用程序处理方法、装置、设备及介质，用以提高子应用程序的页面显示效率。

第一方面，本申请提供一种应用程序处理方法，包括：

响应于检测到子应用程序的页面处理请求，确定目标组件，所述目标组件为所述子应用程序的UI组件；

在主应用程序的组件加载数据中，确定所述目标组件的相关数据，其中，所述主应用程序和所述子应用程序属于同一Web应用程序；

根据所述相关数据，显示所述子应用程序的页面。

在一种可能的实现方式中，所述页面处理请求包括所述子应用程序的组件加载请求，所述在主应用程序的组件加载数据中，确定目标组件的相关数据，包括：

从所述组件加载数据中，获取所述目标组件的资源数据。

在一种可能的实现方式中，所述组件加载数据包括所述Web应用程序的所有UI组件的资源数据，所述应用程序处理方法还包括：

响应于检测到所述主应用程序的组件加载请求，加载所述Web应用程序的所有UI组件的资源数据并缓存。

在一种可能的实现方式中，所述组件加载数据包括第一组件的资源数据，所述第一组件为所述主应用程序与所述子应用程序之间共用的UI组件，和/或，所述第一组件为不同的子应用程序之间共用的UI组件，所述应用程序处理方法还包括：

响应于检测到所述主应用程序的组件加载请求，加载所述第一组件的资源数据并缓存。

在一种可能的实现方式中，所述从所述组件加载数据中，获取所述目标组件的资源数据，包括：

如果确定所述目标组件属于所述第一组件，则从所述组件加载数据中，获取所述目标组件的资源数据。

在一种可能的实现方式中，所述应用程序处理方法还包括：

在所述Web应用程序启动的情形下，触发所述主应用程序的组件加载请求。

在一种可能的实现方式中，所述子应用程序的页面组件加载请求包括所述目标组件的标识信息，所述从所述组件加载数据中，获取目标组件的资源数据，包括：

在所述组件加载数据中，获取与所述目标组件的标识信息对应的资源数据。

在一种可能的实现方式中，所述根据所述相关数据，显示所述子应用程序的页面，包括：

通过所述主应用程序向所述子应用程序发送所述目标组件的资源数据；

在所述子应用程序中，根据所述目标之间的资源数据，进行所述子应用程序的页面渲染。

在一种可能的实现方式中，所述页面处理请求包括组件样式切换请求，所述在主应用程序的组件加载数据中，确定所述目标组件的相关数据，包括：

确定所述目标组件的目标样式；

在所述组件加载数据中，根据所述目标样式，确定所述目标组件的样式信息。

在一种可能的实现方式中，所述组件加载数据中包括多个全局样式变量，所述在所述组件加载数据中，根据所述目标样式，确定所述目标组件的样式信息，包括：

在所述组件加载数据中，确定与所述目标组件相关的目标全局样式变量；根据所述目标样式，确定所述目标全局样式变量的数值。。

在一种可能的实现方式中，所述根据所述相关数据，显示所述子应用程序的页面，包括：

根据所述目标全局样式变量的数值，在所述子应用程序中调用所述目标组件对应的样式函数，并显示所述子应用程序的页面。

另一方面，本申请提供一种应用程序处理装置，包括：

第一确定模块，用于响应于检测到子应用程序的页面处理请求，确定目标组件，所述目标组件为待加载的子应用程序的UI组件；

第二确定模块，用于在主应用程序的组件加载数据中，确定所述目标组件的相关数据，其中，所述主应用程序和所述子应用程序属于同一Web应用程序；

显示模块，用于根据所述相关数据，显示所述子应用程序的页面。

在一种可能的实现方式中，所述页面处理请求包括所述子应用程序的组件加载请求，所述第二确定模块，具体用于：

从所述组件加载数据中，获取所述目标组件的资源数据。

在一种可能的实现方式中，所述组件加载数据包括所述Web应用程序的所有UI组件的资源数据，所述应用程序处理装置还包括：

第一加载模块，用于响应于检测到所述主应用程序的组件加载请求，加载所述Web应用程序的所有UI组件的资源数据并缓存。

在一种可能的实现方式中，所述组件加载数据包括第一组件的资源数据，所述第一组件为所述主应用程序与所述子应用程序之间共用的UI组件，和/或，所述第一组件为不同的子应用程序之间共用的UI组件，所述应用程序处理装置还包括：

第二加载模块，用于响应于检测到所述主应用程序的组件加载请求，加载所述第一组件的资源数据并缓存。

在一种可能的实现方式中，所述第二确定模块，具体用于：

如果确定所述目标组件属于所述第一组件，则从所述组件加载数据中，获取所述目标组件的资源数据。

在一种可能的实现方式中，所述应用程序处理装置还包括：

触发模块，用于在所述Web应用程序启动的情形下，触发所述主应用程序的组件加载请求。

在一种可能的实现方式中，所述子应用程序的页面组件加载请求包括所述目标组件的标识信息，所述第二确定模块，具体用于：

在所述组件加载数据中，获取与所述目标组件的标识信息对应的资源数据。

在一种可能的实现方式中，所述显示模块，具体用于：

通过所述主应用程序向所述子应用程序发送所述目标组件的资源数据；

在所述子应用程序中，根据所述目标之间的资源数据，进行所述子应用程序的页面渲染。

在一种可能的实现方式中，所述页面处理请求包括组件样式切换请求，所述第二确定模块，具体用于：

确定所述目标组件的目标样式；

在所述组件加载数据中，根据所述目标样式，确定所述目标组件的样式信息。

在一种可能的实现方式中，所述组件加载数据中包括多个全局样式变量，所述第二确定模块，具体用于：

在所述组件加载数据中，确定与所述目标组件相关的目标全局样式变量；

根据所述目标样式，确定所述目标全局样式变量的数值。

在一种可能的实现方式中，所述显示模块，具体用于：

根据所述目标全局样式变量的数值，在所述子应用程序中调用所述目标组件对应的样式函数，并显示所述子应用程序的页面。

第三方面，本申请提供一种电子设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的实现方式所述的应用程序处理方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的实现方式所述的应用程序处理方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如上第一方面以及第一方面各可能的实现方式所述的应用程序处理方法。

本申请提供的应用程序处理方法、装置、设备及存储介质，响应于检测到子应用程序的页面处理请求，确定目标组件，目标组件为子应用程序的UI组件。在主应用程序的组件加载数据中，确定目标组件的相关数据。根据该相关数据，显示子应用程序的页面。因此，子应用程序在页面显示时，可从主应用程序的组件加载数据中，直接获取目标组件的相关数据，有效地提高了子应用程序的组件数据获取效率，进而提高子应用程序的页面显示效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请一实施例提供应用程序处理方法适用的应用场景示例图；

图2为本申请一实施例提供应用程序处理方法的流程示意图；

图3为本申请另一实施例提供应用程序处理方法的流程示意图；

图4为本申请另一实施例提供应用程序处理方法的流程示例图；

图5为本申请一实施例提供应用程序处理装置的结构示意图；

图6为本申请一实施例提供电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

首先对本申请的实施例所涉及的名词进行解释：

1、全球广域网(World wide Web，简称Web)应用程序：无需安装、且通常基于浏览器运行的应用程序。

2、基于微服务的前端架构：又称为微前端。在该前端架构中，基于微服务的概念，将较大规模的项目拆分为多个相互关联的子项目，并为多个子项目提供统一的访问入口，便于用户使用各个子项目，又方便开发人员对各个子项目进行独立开发、独立测试、独立发布，有效提高前端的开发效率。

3、用户界面(User Interface，简称UI)组件：用户界面上的功能模块，例如，用户界面上的按钮、编辑框、进度滚动条、字体等。为了避免重复开发相同的功能模块，减少代码冗余，开发人员将用户界面上的功能模块抽象为UI组件，便于不同的用户界面直接调动。通常，应用程序启动后，首先要加载页面上的UI组件，再根据加载的UI组件进行页面渲染。

4、UI组件的资源数据：在页面上进行UI组件的组件视图渲染时所需要的配置参数，例如，UI组件的图像、文本、样式等。

在基于微服务开发的Web应用程序中，包括多个子应用程序和一个主应用程序，子应用程序为单页面应用程序，主应用程序又称为主站或者Portal站，在开发过程中，子应用程序又称为子项目，主应用程序又称为主项目。主应用程序提供各个子应用程序的访问入口。

用户打开主应用程序、子应用程序时，主应用程序、子应用程序进行UI组件的加载，以向用户提供相应的服务。在Web应用程序中，主应用程序提供的服务与子应用程序的服务之间可能存在重合、不同的子应用程序提供的服务之间可能存在重合，换句话说，主应用程序与子应用程序之间存在可能共用的UI组件、不同的子应用程序之间可能存在共用的UI组件。例如，主应用程序与子应用程序采用同样的字体、同样的编辑框，又如，不同的子应用程序采用相同的按钮、相同的日历等。

主应用程序与子应用程序之间存在可能共用的UI组件、不同的子应用程序之间可能存在共用的UI组件，影响到Web应用程序中UI组件的处理效率。

例如，在相关技术中，主应用程序、子应用程序独立进行UI组件加载，比如，用户打开主应用程序，主应用程序进行UI组件的加载，以提供该UI组件对应的服务；用户打开子应用程序，子应用程序进行UI组件的加载，以提供该UI组件对应的服务。该方式下，主应用程序与子应用程序很可能分别进行相同UI组件的加载，导致UI组件的重复加载，UI组件的加载效率不高。

为提高UI组件的处理效率，进而提高子应用程序的页面显示效率，本申请的实施例提供了一种应用程序处理方法，在该方法中，在主应用程序的组件加载数据中，确定子应用程序的UI组件的相关数据，根据确定的UI组件的相关数据，进行子应用程序的页面显示，能够避免子应用程序重复向服务器请求UI组件的相关数据，提高了子应用程序的页面显示效率，也有利于降低用户终端的性能开销。

图1为本申请的实施例提供的应用程序处理方法适用的应用场景示例图。在应用场景中，包括多个用户终端101和服务器102，各用户终端101通过网络与服务器102进行通信。用户可在用户终端101的浏览器上打开Web应用程序，例如，用户可通过在用户终端101上输入主应用程序的统一资源定位器(Uniform Resource Locator，URL)，打开主应用程序；或者，通过输入子应用程序的URL，打开子应用程序。以主应用程序为例，主应用程序启动时，主应用程序通过用户终端101向服务器102请求页面资源。在获得主应用程序的页面资源后，进行主应用程序的页面显示。

其中，用户终端101例如计算机、平板电脑、手机、可穿戴式智能设备、智能家居设备等，图1以用户终端101为计算机为例。服务器102例如为分布式服务器或者集中式服务器。

下面以具体地实施例对本申请的实施例的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

示例性的，本申请各方法实施例的执行主体为电子设备，电子设备例如为图1所示的用户终端101。

图2为本申请一实施例提供的应用程序处理方法的流程示意图。如图2所示，该方法包括：

S201、响应于检测到子应用程序的页面处理请求，确定目标组件。

其中，子应用程序的页面处理请求，用于请求对子应用程序进行页面处理。目标组件为子应用程序的UI组件，也即目标组件为子应用程序的页面上的UI组件，目标组件的数量为一个或多个。

本步骤中，在检测到子应用程序的页面处理请求时，可根据页面处理请求，确定目标组件。例如，若页面处理请求涉及子应用程序的所有UI组件，则可将子应用程序的所有UI组件确定为目标组件；若页面处理请求涉及子应用程序上的一个或多个UI组件，则可将页面处理请求涉及的一个或多个UI组件，确定为目标组件。

S202、在主应用程序的组件加载数据中，确定目标组件的相关数据。

其中，主应用程序与子应用程序属于同一Web应用程序，主应用程序和子应用程序的关系可参照前述相关内容的描述，不再赘述。主应用程序的组件加载数据包括由主应用程序加载的多个UI组件的资源数据。

本步骤中，在确定目标组件后，可在主应用程序的组件加载数据中，查找并得到目标组件的相关数据，其中，目标组件的相关数据可以为目标组件的资源数据中的一项或多项，例如，目标组件的相关数据为目标组件的图像、文本、样式中的一项或多项。

S203、根据相关数据，显示子应用程序的页面。

本步骤中，在得到目标组件的相关数据后，根据目标组件的相关数据，在子应用程序的页面上进行目标组件的视图渲染，并显示子应用程序的页面。因此，在子应用程序的页面显示过程，能够从主应用程序的组件加载数据中获得目标组件的相关数据，减少了子应用程序与主应用程序重复加载的数据量，提高了子应用程序的页面显示效率。

本申请实施例中，检测到子应用程序的页面处理请求时，在主应用程序的组件加载数据中，确定子应用程序上目标组件的相关数据，子应用程序无需向服务器请求加载目标组件的相关数据，从而减少了子应用程序与主应用程序重复加载的数据量，提高了子应用程序的页面显示效率，也有利于降低用户终端的性能开销。

在一些实施例中，S201的一种可能的实现方式包括：响应于检测到子应用程序的页面处理请求，确定目标组件的标识信息。S202的一种可能的实现方式包括：根据目标组件的标识信息，在主应用程序的组件加载数据中，获取目标组件的相关数据。因此，依据目标组件的标识信息，有效提高了获得目标组件的相关数据的效率和准确性。

其中，在开发过程中，为UI组件设置对应的标识信息，UI组件的标识信息唯一。UI组件的标识信息例如为UI组件的组件编号、和/或组件名称。

具体的，在确定目标组件的标识信息时：页面处理请求中包括目标组件的标识信息，因此，可从页面处理请求中，直接获得目标组件的标识信息；或者，预先设置有子应用程序与子应用程序的UI组件的标识信息的对应关系，在检测到子应用程序的页面处理请求时，根据该对应关系，确定子应用程序的UI组件的标识信息，进而得到目标组件的标识信息。

具体的，得到目标组件的标识信息后，以目标组件的标识信息为关键字，在主应用程序的组件加载数据中，查找目标组件的相关数据。

在一些实施例中，子应用程序的页面处理请求包括子应用程序的组件加载请求，组件加载请求用于请求加载子应用程序的各UI组件的资源数据，因此，可以基于主应用程序的组件加载数据，确定目标组件的资源数据，避免子应用程序和主应用程序对目标组件的资源数据的重复加载。

基于子应用程序的页面处理请求包括子应用程序的组件加载请求，图3为本申请另一实施例提供的应用程序处理方法的流程示意图。如图3所示，该方法包括：

S301、响应于检测到子应用程序的组件加载请求，确定目标组件。

本步骤中，可在检测到启动子应用程序的请求时、或者在检测到子应用程序启动时、或者在子应用程序的启动过程中，触发子应用程序的组件加载请求，以请求加载子应用程序的各UI组件的资源数据。

可选的，在检测到启动子应用程序的请求时、或者在检测到子应用程序启动时、或者在子应用程序的启动过程中，触发子应用程序的页面加载请求，其中，页面加载请求包括组件加载请求，页面加载请求用于请求加载子应用程序的页面资源，子应用程序的页面资源包括子应用程序的各UI组件的资源数据和子应用程序上未组件化的各视图元素的资源数据。未组件化的各视图元素的资源数据，例如子应用程序的页面背景的颜色。

本步骤中，在检测到子应用程序的组件加载请求时，由于在Web应用程序中子应用程序为单页面应用程序，子应用程序启动时需要加载子应用程序的所有UI组件的资源数据，可将子应用程序的所有UI组件确定为目标组件。

S302、从组件加载数据中，获取目标组件的资源数据。

本步骤中，在确定目标组件后，可从组件加载数据中多个UI组件的资源数据中，查找并得到目标组件的资源数据。

在一些实施例中，S301的一种可能的实现方式包括：响应于检测到子应用程序的组件加载请求，确定目标组件的标识信息。S302的一种可能的实现方式包括：在组件加载数据中，获取与目标组件的标识信息对应的资源数据。因此，依据目标组件的标识信息，提高获得目标组件的资源数据的效率和准确性。其中，组件的标识信息、以及响应于检测到子应用程序的组件加载请求确定目标组件的标识信息的过程可参照前述实施例的描述，不再赘述。组件加载数据包括多个组件的标识信息与多个组件的资源数据的对应关系。

S303、根据目标组件的资源数据，显示子应用程序的页面。

本步骤中，在得到目标组件的资源数据后，可在子应用程序中，进行目标组件的组件视图的渲染，并进行子应用程序中未组件化的视图元素的渲染，实现子应用程序的页面渲染并显示。

本申请实施例中，检测到子应用程序的页面加载请求时，在主应用程序的组件加载数据中，确定子应用程序上目标组件的资源数据，子应用程序无需向服务器请求加载目标组件的资源数据，从而避免子应用程序与主应用程序重复加载目标组件的资源数据，提高了子应用程序的页面显示效率，也有利于降低用户终端的性能开销。

在一些实施例中，主应用程序的组件加载数据包括Web应用程序的所有UI组件的资源数据，其中，所有UI组件包括Web应用程序中主应用程序的所有UI组件和所有子应用程序的所有UI组件。

因此，在检测到子应用程序的组件加载请求时(例如检测到子应用程序启动时)，可从主应用程序的组件加载数据中，获得子应用程序中所有UI组件的资源数据，子应用程序无需向服务器重复请求UI组件的资源数据，有效地避免了主应用程序和子应用程序之间、不同的子应用程序之间重复向服务器请求加载相同UI组件的资源数据，提高了子应用程序的UI组件加载效率，提高子应用程序的页面显示效率。

可选的，响应于检测到主应用程序的组件加载请求(例如，在主应用程序启动时，触发主应用程序的组件加载请求)，加载Web应用程序的所有UI组件的资源数据并缓存，得到主应用程序预先缓存的组件加载数据。其中，在检测到主应用程序的组件加载请求时，向服务器请求加载Web应用程序的所有UI组件的资源数据，接收服务器返回的Web应用程序的所有UI组件的资源数据、并进行缓存。

在一些实施例中，主应用程序的组件加载数据包括第一组件的资源数据，其中，第一组件为主应用程序与子应用程序之间共用的UI组件，和/或第一组件为不同的子应用程序之间共用的UI组件。换句话说，主应用程序的组件加载数据包括：主应用程序与子应用程序之间共用的UI组件的资源数据，和/或不同的子应用程序之间共用的UI组件的资源数据。

在第一组件为主应用程序与子应用程序之间共用的UI组件、和/或不同的子应用程序之间共用的UI组件时，主应用程序已加载过第一组件的资源数据，子应用程序在进行组件加载时，无需再向服务器请求加载第一组件的资源数据。因此，通过主应用程序对第一组件的资源数据的预先加载，避免主应用程序与子应用程序重复向服务器请求加载相同UI组件的资源数据、和/或不同的子应用程序重复向服务器请求加载相同UI组件的资源数据。

考虑到子应用程序的UI组件中还可能包括仅该子应用程序使用的UI组件，因此，S302的一种可能的实现方式包括：如果确定目标组件属于第一组件，则从组件加载数据中，获取目标组件的资源数据。针对属于主应用程序与子应用程序共用的UI组件、和/或不同子应用程序之间共用的UI组件，可由主应用程序预先加载这些UI组件的资源数据，子应用程序从主应用程序预先加载的UI组件的资源数据中获取目标组件的资源数据，有效地避免了主主应用程序与子应用程序进行相同UI组件的重复加载、和/或避免了不同的子应用程序之间进行相同UI组件的重复加载，提高了UI组件的加载效率，进而提高了子应用程序的页面显示效率。

进一步的，针对不属于第一组件的目标组件，子应用程序可向服务器请求加载该目标组件的资源数据，以实现子应用程序的页面的成功显示。

可选的，响应于检测到主应用程序的组件加载请求(例如，在主应用程序启动时，触发主应用程序的组件加载请求)，加载第一组件的资源数据并缓存，得到主应用程序预先缓存的组件加载数据。其中，在检测到主应用程序的组件加载请求时，向服务器请求加载第一组件的资源数据，接收服务器返回的第一组件的资源数据、并进行缓存。主应用程序的组件加载请求例如包括第一组件的组件标识，或者，服务器上预先设置第一组件的组件标识与组件加载请求的对应关系。

进一步的，在响应于检测到主应用程序的组件加载请求，加载Web应用程序的所有UI组件的资源数据并缓存的情形下，或者，在响应于检测到主应用程序的组件加载请求，加载第一组件的资源数据并缓存的情形下，可在Web应用程序启动的情形下，触发主应用程序的组件加载请求。例如，在检测到用户输入的Web应用程序启动请求时，或者，在Web应用程序启动过程中，触发主应用程序的组件加载请求。其中，用户可通过访问主应用程序或者子应用程序来请求启动Web应用程序，例如，在浏览器中输入主应用程序的URL或者输入子应用程序的URL。

因此，在Web应用程序启动的情况下，不论当前启动的是主应用程序还是子应用程序，都可以触发主应用程序的组件加载请求，以尽早得到主应用程序的组件加载数据，例如得到Web应用程序的所有UI组件的资源数据或者得到第一组件的资源数据，避免在后续启动Web应用程序中的其他应用程序时，可直接从主应用程序的组件加载数据中，得到共用的UI组件的资源数据，避免或者减少Web应用程序重复进行相同UI组件的加载。

在一些实施例中，主应用程序与子应用程序之间可以相互进行通信。基于主应用程序与子应用程序之间可以相互进行通信、以及目标组件的相关数据包括目标组件的资源数据，S203或S303的一种可能的实现方式包括：通过主应用程序向子应用程序发送目标组件的资源数据；在子应用程序中，根据目标组件的资源数据，进行子应用程序的页面渲染。

具体的，在得到目标组件的资源数据后，通过主应用程序向发送组件加载请求的子应用程序发送目标组件的资源数据，例如，主应用程序通过vue工具中的props对象，将目标组件的资源数据下发给子应用程序，其中，vue是一种前端开发框架。子应用程序根据目标组件的资源数据，进行目标组件的组件视图的渲染，实现对子应用程序的页面渲染。

可选的，子应用程序可向主应用程序发送组件加载请求。主应用程序基于子应用程序的组件加载请求，确定目标组件，在自身的组件加载数据中，确定目标组件的相关数据。主应用程序将目标组件的相关数据发送给子应用程序。因此，通过建立主应用程序与各个子应用程序之间的通信，能够由主应用程序实现本实施例提供的应用程序处理方法。各子应用程序在进行页面显示时，都可以从主应用程序的组件加载数据中进行组件的资源数据的获取，避免或者减少主应用程序与子应用程序之间、或者不同的子应用程序之间重复进行相同UI组件的加载，提高子应用程序的页面显示效率。

主应用程序与子应用程序之间存在共用的UI组件、不同的子应用程序治之间存在共用的UI组件，除了主应用程序与子应用程序之间或者不同的子应用程序之间可能重复进行UI组件的资源数据的加载之外，主应用程序与子应用程序之间或者不同的子应用程序之间，同一UI组件的样式可能不统一。例如，在主应用程序的页面和子应用程序的页面上、或者在不同的子应用程序的页面上，同一UI组件的颜色不同、字体不同、背景图像不同。通常需要用户在主应用程序、子应用程序上多次修改UI组件的样式，给用户带来不便。例如，用户在主应用程序上手动将UI组件的样式由样式1切换为样式2后，还需要在子应用程序上手动将该UI组件的样式由样式1切换为样式2。

在一些实施例中，为提高Web应用程序中UI组件的样式切换的灵活性和便捷性，提高子应用程序的页面显示效率，子应用程序的页面处理请求可包括子应用程序的组件样式切换请求，组件样式切换请求用于请求对子应用程序的UI组件进行样式切换。因此，可基于主应用程序的组件加载数据，确定目标组件的样式信息，根据样式信息，实现目标组件的样式切换。

基于子应用程序的页面处理请求包括子应用程序的组件样式切换请求，图4为本申请另一实施例提供的应用程序处理方法的流程示意图。如图4所示，该方法包括：

S401、响应于检测到子应用程序的组件样式切换请求，确定目标组件、以及目标组件的目标样式。

其中，子应用程序的组件样式切换请求可由用户触发，也可以有主应用程序触发。例如，在子应用程序启动的情况下，用户在子应用程序的页面上请求将目标组件的样式切换为目标样式。又如，在主应用程序启动的情况下，用户在主应用程序的页面上请求将目标组件的样式切换为目标样式，主应用程序在进行自身页面上目标组件的样式切换时，可向启动的子应用程序发送对目标组件进行样式切换的组件样式切换请求，从而无需用户再手动在子应用程序上进行目标组件的样式切换。

其中，子应用程序的组件样式切换请求包括目标组件的标识信息和目标组件的目标样式，目标组件为组件样式切换请求指示子应用程序进行样式切换的UI组件，目标样式即目标组件切换后的样式。

其中，目标组件的样式例如为目标组件的皮肤颜色、目标组件的形状、目标组件的字体、等等。比如，组件样式切换请求指示子应用程序将目标组件的皮肤颜色从白色切换为灰色，则目标组件的目标样式为目标组件的皮肤为灰色；组件样式切换请求指示子应用程序将目标组件的字体从宋体切换为楷体，则目标组件的目标样式为目标组件的字体为楷体。

本步骤中，在检测到子应用程序的组件样式切换请求后，可从组件样式切换请求中获取目标组件的标识信息，并获取目标组件的目标样式。目标组件的数量可为一个或多个，不同的目标组件可对应不同或相同的目标样式。

S402、在主应用程序的组件加载数据中，根据目标样式，确定目标组件的样式信息。

其中，UI组件的样式信息用于设置UI组件的样式。

进一步的，UI组件的样式信息包括UI组件的样式函数，样式函数为通过编程语言实现的样式方法，用于实现为UI组件设置相应样式的功能。例如，用于实现UI组件的皮肤颜色切换的样式函数。

本步骤中，主应用程序的组件加载数据包括不同UI组件的样式信息。在确定目标组件和目标组件的样式信息后，可在主应用程序的组件加载数据中，获取目标组件的样式信息，并根据目标样式对目标组件的样式信息进行更新。因此，主应用程序、或者其他子应用程序也可以根据更新的目标组件的样式信息进行目标组件的渲染，实现目标组件的目标样式在主应用程序、不同的子应用程序上的统一，无需用户在主应用程序、各子应用程序上一一进行目标组件的目标样式的切换，提高了用户体验。

例如，可从主应用程序的组件加载数据中，获取用于为目标组件设置皮肤颜色的样式函数。在目标样式为目标组件的皮肤颜色为白色时，可根据用于为目标组件设置皮肤颜色的样式函数，确定将目标组件的皮肤颜色设置为白色的样式函数，并确定目标组件默认的样式函数为将目标组件的皮肤颜色设置为白色的样式函数。

S403、根据目标组件的样式信息，显示子应用程序的页面。

本步骤中，在确定目标组件的样式信息后，可刷新子应用程序的页面，并根据目标组件的样式信息，渲染目标组件，重新显示子应用程序的页面。

本申请实施例中，在检测到子应用程序的组件样式切换请求时，确定目标组件和目标组件的目标样式，在主应用程序的组件加载数据中，根据目标样式，确定目标组件的样式信息，根据目标组件的样式信息，显示子应用程序的页面，提高了目标组件的样式切换的灵活性和便捷性，进而提高了子应用程序的页面显示效率，提高了用户体验。

在一些实施例中，组件加载数据中包括多个全局样式变量，S402的一种可能的实现方式包括：在组件加载数据中，确定与目标组件相关的目标全局样式变量；根据目标样式，确定目标全局样式变量的数值。S403的一种可能的实现方式包括：根据目标全局样式变量的数值，在子应用程序中将目标组件的样式切换为目标样式；显示样式切换后的子应用程序的页面。

其中，主应用程序的组件加载数据中包括多个全局样式变量，不同的UI组件对应不同的全局样式变量。示例性的，针对一个UI组件，UI组件的不同类型的样式可以分别对应一个全局样式变量，例如，UI组件的皮肤颜色对应全局样式变量a1，U1组件的字体对应全局样式变量a2，当a1等于1时表示皮肤颜色为白色，当a1等于2时，表示皮肤颜色为灰色。或者，针对一个UI组件，UI组件的不同类型的样式可以都对应同一个全局样式变量，例如，全局样式变量a3，a3等于1时，表示皮肤颜色为白色、且字体为楷体，a3等于2时，表示皮肤颜色为灰色、且字体为宋体。

在采用全局样式变量时，开发人员针对相同组件的样式可以仅开发一个样式函数和一个全局样式变量，通过改变全局样式变量的数值，来改变样式函数的功能，实现组件样式的切换，而无需为各个样式撰写单独的样式函数。例如，全局样式变量a1的数值为1时，样式函数的功能为将组件的皮肤设置为白色，全局样式变量a1的数值为2时，样式函数的功能为将组件的皮肤设置为灰色，而无需开发一个用于设置皮肤颜色为白色的样式函数、再开发一个用于设置皮肤颜色为灰色的样式函数，而且无需为每个应用程序单独编写相同的样式函数。因此，一方面减少了开发人员的工作量，另一方面只需要改变全局样式变量的值，就能够实现组件样式的切换，提高了组件样式的切换统一性、灵活性和效率，进而提高了子应用程序的页面显示效率。

具体的，在组件加载数据中，可确定与目标组件相关的目标全局样式变量，在根据目标样式，确定目标全局样式变量的值，还在组件加载数据中更新目标全局样式变量的值，以便主应用程序、其它子应用程序在进行组件加载时能够自动将目标组件的样式切换为目标样式。在确定目标全局样式变量的值之后，可通过在子应用程序中调用相应的样式函数，将目标组件的样式切换为目标样式，显示样式切换后的子应用程序的页面。例如，将目标全局样式变量的数值传递到子应用程序的样式文件中，样式文件例如层叠样式表(CascadingStyle Sheets，CSS)。通过运行样式文件(样式文件中包括样式函数)，实现对子应用程序中目标组件的样式切换。因此，通过改变全局样式变量，即可实现UI组件的样式切换。

图5为本申请一实施例提供的应用程序处理装置500的结构示意图。如图5所示，该应用程序处理装置500包括：第一确定模块501、第二确定模块502和显示模块503。

第一确定模块501，用于响应于检测到子应用程序的页面处理请求，确定目标组件，目标组件为待加载的子应用程序的用户界面UI组件；

第二确定模块502，用于在主应用程序的组件加载数据中，确定目标组件的相关数据，其中，主应用程序和子应用程序属于同一全球广域网Web应用程序；

显示模块503，用于根据相关数据，显示子应用程序的页面。

本申请实施例中，检测到子应用程序的页面处理请求时，在主应用程序的组件加载数据中，确定子应用程序上目标组件的相关数据，子应用程序无需向服务器请求加载目标组件的相关数据，从而减少了子应用程序与主应用程序重复加载的数据量，提高了子应用程序的页面显示效率，也有利于降低用户终端的性能开销。

在一种可能的实现方式中，页面处理请求包括子应用程序的组件加载请求，第二确定模块502，具体用于：

从组件加载数据中，获取目标组件的资源数据。

在一种可能的实现方式中，组件加载数据包括Web应用程序的所有UI组件的资源数据，应用程序处理装置500还包括：

第一加载模块(未示出)，用于响应于检测到主应用程序的组件加载请求，加载Web应用程序的所有UI组件的资源数据并缓存。

在一种可能的实现方式中，组件加载数据包括第一组件的资源数据，第一组件为主应用程序与子应用程序之间共用的UI组件，和/或，第一组件为不同的子应用程序之间共用的UI组件，应用程序处理装置500还包括：

第二加载模块(未示出)，用于响应于检测到主应用程序的组件加载请求，加载第一组件的资源数据并缓存。

在一种可能的实现方式中，第二确定模块502，具体用于：

如果确定目标组件属于第一组件，则从组件加载数据中，获取目标组件的资源数据。

在一种可能的实现方式中，应用程序处理装置500还包括：

触发模块(未示出)，用于在Web应用程序启动的情形下，触发主应用程序的组件加载请求。

在一种可能的实现方式中，子应用程序的页面组件加载请求包括目标组件的标识信息，第二确定模块502，具体用于：

在组件加载数据中，获取与目标组件的标识信息对应的资源数据。

在一种可能的实现方式中，显示模块503，具体用于：

通过主应用程序向子应用程序发送目标组件的资源数据；

在子应用程序中，根据目标之间的资源数据，进行子应用程序的页面渲染。

在一种可能的实现方式中，页面处理请求包括组件样式切换请求，第二确定模块502，具体用于：

确定目标组件的目标样式；

在组件加载数据中，根据目标样式，确定目标组件的样式信息。

在一种可能的实现方式中，组件加载数据中包括多个全局样式变量，第二确定模块502，具体用于：

在组件加载数据中，确定与目标组件相关的目标全局样式变量；

根据目标样式，确定目标全局样式变量的数值。

在一种可能的实现方式中，显示模块503，具体用于：

根据目标全局样式变量的数值，在子应用程序中将目标组件的样式切换为目标样式；

显示样式切换后的子应用程序的页面。

本申请实施例提供的应用程序处理装置，可用于执行上述的方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

图6为本申请一实施例提供的电子设备的硬件结构示意图。如图6所示，本实施例提供的电子设备600包括：至少一个处理器601和存储器602。该电子设备600还包括通信部件603。其中，处理器601、存储器602以及通信部件603通过总线604连接。

在具体实现过程中，至少一个处理器601执行存储器602存储的计算机执行指令，使得至少一个处理器601执行如上的应用程序处理方法。

处理器601的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

在上述的图6所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

本申请还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上的应用程序处理方法。

本申请还提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如上的应用程序处理方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。