CN115514611B - 消息处理方法、装置、设备及存储介质 - Google Patents

Abstract

本公开的实施方式涉及计算机技术领域，更具体地，本公开的实施方式涉及消息处理方法、装置、设备及存储介质。本公开的技术方案提供了一套统一的通信协议对应关系，多个容器只需要对应部署一套原生组件，当多个容器需要与该原生组件进行消息传输时，通过事先设置的通信协议对应关系，消息能够转换成统一的原生端通信协议，从而精准送达原生组件。反之，来自原生组件并基于统一的原生端通信协议的消息也可以被转换成对应容器所支持的容器通信协议，再送达到容器。因此，当客户端中接入多个容器的情况下，开发人员在开发原生组件时，不需要每个容器都按照对应的容器通信协议各自开发一套原生组件，这大大降低了代码重复率。

Description

消息处理方法、装置、设备及存储介质

技术领域

本公开的实施方式涉及消息处理技术领域，更具体地，本公开的实施方式涉及消息处理方法、装置、设备及存储介质。

背景技术

本部分旨在为本公开的实施方式提供背景或上下文，此处的描述不因为包括在本部分中就承认是现有技术。

应用程序侧客户端在业务不断沉淀的过程中，可能会发展出多套容器，以满足不同的业务场景需求。其中，容器提供抽象的、标准化的统一基础能力，而之外的众多系统能力、业务能力等，需要开发对应的原生功能，并以原生组件的形式进行部署。容器可通过通信协议与原生组件进行消息传输。

在相关技术中，每个容器都有一套自己的通信协议，容器在与原生组件进行通信的时候，每个容器都需要按照各自的协议开发一套对应的原生组件。

如图1所示，对应于H5容器，在原生端开发bridge1、bridge2、bridge3、…等原生组件，H5容器与原生端之间通过JSBridge协议进行通信；

对应于Flutter容器，在原生端开发plugin1、plugin2、plugin3、…等原生组件，Flutter容器与原生端之间通过FlutterPlugin协议进行通信；

对应于RN容器，在原生端开发module1、module12、module13、…等原生组件，RN容器与原生端之间通过RCTBridgeModule协议进行通信。

在这种情况下，每个容器都有一套自己的通信协议，客户端每加入一种容器，都要按照容器各自的协议重新开发一遍所需要的原生组件。

发明内容

在本上下文中，本发明的实施方式期望提供一种消息处理方法、装置、设备及存储介质。

根据本公开的一个方面，提供一种消息处理方法，在应用程序中部署有原生端和容器端；消息处理方法包括：

从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；

基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；

将基于第二通信协议的目标消息转发给第二端。

在本公开示例性实施方式中，消息处理方法还包括：

在从第二端获取到目标消息的响应消息的情况下，获得响应消息所基于的第二通信协议，对响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息；

将基于第一通信协议的响应消息转发给第一端。

在本公开示例性实施方式中，在原生端部署有多个原生桥接器，原生桥接器与不同类容器支持的容器通信协议之间一一对应；消息处理方法具体应用于对应的原生桥接器。

在本公开示例性实施方式中，在原生端还部署原生桥服务模块和原生组件管理器；在第一端为容器端部署的容器的情况下，将基于第二通信协议的目标消息转发给第二端，包括：

对基于第二通信协议的目标消息进行解析，得到解析数据；

将解析数据转发给第二端。

在本公开示例性实施方式中，消息处理方法还包括：

获取目标消息的响应消息；

对响应消息基于第二通信协议进行封装；

对基于第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息并转发给第一端。

在本公开示例性实施方式中，在第一端为容器端部署的容器的情况下，第一端具体为容器桥接器，其中容器端中不同类容器分别部署不同的容器桥接器。

在本公开示例性实施方式中，在第一端为容器端部署的容器的情况下，在基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，消息处理方法还包括：

在从容器端接收到基于对应的容器通信协议的查询请求的情况下，对查询请求基于对应的容器通信协议进行响应。

根据本公开的一个方面，还提供一种消息处理装置，在应用程序中部署有容器端和原生端；消息处理装置包括：

获取模块，从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；

转换模块，基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；

转发模块，将基于第二通信协议的目标消息转发给第二端。

在本公开示例性实施方式中，转换模块具体还用于：

在从第二端获取到目标消息的响应消息的情况下，获得响应消息所基于的第二通信协议，对响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息；

转发模块具体还用于：

将基于第一通信协议的响应消息转发给第一端。

在本公开示例性实施方式中，在原生端部署有多个原生桥接器，原生桥接器与不同类容器支持的容器通信协议之间一一对应；消息处理装置具体应用于对应的原生桥接器。

在本公开示例性实施方式中，在原生端还部署原生桥服务模块和原生组件管理器；在第一端为容器端部署的容器的情况下，转发模块具体用于：

将基于第二通信协议的目标消息转发给原生桥服务模块；

通过原生桥服务模块对目标消息进行解析，得到解析数据；

通过原生组件管理器，将解析数据转发给第二端。

在本公开示例性实施方式中，转发模块具体还用于：

通过原生组件管理器获取目标消息的响应消息；

通过原生桥服务模块对响应消息基于第二通信协议进行封装；

转换模块具体还用于：

对基于第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息并转发给第一端。

在本公开示例性实施方式中，在第一端为容器端部署的容器的情况下，第一端具体为容器桥接器，其中容器端中不同类容器分别部署不同的容器桥接器。

在本公开示例性实施方式中，在第一端为容器端部署的容器的情况下，获取模块具体还用于：

在基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，在从容器端接收到基于对应的容器通信协议的查询请求的情况下，对查询请求基于对应的容器通信协议进行响应。

根据本公开的一个方面，提供一种存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现：上述消息处理方法。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储处理器的可执行指令；

其中，处理器配置为经由执行可执行指令来执行上述消息处理方法。

根据本公开实施方式的消息处理方法，其应用于应用程序的原生端，应用程序还部署有容器端；消息处理方法包括：从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；将基于第二通信协议的目标消息转发给第二端。

本公开示例性实施方式提供了一套统一的通信协议对应关系，在这种情况下，多个容器只需要对应部署一套原生组件，当多个容器需要与该原生组件进行消息传输时，通过事先设置的通信协议对应关系，消息能够转换成统一的原生端通信协议，从而精准送达原生组件。反之，来自原生组件并基于统一的原生端通信协议的消息也可以被转换成对应容器所支持的容器通信协议，再送达到指定容器。因此，当客户端中接入多个容器的情况下，开发人员在开发原生组件的时候，不需要每个容器都按照对应容器的通信协议各自开发一套原生组件，只需要开发并维护一套原生组件即可，这大大降低了代码重复率，降低客户端臃肿问题，提升客户端性能。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1示意性地示出了根据相关技术的应用程序架构图；

图2示意性地示出了根据本公开实施方式的消息处理方法的流程图之一；

图3示意性地示出了根据本公开实施方式的应用程序架构图之一；

图4示意性地示出了根据本公开实施方式的消息处理方法的流程图之二；

图5示意地示出了根据本公开实施方式的应用程序架构图之二；

图6示意地示出了根据本公开实施方式的消息处理方法的时序图；

图7示意地示出了根据本公开实施方式的消息处理装置的模块示意图图；

图8示出了根据本公开实施方式的存储介质的示意图；以及

图9示意性示出了根据公开实施方式的电子设备的方框图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提供一种消息处理方法、装置、设备及存储介质。

在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐述本公开的原理和精神。

发明概述

本案发明人在实践中发现，由于每加入一种容器，就要在客户端重新开发一种所需要的原生组件，这样，随着时间推移，代码重复率不断增加，导致客户端系统臃肿，客户端性能下降，还带来昂贵复杂的开发和维护成本。

在发现上述技术问题的基础上，本案发明人提出本公开示例性实施方式，其发明思想是，在容器端不同类容器分别支持不同容器通信协议、且原生端中不同原生组件支持同一原生端通信协议的情况下，事先设置容器通信协议与原生端通信协议之间的通信协议对应关系，在原生端，基于该通信协议对应关系，对原生组件与容器端之间的目标消息进行通信协议格式转换，使得消息来源端所支持的通信协议被转换成消息目标端所支持的通信协议，然后基于转换后的通信协议，向消息目标端转发该目标消息。这样，消息目标端能够准确接收该目标消息。

本公开示例性实施方式提供了一套统一的通信协议对应关系，在这种情况下，多个容器只需要对应部署一套原生组件，当多个容器需要与该原生组件进行消息传输时，通过事先设置的通信协议对应关系，消息能够转换成统一的原生端通信协议，从而精准送达原生组件。反之，来自原生组件并基于统一的原生端通信协议的消息也可以被转换成对应容器所支持的容器通信协议，再送达到指定容器。因此，当客户端中接入多个容器的情况下，开发人员在开发原生组件的时候，不需要每个容器都按照对应容器的通信协议各自开发一套原生组件，只需要开发并维护一套原生组件即可，这大大降低了代码重复率，降低客户端臃肿问题，提升客户端性能。

另外，在后续迭代中，如果原生组件功能需要修改/更新，或者遇到bug，也只要维护一套组件，不用每个容器的原生组件都检查更新一遍，冗余代码量大幅降低，代码可读性、可维护性、鲁棒性也相对更高，维护成本大幅降低。

在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。

示例性方法

下面将结合附图描述根据本公开示例性实施方式的消息处理方法。

为了便于理解，下面对本公开实施例涉及的几个名词进行解释。

容器

容器是指将应用程序的代码和所需的功能组件与依赖打包在一起，让它们隔离在自己的区域(容器)中。这样，容器内的代码就可以在跨端环境中迁移，并且一致的运行，不受设备和操作系统的影响，甚至可以动态更新应用的功能。

H5容器、Flutter容器、RN容器

H5容器是通常所说的web容器，可以实时地加载html5语言的页面；

Flutter容器是开源的一款跨端的应用开发框架，可以加载使用Dart语言编写的页面；

RN容器是开源的移动端跨平台框架，可以加载使用React语言编写的页面；

原生端开发

在移动平台上利用平台提供的开发语言、开发类库、开发工具进行应用程序App软件功能开发，其中开发语言如Java语言或Obective语言。

容器原生组件开发

容器本身仅提供一些抽象的、标准化的基础能力，如内容加载、页面绘制、与原生端的通信等能力。如果要扩展容器功能，例如文件下载、选择相册图片、访问日历、系统剪切板、分享等，需要按照容器的通信方式，编写对应的原生组件。原生组件用原生代码编写，用来扩展容器功能。

容器通信协议

容器端来扩展/访问原生组件时，规定通信的通信方式。例如H5容器的JSBridge协议、Flutter容器的FlutterPlugin协议，RN容器的RCTBridgeModule协议等。

下面结合图2来描述根据本公开示例性实施方式的消息处理方法，其中在应用程序中部署有原生端及容器端。参考图2所示，该方法具体包括如下步骤：

步骤210：从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；

步骤220：基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；

步骤230：将基于第二通信协议的目标消息转发给第二端。

如上，本公开示例性实施方式通过部署容器端与原生端之间的通信协议对应关系，基于该通信协议对应关系，原生端对原生组件与容器端之间的目标消息进行通信协议格式转换，使得第一端所支持的通信协议被转换成第二端所支持的通信协议，然后基于转换后的通信协议，向第二端转发该目标消息。这样，第二端能够准确接收并识别该目标消息。

在这种情况下，多个容器只需要对应部署一套原生组件，当不同容器需要与该原生组件进行消息传输时，通过事先设置的通信协议对应关系，消息能够转换成统一的原生端通信协议，从而精准送达原生组件。反之，来自原生组件并基于统一的原生端通信协议的消息也可以被转换成对应容器所支持的容器通信协议，再送达到指定容器。因此，当应用程序中接入多个容器的情况下，开发人员在开发原生组件的时候，不需要每个容器都按照对应容器的通信协议各自开发一套原生组件，只需要开发并维护一套原生组件即可，这大大降低了代码重复率，降低客户端臃肿问题，提升客户端性能。

另外，在后续迭代中，如果原生组件功能需要修改/更新，或者遇到bug，也只要维护一套组件，不用每个容器的原生组件都检查更新一遍，冗余代码量大幅降低，代码可读性、可维护性、鲁棒性也相对更高，维护成本大幅降低。

例如图3所示，原生端部署一套原生组件，如原生组件1、2、3、4、5、……，容器端中部署了H5容器、Flutter容器、RN容器、……，这些容器均能通过NativeBridge与原生端进行通信，实现消息传输。由此可知，多个容器只需要对应部署一套原生组件，即可完成原生功能扩展。其中，NativeBridge能够将容器端中不同的容器通信协议转换成统一的原生端通信协议，因此，该原生端通信协议可记为NativeBridge协议。

在本公开示例性实施方式中，第一通信协议为第一端支持的通信协议，在第一端为容器时，第一通信协议为对应的容器通信协议，而在第一端为原生端时，第一通信协议为对应的原生端通信协议。

第二通信协议为第二端支持的通信协议，在第二端为容器时，第二通信协议为对应的容器通信协议，而在第二端为原生端时，第二通信协议为对应的原生端通信协议。

为增强方案可行性，本公开示例性实施方式提供通用的NativeBridge协议。

对该NativeBridge协议定义如下消息字段：

请求消息字段

	类型	必选	说明
				handlerName	string	是	方法名/事件名
data	map	否	业务参数
				_header	map	否	协议参数(业务方无关)

请求返回消息字段

	类型	必选	说明
				data	json	否	数据
code	int	是	错误码
				message	string	否	错误提示
_header	map	否	协议参数(业务方无关)

错误码

code	描述
		200	成功
400	参数错误
		404	不支持的方法
600-700	业务错误码

_header字段：

	类型	必选
				protocol	string	否	协议名称，默认message

protocol字段：

协议名
		message	普通消息(1个请求对应0个/1个回调)
event	事件消息
		support	接口能力查询

下面结合具体的来自容器端的消息内容，说明基于NativeBridge的消息格式。

容器端需要获取原生端剪切板的内容，按照NativeBridge协议规范转换后的消息格式如下：

原生端登录事件，需要通知到容器端，消息格式如下：

容器端需要获知原生端是否支持读取剪切板的能力，消息格式如下：

图4为本公开实施例提供的消息协议处理方法的流程图，本方法的执行主体为原生端，如图4所示，本方法包括如下步骤：

步骤410：从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；

步骤420：基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；

步骤430：将基于第二通信协议的目标消息转发给第二端；

步骤440：在从第二端获取到目标消息的响应消息的情况下，获得响应消息所基于的第二通信协议，对响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息；

步骤450：将基于第一通信协议的响应消息转发给第一端。

在本实施例中，容器端与原生端之间能够进行消息传输与响应。

在第一端为容器时，目标消息可以是对原生组件的调用请求消息，则原生端响应于该调用请求消息，调用原生组件执行业务逻辑，返回响应消息。

在第一端为原生组件时，目标消息可以是对容器的信息监听消息，则容器端对应容器响应于该信息监听消息，基于监听信息反馈响应消息。

因此，本公开示例性实施方式能够在容器端与原生端之间进行消息交互时，进行双向通信协议格式转换，使得本方案具有较强可行性。

在本公开其他示例性实施方式中，容器端与原生端也可以基于目标消息进行单向的数据传输。

在本公开示例性实施方式中，在第一端为容器端部署的容器的情况下，在基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，消息处理方法还可以包括：

在从容器端接收到基于对应的容器通信协议的查询请求的情况下，对查询请求基于对应的容器通信协议进行响应。

在这种情况下，基于查询请求的响应信息，容器端中的对应容器确认原生端支持相应容器通信协议，并能够对容器通信协议支持通信协议格式转换，从而向容器提供原生组件的原生能力。在这种情况下，容器向原生端发送上述目标消息。

图5展示本公开示例性实施方式提供的基于容器端与原生端的消息处理系统架构，如图5，在原生端部署有多个原生桥接器，原生桥接器与不同类容器支持的容器通信协议之间一一对应。在这种情况下，图3或图4所示消息处理方法具体应用于对应的原生桥接器。

本公开示例性实施方式通过在原生端集成多种容器通信协议各自对应的原生桥接器，原生桥接器与容器通信协议之间为一对一关系，每个原生桥接器与对应容器之间能够通信，以进行消息传输。

在本实施方式中，原生桥接器对应的英文名称为NativeBridge，也可解释成消息适配器，用来适配接入应用程序的各容器的容器通信协议(JS、Flutter、或RN…)，其能够将容器端发送的消息格式转换成为定义的统一的原生端通信协议格式，并且将返回给容器的数据转换成对应容器能够理解的容器通信协议。因此，原生桥接器进一步提升本方案可行性。

在这种情况下，在添加容器时，只需要对应开发一套原生桥接器，就可以在已有原生组件与容器之间进行数据传输。

例如，假设需要扩展的原生功能有50个，应用程序接入的容器有3个，使用相关技术方案，需要编写150个原生组件，如果算上跨移动平台，一个要写300个原生组件的代码。而使用本公开示例性实施方式，各移动平台只需要编写50个原生组件和3个对应容器的原生桥接器即可，开发成本大幅降低，业务能力扩展更高效。

在本公开实施例中，如果原生端部署对应的原生桥接器，则该原生桥接器能够接收到对应容器的查询请求，并能够进行响应，容器端中的对应容器确认原生端中部署支持相应容器通信协议的原生桥接器，从而能够进行消息传输。

如图5所示，在原生端还部署原生桥服务模块和原生组件管理器；在第一端为容器端部署的容器的情况下，将基于第二通信协议的目标消息转发给第二端，包括：

将基于第二通信协议的目标消息转发给原生桥服务模块；

通过原生桥服务模块对目标消息进行解析，得到解析数据；

通过原生组件管理器，将解析数据转发给第二端。

在该示例性实施方式中，第二通信协议为原生端通信协议。

原生桥服务模块，其英文解释为NativeBridgeService，用于从原生桥接器接收来自容器的目标消息，并对目标消息进行解析，把解析数据转发给原生组件管理器。

原生组件管理器，其英文解释为NativeModuleManager，用于对原生组件进行管理，对来自原生桥服务模块的解析数据查询对应的原生组件并转发给对应的原生组件去执行。

本公开示例性实施方式通过在原生端部署原生桥服务模块和原生组件管理器，提升本方案可行性。

在本公开示例性实施方式中，原生端部署原生桥服务模块和原生件管理器为一示例，将基于第二通信协议的目标消息转发给第二端的方法不受限于上述部署。

在本公开示例性实施方式中，消息处理方法还包括如下步骤：

通过原生组件管理器获取目标消息的响应消息；

通过原生桥服务模块对响应消息基于第二通信协议进行封装；

对基于第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息并转发给所容器端，并最终送达对应容器。

因此，原生桥服务模块还具有消息封装功能，具体地，从原生组件管理器获取处理后的响应消息，将响应消息封装好提交给对应的原生桥接器。

如图5所示，原生端还部署具体的原生组件Nativemodule，用于响应于来自容器的目标消息执行的业务逻辑。例如，该原生组件具体可以是剪切板模块、日历模块、路由模块、分享模块或其他模块。

基于图5所示架构，本公开示例性实施方式提供一种具体的消息处理方法，如图6所示，本方法具体包括如下步骤：

步骤610：容器端6a中的容器将消息基于对应的容器通信协议进行封装，封装成各自容器桥接器，如JSBridge、FlutterPlugin或RCTModolue能够识别的通信协议类型；

步骤620：容器端6a将封装消息通过各自的容器发送到原生端6b。

步骤630：原生端6b对容器桥接器发送过来的消息，通过对应的原生桥接器，如NativeBridgeJS、NativeBridgeFlutter或NativeBridgeRN，将消息的通信协议转换成原生端通信协议格式的消息，其中每个原生桥接器均支持原生端通信协议格式，以用来后续的统一解析处理。

步骤640：原生桥接器将适配后的消息发送到原生桥服务(NativeBridgeService)模块，进行消息的解析，解析出对应的消息名称和消息参数内容等解析数据。

步骤650：原生桥服务模块将解析好的数据发送到原生组件管理器(NativeModuleManager)。原生组件管理器管理着所有的原生组件，当收到消息时，用于找到处理该消息的对应的原生组件，将消息转发出去。例如获取剪切板内容的剪切消息，找到专门处理剪切板相关的原生组件原生剪切板模块(NativeModuleClipboard)。

步骤660：原生组件在收到消息之后，会去执行对应的业务逻辑，完成之后，如果有返回数据，会将数据返回。例如原生剪切板模块在接收到读取剪切板的消息之后，会将剪切板的内容返回。

步骤670：如果原生组件有返回数据，原生组件管理器会将返回数据交给原生桥服务模块封装成基于原生端通信协议规范的响应消息，然后返回给对应的原生桥接器。

步骤680：原生桥接器将响应消息转换成对应的容器桥接器能够理解的通信协议格式，再返回给容器端6a。

步骤690：容器端6a接收基于响应消息的返回数据，并用来处理各自业务回调逻辑。

示例性装置

在介绍了本公开示例性实施方式的消息处理方法之后，接下来，参考图7对本公开示例性实施方式的消息处理装置进行描述。

参考图7所示，本公开示例性实施方式的消息处理装置700应用于应用程序的原生端，应用程序还部署有容器端；消息处理装置700包括：

获取模块710，从第一端获取待发送到第二端的目标消息，目标消息是基于第一端支持的第一通信协议封装得到的，其中第一端为容器端中部署的容器且第二端为原生端中部署的原生组件，或者第二端为容器端中部署的容器且第一端为原生端中部署的原生组件；

转换模块720，基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，第二通信协议是第二端支持的通信协议，容器端不同容器分别支持不同容器通信协议且原生端中不同原生组件支持同一原生端通信协议；

转发模块730，将基于第二通信协议的目标消息转发给第二端。

在本公开可选实施方式中，转换模块720具体还用于：

在从第二端获取到目标消息的响应消息的情况下，获得响应消息所基于的第二通信协议，对响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息；

转发模块730具体还用于：

将基于第一通信协议的响应消息转发给第一端。

在本公开可选实施方式中，在原生端部署有多个原生桥接器，原生桥接器与不同类容器支持的容器通信协议之间一一对应；消息处理装置具体应用于对应的原生桥接器。

在本公开可选实施方式中，在原生端还部署原生桥服务模块和原生组件管理器；在第一端为容器端部署的容器的情况下，转发模块730具体用于：

将基于第二通信协议的目标消息转发给原生桥服务模块；

通过原生桥服务模块对目标消息进行解析，得到解析数据；

通过原生组件管理器，将解析数据转发给第二端。

在本公开可选实施方式中，转发模块730具体还用于：

通过原生组件管理器获取目标消息的响应消息；

通过原生桥服务模块对响应消息基于第二通信协议进行封装；

转换模块720具体还用于：

对基于第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于第一通信协议的响应消息并转发给第一端。

在本公开可选实施方式中，在第一端为容器端部署的容器的情况下，第一端具体为容器桥接器，其中容器端中不同类容器分别部署不同的容器桥接器。

在本公开可选实施方式中，在第一端为容器端部署的容器的情况下，获取模块710具体还用于：

在基于通信协议对应关系对目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，在从容器端接收到基于对应的容器通信协议的查询请求的情况下，对查询请求基于对应的容器通信协议进行响应。

本公开实施方式的消息处理装置提供了一套统一的通信协议对应关系，在这种情况下，多个容器只需要对应部署一套原生组件，当多个容器需要与该原生组件进行消息传输时，通过事先设置的通信协议对应关系，消息能够转换成统一的原生端通信协议，从而精准送达原生组件。反之，来自原生组件并基于统一的原生端通信协议的消息也可以被转换成对应容器所支持的容器通信协议，再送达到指定容器。因此，当客户端中接入多个容器的情况下，开发人员在开发原生组件的时候，不需要每个容器都按照对应容器的通信协议各自开发一套原生组件，只需要开发并维护一套原生组件即可，这大大降低了代码重复率，降低客户端臃肿问题，提升客户端性能。

另外，在后续迭代中，如果原生组件功能需要修改/更新，或者遇到bug，也只要维护一套组件，不用每个容器的原生组件都检查更新一遍，冗余代码量大幅降低，代码可读性、可维护性、鲁棒性也相对更高，维护成本大幅降低。

由于本公开实施方式的消息处理装置的各个功能模块与上述消息处理方法公开实施方式中相同，因此在此不再赘述。

示例性存储介质

在介绍了本公开示例性实施方式的消息处理方法及其装置之后，接下来，参考图8对本公开示例性实施方式的存储介质进行说明。

参考图8所示，描述了根据本公开实施方式的用于实现上述方法的程序产品800，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言-诸如Java、C++等，还包括常规的过程式程序设计语言-诸如"C"语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

示例性电子设备

在介绍了本公开示例性实施方式的存储介质之后，接下来，参考图9对本公开示例性实施方式的电子设备进行说明。

图9显示的电子设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930、显示单元940。

其中，存储单元存储有程序代码，程序代码可以被处理单元910执行，使得处理单元910执行本说明书上述"示例性方法"部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元910可以执行如图2或4中所示的步骤。

存储单元920可以包括易失性存储单元，例如随机存取存储单元(RAM)921和/或高速缓存存储单元922，还可以进一步包括只读存储单元(ROM)923。

存储单元920还可以包括具有一组(至少一个)程序模块925的程序/实用工具924，这样的程序模块925包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以包括数据总线、地址总线和控制总线。

电子设备900也可以与一个或多个外部设备901(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过输入/输出(I/O)接口950进行。电子设备900还包括显示单元940，其连接到输入/输出(I/O)接口950，用于进行显示。并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了消息处理装置的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (16)

1.一种消息处理方法，其特征在于，在应用程序中部署有原生端和容器端；所述消息处理方法包括：

从第一端获取待发送到第二端的目标消息，所述目标消息是基于所述第一端支持的第一通信协议封装得到的，其中所述第一端为容器端中部署的容器且所述第二端为原生端中部署的原生组件，或者所述第二端为容器端中部署的容器且所述第一端为原生端中部署的原生组件；

基于通信协议对应关系对所述目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，所述第二通信协议是所述第二端支持的通信协议，所述容器端不同容器分别支持不同容器通信协议且所述原生端中不同原生组件支持同一原生端通信协议；

将基于所述第二通信协议的目标消息转发给所述第二端。

2.根据权利要求1所述的消息处理方法，其特征在于，所述消息处理方法还包括：

在从所述第二端获取到所述目标消息的响应消息的情况下，获得所述响应消息所基于的所述第二通信协议，对所述响应消息进行反向通信协议格式转换，得到基于所述第一通信协议的响应消息；

将基于所述第一通信协议的响应消息转发给所述第一端。

3.根据权利要求1所述的消息处理方法，其特征在于，在所述原生端部署有多个原生桥接器，所述原生桥接器与不同类容器支持的容器通信协议之间一一对应；所述消息处理方法具体应用于对应的原生桥接器。

4.根据权利要求3所述的消息处理方法，其特征在于，在所述第一端为容器端部署的容器的情况下，将基于所述第二通信协议的目标消息转发给所述第二端，包括：

对基于所述第二通信协议的目标消息进行解析，得到解析数据；

将所述解析数据转发给所述第二端。

5.根据权利要求4所述的消息处理方法，其特征在于，所述消息处理方法还包括：

获取所述目标消息的响应消息；

对所述响应消息基于所述第二通信协议进行封装；

对基于所述第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于所述第一通信协议的响应消息并转发给所述第一端。

6.根据权利要求1所述的消息处理方法，其特征在于，在所述第一端为容器端部署的容器的情况下，所述第一端具体为容器桥接器，其中所述容器端中不同类容器分别部署不同的容器桥接器。

7.根据权利要求1所述的消息处理方法，其特征在于，在所述第一端为容器端部署的容器的情况下，在基于通信协议对应关系对所述目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，所述消息处理方法还包括：

在从所述容器端接收到基于对应的容器通信协议的查询请求的情况下，对所述查询请求基于对应的容器通信协议进行响应。

8.一种消息处理装置，其特征在于，在应用程序中部署有容器端和原生端；所述消息处理装置包括：

获取模块，从第一端获取待发送到第二端的目标消息，所述目标消息是基于所述第一端支持的第一通信协议封装得到的，其中所述第一端为容器端中部署的容器且所述第二端为原生端中部署的原生组件，或者所述第二端为容器端中部署的容器且所述第一端为原生端中部署的原生组件；

转换模块，基于通信协议对应关系对所述目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息，其中，所述第二通信协议是所述第二端支持的通信协议，所述容器端不同容器分别支持不同容器通信协议且所述原生端中不同原生组件支持同一原生端通信协议；

转发模块，将基于所述第二通信协议的目标消息转发给所述第二端。

9.根据权利要求8所述的消息处理装置，其特征在于，所述转换模块具体还用于：

在从所述第二端获取到所述目标消息的响应消息的情况下，获得所述响应消息所基于的所述第二通信协议，对所述响应消息进行反向通信协议格式转换，得到基于所述第一通信协议的响应消息；

所述转发模块具体还用于：

将基于所述第一通信协议的响应消息转发给所述第一端。

10.根据权利要求8所述的消息处理装置，其特征在于，在所述原生端部署有多个原生桥接器，所述原生桥接器与不同类容器支持的容器通信协议之间一一对应；所述消息处理装置具体应用于对应的原生桥接器。

11.根据权利要求10所述的消息处理装置，其特征在于，在所述原生端还部署原生桥服务模块和原生组件管理器；在所述第一端为容器端部署的容器的情况下，所述转发模块具体用于：

将基于所述第二通信协议的目标消息转发给所述原生桥服务模块；

通过所述原生桥服务模块对所述目标消息进行解析，得到解析数据；

通过所述原生组件管理器，将所述解析数据转发给所述第二端。

12.根据权利要求11所述的消息处理装置，其特征在于，所述转发模块具体还用于：

通过所述原生组件管理器获取所述目标消息的响应消息；

通过所述原生桥服务模块对所述响应消息基于所述第二通信协议进行封装；

所述转换模块具体还用于：

对基于所述第二通信协议封装的响应消息进行反向通信协议格式转换，得到基于所述第一通信协议的响应消息并转发给所述第一端。

13.根据权利要求8所述的消息处理装置，其特征在于，在所述第一端为容器端部署的容器的情况下，所述第一端具体为容器桥接器，其中所述容器端中不同类容器分别部署不同的容器桥接器。

14.根据权利要求8所述的消息处理装置，其特征在于，在所述第一端为容器端部署的容器的情况下，所述获取模块具体还用于：

在基于通信协议对应关系对所述目标消息进行通信协议格式转换，得到基于第二通信协议的目标消息之前，在从所述容器端接收到基于对应的容器通信协议的查询请求的情况下，对所述查询请求基于对应的容器通信协议进行响应。

15.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现：

权利要求1～7中任一项所述的消息处理方法。

16.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行：

权利要求1～7中任一项所述的消息处理方法。