基于微前端的数据处理方法及框架与流程

本申请涉及数据处理技术领域，具体涉及一种基于微前端的数据处理方法及框架。

背景技术：

现代企业在数字化转型上加速进行，企业的软件工程体量越来越大，软件开发过程中前后端分离，后端的微服务化已经有行业较成熟的解决方案；前端工程采用vue/react/angularjs三个框架其一来构建单页应用是行业中的常规开发模式；随着业务的发展，一个前端工程包含了上百甚至更多的个业务模块，前端单页应用已成为一个单页巨石应用。传统的前端开发技术面临着如下的技术问题：巨石前端工程体量巨大，运维实施编译发布时间长，哪怕是一个文案的改动也需要整个工程重新编译，发布几个小时；每次发布都需要将前端单一工程编译增加发布(release)分支，一个前端工程里包含了十几个项目，几乎每天都会有项目发布，发布分支冗余，常出现发布分支不对造成的错发漏发；代码耦合度高，通过分支管控，每个项目都会有十几个研发分支，十几个项目在一个工程每天会有分支冲突解决，需要大量时间成本，研发效率越来越低；一个前端工程里有成千上百个页面，页面跳转路由由一个文件集中管理，页面路由的身份表示号(id)冲突，命名空间冲突，权限冲突等，管控复杂度高；单页前端工程所有业务逻辑都在一起，采用逻辑隔离，共有和私有组件边界不清晰，各个团队维护的代码冗余且容易污染全局。

在这种情况下，基于微服务架构的微前端开发技术应运而生，微服务是面向服务架构(soa)的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理。越来越重的前端工程也面临同样的问题，自然地想到了将微服务思想应用到前端开发，于是有了微前端(micro-frontends)的概念：微前端是一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

目前行业中常用的微前端解决方案有iframe(中文暂无统一名称)、webcomponent(中文暂无统一名称)和路由分发等等方式。其中，iframe在使用过程中，解决了以上问题同时，也会带来新的问题，如不同微前端之间隔离后，层叠样式表(cascadingstylesheets，css)，javascript(中文暂无统一名称)无法共用，在不同微前端工程中要重复开发；不同微前端工程不同源，cookie(中文暂无统一名称)无法共用；不同微前端将页面切分，无法实现绝对居中定位，隔离的系统加载状态不同，会出现较长时间白屏体验较差等等问题；webcomponent微前端弱隔离方案，是采用组件化来实现，但这种方案需要对已有系统采用整体重构，也会造成重复工作，对已有功能的大量复写。

因此，兹待一种新的处理方法来解决单体应用的弊端同时，改善以上列举的传统微前端出现的种种问题。

需要说明的是，这里的陈述仅提供与本申请有关的背景信息，而不必然地构成现有技术。

技术实现要素：

鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的基于微前端的数据处理方法及框架。

根据本申请的一方面，提供了一种基于微前端的数据处理方法，所述方法是通过微前端的数据处理框架实现的，所述微前端的数据处理框架包括应用配置中心、微前端主工程模块和至少一个微前端子工程模块，所述应用配置中心通讯连接所述微前端主工程模块，所述微前端主工程模块通讯连接所述微前端子工程模块；所述方法包括：

所述应用配置中心接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述微前端主工程模块；

所述微前端主工程模块根据所述各子应用的定制信息生成所述各子应用的加载菜单和初始化文件；根据各子应用的加载菜单加载各子应用对应的微前端子工程模块；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块；

所述微前端子工程模块根据接收的初始化文件发布各子应用，以使所述微前端主工程模块对所述各子应用进行标准化，实现主应用的发布，其中，所述主应用与所述各子应用是同源的。

可选的，在上述的数据处理方法中，所述定制信息包括：应用信息、菜单信息、权限配置信息。

可选的，在上述的数据处理方法中，所述主应用与各所述子应用以及各所述子应用之间通过iframe沙箱技术实现javascript隔离和cascadingstylesheets隔离。

可选的，在上述的数据处理方法中，所述根据各子应用的加载菜单加载各子应用对应的微前端子工程模块包括：

根据所述各子应用的加载菜单中的postmessage确定组成主应用的各子应用，根据所述组成主应用的各子应用确定所述各子应用对应的微前端子工程模块；

加载所述各子应用对应的微前端子工程模块；

所述微前端主工程模块还包括：

加载主工程共享组件，其中，所述主工程共享组件包括常用开源依赖组件和公共共享依赖组件，所述公共共享依赖组件包括渲染组件和开发编译组件。

可选的，在上述的数据处理方法中，所述微前端子工程模块根据接收的初始化文件发布各子应用包括：

根据所述初始化文件调用所述微前端主工程模块的主工程共享组件以完成各子应用的开发；

将开发形成的各子应用中的主工程共享组件剔除后，将所述各子应用打包后，与各子应用的页面加载生命周期对应发送至所述微前端主工程模块。

可选的，在上述的数据处理方法中，所述微前端主工程模块对所述各子应用进行标准化，实现主应用的发布包括：

调用工程标准化模块对所述各子应用的语言、样式、权限进行标准化，将标准化后的各子应用组合在一起形成主应用，并将所述主应用发布；

可选的，在上述的数据处理方法中，所述主应用与所述各子应用的编译是基于node.js技术实现的。

根据本申请的第二方面，提供了一种基于微前端的数据处理框架，该框架包括：应用配置中心、微前端主工程模块和至少一个微前端子工程模块，所述应用配置中心通讯连接所述微前端主工程模块，所述微前端主工程模块通讯连接所述微前端子工程模块；

所述应用配置中心，用于接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述微前端主工程模块；

所述微前端主工程模块，用于根据所述各子应用的定制信息生成所述各子应用的加载菜单和初始化文件；根据各子应用的加载菜单加载各子应用对应的微前端子工程模块；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块；

所述微前端子工程模块，用于根据接收的初始化文件发布各子应用，以使所述微前端主工程模块对所述各子应用进行标准化，以实现主应用的发布。

可选的，在上述的数据处理框架中，所述微前端主工程模块包括路由分发单元和主工程基础前端单元，其中所述主工程基础前端单元包括应用管理及加载单元、公共通讯单元、工程标准化单元；

所述路由分发单元分别通讯连接所述应用配置中心和所述应用管理及加载单元，用于接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述应用管理及加载单元；

所述应用管理及加载单元分别通讯连接各所述微前端子工程模块，用于根据各子应用的加载菜单加载各子应用对应的微前端子工程模块；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块；

所述工程标准化单元，用于对所述各子应用进行标准化，以实现主应用的发布。

公共通讯单元，用于实现所述应用配置中心、所述微前端主工程模块以及各所述微前端子工程模块之间的通讯连接。

可选的，在上述的数据处理框架中，所述微前端前工程模块与各所述微前端子工程模块以及各所述微前端子工程模块之间通过iframe沙箱技术实现javascript隔离和cascadingstylesheets隔离。

根据本申请的第三方面，提供了一种电子设备，其中，该电子设备包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如上任一所述的方法。

根据本申请的第四方面，提供了一种计算机可读存储介质，其中，计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如上任一所述的方法。

综上所述，本申请提供了一种基于订阅-发布思想的微前端数据处理方法，该方法在前端开发的全流程上实现了各个前端子工程的独立开发，独立测试，独立部署；极大程度上降低了主应用以及各子应用之间的耦合，降低了运维实施编译发布时长，显著提升了前端开发的工作效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请的一个实施例的微前端的数据处理框架的结构示意图；

图2示出了根据本申请的一个实施例的微前端的数据处理方法的流程示意图；

图3示出了根据本申请一个实施例的电子设备的结构示意图；

图4示出了根据本申请一个实施例的计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

本申请的构思在于，目前市面上有许多微前端的实现方式，如：路由分发、webcomponents、基于single-spa的微前端、微件化(基于webpack)等，但这些应用在开发成本、维护成本、实现难度上、可行性等方面上多少会有些局限性，比如浏览器兼容性差、页面弹框不能居中，系统提示位置不统一等等。

针对目前微前端开发的现状，基于订阅-发布的思想，提供了一种微前端的数据处理方法，在该方法中，应用定制人员能够根据需要将一个前端工程或应用拆分成若干与其同源的子应用，主工程模块可以根据需要决定对各子工程模块进行加载与否，应用定制人员可以根据需求对各子应用进行个性化定制，各子应用是相互隔离的，以此，实现前端页面的开发，该方法实现了各个前端子工程的独立开发，独立测试，独立部署；极大程度上降低了主应用以及各子应用之间的耦合，降低了运维实施编译发布时长，显著提升了前端开发的工作效率。

本申请的方法是通过微前端的数据处理框架实现的，图1示出了根据本申请的一个实施例的微前端的数据处理框架的结构示意图，从图1可以看出，所述微前端的数据处理框架1包括应用配置中心100、微前端主工程模块200和至少一个微前端子工程模块300，所述应用配置中心100通讯连接所述微前端主工程模块200，所述微前端主工程模块200通讯连接所述微前端子工程模块300。在本申请的一些实施例中，在微前端子工程模块300为多个情况的条件下，各个微前端子工程模块300之间是互相隔离的。另外，微前端主工程模块200和微前端子工程模块300都具有api接口。

在本申请的一些实施例中，微前端主工程模块200包括路由分发单元210和主工程基础前端单元220，其中所述主工程基础前端单元220包括应用管理及加载单元222、公共通讯单元223、工程标准化单元221；路由分发单元210与应用管理及加载单元222通讯连接，应用管理及加载单元222与各微前端子工程模块300通讯连接，在应用管理及加载单元222中包括控制器(roter，图中未示出)，应用管理及加载单元222用于负责微前端子工程模块300的加载以及微前端子工程模块300的消息处理等。

公共通讯单元223主要承载着整个微前端的数据处理框架的各个模块之间的通讯任务，包括但不限于应用配置中心100与微前端主工程模块200之间以及微前端主工程模块200和微前端子工程模块300之间的通讯任务，该单元具体实现了有$message(系统提示信息)、$notify(系统通知信息)、$redirectto(子系统间跳转)、$opendia(打开业务弹框)等等，为整个框架提供了多种多样的通讯功能。如接收微前端主工程模块200的消息：通过处理函数handlemessage来处理消息类型，比如：closedia(关闭对话框)、padding(页面css的相关调整)等等。通过公共通讯单元223提供的相关功能，能快速实现微前端系统的相关基础功能，如：业务功能弹框、系统消息风格统一、子系统间跳转、统一登录处理等等。

图2示出了根据本申请的一个实施例的微前端的数据处理方法的流程示意图，本申请提供的基于微前端的数据处理方法是基于上述任一的微前端的数据处理框架实现的，该微前端的数据处理方法至少包括以下所述的步骤s210到步骤s230：

步骤s210：应用配置中心100接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述微前端主工程模块。

本申请是基于微前端的开发方法，在本申请中，一个主应用有若干子应用组成，且主应用与组成该主应用的各个子应用均是同源的，所谓“同源”表示主应用与各个子应用共享cookie信息并共用nginx服务器。

另外，由于本申请的构思是基于订阅-发布模式的，因此，本申请可以但不限于基于vue(目前没有统一的中文名)框架实现，vue是一套构建用户界面的框架，双向数据绑定，帮助减少不必要的dom(目前没有统一的中文名)操作；通过框架提供的指令，前端只需要关注业务逻辑，不再关心dom如何渲染。

各子应用的定制信息可以由应用定制人员，具体可以为本领域的前端开发工程师在应用配置中心100注册并写入，在本申请的一些实施例中，各子应用的定制信息包括但不限于应用信息、菜单信息、权限配置信息等等。

应用配置中心100接收各子应用的定制信息，并将各子应用的定制信息发送至微前端主工程模块200。

应用配置中心100接收子应用的定制信息后配置相关用户的应用权限后，再配置子应用的相关功能菜单，完成主应用加载子应用的基础工作。

在本申请的一些实施例中，应用配置中心100将上述信息发送至微前端主工程模块200的路由分发单元210中，由路由分发单元210发送至微前端主工程模块200的其他单元中。

步骤s220：微前端主工程模块200根据各子应用的定制信息生成组成各子应用的加载菜单和初始化文件；根据各子应用的加载菜单加载各子应用对应的微前端子工程模块；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块。

微前端主工程模块200在接收到各子应用的定制信息后，根据该定制信息生成各个子应用的加载菜单和初始化文件(package)，以一个子应用为例，根据该子应用的加载菜单，微前端主工程模块200确定对于该子应用对应的微前端子工程模块300是否进行加载，如需加载，则通过应用管理及加载单元222的控制器拉取该子应用对应的微前端子工程模块300。

在对各个微前端子工程模块300加载完毕后，微前端主工程模块200将各子应用初始化文件发送至各子应用对应的微前端子工程模块300中。在本申请的一些实施例中，可以由微前端主工程模块200的应用管理及加载单元222发送至各个微前端子工程模块300中。

步骤s230：微前端子工程模块300根据接收的初始化文件发布各子应用，以使微前端主工程模块200对各子应用进行标准化，实现主应用的发布，其中，主应用与各子应用是同源的。

微前端子工程模块300分别根据接收到的各自的初始化文件对子应用进行建立(build)、测试(test)、发布(pipeline)等操作，在所有子应用发布到对应的服务器目录完毕后，微前端主工程模块200的工程标准化单元221对所有的子应用进行标准化处理，标准化处理包括但不限于系统的主题色、多语言以及用户凭证的统一存储及获取等，以使这些子应用形成统一风格的主应用。当然，在主应用中还包含了用户登录认证信息、菜单权限、多语言、公共组件等通用信息。在本申请的一些实施例中，主应用与各子应用的编译可以但不局限于基于node.js技术实现，node.js很够很好的与vue兼容，主要负责vue工程的编译打包工作。

由图2所示的方法可以看出，本申请在通过调研实践这些已有的实现方式的基础上，建立了一种微前端方法，该方法具有开发成本低、实现难度低、浏览器兼容性高、扩展性好的特点，能在实际项目开发中快速搭建、灵活高效集成以及低耦合发布。

在本申请的一些实施例中，在上述的数据处理方法中，通过iframe技术可以实现子应用的相互嵌套，也可实现多个子应用同时并行在前端主工程；且主应用与各子应用以及各子应用之间通过iframe沙箱(sandbox)技术实现javascript(js，目前没有统一中文名)隔离和cascadingstylesheets(ccs,目前没有统一中文名)隔离。

iframe是前端成熟的技术，采用这种组合技术方案开发维护成本低，可实现程度高、兼容性好，能够方便的实现多个子应用的相互套用、并行等。且iframe天然完美的支持js沙箱、css隔离，不会出现子系统或子应用间的js冲突、css冲突的情况。

在本申请的一些实施例中，在上述的数据处理方法中，所述根据各子应用的加载菜单加载各子应用对应的微前端子工程模块包括：根据所述各子应用的加载菜单中的postmessage确定组成主应用的各子应用，根据所述组成主应用的各子应用确定所述各子应用对应的微前端子工程模块；加载所述各子应用对应的微前端子工程模块。

该步骤的执行主体是微前端主工程模块200，其可以根据子应用的加载菜单中的postmessage确定该子应用是否被需要，若需要，则拉取与该子应用对应的微前端子工程模块300，并加载该微前端子工程模块300。在本申请的一些实施例中，主应用和子应用可以采用跨文档通信模式，具体的子引用可以通过postmessage与主应用通讯，而主工程通过addeventlistener实现对子应用的消息监听。

微前端主工程模块200除了需要加载需要的微前端子工程模块300，还需要对一些基础组件进行预加载，如加载主工程共享组件，在本申请的一些实施例中，该主工程共享组件可以为npm共享插件(目前没有统一中文名)，在本申请的一些实施例中，npm共享插件包括两部分，一部分为常用开源依赖组件，另一部分为公共共享依赖组件，为了减少生产依赖的大小，还可以将公共共享依赖组件拆分为两部分，一部分负责核心组件的渲染，称为渲染组件(exp-component-core)，另一部分负责在开发阶段和编译阶段使用，称为开发编译组件(exp-component-compiler)。子应用在进行发布时，可以直接调用上述主工程共享组件，以减少冗余插件，通过在微前端主工程模块200设置主工程共享组件，极大程度上缓解了各个子应用的插件冗余的问题。

可选的，在上述的数据处理方法中，微前端子工程模块根据接收的初始化文件发布各子应用包括：根据所述初始化文件调用所述微前端主工程模块的主工程共享组件以完成各子应用的开发；将开发形成的各子应用中的主工程共享组件剔除后，将所述各子应用打包后，与各子应用的页面加载生命周期对应发送至所述微前端主工程模块。

该步骤的执行主体为各微前端子工程模块300，也就是说各微前端子工程模块300可以调用上述的主工程共享组件完成子应用的开发工作，然后将主工程共享组件剔除后，再打包，发布至对应的服务器目录中，进一步的，可以与各子应用的页面加载生命周期对应在一起发送至微前端主工程模块200。

在本申请的一些实施例中，在上述的数据处理方法中，微前端主工程模块200对各子应用进行标准化，实现主应用的发布包括：调用工程标准化单元221对所述各子应用的语言、样式、权限进行标准化，将标准化后的各子应用组合在一起形成主应用，并将所述主应用发布。

微前端主工程模块200提供的工程标准化单元221能够使整个应用运行起来协调、统一。

请再次参考图1，本申请还提供了一种基于微前端的数据处理框架1，包括：应用配置中心100、微前端主工程模块200和至少一个微前端子工程模块300，所述应用配置中心100通讯连接所述微前端主工程模块200，所述微前端主工程模块200通讯连接所述微前端子工程模块300；

其中，所述应用配置中心100，用于接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述微前端主工程模块200；

所述微前端主工程模块200，用于根据所述各子应用的定制信息生成组成所述各子应用的加载菜单和初始化文件；根据各子应用的加载菜单加载各子应用对应的微前端子工程模块300；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块300；

所述微前端子工程模块300，用于根据接收的初始化文件发布各子应用，以使所述微前端主工程模块200对所述各子应用进行标准化，以实现主应用的发布。

从图1可以看出，本申请提供的基于微前端的数据处理框架集成度高，微前端主工程模块200为各个子系统提供标准的通信协议，以及标准化模块，以使整个应用运行起来协调、统一，各子应用按需实现各自的业务功能，独立开发、部署，极大的降低了大型工程的开发管理难度，同时使系统的业务拆分更加清晰明了。

在本申请的一些实施例中，在上述的数据处理框架中，所述微前端主工程模块200包括路由分发单元210和主工程基础前端单元220，其中所述主工程基础前端单元220包括应用管理及加载单元222、公共通讯单元223、工程标准化单元221；所述路由分发单元210分别通讯连接所述应用配置中心100和所述应用管理及加载单元222，用于接收各子应用的定制信息，并将所述各子应用的定制信息发送至所述应用管理及加载单元222；所述应用管理及加载单元222分别通讯连接各所述微前端子工程模块300，用于根据各子应用的加载菜单加载各子应用对应的微前端子工程模块300；并将各子应用初始化文件发送至各子工程对应的微前端子工程模块300；所述工程标准化单元221，用于对所述各子应用进行标准化，以实现主应用的发布。公共通讯单元223，用于实现所述应用配置中心110、所述微前端主工程模块200以及各所述微前端子工程模块300之间的通讯连接。

在本申请的一些实施例中，在上述的数据处理框架中，微前端主工程模块200与各所述微前端子工程模块300以及各所述微前端子工程模块300之间通过iframe沙箱技术实现javascript隔离和cascadingstylesheets隔离。

需要说明的是，本申请的基于微前端的数据处理框架能够一一实现上述的基于微前端的数据处理方法，不再赘述。

综上所述，本申请提供了一种基于订阅-发布思想的微前端数据处理方法，该方法在前端开发的全流程上实现了各个前端子工程的独立开发，独立测试，独立部署；极大程度上降低了主应用以及各子应用之间的耦合，降低了运维实施编译发布时长，显著提升了前端开发的工作效率。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本申请的框架中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

例如，图3示出了根据本申请一个实施例的电子设备的结构示意图。该电子设备300包括处理器310和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器320。存储器320可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。存储器320具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码331的存储空间330。例如，用于存储计算机可读程序代码的存储空间330可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码331。计算机可读程序代码331可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(cd)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图4所示的计算机可读存储介质。图4示出了根据本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介质400存储有用于执行根据本申请的方法步骤的计算机可读程序代码331，可以被电子设备300的处理器310读取，当计算机可读程序代码331由电子设备300运行时，导致该电子设备300执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码331可以执行上述任一实施例中示出的方法。计算机可读程序代码331可以以适当形式进行压缩。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。