CN113591006A - 一种基于WebSocket的Web扩展方法和装置 - Google Patents

Abstract

本发明涉及一种基于WebSocket的Web扩展方法和装置，其中，该方法在WebSocket服务端执行：按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；设置本地服务事件监听；注册扩展接口的消息处理函数；建立与Web端的双向通信；注册通用消息处理函数；建立事件监听回调通道；循环等待Web端的请求消息。通过本申请，解决了相关技术中存在的Web扩展需要依赖JS引擎或者带JS引擎的宿主，当JS引擎或者其宿主发生变化时，Webapp不能直接正常运行，需要重新实现其扩展的问题，实现了不依赖JS引擎或者其宿主，只需实现一次扩展。

Description

一种基于WebSocket的Web扩展方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于WebSocket的Web扩展方法、装置、计算机设备和计算机可读存储介质。

背景技术

现有Web常见的扩展方案原理是基于JS引擎或者浏览器中基于JS引擎的框架。基本原理是将native接口通过一个字符串绑定注册进JS引擎，使得Web上下文能够识别这个字段，当调用这个字段的时候，等于调用到native接口，然后Native接口会处理具体的请求，然后把结果返回给Web。现有的扩展方案依赖JS引擎或者带JS引擎的宿主(浏览器)。当JS引擎或者其宿主发生变化时，Webapp不能直接正常运行，需要重新实现其扩展。

目前，针对相关技术中存在的Web扩展需要依赖JS引擎或者带JS引擎的宿主，当JS引擎或者其宿主发生变化时，Webapp不能直接正常运行，需要重新实现其扩展的问题，尚未提出有效的解决方案。

发明内容

本申请的目的是针对现有技术中的不足，提供一种基于WebSocket的Web扩展方法、装置、计算机设备和计算机可读存储介质，以至少解决相关技术中存在的Web扩展需要依赖JS引擎或者带JS引擎的宿主，当JS引擎或者其宿主发生变化时，Webapp不能直接正常运行，需要重新实现其扩展的问题。

为实现上述目的，本申请采取的技术方案是：

第一方面，本申请实施例提供了一种基于WebSocket的Web扩展方法，所述方法在WebSocket服务端的执行流程包括：

按照格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

设置本地服务事件监听；

注册扩展接口的消息处理函数；

建立与Web端的双向通信；

注册通用消息处理函数；

建立事件监听回调通道；

循环等待Web端的请求消息。

在其中一些实施例中，所述方法在Web端的执行流程包括：

添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

添加JS扩展接口描述文件，并初始化JS扩展接口；

注册应用所需的事件监听；

使用所述JS扩展接口开发应用。

在其中一些实施例中，添加JS扩展接口描述文件，并初始化JS扩展接口包括：

将所述JS扩展接口的函数挂载到JS上下文；

为所述JS扩展接口的函数设置发送函数；

构造消息参数；

为每个消请求消息分配唯一标识。

在其中一些实施例中，注册应用所需的事件监听包括：

在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

第二方面，本申请实施例提供了一种基于WebSocket的Web扩展装置，所述装置包括第一执行单元，用于在WebSocket服务端执行流程，其中，所述第一执行单元包括：

定义模块，用于按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

设置模块，用于设置本地服务事件监听；

第一注册模块，用于注册扩展接口的消息处理函数；

第一建立模块，用于建立与Web端的双向通信；

第二注册模块，用于注册通用消息处理函数；

第二建立模块，用于建立事件监听回调通道；

等待模块，用于循环等待Web端的请求消息。

在其中一些实施例中，所述装置还包括第二执行单元，用于在Web端执行流程，其中，所述第二执行单元包括：

第一添加模块，用于添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

第二添加模块，用于添加JS扩展接口描述文件，并初始化JS扩展接口；

第三注册模块，用于注册应用所需的事件监听；

开发模块，用于使用所述JS扩展接口开发应用。

在其中一些实施例中，所述第二添加模块包括：

挂载子模块，用于将所述JS扩展接口的函数挂载到JS上下文；

设置子模块，用于为所述JS扩展接口的函数设置发送函数；

构造子模块，用于构造消息参数；

分配子模块，用于为每个消请求消息分配唯一标识。

在其中一些实施例中，所述第三注册模块包括：

注册子模块，用于在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的基于WebSocket的Web扩展方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的基于WebSocket的Web扩展方法。

本申请采用以上技术方案，与现有技术相比，本申请实施例提供的基于WebSocket的Web扩展，通过在WebSocket服务端执行：按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；设置本地服务事件监听；注册扩展接口的消息处理函数；建立与Web端的双向通信；注册通用消息处理函数；建立事件监听回调通道；循环等待Web端的请求消息，解决了相关技术中存在的Web扩展需要依赖JS引擎或者带JS引擎的宿主，当JS引擎或者其宿主发生变化时，Webapp不能直接正常运行，需要重新实现其扩展的问题，实现了不依赖JS引擎或者其宿主，只需实现一次扩展。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

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

图1是根据本申请实施例的移动终端的结构框图；

图2是根据本申请实施例的基于WebSocket的Web扩展方法的框架结构图；

图3是根据本申请实施例的基于WebSocket的Web扩展方法在WebSocket服务端的执行流程的流程图；

图4是根据本申请实施例的基于WebSocket的Web扩展方法在Web端的执行流程的流程图；

图5是根据本申请实施例的基于WebSocket的Web扩展装置的结构框图；

图6是根据本申请另一实施例的基于WebSocket的Web扩展装置的结构框图；

图7为根据本申请实施例的计算机设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本实施例提供了一种移动终端。图1是根据本申请实施例的移动终端的结构框图。如图1所示，该移动终端包括：射频(Radio Frequency，简称为RF)电路110、存储器120、输入单元130、显示单元140、传感器150、音频电路160、无线保真(wireless fidelity，简称为WiFi)模块170、处理器180、以及电源190等部件。本领域技术人员可以理解，图1中示出的移动终端结构并不构成对移动终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1对移动终端的各个构成部件进行具体的介绍：

RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器180处理；另外，将设计上行的数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，简称为LNA)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯***(Global System of Mobile communication，简称为GSM)、通用分组无线服务(GeneralPacket Radio Service，简称为GPRS)、码分多址(Code Division Multiple Access，简称为CDMA)、宽带码分多址(Wideband Code Division Multiple Access，简称为WCDMA)、长期演进(Long Term Evolution，简称为LTE)、电子邮件、短消息服务(Short MessagingService，简称为SMS)等。

存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行移动终端的各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据移动终端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元130可用于接收输入的数字或字符信息，以及产生与移动终端的用户设置以及功能控制有关的键信号输入。具体地，输入单元130可包括触控面板131以及其他输入设备132。触控面板131，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板131上或在触控面板131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板131。除了触控面板131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元140可用于显示由用户输入的信息或提供给用户的信息以及移动终端的各种菜单。显示单元140可包括显示面板141，可选的，可以采用液晶显示器(LiquidCrystal Display，简称为LCD)、有机发光二极管(Organic Light-Emitting Diode，简称为OLED)等形式来配置显示面板141。进一步的，触控面板131可覆盖显示面板141，当触控面板131检测到在其上或附近的触摸操作后，传送给处理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图1中，触控面板131与显示面板141是作为两个独立的部件来实现移动终端的输入和输入功能，但是在某些实施例中，可以将触控面板131与显示面板141集成而实现移动终端的输入和输出功能。

移动终端还可包括至少一种传感器150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在移动终端移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别移动终端姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于移动终端还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路160中的扬声器161，传声器162可提供用户与移动终端之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经RF电路110以发送给比如另一移动终端，或者将音频数据输出至存储器120以便进一步处理。

WiFi属于短距离无线传输技术，移动终端通过WiFi模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图1示出了WiFi模块170，但是可以理解的是，其并不属于移动终端的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略，或者替换为其他的短距离无线传输模块，例如Zigbee模块、或者WAPI模块等。

处理器180是移动终端的控制中心，利用各种接口和线路连接整个移动终端的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行移动终端的各种功能和处理数据，从而对移动终端进行整体监控。可选的，处理器180可包括一个或多个处理单元；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器180中。

移动终端还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理***与处理器180逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。

尽管未示出，移动终端还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本实施例中，处理器180被配置为：在WebSocket服务端，按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；设置本地服务事件监听；注册扩展接口的消息处理函数；建立与Web端的双向通信；注册通用消息处理函数；建立事件监听回调通道；循环等待Web端的请求消息。

在其中一些实施例中，处理器180还被配置为：在Web端，添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；添加JS扩展接口描述文件，并初始化JS扩展接口；注册应用所需的事件监听；使用所述JS扩展接口开发应用。

在其中一些实施例中，处理器180还被配置为：将所述JS扩展接口的函数挂载到JS上下文；为所述JS扩展接口的函数设置发送函数；构造消息参数；为每个消请求消息分配唯一标识。

在其中一些实施例中，处理器180还被配置为：在确定与WebSocket服务端成功建立通信连接之后，注册事件监听。

本实施例提供了一种基于WebSocket的Web扩展方法。

首先，对本申请实施例中出现的技术术语进行如下解释：

1)WebSocket：一种可与WebSocket Server双向通信的网络技术。本申请实施例通过WebSocket技术来获取服务能力。

2)WebSocket Server：基于WebSocket的服务端，用于响应Web请求。

3)JS接口列表：用JsJson技术按一定格式描述要扩展的接口信息。

4)JS扩展接口模块：是对WebSocket的封装，提供JS接口列表初始化接口，添加和移除事件监听接口等。

5)Adaptor：适配层，实际处理JS接口请求，对接服务。

6)Web app：使用Web技术开发的app。Web技术包括但不限H5+JS，其变种，其子集。

本申请可应用于想要用Web技术开发具备本地服务能力的一切应用。

图2是根据本申请实施例的基于WebSocket的Web扩展方法的框架结构图，如图2所示，基于WebSocket的Web扩展方法的框架结构包括Web端以及WebSocket服务端、浏览器以及本地服务，Web端以及WebSocket服务端之间进行通信连接，WebSocket服务端设置有适配层，利用该适配层可以调用本地服务。

基于WebSocket的Web扩展方法分为WebSocket服务端的执行流程以及在Web端的执行流程。

图3是根据本申请实施例的基于WebSocket的Web扩展方法在WebSocket服务端的执行流程的流程图，如图3所示，在WebSocket服务端的执行流程包括如下步骤：

步骤S301，按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

步骤S302，设置本地服务事件监听；

步骤S303，注册扩展接口的消息处理函数；

步骤S304，建立与Web端的双向通信；

步骤S305，注册通用消息处理函数；

步骤S306，建立事件监听回调通道；

步骤S307，循环等待Web端的请求消息。

图4是根据本申请实施例的基于WebSocket的Web扩展方法在Web端的执行流程的流程图，如图4所示，在Web端的执行流程包括如下步骤：

步骤S401，添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

步骤S402，添加JS扩展接口描述文件，并初始化JS扩展接口；

步骤S403，注册应用所需的事件监听；

步骤S404，使用所述JS扩展接口开发应用。

在其中一些实施例中，步骤S402添加JS扩展接口描述文件，并初始化JS扩展接口包括：

将所述JS扩展接口的函数挂载到JS上下文；

为所述JS扩展接口的函数设置发送函数；

构造消息参数；

为每个消请求消息分配唯一标识。

在其中一些实施例中，步骤S403注册应用所需的事件监听包括：

在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

通过上述步骤，解决了相关技术中存在的Web扩展需要依赖JS引擎或者带JS引擎的宿主，当JS引擎或者其宿主发生变化时，Web app不能直接正常运行，需要重新实现其扩展的问题，实现了不依赖JS引擎或者其宿主，只需实现一次扩展。

本发明用WebSocket的方式绕开了原本的基于JS引擎或者其宿主的扩展方式。

在Web端的流程为：

a)在网页头部添加封装好的JS扩展库，当网页运行时，会自动连接Websocketserver端；

b)在网页头部添加JS扩展接口描述文件；

c)初始化JS扩展接口；

d)注册各模块事件监听；

e)使用扩展接口开发应用。

在WebSocket Server端的流程为：

a)书写JS扩展接口描述；

b)自动Adaptor层代码并实现；

c)设置***服务的监听；

d)注册扩展接口的消息处理函数(Adaptor)，WebSocket Server端最后通过这个监听容器分发请求；

e)建立WebSocket Server；

f)注册通用消息处理函数，有主动请求接口，事件监听添加接口，事件监听移除接口；关于a)中描述都是主动请求接口，在其消息处理中会根据入参分发；

g)建立事件监听回调通道；

h)循环等待Web请求或通知。

具体地：

在Web端的流程包括：

a)在网页头部添加封装好的JS扩展库。当网页运行时，会首先运行，初始化WebSocket，需要做好onpen、onerror、onmessage、onclose、send封装工作。

b)在网页头部添加JS扩展接口描述文件。接口描述文件由扩展开发者提供，在这里添加是为初始化做准备。

c)初始化JS扩展接口。按模块将扩展接口注册进JS上下文，往后就可正常调用扩展接口。

d)注册各模块事件监听。这一步需要在确认和Websocket server连接成功后再注册，否则Web端保存了回调，但相关key没有同步同WebSocket Server端。

e)使用扩展接口开发应用。准备工作已经完毕，可以开始开发应用。

在WebSocket Server端的流程包括：

a)书写JS扩展接口描述。描述扩展接口是什么模块，该模块下有什么API，各个API都有什么参数。

b)自动生成Adaptor层代码并实现。书写脚本自动解析JS扩展接口描述，提供注册扩展接口的API，生成Adaptor的空实现。

c)设置***服务的监听。Web需要注册有些服务的状态，WebSocket Server本身不具备，需要向本地服务注册。

d)注册扩展接口的消息处理函数(Adaptor)，WebSocket Server端最后通过这个监听容器分发请求。用自动生成Adaptor代码中的注册扩展接口的API设置监听。

e)建立WebSocket Server。与Web端双向通信。

f)注册通用消息处理函数。有主动请求接口，事件监听添加接口，事件监听移除接口。关于a)中描述都是主动请求接口，在其消息处理中会根据入参分发。

g)建立事件监听回调通道。主要是当Web端注册一个本地服务事件，但它发生时，需要通知给Web端。

h)循环等待Web请求或通知。保持WebSocket活动。

本申请的一个具体的实例，比如现在需要一个接口来获取电视***的时区。

首先是WebSocket Server端的执行流程：

1)首先需要书写JS接口描述。

2)通过脚本解析JS接口描述生成或者自己写好Adaptor代码。

void apihnd_sraftv_timer_get_time_zone(intid,

const Json::Value&params,Json::Value&result){

TvTimerServicetvTimerService；//***服务

result["value"]＝tvTimerService.getTimeZone()；

result["status"]＝"ok"；

}

3)设置***服务的监听。

这个接口没有监听事件的场景。如果其他接口需要，可按照本地服务监听规范进行监听，并设置好回调函数。

4)注册扩展接口的消息处理函数。

在WebSocket Server启动时，将JS接口描述对应的Adaptor存入一个map中。本例中key可以是sraftv_timer_get_time_zone，当前端请求时，会将接口的模块，子模块，函数以下划线拼接，作为参数传下，最后通过这个key值找到对应的Adaptor。

5)建立WebSocket Server。

可获取任何开源好用的库，比如Libwebsockets，按照其规范进行搭建。设置好端口，双向通信处理函数。主要工作有：

a)WebSocket上下文信息准备和服务启动。

设置好端口，可以是8989；设置好协议状态的处理函数；并起一个线程启动服务并等待消息过来。

b)协议状态的处理。这里只说明接收到消息的处理。

本例中接收消息的状态是LWS_CALLBACK_RECEIVE。当前端发送消息时，就将前端消息打入一个队列中。

6)Web端消息队列消息处理流程。

起一个新的线程，检查消息队列是否有消息，如果有，一一拿出处理；如果没有，等待。

7)通用消息处理函数注册

在进行消息解析前，先说明通用消息处理函数。实际操作时，只需要在请求前注册即可。通用的消息处理只有controlPlatform，addPlatformListener，removePlatformListener。所有API的主动请求都是通过前者传递，后两者则是用来添加或者移除本地***服务或者操作***服务的事件监听。

8)前端消息解析处理。

当前端来消息，并被取出处理时，首先要做的是分发给哪个通用函数。本例中需要分发给controlPlatform。

9)通用消息处理函数(controlPlatform)

解析前端消息参数，找到扩展接口KEY，找到对应Adaptor并执行。

在Web端的执行流程：

1)添加JS扩展库。

a)启动WebSocket连接，并写好各状态回调。

各状态回调有onpen,onerror,onmessage,onclose。其中最主要的是onmessage，这个函数触发，代表着WebSocketServer端有消息过来了。

b)对扩展接口列表的初始化。

初始化第一步主要是将各模块函数挂载到JS上下文。本例中，sraftv可以作为全局变量，然后timer挂在sraftv下，最后get_time_zone挂在timer下；所以之后开发这就可以通过sraftv.timer.get_time_zone的形式来发起请求，这样就传统API的调用方式一样。

初始化第二步是要为各扩展函数设置统一的发送函数。当Web开发这调用扩展函数等于调用这个发送函数。这个形式可以使用Promise，可以很好地进行异步开发。

初始化第三步是构造消息参数。首先是构造通用消息处理的参数，本例中是controlPlatform，然后构建Adaptor的Key参数，本例中为sraftv_timer_get_timer_zone,如果扩展接口有参数，参数可用Json格式描述，本例中没有。

初始化第四步是给每个请求标识唯一Id。并根据这个Id保存其回调函数，这样当WebSocket Server响应时可找到其回调。

具体代码实例如下：

在申请实施例中，当Web调用扩展API时，会按照自定义的消息协议将其转换成一定格式的字符串消息，通过WebSocket技术将其发送给本地的WebSocket server；WebSocket server会解析消息，再分发给相关Adaptor处理，相关Adaptor再调用本地***服务能力实现请求，如果有结果，将结果再通过Websocket技术返回给Web端。

关键技术点：

1)通过WebSocket技术实现Web和Native之间的沟通，解决了现有扩展模式依赖JS引擎或者其宿主的问题。

2)扩展接口描述，是Web能力扩展开发者和WebApp开发者沟通的桥梁，也是Web扩展接口和Adaptor实现能够一一对应的保证。

3)JS扩展模块库，封装了WebSocket重复而多细节，并提供JS接口列表初始化接口，添加和移除事件监听接口等，使得Web可以通过传统的API调用方式使用扩展API。

4)Adaptor自动生成脚本，快速生成Adaptor代码，只需关注具体的请求实现。

本申请实施例能够实现以下技术效果：

1)打破Web扩展对JS引擎或者带JS引擎的宿主(浏览器)的依赖。使得如果在不同的浏览器厂商(举例)运行，不需要再针对新的浏览器进行扩展。

2)使用JS接口描述，使得前端初始化和后端Adaptor一一对应，在整体框架建立后，开发者无需再关心其中过程，使得补充扩展变得十分简单，入手非常快。

3)初始化扩展接口，使得Web端开发者可以用传统的调用方式使用扩展接口，不需要学习成本。并使用Promise特性，分离了异步数据获取和业务逻辑，使开发人员专注于其中一个事务，不需要同时考虑。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例提供了一种基于WebSocket的Web扩展装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5是根据本申请实施例的基于WebSocket的Web扩展装置的结构框图，如图5所示，所述装置包括第一执行单元51，用于在WebSocket服务端执行流程，其中，所述第一执行单元51包括：

定义模块511，用于按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

设置模块512，用于设置本地服务事件监听；

第一注册模块513，用于注册扩展接口的消息处理函数；

第一建立模块514，用于建立与Web端的双向通信；

第二注册模块515，用于注册通用消息处理函数；

第二建立模块516，用于建立事件监听回调通道；

等待模块517，用于循环等待Web端的请求消息。

在其中一些实施例中，如图6所示，所述装置还包括第二执行单元52，用于在Web端执行流程，其中，所述第二执行单元52包括：

第一添加模块521，用于添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

第二添加模块522，用于添加JS扩展接口描述文件，并初始化JS扩展接口；

第三注册模块523，用于注册应用所需的事件监听；

开发模块524，用于使用所述JS扩展接口开发应用。

在其中一些实施例中，所述第二添加模块522包括：

挂载子模块，用于将所述JS扩展接口的函数挂载到JS上下文；

设置子模块，用于为所述JS扩展接口的函数设置发送函数；

构造子模块，用于构造消息参数；

分配子模块，用于为每个消请求消息分配唯一标识。

在其中一些实施例中，所述第三注册模块523包括：

注册子模块，用于在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

实施例提供了一种计算机设备。结合本申请实施例基于WebSocket的Web扩展方法可以由计算机设备来实现。图7为根据本申请实施例的计算机设备的硬件结构示意图。

计算机设备可以包括处理器71以及存储有计算机程序指令的存储器72。

具体地，上述处理器71可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器72可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器72可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器72可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器72可在数据处理装置的内部或外部。在特定实施例中，存储器72是非易失性(Non-Volatile)存储器。在特定实施例中，存储器72包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(RandomAccess Memory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为EPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器72可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器71所执行的可能的计算机程序指令。

处理器71通过读取并执行存储器72中存储的计算机程序指令，以实现上述实施例中的任意一种基于WebSocket的Web扩展方法。

在其中一些实施例中，计算机设备还可包括通信接口73和总线70。其中，如图7所示，处理器71、存储器72、通信接口73通过总线70连接并完成相互间的通信。

通信接口73用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。通信接口73还可以实现与其他部件例如：外接设备、图像/数据采集设备、数据库、外部存储以及图像/数据处理工作站等之间进行数据通信。

总线70包括硬件、软件或两者，将计算机设备的部件彼此耦接在一起。总线70包括但不限于以下至少之一：数据总线(Data Bus)、地址总线(Address Bus)、控制总线(Control Bus)、扩展总线(Expansion Bus)、局部总线(Local Bus)。举例来说而非限制，总线70可包括图形加速接口(Accelerated Graphics Port，简称为AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，简称为EISA)总线、前端总线(Front Side Bus，简称为FSB)、超传输(Hyper Transport，简称为HT)互连、工业标准架构(Industry Standard Architecture，简称为ISA)总线、无线带宽(InfiniBand)互连、低引脚数(Low Pin Count，简称为LPC)总线、存储器总线、微信道架构(Micro ChannelArchitecture，简称为MCA)总线、***组件互连(Peripheral Component Interconnect，简称为PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial AdvancedTechnology Attachment，简称为SATA)总线、视频电子标准协会局部(Video ElectronicsStandards Association Local Bus，简称为VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线70可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的基于WebSocket的Web扩展方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种基于WebSocket的Web扩展方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于WebSocket的Web扩展方法，其特征在于，所述方法在WebSocket服务端的执行流程包括：

按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

设置本地服务事件监听；

注册扩展接口的消息处理函数；

建立与Web端的双向通信；

注册通用消息处理函数；

建立事件监听回调通道；

循环等待Web端的请求消息。

2.根据权利要求1所述的基于WebSocket的Web扩展方法，其特征在于，所述方法在Web端的执行流程包括：

添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

添加JS扩展接口描述文件，并初始化JS扩展接口；

注册应用所需的事件监听；

使用所述JS扩展接口开发应用。

3.根据权利要求2所述的基于WebSocket的Web扩展方法，其特征在于，添加JS扩展接口描述文件，并初始化JS扩展接口包括：

将所述JS扩展接口的函数挂载到JS上下文；

为所述JS扩展接口的函数设置发送函数；

构造消息参数；

为每个消请求消息分配唯一标识。

4.根据权利要求2所述的基于WebSocket的Web扩展方法，其特征在于，注册应用所需的事件监听包括：

在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

5.一种基于WebSocket的Web扩展装置，其特征在于，所述装置包括第一执行单元，用于在WebSocket服务端执行流程，其中，所述第一执行单元包括：

定义模块，用于按格式抒写JS扩展接口描述文件，并生成所述JS扩展接口描述文件对应的适配层代码；

设置模块，用于设置本地服务事件监听；

第一注册模块，用于注册扩展接口的消息处理函数；

第一建立模块，用于建立与Web端的双向通信；

第二注册模块，用于注册通用消息处理函数；

第二建立模块，用于建立事件监听回调通道；

等待模块，用于循环等待Web端的请求消息。

6.根据权利要求5所述的基于WebSocket的Web扩展装置，其特征在于，所述装置还包括第二执行单元，用于在Web端执行流程，其中，所述第二执行单元包括：

第一添加模块，用于添加封装好的JS扩展库，并在网页运行时自动建立与WebSocket服务端之间的通信连接；

第二添加模块，用于添加JS扩展接口描述文件，并初始化JS扩展接口；

第三注册模块，用于注册应用所需的事件监听；

开发模块，用于使用所述JS扩展接口开发应用。

7.根据权利要求6所述的基于WebSocket的Web扩展装置，其特征在于，所述第二添加模块包括：

挂载子模块，用于将所述JS扩展接口的函数挂载到JS上下文；

设置子模块，用于为所述JS扩展接口的函数设置发送函数；

构造子模块，用于构造消息参数；

分配子模块，用于为每个消请求消息分配唯一标识。

8.根据权利要求6所述的基于WebSocket的Web扩展装置，其特征在于，所述第三注册模块包括：

注册子模块，用于在确定与WebSocket服务端成功建立通信连接之后，注册应用所需的事件监听。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至4中任一项所述的基于WebSocket的Web扩展方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至4中任一项所述的基于WebSocket的Web扩展方法。

Images