微前端页面的控制方法、装置、终端设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种微前端页面的控制方法、装置、终端设备及存储介质。

背景技术

目前，在前端应用页面的展示场景中，主要基于多页Web应用(multi page webapplication，MPA)和单页Web应用(single page web application，SPA)实现。但是MPA在页面重刷会出现明显的断点，而SPA无需刷新页面却难以兼容不同框架的应用。因此，具备SPA的无刷新特点以及能够兼容不同框架应用的微前端架构Single-SPA被广泛关注。

在相关技术中，Single-SPA属于JavaScript微前端框架，其能够将多个独立的子应用动态组合到一个主应用中，从而实现在主应用中访问所有子应用的所有功能页面。但是在切换子应用页面时需要获取页面数据，当页面数据处理不好时，主应用页面会显示短暂的空白页面，甚至当页面数据缺失时，主应用页面会一直显示空白页面，对用户体验非常不友好。可见，当前单页面应用存在页面控制不够精准的问题。

发明内容

本申请实施例的目的在于提供一种微前端页面的控制方法、装置、终端设备及存储介质，旨在解决当前单页面应用存在页面控制不够精准的问题。

第一方面，本申请实施例提供了一种微前端页面的控制方法，包括：

获取子应用接入到主应用时的第一路由信息，第一路由信息包括子应用的所有功能页面的路由信息；

将第一路由信息注册到主应用，得到注册记录；

基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配；

若第二路由信息未匹配到第一路由信息，则显示预设容错页面。

在本实施例中，通过将子应用的第一路由信息注册到主应用中，以使主应用能够访问子应用，并能够在同一个页面下控制不同子应用的功能页面；以及以路由信息作为匹配依据，确定主应用是否存在待切换页面对应子应用的页面数据，从而实现路由级的页面控制；并在第二路由信息未匹配到第一路由信息时，即页面数据不存在时，直接跳转至预设容错页面，使得页面不会出现空白而影响用户体验，提高微前端页面的控制精准度，为微前端页面提供实际有效的控制策略。

进一步地，获取子应用接入到主应用时的第一路由信息之前，还包括：

基于子应用的配置文件对应的文件链接，将配置文件加载至主应用，配置文件中包含子应用的所有功能页面的第一路由信息。

在本实施例中，通过将子应用的配置文件加载至主应用，实现将子应用接入到主应用，以使主应用能够访问子应用的所有功能页面。

进一步地，将第一路由信息注册到主应用，得到注册记录，包括：

监听主应用的页面路由切换事件；

若监听到主应用的页面路由信息发生变化，则将子应用的第一路由信息添加至主应用的路由信息表中，并将添加第一路由信息后的路由信息表作为注册记录。

在本实施例中，通过监听主应用的页面路由切换事件，实现在主应用动态注册子应用，而减轻主应用的数据运行负荷，提高主应用对路由信息进行数据处理时的效率。

进一步地，第一路由信息包括第一页面路径，第二路由信息包括第二页面路径，基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配，包括：

获取主应用的待切换页面的页面链接；

从页面链接中，确定待切换页面的第二页面路径；

将第二页面路径与注册记录中的所有第一页面路径匹配。

在本实施例中，页面路径是路由信息自带的信息，通过对页面路径进行匹配，以确定主应用待切换的页面是否存在，而无需对路由信息做数据加工等进一步处理，简化路由信息处理过程和减低处理过程的运算量。

进一步地，基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配之后，还包括：

若第二路由信息成功匹配到第一路由信息，则显示第一路由信息对应的功能页面。

在本实施例中，通过路由信息确定出主应用的待切换页面存在，则显示对应的功能页面。

进一步地，第一路由信息还包括功能页面的页面图标，将显示第一路由信息对应的功能页面之后，还包括：

获取主应用的菜单栏信息表，菜单栏信息表中包含有第三路由信息；

对第一路由信息与第三路由信息进行匹配；

若第一路由信息与第三路由信息匹配成功，则在主应用的菜单栏展示第一路由信息的页面图标。

在本实施例中，由于主应用菜单通常提供菜单收起功能，此时菜单栏宽度变小，不足以展示功能名称，因此通过将第一路由信息的页面图标展示在主应用的菜单栏，便于用户切换功能。

进一步地，基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配之后，还包括：

若第二路由信息成功匹配到第一路由信息，则验证主应用是否具有第一路由信息对应的功能页面的访问权限；

若主应用不具有访问权限，则显示预设的权限提示页面。

在本实施例中，通过访问权限验证，并在主应用不具有访问子应用的权限时，显示权限提示页面，避免主应用无法显示子应用的功能页面而处于空白页面，进一步为微前端的页面控制策略提供精准有效的控制方式。

第二方面，本申请实施例提供了一种微前端页面的控制装置，包括：

获取模块，用于获取子应用接入到主应用时的第一路由信息，第一路由信息包括子应用的所有功能页面的路由信息；

注册模块，用于将第一路由信息注册到主应用，得到注册记录；

匹配模块，用于基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配；

显示模块，用于若第二路由信息未匹配到第一路由信息，则显示预设容错页面。

进一步地，控制装置，还包括：

加载模块，用于基于子应用的配置文件对应的文件链接，将配置文件加载至主应用，配置文件中包含子应用的所有功能页面的第一路由信息。

进一步地，注册模块，包括：

监听单元，用于监听主应用的页面路由切换事件；

添加单元，用于若监听到主应用的页面路由信息发生变化，则将子应用的第一路由信息添加至主应用的路由信息表中，并将添加第一路由信息后的路由信息表作为注册记录。

进一步地，第一路由信息包括第一页面路径，第二路由信息包括第二页面路径，匹配模块，包括：

获取单元，用于获取主应用的待切换页面的页面链接；

确定单元，用于从页面链接中，确定待切换页面的第二页面路径；

匹配单元，用于将第二页面路径与注册记录中的所有第一页面路径匹配。

进一步地，显示模块，还用于若第二路由信息成功匹配到第一路由信息，则显示第一路由信息对应的功能页面。

进一步地，第一路由信息还包括功能页面的页面图标，获取模块，还用于获取主应用的菜单栏信息表，菜单栏信息表中包含有第三路由信息；

匹配模块，还用于对第一路由信息与第三路由信息进行匹配；

控制装置，还包括：

展示模块，用于若第一路由信息与第三路由信息匹配成功，则在主应用的菜单栏展示第一路由信息的页面图标。

进一步地，控制装置，还包括：

验证模块，用于若第二路由信息成功匹配到第一路由信息，则验证主应用是否具有第一路由信息对应的功能页面的访问权限；

显示模块，还用于若主应用不具有访问权限，则显示预设的权限提示页面。

第三方面，本申请实施例提供了一种终端设备，包括存储器及处理器，存储器用于存储计算机程序，处理器运行计算机程序以使终端设备执行上述第一方面的微前端页面的控制方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，计算机程序被处理器执行时实现上述第一方面的微前端页面的控制方法。

可以理解的是，上述第二方面至第四方面的有益效果可参见上述第一方面的相关描述，在此不再赘述。

附图说明

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

图1为本申请一实施例提供的手机的软件结构示意图；

图2为本申请另一实施例提供的Single-SPA的逻辑示意图；

图3为本申请一实施例提供的微前段页面的控制方法的流程示意图；

图4为本申请另一实施例提供的微前段页面的控制方法的流程示意图；

图5为本申请又一实施例提供的微前段页面的控制方法的流程示意图；

图6为本申请再一实施例提供的微前段页面的控制方法的流程示意图；

图7为本申请实施例提供的微前段页面的控制装置和的结构示意图；

图8为本申请实施例提供的终端设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如背景技术相关记载，在页面切换场景中，主要是基于MPA和SPA实现。其中MPA将页面部署于不同的统一资源定位器(Uniform Resource Locator，URL)下，通过访问不同URL以实现不同页面的切换，但是在浏览器页面重刷或者从一个应用页面切换至另一个应用页面时，页面会出现明显的断点。SPA能够加载单个超文本标记语言(Hyper Text MarkupLanguage，HTML)页面，并在用户与应用程序交互时动态更新该页面，以实现无刷新切换页面，但是SPA受制于当前技术，难以兼容不同框架的应用。

为此，目前采用Single-SPA将多个不同框架下相对独立的子应用组合到一个主应用中，从而实现主应用页面中切换多个子应用的功能页面。但是在切换子应用页面时需要获取页面数据，当页面数据处理不好时，主应用页面会显示短暂的空白页面，甚至当页面数据缺失时，主应用页面会一直显示空白页面，对用户体验非常不友好。可见，当前单页面应用存在页面控制不够精准的问题。

针对上述现有技术中的问题，本申请提供了一种微前段页面的控制方法，通过将子应用的第一路由信息注册到主应用中，以使主应用能够访问子应用，并能够在同一个页面下控制不同子应用的功能页面；以及以路由信息作为匹配依据，确定主应用是否存在待切换页面对应子应用的页面数据，从而实现路由级的页面控制；并在第二路由信息未匹配到第一路由信息时，即页面数据不存在时，直接跳转至预设容错页面，使得页面不会出现空白而影响用户体验，提高微前端页面的控制精准度，为微前端页面提供实际有效的控制策略。

本申请实施例中的微前段页面的控制方法可应用于终端设备，终端设备包括但不限于设有或者连接有显示单元的手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personaldigital assistant，PDA)、智能网关、智能家居设备等终端，本申请实施例对终端的具体类型不作任何限制。可以理解，微前端页面显示于上述显示单元。

上述终端设备为之手机为例。图1是本申请实施例的手机的软件结构示意图。以手机操作系统为Android系统为例，在一些实施例中，将Android系统分为四层，分别为应用程序层、应用程序框架层(framework，FWK)、系统层以及硬件抽象层，层与层之间通过软件接口通信。

如图1所示，应用程序层可以一系列应用程序包，应用程序包可以包括短信息，日历，相机，视频，导航，图库，通话、浏览器等应用程序。其中浏览器可以通过Single-SPA架构访问其他应用程序的功能页面。如图2示出的Single-SPA的逻辑示意图，浏览器向app1发送获取manifest.json文件(即子应用的资源文件)的ajax请求，app1将manifest.json文件发送给浏览器，浏览器加载该manifest.json文件后，通过向app1发送get请求以访问app1的功能页面。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层可以包括一些预先定义的函数，例如用于接收应用程序框架层所发送的事件的函数。应用程序框架层可以包括窗口管理器、资源管理器以及通知管理器等。窗口管理器用于管理窗口程序。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。

系统层可以包括多个功能模块。例如：传感器服务模块，物理状态识别模块，三维图形处理库(例如：OpenGL ES)等。传感器服务模块，用于对硬件层各类传感器上传的传感器数据进行监测，确定手机的物理状态；物理状态识别模块，用于对用户手势、人脸等进行分析和识别；三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

硬件抽象层是硬件和软件之间的层。硬件抽象层可以包括显示驱动，摄像头驱动，传感器驱动等，用于驱动硬件层的相关硬件，如显示屏、摄像头、传感器等。

应理解，图1示出的手机软件结构示意图和图2示出的Single-SPA的逻辑示意图，仅用作示例而非限定，在其他实施例中，可以包括更多或更少的组件，在此不再赘述。

参见图3，图3示出了本申请实施例提供的一种微前段页面的控制方法的流程示意图。本申请实施例的微前段页面的控制方法，包括步骤S301至S304，详述如下：

步骤S301，获取子应用接入到主应用时的第一路由信息，第一路由信息包括子应用的所有功能页面的路由信息。

在本实施例中，主应用为与用户交互的Web应用，子应用为能够被主应用访问的Web应用，主应用和子应用均运行于浏览器中。例如，运行于浏览器的主应用以体育论坛为例，则子应用为体育论坛中的留言版、聊天室等。其中子应用可以是由主应用的功能应用分拆而来，如将浏览器的搜索功能分离为搜索子应用，再通过Single-SPA将搜索子应用重新整合到浏览器中；子应用也可以是其他框架的独立应用，如将独立的日历应用通过Single-SPA将其接入到浏览器中，以使浏览器能够显示日历页面。

举例来说，假设主应用是在线教育网站，子应用就可能是该在线教育网站的聊天窗口、评论区以及直播区等，对此不做赘述。

第一路由信息为子应用的功能页面的路由信息，其包括但不限于页面路径、页面图标和页面功能名称。页面路径包含当前路由所归属的子应用信息，如/user、/login等；页面图标为功能页面的功能图标，如购物应用中购物车功能的购物车图标；页面功能名称为功能页面的功能名称，如购物应用中个人功能页面的个人中心。

可以理解的是，主应用只有一个，接入到主应用的子应用可以有多个，即本申请可以获取多个子应用的第一路由信息，具体地，包含每个子应用的所有功能页面的第一路由信息。

步骤S302，将第一路由信息注册到主应用，得到注册记录。

在本实施例中，注册指的是将子应用的路由信息登记到主应用中，其包括静态注册和动态注册。可选地，注册第一路由信息时，可以将第一路由信息中的任意一个信息注册到主应用以完成注册。注册记录中包含有多个功能页面的路由信息，注册记录中的路由信息包括页面路径、页面图标和/或页面功能名称。

在一实施例中，将第一路由信息静态注册到主应用，即子应用接入到主应用时，主应用获取到所有子应用的所有第一路由信息，并将所有第一路由信息添加至主应用自身的路由信息中，以使主应用在切换任何页面时均能够与所有子应用的路由信息匹配，避免页面数据缺失的情况。

在另一实施例中，将第一路由信息动态注册到主应用，得到注册记录，包括：监听主应用的页面路由切换事件；若监听到主应用的页面路由信息发生变化，则将子应用的第一路由信息添加至主应用的路由信息表中，并将添加第一路由信息后的路由信息表作为注册记录。

在本实施例中，页面路由切换事件包括页面路由信息未发生变化和页面路由信息发生变化。示例性地，对于浏览器的监听方式，浏览器提供了hashchange事件，基于hash页面地址发生变化的时候会触发hashchange事件，以此来此实现监听页面路由切换事件。本实施例动态注册子应用，能够减轻主应用的数据运行负荷，提高主应用对路由信息进行数据处理时的效率。

步骤S303，基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配。

在本实施例中，待切换页面为主应用即将跳转的目标页面，例如，当前处于购物车页面，当用户选择下单选项后，页面即将显示为订单页面，订单页面即为待切换页面。

可选地，将第二路由信息中的所有信息与第一路由信息中的所有信息匹配，即第二路由信息与第一路由信息完全相同视为匹配成功，反之匹配失败。示例性地，注册记录中存储了路由信息和具体页面的对应关系，比如注册记录中包含两组路由信息：第一组：路由信息“/user”,对应页面文件“userPage.js”；第二组：路由信息“/login”,对应页面文件“loginPage.js”；即将跳转的路由信息为/login，匹配规则为将即将跳转的路由信息和路由信息表里所有的路由信息进行比对，找到完全一致的则为匹配成功，即匹配成功结果为第二组路由信息。

可选地，将第二路由信息中的重要信息与第一路由信息中的重要信息匹配，即重要信息相同视为匹配成功，反之匹配失败。重要信息可以是路由名称或页面路径等。

在一实施例中，第一路由信息包括第一页面路径，第二路由信息包括第二页面路径，步骤S303包括：获取主应用的待切换页面的页面链接；从页面链接中，确定待切换页面的第二页面路径；将第二页面路径与注册记录中的所有第一页面路径匹配。

在本实施例中，第二页面路径为页面路由。页面即将跳转的下一个页面路由是通过页面链接获取到，通常是域名链接后边的内容。例如页面链接为https://baidu.com/user，则域名为https://baidu.com,页面路由为/user。再通过对页面路由进行匹配，以确定主应用待切换的页面是否存在，从而简化路由信息处理过程和减低处理过程的运算量。

步骤S304，若第二路由信息未匹配到第一路由信息，则显示预设容错页面。

在本实施例中，预设容错页面表示主应用当前访问的页面不存在，以用于提示用户。本实施例在待切换页面的页面数据缺失时，显示预设容错页面，使得页面不会出现空白而影响用户体验，提高微前端页面的控制精准度，为微前端页面提供实际有效的控制策略。

在图3实施例的基础上，图4示出了另一实施例提供的微前端页面的控制方法的流程示意图。如图4所示，在步骤S301之前还包括步骤S401。需要说明的是，与图3实施例相同的步骤，此处不再赘述。

步骤S401，基于子应用的配置文件对应的文件链接，将配置文件加载至主应用，配置文件中包含子应用的所有功能页面的第一路由信息。

在本实施例中，配置文件为子应用通过编译工具编译得到的文件，其包括但不限于js文件、css文件和manifest文件。示例性地，在子应用上，利用webpack插件(一种应用模块化工具)，生成带有所有需要加载的依赖文件的manifest.json文件，再由主应用加载该manifest.json，以能够获取到具体的js，并使用script标签将其放到主应用上进行渲染。

可选地，可以在主应用启动时加载上述配置文件，也可以在其他时刻加载上述配置文件。通过将子应用的配置文件加载至主应用，实现将子应用接入到主应用，以使主应用能够访问子应用的所有功能页面。

可以理解的是，当主应用的功能发生变更时(如系统重构)，可以变更功能页面的路由信息，并重新生成配置文件，以及将重新生成的配置文件接入到主应用中，以完成主应用对子应用的访问更新。其中路由信息的变更包括但不限于增加、删除和修改。

在图3实施例的基础上，图5示出了又一实施例提供的微前端页面的控制方法的实现流程图。如图5所示，在步骤S303之后还包括步骤S501至S504。需要说明的是，与图3实施例相同的步骤，此处不再赘述。

步骤S501，若第二路由信息成功匹配到第一路由信息，则显示第一路由信息对应的功能页面。

在本步骤中，第二路由信息成功匹配到第一路由信息，如第一页面路径成功匹配到第二页面路径，说明在主应用所注册的子应用页面中存在主应用所要切换的功能页面，所以显示该功能页面。

可选地，该功能页面的显示方式可以是显示于主应用页面的某个区域，也可以是无刷新切换页面。

可选地，无刷新切换页面后，会在当前系统打开新的tab页面(tabulator key)，tab页面用于展示当前所处功能，以便于有多个tab页面时区分不同功能。例如，路由为/userCenter,功能名称为个人中心，切换至该功能后，根据功能名称，tab标签显示为个人中心。

步骤S502，获取主应用的菜单栏信息表，菜单栏信息表中包含有第三路由信息；

步骤S503，对第一路由信息与第三路由信息进行匹配；

步骤S504，若第一路由信息与第三路由信息匹配成功，则在主应用的菜单栏展示第一路由信息的页面图标。

在步骤S502至步骤S504中，基于通常的管理系统设计，菜单名称前通常有含义与功能名称一致或相近的图标作为标识，管理系统菜单通常提供菜单收起功能，此时菜单栏宽度变小，不足以展示功能名称。本实施例中菜单栏信息表为记录该功能菜单栏的具体信息的表单，该菜单信息表中存储某个页面的路由信息。示例性地，根据当前页面地址的路由信息与菜单信息表中的所有路由信息进行匹配，若匹配成功，则说明当前跳转的页面为菜单栏的菜单功能之一，因此通过将第一路由信息的页面图标展示在主应用的菜单栏，以在主应用菜单收起，菜单栏宽度变小而不足以展示功能名称时，为用户提供页面图标，便于用户切换功能。

在图3实施例的基础上，图6示出了再一实施例提供的微前端页面的控制方法的实现流程图。如图6所示，在步骤S303之后还包括步骤S601至S602。需要说明的是，与图3实施例相同的步骤，此处不再赘述。

步骤S601，若第二路由信息成功匹配到第一路由信息，则验证主应用是否具有第一路由信息对应的功能页面的访问权限。

步骤S602，若主应用不具有访问权限，则显示预设的权限提示页面。

在步骤S601至步骤S602中，权限提示页面用于提示用户当前不具有功能页面的访问权限。对于部分子应用需要查看权限才能展示给用户的功能页面，如浏览器访问手机银行app时需要查看银行账户余额对应的功能页面，则通过主应用向子应用发送权限验证信息，以验证主应用是否具有访问权限，若主应用不具有访问权限，则显示权限提示页面，避免了主应用无法显示子应用的功能页面而处于空白页面，进一步为微前端的页面控制策略提供精准有效的控制方式。

可选地，验证信息可以预先存储于主应用中，在验证权限时，由主应用发送给子应用。验证信息也可以是用户与主应用实时交互时输入的验证信息。

为了执行上述方法实施例对应的方法，以实现相应的功能和技术效果，下面提供一种微前端页面的控制装置。参见图7，图7是本申请实施例提供的一种微前端页面的控制装置的结构框图。为了便于说明，仅示出了与本实施例相关的部分，本申请实施例提供的微前端页面的控制装置700，包括：

获取模块701，用于获取子应用接入到主应用时的第一路由信息，第一路由信息包括子应用的所有功能页面的路由信息；

注册模块702，用于将第一路由信息注册到主应用，得到注册记录；

匹配模块703，用于基于注册记录，对主应用的待切换页面的第二路由信息与第一路由信息进行匹配；

显示模块704，用于若第二路由信息未匹配到第一路由信息，则将显示预设容错页面。

在一实施例中，控制装置700，还包括：

加载模块，用于基于子应用的配置文件对应的文件链接，将配置文件加载至主应用，配置文件中包含子应用的所有功能页面的第一路由信息。

在一实施例中，注册模块702，包括：

监听单元，用于监听主应用的页面路由切换事件；

添加单元，用于若监听到主应用的页面路由信息发生变化，则将子应用的第一路由信息添加至主应用的路由信息表中，并将添加第一路由信息后的路由信息表作为注册记录。

在一实施例中，第一路由信息包括第一页面路径，第二路由信息包括第二页面路径，匹配模块703，包括：

获取单元，用于获取主应用的待切换页面的页面链接；

确定单元，用于从页面链接中，确定待切换页面的第二页面路径；

匹配单元，用于将第二页面路径与注册记录中的所有第一页面路径匹配。

在一实施例中，显示模块704，还用于若第二路由信息成功匹配到第一路由信息，则将主应用页面切换至第一路由信息对应的功能页面。

在一实施例中，第一路由信息还包括功能页面的页面图标，获取模块701，还用于获取主应用的菜单栏信息表，菜单栏信息表中包含有第三路由信息；

匹配模块703，还用于对第一路由信息与第三路由信息进行匹配；

控制装置700，还包括：

展示模块，用于若第一路由信息与第三路由信息匹配成功，则在主应用的菜单栏展示第一路由信息的页面图标。

在一实施例中，控制装置700，还包括：

验证模块，用于若第二路由信息成功匹配到第一路由信息，则验证主应用是否具有第一路由信息对应的功能页面的访问权限；

显示模块704，还用于若主应用不具有访问权限，则将显示预设的权限提示页面。

上述的微前端页面的控制装置可实施上述方法实施例的微前端页面的控制方法。上述方法实施例中的可选项也适用于本实施例，这里不再详述。本申请实施例的其余内容可参照上述方法实施例的内容，在本实施例中，不再进行赘述。

图8为本申请一实施例提供的终端设备的结构示意图。如图8所示，该实施例的终端设备8包括：至少一个处理器80(图8中仅示出一个)、存储器81以及存储在所述存储器81中并可在所述至少一个处理器80上运行的计算机程序82，所述处理器80执行所述计算机程序82时实现上述任意方法实施例中的步骤。

所述终端设备8可以是智能手机、平板电脑、桌上型计算机、超级计算机、个人数字助理、物理服务器和云服务器等计算设备。该终端设备可包括但不仅限于处理器80、存储器81。本领域技术人员可以理解，图8仅仅是终端设备8的举例，并不构成对终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，该处理器80还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81在一些实施例中可以是所述终端设备8的内部存储单元，例如终端设备8的硬盘或内存。所述存储器81在另一些实施例中也可以是所述终端设备8的外部存储设备，例如所述终端设备8上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。

另外，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述任意方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。