CN110633443B - 一种页内数据通信的方法、装置、设备和介质 - Google Patents

Abstract

本申请属于数据处理技术领域，公开了一种页内数据通信的方法、装置、设备和介质，本申请公开的一种页内数据通信的方法包括，root页面中的Hub根据接收的消息订阅页面发送的包含消息类型的消息订阅请求，建立消息订阅页面的页面对象与消息类型之间的对应关系。当Hub监听到第一页面发送的页内传递消息时，根据页内传递消息中包含的消息类型，获取对应该消息类型设置的页面对象，以及根据页面对象，将页内传递消息转发至相应的第二页面。这样，不需要后端服务器的通信支持，不需要网络通信，简化了通信步骤，降低了通信成本，提高了通信效率和成功率。

Description

一种页内数据通信的方法、装置、设备和介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种页内数据通信的方法、装置、设备和介质。

背景技术

前端即网站前台部分，即运行在终端设备的应用上展现给用户浏览的网页。一个网页对应于一个超文本标记语言(HyperText Markup Language，HTML)文件。前端技术一般分为前端设计和前端开发，前端设计一般可以理解为网站的视觉设计，前端开发则是网站的前台代码实现。

传统技术中，实现前端的页内数据通信时，通常需要后端服务器的通信支持。所谓页内数据通信，即根(root)页面与root页面内的子页面之间，以及root页面内的不同子页面之间的数据通信。

其中，若一个HTML页面包含一个或多个内联框架(iframe)页面，则该HTML页面被称为上述iframe页面的root页面，上述iframe页面为root页面的子页面。

例如，参阅图1所示，为现有技术中一种页内数据通信的架构示意图，root页面内包括第一子页面和第二子页面。第一子页面通过建立的互联网套接字WebSocket长连接，将消息发送至后端服务器，后端服务器再将消息推送至第二子页面。

但是，通过后端服务器实现页内数据通信时，通讯效率较低，以及会出现长连接失效以及消息发送超时等问题。

由此，如何提高通信效率和通信成功率，是一个亟待解决的问题。

发明内容

本申请实施例提供一种页内数据通信的方法、装置、设备和介质，用以在进行页内数据通信时，提高通信效率和通信成功率。

一方面，提供一种页内数据通信的方法，包括：

当插件Hub监听到第一页面发送的页内传递消息时，获取页内传递消息中包含的消息类型，Hub为根页面中用于消息的订阅和转发的插件；

获取对应消息类型设置的页面对象，各消息类型对应的页面对象是对应发送消息订阅请求的消息订阅页面设置的，消息订阅请求中包含消息类型；

根据获取的页面对象，将页内传递消息转发至相应的第二页面，使得第二页面采用对应消息类型设置的回调函数处理页内传递消息；

其中，第一页面和第二页面分别为Hub所属的根页面或该根页面内的子页面。

一方面，提供一种页内数据通信的装置，包括：

监听单元，用于当监听到第一页面发送的页内传递消息时，获取页内传递消息中包含的消息类型，Hub为根页面中用于消息的订阅和转发的插件；

获取单元，用于获取对应消息类型设置的页面对象，各消息类型对应的页面对象是对应发送消息订阅请求的消息订阅页面设置的，消息订阅请求中包含消息类型；

发送单元，用于根据获取的页面对象，将页内传递消息转发至相应的第二页面，使得第二页面采用对应消息类型设置的回调函数处理页内传递消息；

其中，第一页面和所述第二页面分别为Hub所属的根页面或该根页面内的子页面。

一方面，提供一种控制设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时执行上述任一种页内数据通信的方法的步骤。

一方面，提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种页内数据通信的方法的步骤。

本申请实施例提供的一种页内数据通信的方法、装置、设备和介质中，root页面中的Hub根据接收的消息订阅页面发送的包含消息类型的消息订阅请求，建立消息订阅页面的页面对象与消息类型之间的对应关系。当Hub监听到第一页面发送的页内传递消息时，根据页内传递消息中包含的消息类型，获取对应该消息类型设置的页面对象，以及根据页面对象，将页内传递消息转发至相应的第二页面。这样，在root页面中引入Hub插件，以Hub为数据中转站，使得root页面以及root页面中的各子页面可以通过Hub进行数据传输，实现页内数据通信，不需要后端服务器的通信支持，不需要网络通信，简化了通信步骤，降低了通信成本，提高了通信效率和成功率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中一种页内数据通信的架构示意图；

图2为本申请实施方式中一种消息订阅的方法的实施流程图；

图3a为本申请实施方式中一种消息订阅的交互流程图；

图3b为本申请实施方式中一种消息订阅的示例图；

图4为本申请实施方式中一种页内数据通信的方法的实施流程图；

图5a为本申请实施方式中一种页内数据通信的交互流程图；

图5b为本申请实施方式中一种页内数据通信的示例图；

图5c为本申请实施方式中一种《英雄联盟》大厅所在的root页面；

图5d为本申请实施方式中一种防沉迷弹窗；

图6为本申请实施方式中一种页内数据通信的装置的结构示意图；

图7为本申请实施方式中一种控制设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

首先，对本申请实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。

终端设备：可以安装各类应用，并且能够将已安装的应用中提供的对象进行显示的设备，该电子设备可以是移动的，也可以是固定的。例如，手机、平板电脑、各类可穿戴设备、车载设备、个人数字助理(personal digital assistant，PDA)、销售终端(point ofsales，POS)或其它能够实现上述功能的电子设备等。

应用：即应用程序，可以完成某项或多项业务的计算机程序，一般具有可视的显示界面，能与用户进行交互，比如电子地图和微信等都可以称为应用。本申请实施例中，主要应用于浏览器以及游戏等应用的前端。

IFRAME：是HTML标签，作用是文档中的文档，或者浮动的框架(FRAME)。iframe元素会创建包含另外一个文档的内联框架(即行内框架)。

HTML：是一种规范，一种标准，它通过标记符号来标记要显示的网页中的各个部分。网页文件本身是一种文本文件，通过在文本文件中添加标记符，可以告诉浏览器如何显示其中的内容(如：文字如何处理，画面如何安排，图片如何显示等)。浏览器按顺序阅读网页文件，然后根据标记符解释和显示其标记的内容。HTML文件以.htm或.html为扩展名。HTML之所以称为超文本标记语言，是因为文本中包含了所谓“超级链接”“点，就是一种统一资源定位符(Uniform Resource Locator，URL)指针，通过激活(点击)它，可使浏览器方便地获取新的网页。

插件：是一种遵循一定规范的应用程序接口编写出来的程序。

Hub是一种插件。本申请实施例中，Hub为负责消息的订阅、解订以及消息的转发的插件。

PostMessage：是Windows API(应用程序接口)中的一个常用函数。

具体的，如，postMessage:window.postMessage()方法。postMessage:window.postMessage()方法可以安全地实现跨源通信。通常，对于两个不同页面的脚本，只要当执行它们的页面位于具有相同的协议(如，超文本传输安全协议(Hyper TextTransfer Protocol over Secure Socket Layer，HTTPS))就可以使用postMessage进行通信。

下面介绍本申请实施例的设计思想。

传统技术中，页内数据通信时，通常采用以下步骤：

root页面中的第一页面通过通信协议将消息发送至后端服务器，后端服务器通过通信协议将消息转发至root页面中的第二页面。其中，第一页面和第二页面为root页面或root页面内的子页面。

通过通信协议(如，WebSocket)，可以实现前端和后端服务器之间的双向通信的问题，使得后端服务器可以将消息主动推送到前端的页面。但是，由于页内数据通信时，存在网络通信，可能会出现长连接失效以及消息发送超时等问题，通信成功率低，并且需要通过后端服务器进行数据的转发，成本较高，通信效率较低。

对传统技术进行分析后发现，传统技术中并没有提供一种可以降低页内数据通信的成本，提高通信效率和成功率的页内数据通信的技术方案。因此，亟待需要一种页内数据通信的技术方案，以在页内数据通信时，降低通信成本，提高通信效率和成功率。

鉴于此，考虑到可以在root页面内引入用于消息的订阅和转发的插件，root页面以root页面内的子页面均可以向该插件进行消息订阅，以将该插件作为页面之间的消息中转站，实现页内数据的通信。

鉴于以上分析和考虑，本申请实施例中提供了一种页内数据通信的方案，该方案中，插件(Hub)根据监听的消息订阅请求中的消息类型，建立消息类型与发送消息订阅请求页面的页面对象之间的对应关系。在监听到第一页面的页内传递消息时，根据接收的页内传递消息中包含的消息类型，以及消息类型和页面对象之间的对应关系，将页内传递消息转发至相应的第二页面。其中，第一页面和第二页面分别为Hub所属的根页面或该根页面内的子页面。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

本申请实施例，主要应用于包含一个或多个子页面的root页面内，并在该root页面中引入用于消息的订阅和转发的插件Hub。在进行页内数据通信时，先进行消息订阅，参阅图2所示，为本申请提供的一种消息订阅的方法的实施流程图。该方法的具体流程如下：

步骤200：消息订阅页面向Hub发送消息订阅请求。

具体的，消息订阅页面确定待订阅的消息类型以及设置的用于处理该消息类型的消息的回调函数，通过指定通信方式向Hub发送包含消息类型的消息订阅请求。

其中，回调函数用于处理接收的订阅的相应消息类型的消息。消息订阅页面为root页面或者root页面内的子页面。

可选的，消息订阅请求中可以包含回调函数，也可以不包含回调函数。本申请实施例中，仅以消息订阅请求中包含回调函数为例进行说明。

需要说明的是，Hub是一种插件，插件是一种遵循一定规范的应用程序接口编写出来的程序。本申请实施例中，Hub负责消息的订阅、解订以及消息的转发。Hub设置于root页面。

其中，指定通信方式为不需要通过后端服务器支持的通信方式。可选的，指定通信方式可以为postMessage。

PostMessage是Windows API中的一个常用函数。具体的，如，postMessage:window.postMessage()方法。postMessage:window.postMessage()方法可以安全地实现跨源通信。通常，对于两个不同页面的脚本，只要当执行它们的页面位于具有相同的协议(如，HTTPS)就可以使用postMessage进行通信。

这样，消息订阅页面就可以通过postMessage等方式，向Hub发送消息订阅请求，不需要通过后端服务器的通信支持，也不需要网络通信。

步骤201：当Hub监听到消息订阅请求时，获取消息订阅请求中包含的消息类型。

进一步的，若消息订阅请求中还包含回调函数，则Hub获取消息订阅请求中包含的回调函数。

这样，Hub就可以获取消息订阅的消息类型。

步骤202：Hub获取消息订阅页面的页面对象，并将消息类型与页面对象关联存储。

具体的，执行步骤202时，Hub可以执行一下步骤：

S2021：根据消息类型，获取对应消息类型设置的处理函数。

其中，Hub预先针对每一消息类型设置相应的处理函数，以对订阅消息和转发消息进行处理。

S2022：通过获取的处理函数获取消息订阅页面的页面对象。

具体的，页面对象是预先针对消息订阅页面设置的。页面对象用于标识页面，以及可以用于获取页面的页面地址以实现通信。即可以将页面对象理解为每一页面的页面地址，通信时，可以通过页面的页面对象，可以实现各页面之间的数据通信。

一种实施方式中，页面对象为xindow对象。Window对象表示浏览器中打开的窗口。如果文档包含框架(frame或iframe标签)，则浏览器会为HTML文档创建一个window对象，并为每个框架创建一个额外的window对象。

S2023：建立消息类型和页面对象之间的对应关系，将消息类型和页面对象在内存中关联存储。

这样，Hub就可以在内存中将消息订阅页面订阅的消息类型与消息订阅页面的页面对象关联存储，即建立消息订阅页面订阅的消息类型与消息订阅页面的页面对象之间的对应关系，以便在后续的步骤中，根据该对应关系，将接收的页内传递消息，通过页内传递消息中包含的消息类型对应的页面对象，转发至相应的页面。

步骤203：Hub向消息订阅页面返回订阅成功消息。

具体的，Hub确定成功将消息类型和页面对象在内存中关联存储时，通过指定通信方式向消息订阅页面返回订阅成功消息。

一种实施方式中，Hub通过指定通信方式向消息订阅页面返回包含回调函数的订阅成功消息。

一种实施方式中，Hub通过指定通信方式向消息订阅页面返回不包含回调函数的订阅成功消息。

这样，在成功建立消息类型和页面对象之间的对应关系后，通知消息订阅页面订阅成功。

步骤204：消息订阅页面基于接收的订阅成功消息，将消息类型和回调函数关联存储。

具体的，一种实施方式中，当订阅成功消息中包含回调函数时，将消息订阅请求中包含的消息类型和订阅成功消息中包含的回调函数进行关联存储。

一种实施方式中，当订阅成功消息中包含回调函数时，将消息订阅请求中包含的消息类型和预先设置的回调函数进行关联存储。

这样，就可以建立消息类型和页面对象之间的对应关系，以及消息类型与回调函数之间的对应关系，实现消息的订阅，从而可以在后续的步骤中，通过消息类型和页面对象之间的对应关系，将接收的消息按照消息类型对应的页面对象，将该消息转发至相应的页面，以及该页面可以通过消息类型与回调函数之间的对应关系，调用消息类型对应的回调函数处理该消息。

参阅图3a所示，为一种消息订阅的交互流程图。本申请实施例中，采用一个具体的应用场景对上述实施例进行进一步具体说明，具体流程如下：

步骤300：消息订阅页面获取待订阅的消息类型和设置的回调函数。

步骤301：消息订阅页面将消息订阅请求发送至Hub。

具体的，消息订阅页面将包含消息类型和回调函数的消息订阅请求发送至Hub。

其中，执行步骤301时，具体步骤参见上述步骤200。

步骤302：Hub将根据接收的消息订阅请求获取的消息类型和页面对象关联存储。

具体的，Hub获取消息订阅请求中包含的消息类型，并获取消息订阅请求页面的页面对象，以及将消息类型和页面对象关联存储。

其中，执行步骤302时，具体步骤参见上述步骤202。

步骤303：Hub向消息订阅页面返回订阅成功消息。

具体的，执行步骤303时，具体步骤参见上述步骤203。

步骤304：消息订阅页面根据接收的订阅成功消息，将消息类型和回调函数关联存储。

具体的，消息订阅页面获取订阅成功消息中包含的回调函数，并建立回调函数与消息类型之间的关联关系。

例如，参阅图3b所示，为一种消息订阅的示例图。假设消息类型message-type：“hello_world”，回调函数callback：function，页面对象为：iframe1_winObj。

则消息订阅页面iframe1将包含message-type：“hello_world”和callback：function的消息订阅请求发送至Hub，Hub根据接收的消息订阅请求，将hello_world和iframe1_winObj关联存储，并向消息订阅页面iframe1返回订阅成功消息。消息订阅页面iframe1基于接收的订阅成功消息，将hello_world和function关联存储。

这样，Hub就可以根据消息订阅请求，将各消息类型和各页面对象关联存储，实现消息订阅。

参阅图4所示，为本申请提供的一种页内数据通信的方法的实施流程图。

该方法的具体流程如下：

步骤400：第一页面向Hub发送包含消息类型的页内传递消息。

具体的，第一页面构建页内传递消息的消息结构，并将构建好的页内传递消息通过指定通信方式，发送至Hub。

其中，构建好的页内传递消息中包含消息类型，以及消息内容。

一种实施方式中，第一页面通过postMessage，将包含消息类型和消息内容的页内传递消息发送至Hub。

这样，第一页面就可以通过Hub实现页内传递消息的广播。

步骤401：当Hub监听到第一页面发送的页内传递消息时，获取页内传递消息中包含的消息类型。

步骤402：Hub获取对应消息类型设置的页面对象。

需要说明的是，各消息类型和各页面对象是关联存储的，各消息类型对应的页面对象是对应发送消息订阅请求的消息订阅页面设置的。其中，消息订阅请求中包含消息类型，页面对象与消息订阅页面是对应设置的。

步骤403：Hub根据获取的页面对象，将页内传递消息转发至相应的第二页面。

具体的，Hub通过指定通信方式，根据页面对象，将页内传递消息转发至页面对象对应的第二页面。

需要说明的是，第二页面可以为一个，也可以为多个，在此不作限制。

其中，第一页面和第二页面分别为Hub所属的根页面或该根页面内的子页面，并且第一页面和第二页面是不同的页面。

进一步地，Hub确定页内传递消息发送成功之后，根据第二页面返回的响应消息，确定成功接收到页内传递消息的第二页面的页面数量，并将包含页面数量的通知消息返回至第一页面。

这样，Hub在成功转发将页内传递消息转发至第二页面后，通知第一页面发送成功的页面数量。

步骤404：第二页面采用对应消息类型设置的回调函数处理接收的页内传递消息。

具体的，第二页面根据预先设置的消息类型和回调函数之间的对应关系，调用页内传递消息中包含的消息类型对应的回调函数，处理接收的页内传递消息。

这样，第一页面和第二页面就可以通过Hub实现页内数据通信，仅在前端内进行数据处理，不需要后端服务器的支持，也不需要网络通信。

参阅图5a所示，为一种页内数据通信的交互流程图，下面采用一个具体的应用场景，对上述实施例进行进一步说明，具体流程如下：

步骤500：第一页面获取待发送的消息类型和消息内容。

步骤501：第一页面将包含消息类型和消息内容的页内传递消息发送至Hub。

具体的，执行步骤501时，具体步骤参见上述步骤400。

步骤502：Hub获取对应页内传递消息内的消息类型设置的页面对象。

具体的，执行步骤502时，具体步骤参见上述步骤402。

步骤503：Hub根据页面对象，将页内传递消息转发至相应的第二页面。

具体的，执行步骤503时，具体步骤参见上述步骤403。

步骤504：第二页面根据对应页内传递消息中的消息类型设置的回调函数，处理页内传递消息。

具体的，执行步骤504时，具体步骤参见上述步骤404。

步骤505：Hub确定成功接收页内传递消息的第二页面的页面数量，并将包含页面数量的通知消息发送至第一页面。

步骤506：第一页面确定接收到通知消息，执行消息发送成功回调函数。

例如，参阅图5b所示，为一种页内数据通信的示例图。假设第一页面为iframe2。iframe2将包含{message-type：“hello_world”data：xxxxxx}(即，消息类型和消息类型)的页内传递消息发送至Hub。Hub根据接收的页内传递消息，获取对应hello_world(消息类型)设置的winObj(页面对象)，并根据winObj，将页内传递消息发送至第二页面。

其中，第二页面包括：页面1(iframe)、页面2(iframe2)……xxxxxx。Hub确定成功接收页内传递消息的第二页面的页面数量，并将包含页面数量的通知消息发送至iframe2。

例如，参阅图5c所示，为一种《英雄联盟》大厅所在的root页面。参阅图5d所示，为一种防沉迷弹窗。图5c中的Root页面包括多个iframe和Hub。其中，root页面中的iframe1负责与后端服务器进行长连接通信。

iframe1将从后端服务器接收的玩家进入防沉迷通知转发至Hub。Hub根据消息类型和页面对象之间的对应关系，确定防沉迷通知中包含的消息类型对应root页面的页面对象，并通过root页面的页面对象，将该通知推送至root页面。root页面根据接收的通知，弹出图5d防沉迷弹窗，以阻止玩家继续玩游戏。这样，实现了iframe1与root页面通过Hub的页内数据通信。

需要说明的是，图5c仅用于示例说明一种root页面，图5c中的文字或线条不清晰不影响本申请说明书的示例说明。

本申请实施例中，在需要通信的root页面，引入Hub插件。root页面以及root页面中的每一子页面均可以向Hub进行消息订阅。当Hub接收到其它页面发送的页内传递消息时，通过postMessage将该页内传递消息转发至订阅页内传递消息中的消息类型的页面，实现一对一或一对多的页内数据通信。

这样，通过root页面中的Hub插件，采用web原生的API postMessage替代需要后端服务器支持的websocket等通信方式，仅在前端就可以进行页内数据通信，不需要后端服务器的通信支持，简化了通信的繁琐步骤，降低了通信成本，提高了通信效率。进一步地，由于不存在网络传输，因此，不会出现网络超时以及长连接失效等问题，提高了通信成功率。

基于同一发明构思，本申请实施例中还提供了一种页内数据通信的装置，由于上述装置及设备解决问题的原理与一种页内数据通信的方法相似，因此，上述装置的实施可以参见方法的实施，重复之处不再赘述。

如图6示，其为本申请实施例提供的一种页内数据通信的装置的结构示意图。一种页内数据通信的装置包括：

监听单元601，用于当监听到第一页面发送的页内传递消息时，获取页内传递消息中包含的消息类型，Hub为根页面中用于消息的订阅和转发的插件；

获取单元602，用于获取对应消息类型设置的页面对象，各消息类型对应的页面对象是对应发送消息订阅请求的消息订阅页面设置的，消息订阅请求中包含消息类型；

发送单元603，用于根据获取的页面对象，将页内传递消息转发至相应的第二页面，使得第二页面采用对应消息类型设置的回调函数处理页内传递消息；

其中，第一页面和所述第二页面分别为Hub所属的根页面或该根页面内的子页面。

较佳的，获取单元602用于：

当监听到消息订阅页面发送的消息订阅请求时，获取消息订阅请求中包含的消息类型；

获取消息订阅页面的页面对象；

将消息订阅请求中的消息类型以及消息订阅页面的页面对象关联存储；

向消息订阅页面返回订阅成功消息，使得消息订阅页面将消息订阅请求中的消息类型和设置的回调函数关联存储。

较佳的，发送单元603用于：

通过postMessage通信方式，将页内传递消息转发至页面对象对应的第二页面。

较佳的，发送单元603还用于：

确定成功接收到页内传递消息的第二页面的页面数量；

将包含页面数量的通知消息，发送至第一页面。

本申请实施例提供的一种页内数据通信的方法、装置、设备和介质中，root页面中的Hub根据接收的消息订阅页面发送的包含消息类型的消息订阅请求，建立消息订阅页面的页面对象与消息类型之间的对应关系。当Hub监听到第一页面发送的页内传递消息时，根据页内传递消息中包含的消息类型，获取对应该消息类型设置的页面对象，以及根据页面对象，将页内传递消息转发至相应的第二页面。这样，在root页面中引入Hub插件，以Hub为数据中转站，使得root页面以及root页面中的各子页面可以通过Hub进行数据转发，实现页内数据通信，不需要后端服务器的支持，不需要网络通信，简化了通信步骤，降低了通信成本，提高了通信效率和成功率。

图7示出了一种控制设备7000的结构示意图。参阅图7所示，控制设备7000包括：处理器7010、存储器7020、电源7030、显示单元7040、输入单元7050。

处理器7010是控制设备7000的控制中心，利用各种接口和线路连接各个部件，通过运行或执行存储在存储器7020内的软件程序和/或数据，执行控制设备7000的各种功能，从而对控制设备7000进行整体监控。

本申请实施例中，处理器7010调用存储器7020中存储的计算机程序时执行如图4中所示的实施例提供的页内数据通信的方法。

可选的，处理器7010可包括一个或多个处理单元；优选的，处理器7010可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器7010中。在一些实施例中，处理器、存储器、可以在单一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

存储器7020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、各种应用等；存储数据区可存储根据控制设备7000的使用所创建的数据等。此外，存储器7020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件等。

控制设备7000还包括给各个部件供电的电源7030(比如电池)，电源可以通过电源管理系统与处理器7010逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗等功能。

显示单元7040可用于显示由用户输入的信息或提供给用户的信息以及控制设备7000的各种菜单等，本发明实施例中主要用于显示控制设备7000中各应用的显示界面以及显示界面中显示的文本、图片等对象。显示单元7040可以包括显示面板7041。显示面板7041可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置。

输入单元7050可用于接收用户输入的数字或字符等信息。输入单元7050可包括触控面板7051以及其他输入设备7052。其中，触控面板7051，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触摸笔等任何适合的物体或附件在触控面板7051上或在触控面板7051附近的操作)。

具体的，触控面板7051可以检测用户的触摸操作，并检测触摸操作带来的信号，将这些信号转换成触点坐标，发送给处理器7010，并接收处理器7010发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板7051。其他输入设备7052可以包括但不限于物理键盘、功能键(比如音量控制按键、开关机按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

当然，触控面板7051可覆盖显示面板7041，当触控面板7051检测到在其上或附近的触摸操作后，传送给处理器7010以确定触摸事件的类型，随后处理器7010根据触摸事件的类型在显示面板7041上提供相应的视觉输出。虽然在图7中，触控面板7051与显示面板7041是作为两个独立的部件来实现控制设备7000的输入和输出功能，但是在某些实施例中，可以将触控面板7051与显示面板7041集成而实现控制设备7000的输入和输出功能。

控制设备7000还可包括一个或多个传感器，例如压力传感器、重力加速度传感器、接近光传感器等。当然，根据具体应用中的需要，上述控制设备7000还可以包括摄像头等其它部件，由于这些部件不是本申请实施例中重点使用的部件，因此，在图7中没有示出，且不再详述。

本领域技术人员可以理解，图7仅仅是控制设备的举例，并不构成对控制设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任意方法实施例中的页内数据通信的方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台控制设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (8)

1.一种页内数据通信的方法，其特征在于，包括：

当插件Hub监听到第一页面发送的页内传递消息时，获取所述页内传递消息中包含的消息类型，所述Hub为根页面中用于消息的订阅和转发的插件；

根据所述消息类型，获取对应所述消息类型设置的处理函数；

通过获取的所述处理函数获取消息订阅页面的页面对象；

建立消息类型和页面对象之间的对应关系，将消息类型和页面对象在内存中关联存储；所述页面对象是对应发送消息订阅请求的消息订阅页面设置的，所述消息订阅请求中包含消息类型；

通过postMessage通信方式，将所述页内传递消息转发至所述页面对象对应的第二页面，使得所述第二页面根据预先设置的消息类型和回调函数之间的对应关系，调用页内传递消息中包含的消息类型对应的回调函数处理所述页内传递消息；

其中，所述第一页面和所述第二页面分别为所述Hub所属的根页面或该根页面内的子页面。

2.如权利要求1所述的方法，其特征在于，所述页面对象是对应发送消息订阅请求的消息订阅页面设置的，具体包括：

当监听到消息订阅页面发送的消息订阅请求时，获取所述消息订阅请求中包含的消息类型；

获取所述消息订阅页面的页面对象；

将所述消息订阅请求中的消息类型以及所述消息订阅页面的页面对象关联存储；

向所述消息订阅页面返回订阅成功消息，使得所述消息订阅页面将所述消息订阅请求中的消息类型和设置的回调函数关联存储。

3.如权利要求1或2所述的方法，其特征在于，在将所述页内传递消息转发至相应的第二页面之后，进一步包括：

确定成功接收到所述页内传递消息的第二页面的页面数量；

将包含所述页面数量的通知消息，发送至所述第一页面。

4.一种页内数据通信的装置，其特征在于，包括：

监听单元，用于当插件Hub监听到第一页面发送的页内传递消息时，获取所述页内传递消息中包含的消息类型，所述Hub为根页面中用于消息的订阅和转发的插件；

获取单元，用于根据所述消息类型，获取对应所述消息类型设置的处理函数；通过获取的所述处理函数获取消息订阅页面的页面对象；建立消息类型和页面对象之间的对应关系，将消息类型和页面对象在内存中关联存储；所述页面对象是对应发送消息订阅请求的消息订阅页面设置的，所述消息订阅请求中包含消息类型；

发送单元，用于通过postMessage通信方式，将所述页内传递消息转发至所述页面对象对应的第二页面，使得所述第二页面根据预先设置的消息类型和回调函数之间的对应关系，调用页内传递消息中包含的消息类型对应的回调函数处理所述页内传递消息；

其中，所述第一页面和所述第二页面分别为所述Hub所属的根页面或该根页面内的子页面。

5.如权利要求4所述的装置，其特征在于，所述获取单元用于：

当监听到消息订阅页面发送的消息订阅请求时，获取所述消息订阅请求中包含的消息类型；

获取所述消息订阅页面的页面对象；

将所述消息订阅请求中的消息类型以及所述消息订阅页面的页面对象关联存储；

向所述消息订阅页面返回订阅成功消息，使得所述消息订阅页面将所述消息订阅请求中的消息类型和设置的回调函数关联存储。

6.如权利要求4或5所述的装置，其特征在于，所述发送单元还用于：

确定成功接收到所述页内传递消息的第二页面的页面数量；

将包含所述页面数量的通知消息，发送至所述第一页面。

7.一种控制设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-3任一项所述的方法的步骤。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1~3任一所述方法的步骤。