CN110662089A - 弹幕接收处理方法、存储介质、电子设备及系统 - Google Patents
弹幕接收处理方法、存储介质、电子设备及系统 Download PDFInfo
- Publication number
- CN110662089A CN110662089A CN201810715414.0A CN201810715414A CN110662089A CN 110662089 A CN110662089 A CN 110662089A CN 201810715414 A CN201810715414 A CN 201810715414A CN 110662089 A CN110662089 A CN 110662089A
- Authority
- CN
- China
- Prior art keywords
- bullet screen
- streaming data
- protocol file
- content
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8547—Content authoring involving timestamps for synchronizing content
Abstract
本发明公开了一种弹幕接收处理方法、存储介质、电子设备及系统，涉及信息处理领域，该方法包括：服务器中定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；生成协议文件的序列化代码，将协议文件序列化成流式数据后发送至客户端；客户端的so层接收流式数据并将接收的流式数据传递至Java层；Java层对流式数据进行反序列化，得到弹幕内容并展示。本发明能够有效提升弹幕消息的处理速度，从而提高弹幕消息的处理效率。
Description
技术领域
本发明涉及信息处理领域，具体涉及一种弹幕接收处理方法、存储介质、电子设备及系统。
背景技术
当前，随着智能移动设备的普及，移动端的应用程序也越来越多，且随着智能移动设备功能的强大，应用程序的功能随之也越来越多并越来越复杂，从而导致应用程序的开发和架构设计也越来越复杂。
最初，Android端应用程序都是由JAVA层代码开发完成，然而随着技术的不断发展，为了提高应用程序的性能和安全性，现在Android端应用程序则由JAVA层代码和C++层代码组合而成，将应用程序中某些性能消耗较高、调用频繁的功能使用C++开发完成，最终生成一个SO文件，那么最终，一个Android端应用程序则由多个SO和JAVA层代码组合而成。但是，对于直播平台的弹幕消息来说，客户端需要频繁的接收服务器发送的弹幕消息并处理，现有的技术通常是使用C++开发来完成弹幕的接收和处理，效率极为低下。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种弹幕接收处理方法，能够有效提升弹幕消息的处理速度，从而提高弹幕消息的处理效率。
为达到以上目的，本发明采取的技术方案是，包括：
服务器中定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
生成协议文件的序列化代码，将协议文件序列化成流式数据后发送至客户端；
客户端的so层接收流式数据并将接收的流式数据传递至Java层；
Java层对流式数据进行反序列化，得到弹幕内容并展示。
在上述技术方案的基础上，
所述弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间；
所述协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容。
在上述技术方案的基础上，所述协议文件的序列化代码由Protobuf提供的工具自动生成。
在上述技术方案的基础上，该方法还包括：
服务器和客户端中均生成一对私钥和公钥；
服务器和客户端均将自身生成的公钥发送给对方，自身保存私钥；
服务器使用自身保存的私钥和接收的公钥生成一个密钥，直播APP使用自身保存的私钥和接收的公钥生成一个密钥；
服务器将流式数据使用自身生成的密钥加密后，发送至客户端；
客户端的so层接收流式数据并使用客户端自身生成的秘钥解密后，将流式数据传递至Java层。
在上述技术方案的基础上，
所述Java层中创建有消息接口；
所述客户端的so层获取Java层的消息接口，然后调用Java层的消息接口将流式数据传递至Java层。
本发明还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
生成协议文件的序列化代码；
将协议文件序列化成流式数据，然后将流式数据发出。
本发明还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
通过so层接收流式数据，并将接收的流式数据传递至Java层；
Java层对流式数据进行反序列化，得到弹幕内容；
对弹幕内容进行展示。
本发明还提供一种电子设备，其包括：
第一模块，所述第一模块用于定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
第二模块，所述第二模块用于生成协议文件的序列化代码，并将协议文件序列化成流式数据后发送至客户端；
第三模块，所述第三模块用于通过so层接收流式数据并将接收的流式数据传递至Java层；
第四模块，所述第四模块用于在Java层对流式数据进行反序列化，得到弹幕内容并展示。
本发明还提供一种弹幕接收处理系统，包括服务器和客户端；
所述服务器用于定义Protobuf的协议文件，生成协议文件的序列化代码，然后将协议文件序列化成流式数据后发送至客户端，所述协议文件用于描述弹幕消息的内容；
所述客户端用于在so层接收流式数据并将接收的流式数据传递至Java层，以及在Java层对流式数据进行反序列化，得到弹幕内容并展示。
在上述技术方案的基础上，
所述弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间；
所述协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容。
与现有技术相比，本发明的优点在于：使用Protobuf来定义协议文件格式，并且使用Protobuf来生成C++的代码和Java层的代码，从而对于协议内容的解析可以使用Protobuf的代码，并不需要独立的编写协议字段的解析代码，so层收到服务器的流式数据转发给Java层代码，Java层代码解析弹幕并进行显示，有效提升弹幕消息的处理速度，从而提高弹幕消息的处理效率。
附图说明
图1为本发明实施例中一种弹幕接收处理方法的流程图；
图2为本发明实施例中一种电子设备的结构示意图。
具体实施方式
以下结合附图及实施例对本发明作进一步详细说明。
参见图1所示，本发明实施例提供一种弹幕接收处理方法，用于在Android平台上实现客户端对服务器弹幕消息的接收和处理。本发明实施例的弹幕接收处理方法，具体包括以下步骤：
S1：服务器中定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容。弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间。协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容，如一个字段代表弹幕文本，一个字段代表弹幕发送着等。
协议文件中包含多个字段，且每个字段均代表一个具体的弹幕消息内容，后续在对数据进行打包时则会对协议文件中的每个字段进行赋值，最终序列化成数据流，当数据流由C++代码打包完成后，传递到Java层代码，Java层代码则会进行反序列化，并且对协议中的每个字段进行赋值，从而实现了数据的传输功能。例如对于服务器待发送的一条弹幕消息，定义的协议文件如下：
其中，message chatmessage标识此协议文件描述的是一条弹幕消息；requiredstring type＝1标识协议文件的类型；required stringcontent＝2标识协议文件中的弹幕文本；required string nc＝3标识协议文件中的弹幕发送者；required int64time＝4标识协议文件中的弹幕发送时间。通过上述便定义了一个协议文件，然后将定义的协议文件保存到chatmessage.proto文件中。
S2：生成协议文件的序列化代码，将协议文件序列化成流式数据后发送至客户端。具体的协议文件的序列化代码由Protobuf提供的工具自动生成。定义了协议文件后，则可以通过Protobuf提供的工具来自动生成对应协议文件的序列化代码，工具具体为protoc.exe，通过此工具生成序列化代码，即对应于协议文件的C++代码和Java代码。具体的生成方式通过以下命令来完成：
Protoc.exe--cpp_out＝.chatmessage.proto
其中--cpp_out表示生成的C++的序列化代码，最终生成chatmessage.pb.h和chatmessage.pb.cc，上述代码命令会定义出协议文件的所有字段，同时也提供了相应的接口来打包协议文件的字段和字段的内容。
然后通过命令Protoc.exe--Java_out＝.chatmessage.proto，生成Java的协议打包解包的代码文件chatmessage.Java，至此便通过Protobuf提供的工具生成了协议文件用于与C++和Java交互的的序列化代码。
对于应用程序来说，增加协议字段和修改协议字段是很常见的事情，如果需要在现有协议中增加新的字段，那么具体实现方式则只需要在现有的协议文件中增加新的字段，然后使用上述Protobuf提供的工具来生成新的协议打包和解包的代码，则可以完成新的增加字段的功能。对比现有方式：现有方式则是首先定义协议格式的内容和字段，并且需要编写Java代码来对协议进行序列化和反序列化的代码，同时对于C++也需要编写相应的代码，同时如果新增加字段，则2份代码都需要进行修改，而对于C++将数据或者消息传递到Java层时，则需要C++代码和Java层代码都定义好消息的各个字段，并且都编写好消息的解析和打包代码，但使用本本发明实施例中的protobuf来定义消息传递则可以使用工具来生成消息的序列化代码。
服务器不管使用何种协议来生成最终的协议数据，包括使用本发明实施例中的protobuf来生成协议文件数据，或者服务器使用自定义的方式来生成网络协议数据，最终均需要序列化成流式数据，然后通过网络发送给客户端，客户端运行于智能移动设备中，且智能移动设备运行Android操作系统。
对于将协议文件序列化成流式数据，具体过程举例说明如下为：
服务器则首先定义一个弹幕消息对象chat：
chatmessage chat；
然后来对chat进行赋值：
chat.set_type(“chat”)；表示写入消息的类型是chat。
Chat.set_content(“666”)；表示写入消息的弹幕内容是“666”。
Chat.set_nc(“yy”)；表示写入发送弹幕的发送者的名称“yy”。
Chat.set_time(“1525573879”)；表示发送弹幕的时间戳。
通过调用chat的方法则可以将上面的数据进行序列化操作成流式的数据。
Char*pBuff＝chat.Serialize()；
Int nLength＝chat.length()；
调用chat对象的Serialize方法则可以将协议文件内容进行序列化操作，从而生成到pBuff缓存中，同时还可以通过length来获取最终生成的流式数据的长度。
若服务器不是使用的protobuf的数据格式，那么服务器的消息内容假设是定义的自己的一条消息格式内容如下：
type@＝chat/content@＝666/nc@＝yy/time@＝1525573879/
则Char*pBuff＝“type@＝chat/content@＝666/nc@＝yy/time@＝1525573879/”
S3：客户端的so层接收流式数据并将接收的流式数据传递至Java层，即在客户端中将消息的接收和处理放至Android系统的so层的C++代码中来进行处理，提高数据的处理效率。
Java层中创建有消息接口，客户端的so层获取Java层的消息接口，然后调用Java层的消息接口将流式数据传递至Java层，即客户端的so层直接将收到的数据发送给Java层代码进行。
C++代码调用Java层代码则需要通过编写JNI层代码来进行传递。
Java层创建一个消息接口，用于接收C++层的消息，并对消息进行显示，如果是弹幕则在屏幕上显示弹幕内容，那么在so层中首先需要获取Java层的接口，然后调用Java层的接口来将protobuf的数据传递给Java层代码。
首先通过JNI的接口来获取JAVA层的类的实例：
jclass clazz＝(*env)->FindClass(env,JAVA_DANMU_CLASS)；
其中通过JNI层提供的接口FindClass来查找到Java层的类AVA_DANMU_CLASS。
其中env是Java层提供的Java的环境变量。
然后通过JNI层提供的接口GetStaticMethodID来获取Java层类的接口方法：
Jobject post_event＝(*env)->GetStaticMethodID(env,clazz,"postNative",
"(ILJava/lang/Object；)V")；
其中参数env是Java的环境变量，
其中参数clazz是之前查找到的类的实例，
其中参数"postNative"是Java层提供的给so层传递消息的接口名称。
其中参数"(LJava/lang/Object；)V"则是描述接口的参数类型。
其中获取到了接口后则存储到返回值post_event中。
具体调用则可以直接在C++层代码中调用post_event来将收到的数据传递给Java层代码中：
(*env)->CallStaticVoidMethod(env,clazz,post_event,pbuff)；
其中通过JNI层提供的方法CallStaticVoidMethod来调用Java层提供的接口。
其中参数clazz是之前获取的接口的类。
其中参数post_event是获取的类的接口实例。
其中参数pbuff是服务器发送过来so层收到的消息。
至此便通过调用将数据传递到了Java层代码中。
在一种实施方式中，若服务器不是使用protobuf来定义的协议文件数据，为了更为方便的提供so层数据与Java层数据的交互，并且协议定义时更为方便，则在so层中对服务器下发的非protobuf的数据使用protobuf来进行一次打包，将非protobuf的数据打包成protobuf的数据后再传递到应用层，从而可以提高数据解析的效率，同时对于协议格式的定义更为方便。
具体则是客户端收到服务器下发的弹幕协议内容是：
type@＝chat/content@＝666/nc@＝yy/time@＝1525573879/
那么首先解析出协议的各个字段后，则会生成一个protobuf的对象chatmessagechat；
然后来对chat进行赋值。
chat.set_type(“chat”)；表示写入消息的类型是chat。
Chat.set_content(“666”)；表示写入消息的弹幕内容是“666”。
Chat.set_nc(“yy”)；表示写入发送弹幕的发送者的名称“yy”。
Chat.set_time(“1525573879”)；表示发送弹幕的时间戳。
然后将数据进行序列号：
Char*pBuff＝chat.Serialize()；
Int nLength＝chat.length()；
从而得到了protobuf序列化后的数据pBuff。
然后则可以通过调用java层的代码从而将数据传递到java层中。
(*env)->CallStaticVoidMethod(env,clazz,post_event,pbuff)；
从而实现对任意协议的数据进行转换后，将非protobuf的数据转换成protobuf的数据并传递到应用层的java代码中
在一种实施方式中，服务器和客户端中均生成一对私钥和公钥；
服务器和客户端均将自身生成的公钥发送给对方，自身保存私钥；服务器使用自身保存的私钥和接收的公钥生成一个密钥，直播APP使用自身保存的私钥和接收的公钥生成一个密钥；服务器将流式数据使用自身生成的密钥加密后，发送至客户端；客户端的so层接收流式数据并使用客户端自身生成的秘钥解密后，将流式数据传递至Java层。
当客户端登录到服务器时，此时服务器则会依据该客户端的用户信息来生成一对秘钥，同时为了保障每个用户的秘钥信息不一致，提高破解的门槛，则将用户的账号以及随机数据做为私钥信息，从而保障每个用户私钥都不一致。具体实现如下：
采用非对称RSA加密算法来生成一对公钥和私钥。具体私钥可以使用随机数生成，公钥则调用RSA的接口函数可以生成对应的公钥，私钥和公钥是唯一配对的关系。
1.生成随机数据
Randdata＝rand()；
通过调用系统函数rand来生成一段随机数据Randdata。
2.依据房间号和随机数生成Md5值做为私钥。
ClientPrivatekey＝Md5.Create(UserId+TimeStamp+randdata)
通过调用Md5函数的接口Md5.Create来对用户ID、随机数据、当前时间戳信息以及随机数拼接到一起计算Md5值，从而得到了私钥数据。
3.计算公钥。
ClientPublickey＝RSA.CreatePair(ClientPrivatekey)；
调用RSA的生成配对钥匙接口RSA.CreatePair来生成。
至此，服务器生成了公钥和私钥。
对于客户端生成的公钥和私钥，当客户端登录到服务器时，客户端则会使用随机数据和时间戳来生成私钥，从而尽可能保障不同客户端是不一样的私钥和公钥。具体实现如下：
1.生成随机数据
Randdata＝rand()；
通过调用系统函数rand来生成一段随机数据Randdata。
2.使用时间戳和随机数生成Md5值做为私钥。
ServerPrivatekey＝Md5.Create(Randdata+timestamp)
通过调用Md5函数的接口Md5.Create来对随机数据和当前时间戳信息拼接到一起计算Md5值，从而得到了私钥数据。
3.计算公钥。
ServerPublickey＝RSA.CreatePair(ServerPrivatekey)；
公钥则调用RSA的生成配对钥匙接口RSA.CreatePair来生成。
至此，客户端则生成了公钥和私钥。
服务器将自身的公钥ServerPublickey发送给客户端，客户端将自身的公钥ClientPublickey发送给服务器。
服务器使用自身保存的私钥和接收的公钥生成一个密钥：
ShareKey＝RSA.CreateShareKey(ClientPublickey,ServerPrivatekey)；
直播APP使用自身保存的私钥和接收的公钥生成一个密钥：
ShareKey＝RSA.CreateShareKey(ServerPublickey,ClientPrivatekey)。
且服务器和客户端生成的秘钥ShareKey的值一致。
服务器将流式数据加密后发送至客户端，具体加密代码为：encryptData＝AES.Encrypt(Protobuf+userid+token+timestamp,ShareKey)，即将Protobuf与用户ID信息userid、登录时服务器下发的token信息、当前的时间戳一起使用秘钥ShareKey进行加密。
客户端接收到流式数据后，需先进行解密，解密的功能也在so层的C++代码中进行，解密过程具体为：
pBuff+userid+token+timestamp＝AES.Decrypt(encryptData,ShareKey)；
其中AES.Decrypt是算法的解密接口；ShareKey是之前服务器与客户端协商的共享密钥；pBuff+userid+token+timestamp是客户端解密出的原始数据。
S4：Java层对流式数据进行反序列化，得到弹幕内容并展示。在Java层中提供了接口post_event用于接收so层传递过来的消息数据，则在post_event中接收到的是protobuf的序列化后的数据则需要在Java层对数据进行反序列化，然后将数据进行展示，即展示弹幕内容，具体实现如下：
首先会定义一个弹幕消息的对象chatmessage chat，此对象是protobuf提供的工具自动生成的，然后此对象来对收到的消息进行反序列化。Chat.ParseFromArray(pBuff,length)；其中通过调用该对象的接口ParseFromArray实现反序列化的操作，由于对该对象的属性已经进行赋值，那么在Java层代码中，如果要显示弹幕，则可以直接从Chat对象中获取相关的数据，例如获取弹幕的内容，chat.get_content()则会返回弹幕文本是“666”，例如获取弹幕发送者，则可以通过调用chat.get_nc()，从而得到弹幕发送者是”yy”。
本发明实施例的弹幕接收处理方法，使用Protobuf来定义协议文件格式，并且使用Protobuf来生成C++的代码和Java层的代码，从而对于协议内容的解析可以使用Protobuf的代码，并不需要独立的编写协议字段的解析代码，so层收到服务器的流式数据转发给Java层代码，Java层代码解析弹幕并进行显示，有效提升弹幕消息的处理速度，从而提高弹幕消息的处理效率，且使用Protobuf来定义协议文件内容及格式，从而使得协议的解析代码和打包代码可以使用Protobuf来自动生成，并且能够生成服务器的打包代码，同时生成客户端Java层的解析代码，因此so层的接收弹幕功能则只需要透传接收到的弹幕内容至Java层，Java层直接解析，而so则不需要对协议文件进行解析和编码的过程，提升弹幕消息处理效率。
本发明实施例还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
生成协议文件的序列化代码；
将协议文件序列化成流式数据，然后将流式数据发出。
本发明实施例还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
通过so层接收流式数据，并将接收的流式数据传递至Java层；
Java层对流式数据进行反序列化，得到弹幕内容；
对弹幕内容进行展示。
参见图2所示，本发明实施例还提供一种电子设备，包括第一模块、第二模块、第三模块和第四模块。
第一模块用于定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；第二模块用于生成协议文件的序列化代码，并将协议文件序列化成流式数据后发送至客户端；第三模块用于通过so层接收流式数据并将接收的流式数据传递至Java层；第四模块用于在Java层对流式数据进行反序列化，得到弹幕内容并展示。
本发明实施例还提供一种弹幕接收处理系统，包括服务器和客户端。服务器用于定义Protobuf的协议文件，生成协议文件的序列化代码，然后将协议文件序列化成流式数据后发送至客户端，所述协议文件用于描述弹幕消息的内容；客户端用于在so层接收流式数据并将接收的流式数据传递至Java层，以及在Java层对流式数据进行反序列化，得到弹幕内容并展示。弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间；协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容。
本发明实施例的弹幕接收处理系统，使用Protobuf来定义协议文件格式，并且使用Protobuf来生成C++的代码和Java层的代码，从而对于协议内容的解析可以使用Protobuf的代码，并不需要独立的编写协议字段的解析代码，so层收到服务器的流式数据转发给Java层代码，Java层代码解析弹幕并进行显示，有效提升弹幕消息的处理速度，从而提高弹幕消息的处理效率。
本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种弹幕接收处理方法，其特征在于，包括以下步骤：
服务器中定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
生成协议文件的序列化代码，将协议文件序列化成流式数据后发送至客户端；
客户端的so层接收流式数据并将接收的流式数据传递至Java层；
Java层对流式数据进行反序列化，得到弹幕内容并展示。
2.如权利要求1所述的一种弹幕接收处理方法，其特征在于：
所述弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间；
所述协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容。
3.如权利要求1所述的一种弹幕接收处理方法，其特征在于：所述协议文件的序列化代码由Protobuf提供的工具自动生成。
4.如权利要求1所述的一种弹幕接收处理方法，其特征在于，该方法还包括：
服务器和客户端中均生成一对私钥和公钥；
服务器和客户端均将自身生成的公钥发送给对方，自身保存私钥；
服务器使用自身保存的私钥和接收的公钥生成一个密钥，直播APP使用自身保存的私钥和接收的公钥生成一个密钥；
服务器将流式数据使用自身生成的密钥加密后，发送至客户端；
客户端的so层接收流式数据并使用客户端自身生成的秘钥解密后，将流式数据传递至Java层。
5.如权利要求1所述的一种弹幕接收处理方法，其特征在于：
所述Java层中创建有消息接口；
所述客户端的so层获取Java层的消息接口，然后调用Java层的消息接口将流式数据传递至Java层。
6.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现以下步骤：
定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
生成协议文件的序列化代码；
将协议文件序列化成流式数据，然后将流式数据发出。
7.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现以下步骤：
通过so层接收流式数据，并将接收的流式数据传递至Java层；
Java层对流式数据进行反序列化，得到弹幕内容；
对弹幕内容进行展示。
8.一种电子设备，其特征在于，其包括：
第一模块，所述第一模块用于定义Protobuf的协议文件，所述协议文件用于描述弹幕消息的内容；
第二模块，所述第二模块用于生成协议文件的序列化代码，并将协议文件序列化成流式数据后发送至客户端；
第三模块，所述第三模块用于通过so层接收流式数据并将接收的流式数据传递至Java层；
第四模块，所述第四模块用于在Java层对流式数据进行反序列化，得到弹幕内容并展示。
9.一种弹幕接收处理系统，其特征在于，包括服务器和客户端；
所述服务器用于定义Protobuf的协议文件，生成协议文件的序列化代码，然后将协议文件序列化成流式数据后发送至客户端，所述协议文件用于描述弹幕消息的内容；
所述客户端用于在so层接收流式数据并将接收的流式数据传递至Java层，以及在Java层对流式数据进行反序列化，得到弹幕内容并展示。
10.如权利要求1所述的一种弹幕接收处理系统，其特征在于：
所述弹幕消息的内容包括弹幕文本、弹幕发送者和弹幕发送时间；
所述协议文件中包括多个字段，且每个字段代表弹幕消息的一个内容。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810715414.0A CN110662089A (zh) | 2018-06-29 | 2018-06-29 | 弹幕接收处理方法、存储介质、电子设备及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810715414.0A CN110662089A (zh) | 2018-06-29 | 2018-06-29 | 弹幕接收处理方法、存储介质、电子设备及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110662089A true CN110662089A (zh) | 2020-01-07 |
Family
ID=69027193
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810715414.0A Pending CN110662089A (zh) | 2018-06-29 | 2018-06-29 | 弹幕接收处理方法、存储介质、电子设备及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110662089A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112100255A (zh) * | 2020-08-03 | 2020-12-18 | 中冶南方工程技术有限公司 | 一种钢铁全流程质量数据平台的对外数据通讯方法和系统 |
| CN112651045A (zh) * | 2020-12-30 | 2021-04-13 | 北京奇艺世纪科技有限公司 | 弹幕数据的处理方法、装置及存储介质 |
| CN113407190A (zh) * | 2021-06-16 | 2021-09-17 | 武汉光庭信息技术股份有限公司 | Android系统与汽车ECU模块通信数据序列化和反序列化方法及系统 |
| CN115442635A (zh) * | 2021-06-04 | 2022-12-06 | 武汉斗鱼鱼乐网络科技有限公司 | 一种跨平台安全过滤弹幕的方法、装置、设备和存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101459506A (zh) * | 2007-12-14 | 2009-06-17 | 华为技术有限公司 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
| US20150058781A1 (en) * | 2013-08-26 | 2015-02-26 | Stadium Technology Company | Providing game and facility information to in-stadium spectators |
| CN105959383A (zh) * | 2016-06-07 | 2016-09-21 | 北京百度网讯科技有限公司 | 内容订阅方法和装置 |
-
2018
- 2018-06-29 CN CN201810715414.0A patent/CN110662089A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101459506A (zh) * | 2007-12-14 | 2009-06-17 | 华为技术有限公司 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
| US20150058781A1 (en) * | 2013-08-26 | 2015-02-26 | Stadium Technology Company | Providing game and facility information to in-stadium spectators |
| CN105959383A (zh) * | 2016-06-07 | 2016-09-21 | 北京百度网讯科技有限公司 | 内容订阅方法和装置 |
Non-Patent Citations (4)
| Title |
|---|
| 李波: "某互动教学直播系统的设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
| 聂晓旭 等: "基于Protobuf的数据传输协议", 《计算机系统应用》 * |
| 钟正伟: "基于Android的即时微视频流客户端开发", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
| 隋心怡 等: "基于Google protocol buffer的即时通讯系统设计", 《电子科技》 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112100255A (zh) * | 2020-08-03 | 2020-12-18 | 中冶南方工程技术有限公司 | 一种钢铁全流程质量数据平台的对外数据通讯方法和系统 |
| CN112651045A (zh) * | 2020-12-30 | 2021-04-13 | 北京奇艺世纪科技有限公司 | 弹幕数据的处理方法、装置及存储介质 |
| CN115442635A (zh) * | 2021-06-04 | 2022-12-06 | 武汉斗鱼鱼乐网络科技有限公司 | 一种跨平台安全过滤弹幕的方法、装置、设备和存储介质 |
| CN113407190A (zh) * | 2021-06-16 | 2021-09-17 | 武汉光庭信息技术股份有限公司 | Android系统与汽车ECU模块通信数据序列化和反序列化方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10721057B2 (en) | Dynamic channels in secure queries and analytics | |
| CN110662089A (zh) | 弹幕接收处理方法、存储介质、电子设备及系统 | |
| WO2021012574A1 (zh) | 多重签名方法、签名中心、介质及电子设备 | |
| KR102079626B1 (ko) | 모바일 환경에서 생체 인증 기반 경량 상호 인증 프로토콜을 이용한 정보 은닉 시스템, 이를 위한 방법 및 이 방법을 수행하기 위한 프로그램이 기록된 컴퓨터 판독 가능한 기록매체 | |
| CN111565107B (zh) | 基于云服务平台的密钥处理方法、装置和计算机设备 | |
| CN107786331B (zh) | 数据处理方法、装置、系统及计算机可读存储介质 | |
| US20140122884A1 (en) | Decoupled cryptographic schemes using a visual channel | |
| CN110609679B (zh) | 数据处理方法、装置、计算机可读存储介质和计算机设备 | |
| US11750403B2 (en) | Robust state synchronization for stateful hash-based signatures | |
| CN112822193B (zh) | 应用通信方法、装置、设备及存储介质 | |
| CN111832056A (zh) | 用于生成二维码的方法和系统 | |
| TW201220122A (en) | Software authorization system and method | |
| CN111464564A (zh) | 一种基于对称密码算法的数据高速加解密方法及装置 | |
| CN111193741B (zh) | 一种信息发送方法、信息获取方法、装置及设备 | |
| CN112954050A (zh) | 分布式管理方法及装置、管理设备和计算机存储介质 | |
| CN109711178B (zh) | 一种键值对的存储方法、装置、设备及存储介质 | |
| CN111431922A (zh) | 物联网数据加密传输方法及系统 | |
| CN109120576B (zh) | 数据分享方法及装置、计算机设备及存储介质 | |
| US20230208615A1 (en) | Online-Streamer Image Model File Transmission in Co-Hosting During Livestreaming | |
| CN111460464B (zh) | 数据加解密方法、装置、电子设备及计算机存储介质 | |
| CN113672954A (zh) | 特征提取方法、装置和电子设备 | |
| CN113783835B (zh) | 一种口令分享方法、装置、设备及存储介质 | |
| CN110677693A (zh) | 基于安卓系统的加密视频离线播放方法及装置、电子设备 | |
| CN109933960A (zh) | 服务调用控制方法、服务调用方法、装置及终端 | |
| WO2023159900A1 (zh) | 远程开发的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200107 |