CN109308224A

CN109308224A - 跨平台数据通信、跨平台数据处理的方法、装置及***

Info

Publication number: CN109308224A
Application number: CN201710620876.XA
Authority: CN
Inventors: 刘璇
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2017-07-27
Filing date: 2017-07-27
Publication date: 2019-02-05
Anticipated expiration: 2037-07-27
Also published as: CN109308224B

Abstract

本申请公开了一种跨平台数据通信、处理的方法、装置及电子设备。其中，所述跨平台数据通信的方法，包括：获取数据信息；对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；向需求所述数据信息的接收端发送所述中间文件。所述技术方案通过以开源协议和脚本工具生成服务器端以及不同平台的客户端均能进行交互的中间文件，实现跨平台间的网络通信，提升开发效率；并由于Java和object‑c都能和C语言以及C++语言进行交互，所以以c++作为网络接口统一封装，实现了网络层接口跨平台，同时对网络数据的响应和传输起到一定程度的优化作用。

Description

跨平台数据通信、跨平台数据处理的方法、装置及***

技术领域

本申请涉及计算机通信领域，具体涉及一种跨平台数据通信的方法、一种跨平台数据处理的方法以及一种跨平台数据通信的***。本申请同时涉及一种跨平台数据通信的装置、电子设备、一种跨平台数据处理的装置以及另一种电子设备。

背景技术

目前的移动端通信平台多种多样，而网络通信多是以xml或json的方式进行传输。不同的移动端通信平台进行通信时，需要把对象转换成xml或json。而不同的移动端通信平台将对象转换成xml或json的标准不一致。不同的平台内部的通讯标准不一样，无法直接进行通信。例如目前移动端有两大主流平台，ios和android，由于上层应用开发的平台相关性及使用不同的编程语言，在Java语言中构造的一个对象，无法直接让object-c使用。

由此可见，通过以xml或json的方式进行网络通信时，不能实现跨平台间的通信，所以目前各公司都需要两个专门团队在维护着同一个产品，服务端需要和多个平台或者语言调试；且不同平台需要分别实现一套网络层接口，若接口数据需要模型化，需采用手动生成对应的模型类，开发成本较高；此外，xml在解析时的时间开销较大，xml格式为了有较好的可读性，还会引入一些冗余的文本信息占用空间，空间开也大。

发明内容

本申请提供一种跨平台数据通信的方法、一种跨平台数据处理的方法以及一种跨平台数据通信的***，以解决现有技术中的上述问题。本申请另外提供了一种跨平台数据通信的装置、电子设备、一种跨平台数据处理的装置以及另一种电子设备。

本申请提供了一种跨平台数据通信的方法，所述跨平台数据通信的方法，包括：

获取数据信息；

对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；

向需求所述数据信息的接收端发送所述中间文件。

可选的，所述中间文件，包括：proto文件；所述proto文件为Protobuf数据的定义文件。

可选的，所述数据信息，包括：字段名称以及字段的值。

可选的，所述对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件，包括：

获取预先设置的用于存储所述数据信息的类；

将所述数据信息中字段的值，存储在所述类中；

将实例化后的所述类作为所述中间文件。

可选的，所述向需求所述数据信息的接收端发送所述中间文件，包括：

基于C或C++实现的网络层接口，向需求所述数据信息的接收端发送所述中间文件。

可选的，在所述向需求所述数据信息的接收端发送所述中间文件的步骤之前，包括：

根据Protobuf库对所述中间文件执行序列化操作，获取二进制数据串；

相应的，所述向需求所述数据信息的接收端发送所述中间文件，包括：

向需求所述数据信息的接收端发送所述中间文件序列化后的二进制数据串。

可选的，所述接收端，包括：android客户端、ios客户端或Windows客户端。

可选的，在所述获取数据信息的步骤之前，包括：

基于C或C++实现的网络层接口，接收所述接收端发送的获取数据信息的请求。

相应的，本申请还提供了一种跨平台数据通信的装置，所述跨平台数据通信的装置，包括：

数据获取单元，用于获取数据信息；

中间文件生成单元，用于对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；

中间文件发送单元，用于向需求所述数据信息的接收端发送所述中间文件。

此外，本申请还提供了一种电子设备，所述电子设备，包括：

处理器；

存储器，用于数据通信程序,所述程序在被所述处理器读取执行时,执行如下操作:获取数据信息；对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；向需求所述数据信息的接收端发送所述中间文件。

此外，本申请还提供了一种跨平台数据处理的方法，所述跨平台数据处理的方法，包括：

获取中间文件；所述中间文件携带预设数据格式的数据对象；

对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；

将转换后的所述数据对象与预设的数据模型进行匹配；

实例化匹配到所述预设的数据模型中的所述数据对象。

可选的，所述***，包括：android***、ios***或Windows***。

可选的，所述对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象，包括：

对所述中间文件进行解析，获取所述中间文件携带的预设数据格式的数据对象；

根据对应所述中间文件预设的数据格式转换协议，将所述数据对象转换为对应当前***的数据对象。

可选的，所述获取中间文件，包括：

接收二进制数据串；

根据Protobuf的语言库中提供的应用程序编程接口，对所述二进制数据串执行反序列化操作，获取所述中间文件。

可选的，所述接收二进制数据串，包括：

基于C或C++实现的网络层接口，接收接收二进制数据串。

可选的，在所述实例化匹配到所述预设的数据模型中的所述数据对象的步骤之后，包括：

将所述数据对象生成指定的图表格式的数据，并进行显示；或者

将所述数据对象存储到指定的数据库表中。

相应的，本申请还提供了一种跨平台数据处理的装置，所述跨平台数据处理的装置，包括：

获取单元，用于获取中间文件；所述中间文件携带预设数据格式的数据对象；

数据对象获取单元，用于对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；

匹配单元，用于将转换后的所述数据对象与预设的数据模型进行匹配；

实例化单元，用于实例化匹配到所述预设的数据模型中的所述数据对象。

此外，本申请还提供了另一种电子设备，所述电子设备，包括：

处理器；

存储器，用于数据通信程序,所述程序在被所述处理器读取执行时,执行如下操作:获取中间文件；所述中间文件携带预设数据格式的数据对象；对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；将转换后的所述数据对象与预设的数据模型进行匹配；实例化匹配到所述预设的数据模型中的所述数据对象。

此外，本申请还提供了一种跨平台数据通信的***，所述跨平台数据通信的***，包括：

所述的跨平台数据通信的装置；以及

所述的跨平台数据处理的装置。

与现有技术相比，本申请具有以下优点:

本申请提供的一种跨平台数据通信的方法、装置以及电子设备，通过获取数据信息；对所述数据信息进行实例化，形成中间文件；向需求所述数据信息的接收端发送所述中间文件。

本申请还提供了一种跨平台数据处理的方法、装置以及电子设备，通过获取中间文件；对所述中间文件进行解析，获取与当前***相对应的数据对象；将所述数据对象与预设的数据模型进行匹配；实例化匹配到所述预设的数据模型中的所述数据对象。

所述跨平台数据通信的方法以及所述跨平台数据处理的方法相互配合使用，通过以开源协议和脚本工具生成服务器端以及不同平台的客户端均能进行交互的中间文件，实现跨平台间的网络通信，提升开发效率；并由于Java和object-c都能和C语言以及C++语言进行交互，所以以c++作为网络接口统一封装，实现了网络层接口跨平台，同时对网络数据的响应和传输起到一定程度的优化作用。

除此之外，由于脚本工具支持自动生成oc/Java的模型类，实现了数据模型层的自动化生成；由于通过开源协议对中间文件进行了序列化以及反序列化操作，将传输的数据转化为二进制数据串，比起原先的xml以及json，在网请求的响应速度上更快、数据传输量更小，增加传输效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1示出了根据本申请的实施例提供的跨平台数据通信的方法的流程图；

图2示出了根据本申请的实施例提供的跨平台数据通信的装置的示意图；

图3示出了根据本申请的实施例提供的电子设备的示意图；

图4示出了根据本申请的实施例提供的跨平台数据处理的方法的流程图；

图5示出了根据本申请的实施例提供的跨平台数据处理的装置的示意图；

图6示出了根据本申请的实施例提供的另一电子设备的示意图；

图7示出了根据本申请的实施例提供的跨平台数据通信的***的示意图。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面结合附图和具体实施方式对本申请进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。

本申请的实施例提供了一种跨平台数据通信的方法、一种跨平台数据处理的方法以及一种跨平台数据通信的***；本申请的实施例同时提供了一种跨平台数据通信的装置、电子设备、一种跨平台数据处理的装置以及另一种电子设备。在下面的实施例中逐一进行详细说明。

目前移动端有两大主流平台，ios和android，由于上层应用开发的平台相关性及使用不同的编程语言，在Java语言中构造的一个对象，通过以xml或json的方式进行网络通信时，无法直接让object-c使用。由此可见，通过以xml或json的方式进行网络通信时，不能实现跨平台间的通信，所以目前各公司都需要两个专门团队在维护着同一个产品，服务端需要和多个平台或者语言调试；且不同平台需要分别实现一套网络层接口，若接口数据需要模型化，需采用手动生成对应的模型类，开发成本较高；此外，xml在解析时的时间开销较大，xml格式为了有较好的可读性，还会引入一些冗余的文本信息占用空间，空间开也大。针对这一问题，在本申请实施例中，通过以开源协议和脚本工具生成服务器端以及不同平台的客户端均能进行交互的中间文件，从而实现了跨平台间的网络通信。

在详细描述本实施例的具体步骤之前，先对本技术方案涉及的开源项目作简要说明。

curl是利用URL语法在命令行方式下工作的开源文件传输工具。它被广泛应用在Unix、多种Linux发行版中，并且有DOS和Win32、Win64下的移植版本。在本申请实施例中，基于开源项目curl做c++接口的统一封装，由于Java和object-c都能与C++进行交互，所以通过开源项目curl实现了网络层接口跨平台，同时对网络数据的响应和传输起到一定程度的优化。

protocolbuffer是***的一种数据交换的格式，它独立于语言，独立于平台。***提供了多种语言的实现：Java、c#、c++、go和python，每一种实现都包含了相应语言的编译器以及库文件。由于它是一种二进制的格式，比使用xml或json进行数据交换快许多。可以把它用于分布式应用之间的数据通信或者异构环境下的数据交换，能够将结构化数据序列化，可用于数据存储、通信协议等方面。作为一种效率和兼容性都很优秀的二进制数据传输格式，可以用于诸如网络传输、配置文件、数据存储等诸多领域。

本申请的实施例提供了一种跨平台数据通信的方法，所述跨平台数据通信的方法可以在android、ios或Windows客户端或者服务器端中实施，同时，可以适用于C语言、C++、Java等编程语言环境，当然并不局限于此。可以理解的是，为了适用于某一操作***或者某一语言环境，实现本实施例所提供的跨平台数据通信的方法的程序代码可以根据该操作***或者该语言环境的特点进行编写。所述跨平台数据通信的方法实施例如下：

请参考图1，其示出了根据本申请的实施例提供的跨平台数据通信的方法的流程图。

所述跨平台数据通信的方法，包括：

步骤S101，获取数据信息。

在本实施例中，所述获取数据信息，可以采用如下方式实现：服务器端从数据库中获取所述数据信息。

需要说明的是，所述数据信息在数据库中是以数据库表的形式进行存储的，以若干字段对一条记录进行描述，所以在本步骤中获取的所述数据信息是由所述数据信息被存储的数据库表中的字段名称以及字段的值组成，此外在本步骤中获取的所述数据信息可以是一条记录或是若干条记录的组合。

可以理解的，在访问数据库获取数据信息时，需要根据用户的需求访问对应的数据库表从而获取对应的数据信息，需要先确定用户所需求的数据信息的类型以及查询参数，所以在执行步骤S101获取数据信息的步骤之前，包括如下步骤：

需要说明的是，由于本申请提供的跨平台数据通信的方法实现了跨平台间的网络通信，以目前移动端有两大主流平台ios和android为例：由于android***的编程语言Java和ios的编程语言object-c都能和C语言以及C++语言进行交互，所以基于C或C++实现的网络层接口时，***不相同的两个平台之间也能通过该网络层接口进行通信。所述接收端是用于接收所述服务器端反馈的信息的一端，根据接收端的操作***的不同，至少包括以下3种客户端：android客户端、ios客户端或Windows客户端。

在本实施例中，所述基于C或C++实现的网络层接口是：基于开源项目curl做c++接口的统一封装。其中，封装是指：隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性的读和修改的访问级别；将抽象得到的数据和行为(或功能)相结合，也就是将数据与操作数据的源代码进行有机的结合，形成“类”，其中数据和函数都是类的成员。

具体的，所述服务器端接收所述接收端发送的获取数据信息的请求时，是通过HTTP传输所述获取数据信息的请求。其中，HTTP用来从服务器端获得数据，是一种建筑在TCP/IP之上的简单协议。HTTP允许从客户端向服务器端发送数据。HTTP是一些ASCII文字行，这些ASCII文字从客户端发送给服务器端来请求一个特别的操作。然后，服务器端在发送给客户端的实际请求内容之前回应一些文字行。例如：客户端(curl)，发送一个HTTP请求，该请求包含一个操作方法(例如：GET)，服务器端基于HTTP请求响应一个状态行(表明操作结果是否成功)，以及响应消息体，所述消息体部分就是请求的实际数据(服务器端基于获取数据信息的请求从数据库表中查询出的对应数据信息)。

下面通过一个具体的例子对获取数据信息的获取过程进行详细说明。

在数据库中具有2张数据库表，一张为影片信息表，一张为人员信息表，其中所述影片信息表包括如下字段：

编号	电影名称	导演	上映日期
				1	ABC	Aa	1.10
2	QWE	Bb	1.20

所述人员信息表包括如下字段：

工号	姓名	性别	工龄
				1	aa	男	1
2	bb	女	2

若所述服务器端基于C或C++实现的网络层接口，接收的所述接收端发送的获取数据信息的请求中，包含的查询参数为导演Aa，则在执行步骤S101获取数据信息时，是以导演Aa作为参数查询数据库中的数据库表，根据导演字段确定影片信息表，再根据Aa确定对应的记录。

步骤S103，对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件。

在本实施例中，所述对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件，可以采用如下方式实现：在预先设置的类中以所述数据信息作为参数创建数据对象，并将创建完数据对象的所述类作为中间文件。

需要说明的是，所述实例化是指：在面向对象的编程中，通常把用类创建对象的过程称为实例化，实例化的过程就是为对象分配内存空间的过程，用关键字new创建一个新对象，其格式如下：

类名对象名＝new类名([参数列表])；

例如Date date＝new Date()；就是用日期类创建了一个上映日期的对象，就叫对象的实例化。

所述对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件，具体包括如下步骤：

获取预先设置的用于存储所述数据信息的类；

将所述数据信息中字段的值，存储在所述类中；

将实例化后的所述类作为所述中间文件。

需要说明的是，所述预先设置的用于存储所述数据信息的类，是由.proto文件生成的类。在所述类中只是声明了对象，没有对其分配一个完整的内存空间。所述声明对象是指：当一个计算机程序需要调用内存空间时，对内存发出的占位指令。声明只是将对象名(用户标识符)的有关信息告诉编译器，但不引起内存的分配，只是将对象名所代表的变量看成是一个引用变量，并为它分配所需内存空间，它所占用的空间远远小于一个类的对象所需要的空间，但声明的对象不能马上使用，还需要对它进行实例化。

可以理解的，所述类只是通知编译器需要准备多大的内存空间，并没有为它分配内存空间。只有用类创建了对象后，才会真正占用内存空间。

在执行所述获取预先设置的用于存储所述数据信息的类的步骤时，是根据在步骤S101中获取的所述数据信息，获取对应的预先设置的用于存储所述数据信息的类，具体的，可以根据所述数据信息中的字段名称获取对应的预先设置的用于存储所述数据信息的类。

下面沿用上述例子对设置的用于存储所述数据信息的类进行详细说明。

以对影片信息表预先设置的用于存储所述数据信息的类为例：

影片信息包括如下属性：

编号：number(用整数表示)

电影名称：name(用字符串表示)

导演：director(用字符串表示)

时长：time(用日期表示)

使用Protobuf实现以.proto文件(movie.proto)生成类，在.proto文件中添加一个名为Movie的message结构，用来描述通讯协议中的结构化数据。该文件的内容大致如下：

Movie消息格式有4个字段，在消息中承载的数据信息分别对应于每一个字段。其中每个字段都有一个名字和一种类型。

在上面的例子中，所有字段都是标量类型：一个整型(number)，一个日期(日期)，两个string类型(name和director)。

正如上述文件格式，在消息定义中，每个字段都有唯一的一个标识符。这些标识符是用来在消息中识别各个字段的，一旦开始使用就不能够再改变。[1,15]之内的标识号在编码的时候会占用一个字节。

所指定的消息字段修饰符包括如下之一：

required：表示不能增加或删除的字段；

optional：消息格式中该字段可以有0个或1个值(不超过1个)。

repeated：在一个格式良好的消息中，这种字段可以重复任意多次(包括0次)。重复的值的顺序会被保留。表示该值可以重复，相当于Java中的List。

上述每一个message可以分别对应一个.proto文件。

需要说明的是，所述类是在执行步骤S101获取数据信息的步骤之前，就预先设置的，上述给出的例子仅仅是示意性的，在具体实施中，可以以部分字段的组合预先设置对应的类，同样的针对在是数据库中的其他数据库表也需要预先设置对应的类，由于在设置时只是字段类型和字段名称不同，所以在此不再赘述。

由于获取的所述类中只是声明了对象，并没有对其分配一个完整的内存空间，所以需要对所述类中的对象进行实例化，所以在执行所述将所述数据信息中字段的值，存储在所述类中的步骤时，是将所述数据信息中字段的值，赋值给在所述类中对应该值的字段名称的对象，完成实例化过程。具体的，可以采用GET方法，从所述数据信息中获取字段的值，在所述类中进行赋值。

在进行赋值时，由于在获取所述数据信息获取到的是记录有导演Aa的记录，所示将从所述数据信息中获取字段的值，在所述类中进行赋值时，是将编号1赋值给number、将电影名称ABC赋值给name、将导演Aa赋值给director以及将时长1.10赋值给date。

在本实施例中，所述中间文件包括：proto文件；所述proto文件为Protobuf数据的定义文件。

步骤S105，向需求所述数据信息的接收端发送所述中间文件。

在本实施例中，所述向需求所述数据信息的接收端发送所述中间文件，可以采用如下方式实现：服务器端通过HTTP向需求所述数据信息的接收端发送在步骤S103中形成的所述中间文件。

具体的，所述向需求所述数据信息的接收端发送所述中间文件，是基于C或C++实现的网络层接口，向需求所述数据信息的接收端发送所述中间文件。

需要说明的是，所述接收端是用于接收所述服务器端发送的中间文件的一端，根据接收端的操作***的不同，至少包括以下3种客户端：android客户端、ios客户端或Windows客户端。

在执行步骤S105向需求所述数据信息的接收端发送所述中间文件时，为了提高数据的传输效率，减少数据的传输量，本实施例的技术方案提供了一种优选实施方式，在执行步骤S105向需求所述数据信息的接收端发送所述中间文件之前，对所述中间文件进行压缩。

所述对所述中间文件进行压缩，可以采用如下方式实现：

根据Protobuf库对所述中间文件执行序列化操作，获取二进制数据串。

需要说明的是，所述序列化操作是指：对象序列化(Serialization)技术，是将对象数据转换成另一种持久化数据形式的技术，即将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。为了使得存储和传输后的数据能够再次变回内存中的对象，这样的转换必须是可逆的。序列化方法和反序列化方法被广泛使用在网络间数据传输和应用中，通常需要将信息转换成数据流，实现数据传输和应用。类似地，反序列化从序列化的表示形式中提取数据，并直接设置对象状态。

下面沿用上述例子对所述中间文件执行序列化操作进行详细说明。

以进行赋值后的所述中间文件为例：

使用protoc编译器，编译所述中间文件，以C++为例(Protobuf协议还支持Java语言、Python语言，可以换成相应的类型)，在对所述中间文件进行编译后会生成.h和.cc文件，.h是类的声明.cc是实现。

由于Protobuf的message中有很多字段，每个字段的格式为：修饰符字段类型字段名＝域号；再通过Protobuf库对所述中间文件执行序列化时，Protobuf协议会按照TLV(T为key，V是字段对应的值value，L是Value的长度)的二进制格式序列化每一个字段，序列化后的Value是按原样保存，Key按照一定的转换条件保存起来，序列化后的结果就是KeyValueKeyValue…。Key的序列化格式是按照message中字段后面的域号与字段类型来转换。

遍历对象中Message结构，并序列化Message中每一个字段，方法大致如下：

Movie movie；

movie.set_number("1")；

movie.set_name("ABC")；

movie.set_director("Aa")；

movie.set_time("1.10")；

movie.SerializeToOstream()；

下面以Java语言为例对所述中间文件的序列化过程进行简单说明。

通过调用编译生类GenerateMessage中的wirteTo()方法开始将序列化后的字节写入输出流中。其中，GenerateMessage继承AbstractMessage类，序列化最终在AbstractMesssage中完成，序列化的实现过程如下：

调用AbstractMessage类中的writeTo()方法，遍历对象中的Message结构()；

调用CodeOutputStream类中的writeMessageSetExtension()方法，序列化Message中每一个字段。

可以理解的，由于将所述中间文件进行序列化，生成对所述中间文件压缩后的二进制数据串，所以在执行步骤S105向需求所述数据信息的接收端发送所述中间文件时，是向需求所述数据信息的接收端发送所述中间文件序列化后的二进制数据串。

在上述的实施例中，提供了一种跨平台数据通信的方法，与上述跨平台数据通信的方法相对应的，本申请还提供了一种跨平台数据通信的装置。由于装置的实施例基本相似于方法的实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述跨平台数据通信的装置实施例如下：

请参考图2，其示出了根据本申请的实施例提供的跨平台数据通信的装置的示意图。

所述跨平台数据通信的装置，包括：数据获取单元201、中间文件生成单元203以及中间文件发送单元205；

所述数据获取单元201，用于获取数据信息；

所述中间文件生成单元203，用于对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；

所述中间文件发送单元205，用于向需求所述数据信息的接收端发送所述中间文件。

可选的，所述中间文件生成单元203，具体用于对所述数据信息进行实例化，形成proto文件；所述proto文件为Protobuf数据的定义文件。

可选的，所述数据获取单元201，具体用于获取字段名称以及字段的值。

可选的，所述的跨平台数据通信的装置，所述中间文件生成单元203，包括：类获取子单元、存储子单元以及中间文件生成子单元；

所述类获取子单元，用于获取预先设置的用于存储所述数据信息的类；

所述存储子单元，用于将所述数据信息中字段的值，存储在所述类中；

所述中间文件生成子单元，用于将实例化后的所述类作为所述中间文件。

可选的，所述中间文件发送单元205，具体用于基于C或C++实现的网络层接口，向需求所述数据信息的接收端发送所述中间文件。

可选的，所述的跨平台数据通信的装置，还包括：序列化单元；

所述序列化单元，用于在所述向需求所述数据信息的接收端发送所述中间文件的之前，根据Protobuf库对所述中间文件执行序列化操作，获取二进制数据串。

相应的，所述中间文件发送单元205，具体用于向需求所述数据信息的接收端发送所述中间文件序列化后的二进制数据串。

可选的，所述中间文件发送单元205，具体用于基于C或C++实现的网络层接口，向需求所述数据信息的android客户端、ios客户端或Windows客户端发送所述中间文件。

可选的，所述的跨平台数据通信的装置，还包括：请求接收单元；

所述请求接收单元，用于在所述获取数据信息之前，基于C或C++实现的网络层接口，接收所述接收端发送的获取数据信息的请求。

在上述的实施例中，提供了一种跨平台数据通信的方法以及一种跨平台数据通信的装置，此外，本申请还提供了一种电子设备；所述电子设备实施例如下：

请参考图3，其示出了根据本申请的实施例提供的电子设备的示意图。

所述电子设备，包括：处理器301；存储器303；

所述存储器303，用于数据通信程序,所述程序在被所述处理器读取执行时,执行如下操作:获取数据信息；对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；向需求所述数据信息的接收端发送所述中间文件。

例如，所述电子设备为服务器端，所述服务器端与客户端进行网络链接，所述服务器端根据所述客户端需求的数据信息，获取对应数据信息；并对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；最后向需求所述数据信息的接收端发送所述中间文件。由于本电子设备使用上述跨平台数据通信的方法，相关之处请参见上述跨平台数据通信的方法的实施例说明，此处不再赘述。

在上述的实施例中，提供了一种跨平台数据通信的方法、一种跨平台数据通信的装置以及一种电子设备，此外，本申请还提供了一种跨平台数据处理的方法；所述跨平台数据处理的方法实施例如下：

请参考图4，其示出了根据本申请的实施例提供的跨平台数据处理的方法的流程图。

所述跨平台数据处理的方法，包括：

步骤S401，获取中间文件；所述中间文件携带预设数据格式的数据对象。

在本实施例中，所述获取中间文件；所述中间文件携带预设数据格式的数据对象，可以采用如下方式实现：基于C或C++实现的网络层接口，接收所述服务器端通过HTTP发送的所述中间文件。所述基于C或C++实现的网络层接口是：基于开源项目curl做c++接口的统一封装。

需要说明的是，由于本申请提供的跨平台数据处理的方法实现了跨平台间的网络通信，以目前移动端有两大主流平台ios和android为例：由于android***的编程语言Java和ios的编程语言object-c都能和C语言以及C++语言进行交互，所以基于C或C++实现的网络层接口时，***不相同的两个平台之间也能通过该网络层接口进行通信。

具体的，接收端(curl)是基于HTTP接收所述获取中间文件的。例如：所述接收端通过网络层接口(curl)先向所述服务器端发送一个HTTP请求(请求内包含获取数据信息的请求)，服务器端基于HTTP请求响应一个状态行(表明操作结果是否成功)，以及响应消息体，所述消息体部分就是请求的实际数据(服务器端基于获取数据信息的请求反馈的中间文件)，所述接收端通过网络层接口(curl)接收所述中间文件。

在本实施例中，所述中间文件，包括：proto文件；所述proto文件为Protobuf数据的定义文件。

除上述直接从所述服务器端接收所述中间文件的方式之外，在执行步骤S401获取中间文件时，为了提高数据的传输效率，减少数据的传输量，本实施例的技术方案提供了一种优选实施方式，在执行步骤S401获取中间文件时，是从所述服务器端接收经过压缩的所述中间文件，并从压缩后的所述中间文件中获取所述中间文件，具体包括如下步骤：

接收二进制数据串；

在本实施例中，所述接收二进制数据串，可以采用如下方式实现：基于C或C++实现的网络层接口，接收所述服务器端通过HTTP发送的所述二进制数据串。所述基于C或C++实现的网络层接口是：基于开源项目curl做c++接口的统一封装。

需要说明的是，Protobuf的语言库包括但不限于C、C++、Java等语言的语言库；本实施例的跨平台数据处理的方法通过Protobuf的语言库(比如Java库)中提供的相应的应用程序编程接口(Application Programming Interface，API)对该二进制数据串进行解析，将该二进制数据串反序列化为对应的中间文件；本实施例中的.proto文件是通过Protobuf语言来定义消息类型生成的文件，proto文件可以定义多个消息类型。

下面以一个具体的例子对所述二进制数据串执行反序列化操作进行详细说明。

以Java使用Protobuf的反序列化时：

通过调用parserFrom(byte[]data)开始对所述二进制数据串进行反序列化，所述parserFrom()方法在com.***.protobuf.AbstractParser类中实现，最后在com.***.protobuf.CodedInputStream类中完成反序列化，获取所述中间文件。

使用C++stream的反序列化API时：是通过ParseFromIstream()方法，对所述二进制数据串进行反序列化，获取所述中间文件。

步骤S403，对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象。

在本实施例中，所述对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象，可以采用如下方式实现：对所述中间文件(.proto)进行解析，从所述中间文件中获取所述中间文件携带的所述数据对象，并将所述数据对象转换为当前***的编程语言能够解析的数据结构。

所述对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象，具体包括如下步骤：

在本实施例中，是通过Protobuf的语言库中提供的应用程序编程接口，对所述中间文件进行解析，并根据数据格式转换协议Protocolbuffer，可以将所述中间文件的数据结构解析成当前语言能够解析的数据结构。

需要说明的是，当用protocolbuffer编译器来运行.proto文件时，将生成所选择语言的代码，这些代码可以操作在.proto文件中定义的消息类型，包括获取、设置字段值，从一个输入流中解析消息。对C++来说，编译器会为每个.proto文件生成一个.h文件和一个.cc文件，.proto文件中的每一个消息有一个对应的类；对Java来说，编译器为每一个消息类型生成了一个.Java文件。

在本实施例中，所述当前***，至少包括：android***、ios***或Windows***。当当前***为android***时，获取的数据对象为Java对象；同样的道理，当当前***为ios***时，获取的数据对象为oc对象。

步骤S405，将转换后的所述数据对象与预设的数据模型进行匹配。

在本实施例中，所述将转换后的所述数据对象与预设的数据模型进行匹配，可以采用如下方式实现：将转换后的所述数据对象与预设的数据模型中的对象进行匹配。

需要说明的是，所述预设的数据模型是:根据与该客户端进行连接的服务器端中，对应的数据库内的数据库表而形成的数据模型，所述客户端可以从所述服务器端内获取多种数据信息，而所述数据信息可能会分别存储在不同的数据库表内，所述数据库表内的字段各不相同，从而根据数据库表内不同的字段形成的数据模型也各不相同，因此需要预先针对各类数据信息及数据信息的组合形成对用的数据模型。

所述数据模型中只是声明了对应的对象，没有对其分配一个完整的内存空间，而在执行本步骤时，在所述数据对象与预设的数据模型进行匹配后，会进入步骤S407对匹配成功的数据模型中声明的对象进行实例化。

步骤S407，实例化匹配到所述预设的数据模型中的所述数据对象。

在本实施例中，所述实例化匹配到所述预设的数据模型中的所述数据对象，可以采用如下方式实现：在匹配到所述预设的数据模型中以所述数据信息作为参数创建数据对象。

需要说明的是，由于在所述数据模型中只是声明了对象，并没有对其分配一个完整的内存空间，所以需要对所述数据模型中的对象进行实例化，是将所述数据对象中的参数值赋值给在所述数据模型中对应该值的字段名称的对象，完成实例化过程。具体的，在所述预设的数据模型中进行实例化是通过关键字new实例化对象，其格式如下：

类名对象名＝new类名()；

例如：Movie movie＝new Movie()；

movie.setNumber("1")；

movie.setName("ABC")；

movie.setDirector("Aa")；

movie.setDate("1.10")

作为一个优选实施方式，本申请实施例提供的跨平台数据处理的方法中，在从所述数据对象中获取了相应的参数值之后，还需在当前客户端中根据所述参数值在显示界面中进行显示。

例如：从所述数据对象中获取了相应的参数值之后，在当前客户端中将所述数据对象生成指定的图表格式的数据(生成指定的超文本标记语言HyperText Mark-upLanguage，HTML等)，并将所述数据对象的参数值进行显示；或者

将所述数据对象存储到指定的数据库表中。

在上述的实施例中，提供了一种跨平台数据处理的方法，与上述跨平台数据处理的方法相对应的，本申请还提供了一种跨平台数据处理的装置。由于装置的实施例基本相似于方法的实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述跨平台数据处理的装置实施例如下：

请参考图5，其示出了根据本申请的实施例提供的跨平台数据处理的装置的示意图。

所述跨平台数据处理的装置，包括：获取单元501、数据对象获取单元503、匹配单元505以及实例化单元507；

所述获取单元501，用于获取中间文件；所述中间文件携带预设数据格式的数据对象；

所述数据对象获取单元503，用于对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；

所述匹配单元505，用于将转换后的所述数据对象与预设的数据模型进行匹配；

所述实例化单元507，用于实例化匹配到所述预设的数据模型中的所述数据对象。

可选的，所述获取单元501，具体用于获取proto文件；所述proto文件为Protobuf数据的定义文件。

可选的，所述数据对象获取单元503，具体用于用于对所述中间文件进行解析，获取对应android***、ios***或Windows***的数据对象。

可选的，所述数据对象获取单元503，包括：解析子单元以及转换子单元；

所述解析子单元，用于对所述中间文件进行解析，获取所述中间文件携带的预设数据格式的数据对象；

所述转换子单元，用于根据对应所述中间文件预设的数据格式转换协议，将所述数据对象转换为对应当前***的数据对象。

可选的，所述的跨平台数据处理的装置，所述获取单元，包括：数据串接收单元以及反序列化单元；

所述数据串接收单元，用于获取二进制数据串；

所述反序列化单元，用于根据Protobuf的语言库中提供的应用程序编程接口，对所述二进制数据串执行反序列化操作，获取所述中间文件。

可选的，所述的跨平台数据处理的装置，所述数据串接收单元，具体用于基于C或C++实现的网络层接口，接收接收二进制数据串。

可选的，所述的跨平台数据处理的装置，还包括：存储显示单元；

所述存储显示单元，用于在所述实例化匹配到所述预设的数据模型中的所述数据对象之后，将所述数据对象生成指定的图表格式的数据，并进行显示；或者

将所述数据对象存储到指定的数据库表中。

在上述的实施例中，提供了一种跨平台数据通信的方法、一种跨平台数据通信的装置、一种电子设备、一种跨平台数据处理的方法以及一种跨平台数据处理的装置，此外，本申请还提供了另一种电子设备；所述电子设备实施例如下：

请参考图6，其示出了根据本申请的实施例提供的另一电子设备的示意图。

所述电子设备，包括：处理器601；存储器603；

所述存储器603，用于数据通信程序,所述程序在被所述处理器读取执行时,执行如下操作:获取中间文件；所述中间文件携带预设数据格式的数据对象；对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；将转换后的所述数据对象与预设的数据模型进行匹配；实例化匹配到所述预设的数据模型中的所述数据对象。

例如，所述电子设备为客户端，所述客户端与服务器端进行网络链接，所述客户端接收所述服务器端发送的中间文件；并对所述中间文件进行解析，获取与当前***相对应的数据对象；再将所述数据对象与预设的数据模型进行匹配；最后实例化匹配到所述预设的数据模型中的所述数据对象。由于本电子设备使用上述跨平台数据处理的方法，相关之处请参见上述跨平台数据处理的方法的实施例说明，此处不再赘述。

在上述的实施例中，提供了一种跨平台数据通信的方法、一种跨平台数据通信的装置、一种电子设备、一种跨平台数据处理的方法、一种跨平台数据处理的装置以及另一种电子设备，此外，本申请还提供了一种跨平台数据通信的***；所述跨平台数据通信的***实施例如下：

请参考图7，其示出了根据本申请的实施例提供的跨平台数据通信的***的示意图。

所述跨平台数据通信的***，包括：跨平台数据通信的装置701以及跨平台数据处理的装置703；

所述跨平台数据通信的装置701，用于获取数据信息；对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件；向需求所述数据信息的接收端发送所述中间文件；

所述跨平台数据处理的装置703，用于获取中间文件；所述中间文件携带预设数据格式的数据对象；对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象；将转换后的所述数据对象与预设的数据模型进行匹配；实例化匹配到所述预设的数据模型中的所述数据对象。

其中，所述跨平台数据通信的装置701可以布置与计算机上，根据所述跨平台数据通信的装置701在***中的具体作用，可以分别在服务器端以及客户端上实施。例如：在客户端向服务器端提交表单或注册信息时，跨平台数据通信的装置701就可以是客户端；在服务器端向客户端推送信息或反馈信息时，跨平台数据通信的装置701就可以是服务器端；同样的道理，所述跨平台数据处理的装置703也可以布置与计算机上，根据所述跨平台数据处理的装置703在***中的具体作用，也可以分别在服务器端以及客户端上实施。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

Claims

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

获取数据信息；

向需求所述数据信息的接收端发送所述中间文件。

2.根据权利要求1所述的跨平台数据通信的方法，其特征在于，所述中间文件，包括：proto文件；所述proto文件为Protobuf数据的定义文件。

3.根据权利要求2所述的跨平台数据通信的方法，其特征在于，所述数据信息，包括：字段名称以及字段的值。

4.根据权利要求3所述的跨平台数据通信的方法，其特征在于，所述对所述数据信息以预设的数据格式进行实例化，生成携带对应所述数据信息的数据对象的中间文件，包括：

获取预先设置的用于存储所述数据信息的类；

将所述数据信息中字段的值，存储在所述类中；

将实例化后的所述类作为所述中间文件。

5.根据权利要求1-4任意一项所述的跨平台数据通信的方法，其特征在于，所述向需求所述数据信息的接收端发送所述中间文件，包括：

6.根据权利要求5所述的跨平台数据通信的方法，其特征在于，在所述向需求所述数据信息的接收端发送所述中间文件的步骤之前，包括：

7.根据权利要求6所述的跨平台数据通信的方法，其特征在于，所述接收端，包括：android客户端、ios客户端或Windows客户端。

8.根据权利要求7所述的跨平台数据通信的方法，其特征在于，在所述获取数据信息的步骤之前，包括：

9.一种跨平台数据通信的装置，其特征在于，包括：

数据获取单元，用于获取数据信息；

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

处理器；

11.一种跨平台数据处理的方法，其特征在于，包括：

将转换后的所述数据对象与预设的数据模型进行匹配；

实例化匹配到所述预设的数据模型中的所述数据对象。

12.根据权利要求11所述的跨平台数据处理的方法，其特征在于，所述中间文件，包括：proto文件；所述proto文件为Protobuf数据的定义文件。

13.根据权利要求12所述的跨平台数据处理的方法，其特征在于，所述***，包括：android***、ios***或Windows***。

14.根据权利要求13所述的跨平台数据处理的方法，其特征在于，所述对所述中间文件进行解析，将所述中间文件携带的所述数据对象，转换为数据格式与当前***相对应的数据对象，包括：

15.根据权利要求11-14任意一项所述的跨平台数据处理的方法，其特征在于，所述获取中间文件，包括：

接收二进制数据串；

16.根据权利要求15所述的跨平台数据处理的方法，其特征在于，所述接收二进制数据串，包括：

基于C或C++实现的网络层接口，接收接收二进制数据串。

17.根据权利要求16所述的跨平台数据处理的方法，其特征在于，在所述实例化匹配到所述预设的数据模型中的所述数据对象的步骤之后，包括：

将所述数据对象存储到指定的数据库表中。

18.一种跨平台数据处理的装置，其特征在于，包括：

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

处理器；

20.一种跨平台数据通信的***，其特征在于，包括：

根据权利要求9所述的跨平台数据通信的装置；以及

根据权利要求18所述的跨平台数据处理的装置。