消息转发方法及系统

技术领域

本申请涉及通信技术领域，尤其涉及消息转发方法及系统。

背景技术

随着信息技术的快速发展，分布式技术备受关注。分布式技术与传统的集成计算处理能力相比，将计算能力分散到网络中的设备中进行计算，其优点是可以快速访问、并且多用户使用。例如，华为的全场景音视频通话产品-畅连，可以实现手机与手机、大屏、音箱等设备的音视频通话。然而在设备到设备的畅连的同时，畅连消息的需求越来越备受关注，用户在消息聊天时可以选择逐条转发和合并转发的功能，为用户提供了方便快捷的聊天方式。但是在已经被转发的消息再次被转发时，转发的速度较慢。

发明内容

有鉴于此，本发明提供一种消息转发方法及系统，能够解决消息发送慢的问题，并且可以避免再次转发的消息重复上传，影响转发速度，浪费流量的问题。

本申请的一些实施方式提供了一种消息转发方法。以下从多个方面介绍本申请，以下多个方面的实施方式和有益效果可互相参考。

第一方面，本发明提供一种消息转发方法，应用于作为消息发送方的发送侧电子设备、服务器及作为消息接收方的多个接收侧电子设备构成的系统，方法包括：发送侧电子设备响应于用户针对至少一条消息的转发操作，将被选中的至少一条消息封装成消息体报文，并生成与消息体报文唯一对应的签名；其中，转发操作为电子设备将被选中的至少一条消息转发给多个接收侧电子设备中的至少一个接收侧电子设备的操作；发送侧电子设备将消息体报文及签名发送到服务器；服务器将消息体报文和签名存储在服务器中，并将消息体报文发送给接收侧电子设备；发送侧电子设备响应于用户对被选中的至少一条消息或消息体报文的再次转发操作，将消息体报文的签名发送给服务器；其中，再次转发操作为发送侧电子设备将之前转发的被选中的至少一条消息或消息体报文再次转发给多个接收侧电子设备中的至少一个接收侧电子设备；服务器基于签名确定服务器中存储有与签名对应的消息体报文，将服务器中存储的消息体报文发送给多个接收侧电子设备中的至少一个接收侧电子设备。

根据本申请实施例的消息转发方法，发送侧电子设备对转发的至少一条消息封装成固定的消息体报文后，对消息体报文生成唯一的签名。当再次转发之前转发过的消息时，发送侧设备只要将该消息对应的签名发送给服务器，服务器根据签名确认其内部的存储有与该消息对应的消息体报文后，直接将与该签名对应的消息体报文发送给接收方电子设备，从而不需要发送侧电子设备上传文件后进行透传，而是由服务器直接转发给接收侧电子设备，提高了消息转发的效率。

在上述第一方面的一种可能的实现中，服务器基于签名确定服务器中存储有与签名对应的消息体报文，还包括：服务器向发送侧电子设备发送不需要上传与该签名对应的消息体报文的通知，以使发送侧电子设备不再向服务器发送消息体报文。从而可以避免大量重复的消息内容被上传服务器，减少服务器接口的开销，且节约了流量。

在上述第一方面的一种可能的实现中，转发操作包括用户选择对被选中的消息的逐条转发，或者用户选择对被选中的消息的合并转发。

在上述第一方面的一种可能的实现中，发送侧电子设备生成与消息体报文唯一对应的签名，包括：发送侧电子设备基于其自身的发送地址，以及用于表达被选中的消息的含义的数据信息生成唯一签名。也就是说，只要消息内容和发送侧电子设备是固定不变的，就可以生成唯一的签名，因而当被选中的至少一个消息无论时在单聊或群聊时都不会受到限制，从而提高了消息转发的灵活性。

在上述第一方面的一种可能的实现中，用于表达被选中的至少一条消息的含义的数据信息包括：被选中的消息中的每一条消息的唯一标识ID、消息的类型、以及消息内容中的一种或几种。

在上述第一方面的一种可能的实现中，消息的类型包括纯文本、富媒体文件、小文件、预制表情和地理位置中的一种或几种；

其中，当消息的类型包括富媒体文件时，发送侧电子设备生成与消息体报文唯一对应的签名，还包括：

发送侧电子还基于富媒体文件ID、富媒体文件对应的URL地址、富媒体文件名字、富媒体文件大小和富媒体文件备注描述信息生成唯一的签名。

在上述第一方面的一种可能的实现中，富媒体文件包括语音、视频和图片中的一种或几种。

在上述第一方面的一种可能的实现中，签名的加密算法包括：通过安全哈希算法SHA256、SHA1、或消息摘要算法MD5。

第二方面，本申请提供消息转发的系统，包括发送侧电子设备、服务器、及作为消息接收方的多个接收侧电子设备，发送侧电子设备用于响应于用户针对至少一条消息的转发操作，将被选中的至少一条消息封装成消息体报文，并生成与消息体报文唯一对应的签名；其中，转发操作为电子设备将被选中的至少一条消息转发给多个接收侧电子设备中的至少一个接收侧电子设备的操作；发送侧电子设备用于将消息体报文及签名发送到服务器；服务器用于将消息体报文和签名存储在服务器中，并将消息体报文发送给接收侧电子设备；发送侧电子设备用于响应于用户对被选中的至少一条消息或消息体报文的再次转发操作，将消息体报文的签名发送给服务器；其中，再次转发操作为发送侧电子设备将之前转发的被选中的至少一条消息或消息体报文再次转发给多个接收侧电子设备中的至少一个接收侧电子设备；服务器用于基于签名确定服务器中存储有与签名对应的消息体报文，将服务器中存储的消息体报文发送给多个接收侧电子设备中的至少一个接收侧电子设备。

根据本申请实施例的消息转发的系统，发送侧电子设备对转发的至少一条消息封装成固定的消息体报文后，对消息体报文生成唯一的签名。当再次转发之前转发过的消息时，发送侧电子设备只要将该消息对应的签名发送给服务器，服务器根据签名确认其内部存储有与该签名对应的消息体报文后，直接将与该签名对应的消息体报文发送给接收方的设备，不在等待发送侧电子设备上传消息体报文，而是直接转发给接收侧电子设备，提高了消息转发的效率。

在上述第二方面的一种可能的实现中，服务器还用于：服务器用于向发送侧电子设备发送不需要上传与该签名对应的消息体报文的通知，以使发送侧电子设备不再向服务器发送消息体报文。从而可以避免大量重复的消息内容被上传服务器，减少服务器接口的开销，且节约了流量。

在上述第二方面的一种可能的实现中，转发操作包括用户选择对被选中的消息的逐条转发，或者用户选择对被选中的消息的合并转发。

在上述第二方面的一种可能的实现中，发送侧电子设备具体用于：发送侧电子设备用于基于其自身的发送地址，以及用于表达被选中的消息的含义的数据信息生成唯一签名。

在上述第二方面的一种可能的实现中，用于表达被选中的至少一条消息的含义的数据信息包括：被选中的消息中的每一条消息的唯一标识ID、消息的类型、以及消息内容中的一种或几种。

在上述第二方面的一种可能的实现中，消息的类型包括纯文本、富媒体文件、小文件、预制表情和地理位置中的一种或几种；

其中，当消息的类型包括富媒体文件时，发送侧电子设备生成与消息体报文唯一对应的签名，还包括：发送侧电子还用于基于富媒体文件ID、富媒体文件对应的URL地址、富媒体文件名字、富媒体文件大小和富媒体文件备注描述信息生成唯一的签名。

在上述第二方面的一种可能的实现中，富媒体文件包括语音、视频和图片中的一种或几种。

在上述第二方面的一种可能的实现中，签名的加密算法包括：通过安全哈希算法SHA256、SHA1、或消息摘要算法MD5。

第三方面，本申请还提供一种消息转发方法，该方法应用于电子设备中，该方法包括：

电子设备响应于用户针对至少一条消息的转发操作，将被选中的至少一条消息封装成消息体报文，并生成与消息体报文唯一对应的签名；其中，转发操作为电子设备将被选中的至少一条消息转发给多个接收侧电子设备中的至少一个接收侧电子设备的操作；

电子设备将消息体报文及签名发送到服务器，以使服务器存储消息体报文和签名，并将消息体报文透传给接收侧电子设备；

电子设备响应于用户对被选中的至少一条消息或消息体报文的再次转发操作，将消息体报文的签名发送给服务器；其中，再次转发操作为电子设备将之前转发的被选中的至少一条消息或消息体报文再次转发给接收侧电子设备；以使服务器基于签名确定服务器中存储有与签名对应的消息体报文，将消息体报文发送给接收侧电子设备。

根据本申请实施例的消息转发方法，电子设备对转发的至少一条消息封装成固定的消息体报文后，对消息体报文生成唯一的签名。当再次转发之前转发过的消息时，电子设备只要将该消息对应的签名发送给服务器，以使服务器根据签名确认其内部存储有与该签名对应的消息体报文后，直接将与该签名对应的消息体报文发送给接收方的设备，不需要将再次转发的消息体报文上传服务器，而是由服务器直接转发给接收侧电子设备，提高了消息转发的效率。

在上述第三方面的一种可能的实现中，转发操作包括用户选择对被选中的消息的逐条转发，或者用户选择对被选中的消息的合并转发。

在上述第三方面的一种可能的实现中，电子设备生成与消息体报文唯一对应的签名，包括：电子设备基于其自身的发送地址，以及用于表达被选中的消息的含义的数据信息生成唯一签名。

在上述第三方面的一种可能的实现中，用于表达被选中的至少一条消息的含义的数据信息包括：被选中的消息中的每一条消息的唯一标识ID、消息的类型、以及消息内容中的一种或几种。

在上述第三方面的一种可能的实现中，消息的类型包括纯文本、富媒体文件、小文件、预制表情和地理位置中的一种或几种；其中，当消息的类型包括富媒体文件时，电子设备生成与消息体报文唯一对应的签名，还包括：电子还基于富媒体文件ID、富媒体文件对应的URL地址、文件名字、文件大小和文件备注描述信息生成唯一的签名。

在上述第三方面的一种可能的实现中，富媒体文件包括语音、视频和图片中的一种或几种。

在上述第三方面的一种可能的实现中，签名的加密算法包括：通过安全哈希算法SHA256或SHA1，或消息摘要算法MD5。

第四方面，本申请还提供一种消息转发方法，应用于服务器，方法包括：

服务器将由电子设备发送的消息体报文和与消息体报文对应的签名存储在服务器中，并将消息体报文发送给接收侧电子设备；当服务器再次接收签名，并基于签名确认其内部存储有与签名对应的消息体报文，将消息体报文发送给对应的接收侧电子设备。

根据本申请实施例的消息转发方法，服务器可以根据签名将由电子设备第一次转发的消息体报文从其内部调取，并直接转发给对应的接收侧电子设备，不需要等待发送侧的电子设备的再次上传，提高了消息转发的效率。

在上述第四方面的一种可能的实现中，服务器基于签名确认其内部存储有与签名对应的消息体报文，还包括：服务器向发送侧电子设备发送不需要上传与该签名对应的消息体报文的通知，以使发送侧电子设备不再向服务器发送消息体报文。从而可以避免大量重复的消息内容被上传服务器，减少服务器接口的开销，且节约了流量。

第五方面，本申请提供一种电子设备，包括：

存储器，用于存储由设备的一个或多个处理器执行的指令，以及

处理器，用于执行上述第三方面或第四方面实施例的方法。

第六方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器运行时，使得处理器执行上述第三方面或第四方面实施例的方法。

第七方面，本申请的公开了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第三方面或第四方面实施例公开的方法。

第八方面，本申请的公开了一种设备，包括处理器、存储器和通信模块。处理器、存储器和通信模块之间通过内部链接通路互相通信，传递控制和/或数据信号，使得该设备执行上述第三方面或第四方面实施例公开的方法。

附图说明

图1典型的通信系统的示意图；

图2a为现有技术的一个示例性的方案中的消息转发的流程图；

图2b为现有技术的另一个示例性的方案中的消息转发的流程图；

图3为本申请另一个实施例的电子设备的结构示意图；

图4为本申请一个实施例的电子设备的软件结构框图；

图5为本申请一个实施例的服务器的结构示意图；

图6为本申请一个实施例的消息快速转发的流程示意图；

图7a为本申请另一个实施例的发送侧手机对被选中的消息被再次转发的判断的流程图；

图7b为本申请一个实施例的云服务器对被选中的消息被再次转发的判断的流程图；

图8a为本申请另一个实施例的手机界面的示意图；

图8b为本申请一个实施例的手机界面的示意图；

图8c为本申请一个实施例的手机界面的示意图；

图9a为本申请一个实施例的手机界面的示意图；

图9b为本申请一个实施例的手机界面的示意图；

图10为本申请一个实施例的消息转发的系统；

图11为本申请一些实施例的一种终端设备的示意图；

图12为本申请一些实施例的一种片上系统(SoC)的框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

图1示出了一种典型的通信系统的示意图。该通信系统包括手机101、云服务器102、手机103和平板104。其中，手机101作为消息发送方的电子设备，手机103和平板104作为消息接收方的电子设备。当用户通过手机101向手机103转发消息时，手机101首先将用户选中的需要转发的消息封装成固定的消息体报文，举例说明，用户选中5条消息进行合并转发，手机101将这5条消息封装成固定的消息体报文。手机101转发时，将该签名发送给云服务器，由云服务器将该消息体报文发送给手机103。

为更清楚的理解本申请的技术方案，结合上述通信系统图，首先对示例性的现有技术进行说明。

图2a示出了现有技术的一个示例性的消息转发的流程示意图。如图2a所示，包括以下步骤：用户在发送端设备上选择要转发的消息，例如，转发50条消息。发送端设备将用户选中的50条消息封装成消息体报文，并发送给云侧。云侧将消息体报文透传给接收端设备。接收端接收并解析消息体报文。当用户再次转发该50条消息时，发送端设备依然将该50条消息封装成消息体报文，再上传云侧。由于大量的消息体报文上传云侧，不仅浪费流量，同事云侧接口开销较大，云侧的影响消息发送的速度。

图2b示出了现有技术的另一个示例性的方案中消息转发的流程图。如图2b所示，包括以下步骤：用户选择发送富媒体消息，例如，该富媒体消息中包括图片、视频和文本文件。发送端设备将用户选中图片、视频和文本文件分别进行签名，并将签名发送给云侧。云侧根据签名判断是否需要上传文件。若需要上传云侧时，发送端设备将这些富媒体消息上传至云侧，再将这些富媒体消息封装成消息体报文，由云侧透传给接收端设备。若之前已经发送过的信息，则不需要将富媒体消息文件上传云侧，发送端设备将这些富媒体消息封装成消息体报文，将消息体报文发送给云侧，由云侧将消息体报文透传给接收端设备。该方案中对单个的文件进行签名，例如，对图片、视频和文本文件分别进行签名，通过该签名判断之前这些文件是否有上传过。当转发的消息条数较多，或者文本和图片混合转发时，在封装消息体报文时，仍存在需要封装并发送大量报文的问题。

与现有技术不同，本申请提供了一种新的技术方案以解决上面提到的技术问题。同样可以参照图1所示的用于消息转发的通信系统的示意图。

继续如图1所示，该通信系统包括手机101、云服务器102、手机103和平板104。其中，手机101作为消息发送方的电子设备，手机103和平板104作为消息接收方的电子设备。当用户通过手机101向手机103转发消息时，手机101首先将用户选中的需要转发的消息封装成固定的消息体报文，并对该消息体报文进行签名。举例说明，用户选中5条消息进行合并转发，手机101将这5条消息封装成固定的消息体报文，并对该消息体报文生成唯一对应的签名，即对5条消息的整体做一个唯一的签名。手机101转发时，将该签名和与该签名对应的消息体报文发送给云服务器，由云服务器将该消息体报文发送给手机103。当用户再次针对这5条消息进行转发时，例如，用户再次选中这5条消息转发给平板104，手机101将再次选中的5条消息对应的签名发送给云服务器102，云服务器102根据签名查询对应的消息体报文，并直接将与该签名对应的消息体报文发送给平板104。从而云服务器不需要在等待手机101上传消息体报文，而是直接将已存储的与签名对应的消息体报文转发给接收方，从而提高了消息转发的速度。

在本申请的实施例中，作为消息发送的电子设备还可以是除手机之外的电子设备，例如，平板电脑、笔记本电脑、超级移动个人计算机、个人数字助理(personal digitalassistant，PDA)等具有信息发送功能的电子设备，或者具有信息发送功能穿戴设备，如电子手表等。作为接收方的电子设备除上述实施例中的手机和平板以外，还可以是笔记本电脑、超级移动个人计算机、个人数字助理(personal digital assistant，PDA)等具有信息接收功能的电子设备，或者具有信息接收功能的穿戴设备，例如，电子手表等。

下面结合发送侧电子设备的具体结构对本申请的消息转发的过程进行描述。

发送侧电子设备结构：

示例性的，图3示出了一种电子设备的结构示意图。参考图3，该电子设备100可以实现为如图1所示的手机101，也可以实现为其他的电子设备，例如，电脑、手表等。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserial bus，USB)接头130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本发明实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器110可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在本申请的一个实施例中，处理器210可以通过设置的存储器来存储用于实施根据本申请的消息快速转发的指令。在该指令被执行后，电子设备100接收用户输入的针对至少一条消息的转发操作，将被用户选中的至少一条消息封装成消息体报文。电子设备100将封装的消息体报文生成唯一对应的签名，并在电子设备100第一次向接收消息的接收侧电子设备发送该消息时，电子设备100将该签名和与该签名对应的消息体报文上传到服务器中，以通过服务器将消息体报文透传给接收侧电子设备。而当电子设备100再次将上述已经转发过的消息转发给接收侧电子设备的任一个设备时(接收侧电子设备可以是之前接收信息的对象，也可以是不同于之前接收消息的对象)，电子设备不需要再次上传与被选中消息对应的消息体报文，只需要将与该消息体报文对应的签名发送给服务器，以使服务器根据签名查询已存的与该签名对应的消息体报文，并将该消息体报文发送给再次转发的接收侧设备。由于该方法可以不用对重复转发的消息对应的消息体报文上传服务器，而是由服务器直接透传给接收侧电子设备，提高了消息转发的效率。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以将用户选择的消息对应的消息体报文和与消息体报文对应的签名上传至云侧，以使云侧将消息体报文透传给接收侧电子设备。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

在一些实施例中，显示屏可以显示应用程序打开的界面，以及显示用户聊天的消息内容，用户可以根据显示屏194显示的内容选择想要转发的消息，以及选择转发的方式，例如逐条转发，或合并转发。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备100的各种功能应用以及数据处理，例如，执行电子设备100的消息应用中的逐条转发功能或合并转发功能，以及对消息数据的处理。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

图4是本发明实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图4所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，消息，短信息等应用程序。

在一个实施例中，消息应用可以用于将用户选择的需要转发的消息封装成消息体报文，并对消息体报文签名等。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图4所示，应用程序框架层可以包括内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

下面结合聊天消息转发场景，示例性说明电子设备100软件以及硬件的工作流程。

当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，该单击操作所对应的控件为消息应用图标的控件为例，消息应用调用应用框架层的接口，启动消息应用，进而通过调用内核层启动消息应用驱动，打开对用的消息应用，其中消息应用可以是用于聊天的应用软件等。

下面结合中间转发的服务器的具体结构对本申请的消息转发的过程进行描述。

服务器：

示例性的，图5示出了一种服务器的结构示意图。参考图5，该服务器500可以实现为如图1所示的云服务器101，也可以实现为其他的服务器。

服务器500可以包括耦合到控制器中枢503的一个或多个处理器501。对于至少一个实施例，控制器中枢503经由诸如前端总线(Front Side Bus，FSB)之类的多分支总线、诸如快速通道互连(Quick Path Interconnect，QPI)之类的点对点接口、或者类似的连接506与处理器501进行通信。处理器501执行控制一般类型的数据处理操作的指令。在一实施例中，控制器中枢503包括，但不局限于，图形存储器控制器中枢(Graphics MemoryController Hub，GMCH)(未示出)和输入/输出中枢(Input Output Hub，IOH)(其可以在分开的芯片上)(未示出)，其中GMCH包括存储器和图形控制器并与IOH耦合。

服务器500还可包括耦合到控制器中枢503的协处理器502和存储器504。或者，存储器和GMCH中的一个或两者可以被集成在处理器内(如本申请中所描述的)，存储器504和协处理器502直接耦合到处理器501以及控制器中枢503，控制器中枢503与IOH处于单个芯片中。存储器504可以是例如动态随机存取存储器(Dynamic Random Access Memory，DRAM)、相变存储器(Phase Change Memory，PCM)或这两者的组合。在一个实施例中，协处理器502是专用处理器，诸如例如高吞吐量MIC处理器(Many Integerated Core，MIC)、网络或通信处理器、压缩引擎、图形处理器、通用图形处理器(General Purpose Computing onGPU，GPGPU)、或嵌入式处理器等等。协处理器502的任选性质用虚线表示在图5中。

存储器504作为计算机可读存储介质，可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性计算机可读介质。例如，存储器504可以包括闪存等任何合适的非易失性存储器和/或任何合适的非易失性存储设备，例如一个或多个硬盘驱动器(Hard-DiskDrive，HDD(s))，一个或多个光盘(Compact Disc，CD)驱动器，和/或一个或多个数字通用光盘(Digital Versatile Disc，DVD)驱动器。

在一个实施例中，服务器500可以进一步包括网络接口(Network InterfaceController，NIC)506。网络接口506可以包括收发器，用于为服务器500提供无线电接口，进而与任何其他合适的设备(如前端模块，天线等)进行通信。在各种实施例中，网络接口506可以与服务器500的其他组件集成。网络接口506可以实现上述实施例中的通信单元的功能。

服务器500可以进一步包括输入/输出(Input/Output，I/O)设备505。I/O 505可以包括：用户界面，该设计使得用户能够与服务器500进行交互；外围组件接口的设计使得外围组件也能够与服务器500交互；和/或传感器设计用于确定与服务器500相关的环境条件和/或位置信息。

值得注意的是，图5仅是示例性的。即虽然图5中示出了服务器500包括处理器501、控制器中枢503、存储器504等多个器件，但是，在实际的应用中，使用本申请各方法的设备，可以仅包括服务器500各器件中的一部分器件，例如，可以仅包含处理器501和NIC1206。图5中可选器件的性质用虚线示出。

根据本申请的一些实施例，作为计算机可读存储介质的存储器504上存储有指令，该指令在计算机上执行时使服务器500接收发送侧电子设备发送的消息体报文和该消息体报文对应的签名，并将该消息体报文和签名存储在存储器504中，同时将消息体报文发送给由发送侧电子设备提供的接收侧电子设备的地址。并且，当服务器500再次接收到来自同一发送侧电子设备发送的同一个签名时，则根据该签名查询存储器504中对应的消息体报文，并直接将该消息体报文发送给由发送侧电子设备提供的地址。两次发送的接收侧电子设备地址可以相同，也可以不同，在此并不作为限定。

下面结合具体的实施例来介绍消息转发方法。

参考图6，图6示出了消息快速转发的流程示意图，如图6所示，该视图中包括实现消息转发的的通信系统，该通信系统包括：作为消息发送的发送侧电子设备的手机601，云服务器602，以及作为接收消息的接收侧电子设备手机603和手机604。其中，当发送侧电子设备的手机601再次转发相同内容的消息时，作为消息接收的接收侧电子设备可以是与第一次接收的手机603相同，也可以是其他的不同于手机603的手机604。本申请在下面的实施例中，将第一次转发的消息发送给手机603，再次转发的信息发送给手机604为例进行说明。

参考图6所示，该流程图主要包括手机601向手机603第一次转发被选中的至少一条消息的过程，即S611-S611，以及重复(再次)转发被选中的至少一条消息的过程，即S621-S626。下面对各步骤进行描述。

步骤S611，手机601接收用户选中的至少一条消息的转发操作。

其中，转发操作可以是逐条转发，也可以是合并转发。例如，用户使用手机601与朋友通过聊天应用软件聊天，朋友使用手机603。用户选择50条消息后，将这50条消息通过合并转发的方式发送给朋友手机603，以使朋友可以看到50条消息的内容，使聊天更加顺畅。

在本申请的实施例中，在用户选择逐条转发时，则手机可将该逐条转发的操作标注为individual Forward Msg＝11//，合并转发可以标识为merge Forward Msg＝12//，以使得云服务器根据标识可以判断用户的转发操作是合并转发或是逐条转发。

步骤S612，手机601将被选中的至少一条消息封装成消息体报文。例如，将50条消息封装成含有50条消息的消息体报文。本申请中对于将至少一个消息封装为消息体报文的方法具体可参考现有技术中的封装方法，在此不在详细描述。

步骤S613，手机601对消息体报文生成唯一与其对应的签名。

本申请的一个实施例中，签名作为代表50条消息的内容的唯一签名。具体的用于生成签名的信息至少包括发送方地址，以及用于表达被选中的消息的含义的数据信息，例如，消息ID、消息类型和消息内容等。在下面的实施例中，将对用于生成签名的信息进行详细的描述，请参考下面实施例中关于签名的描述。

在本申请的一个实施例中，签名的算法可以采用安全哈希算法SHA256、SHA1、或消息摘要算法MD5等，在此并不作为限定。

上述S611-S612可以在手机601中的消息应用中完成。步骤S614，将消息体报文和签名发送给云服务器。其中，在发送消息提报文和签名的同时，手机601还会将接收侧手机603的地址发送给云服务器，以使服务器能够确认需要转发的对象。

在该步骤中，将被用户选中的至少一条消息作为第一次转发时的情况下，手机601将消息体报文和签名发送给云服务器，并且，使得所述云服务器执行步骤S615-S616，即云服务器602存储消息体报文及对应的签名,将消息体报文透传给手机603。

在本申请的实施例中，对被用户选中的至少一条消息是否为第一次转发或重复转发的判断过程，可以在发送侧的手机601内执行，也可以在云服务器602中执行，在此并不作为限定。在下面的实施例中，将分别对判断是否为重复转发的步骤在手机601内执行，或者在云服务器602内执行进行举例说明，具体参考下面的实施例。

步骤S617，手机603接收消息体报文，并解析消息体报文，以使得使用手机603的用户可以获知消息体报文内的消息内容。

上述步骤是针对当用户选中的至少一条消息是第一次被手机601转发给手机601的情况下，手机601、云服务器602以及手机603执行的步骤。

在下面步骤S621-S626，将对手机601第一次转发过的至少一条消息的再次转发给手机604的情况进行描述。

步骤S621，手机601接收用户再次选中的至少一条消息的转发操作。例如在步骤S611中，用户选择50条消息后，在该步骤中再次选中相同的50条消息转发给手机604。

步骤S622，手机601将被选中的至少一条消息封装成消息体报文。

步骤S623，手机601生成与消息体报文唯一对应的签名。

在本申请的一些实施例中，在步骤S622和步骤623中，当手机601确认为被选中的至少一条消息是再次转发时，例如，被选中的50条消息是第一次已经转发过的，则手机601可以直接从本地存储器中获取该50条消息对应的签名，而不用再次生成。此处不作为对本申请的限定。步骤S624，手机601将签名发送给云服务器。在该步骤中还应该包括接收侧的手机604的地址。步骤S625，云服务器602根据签名确认消息体报文。云服务器602接收到签名后，根据签名在本地存储器内查询与该签名对应的消息体报文。若云服务器602查询到本地存储器内没有与该签名对应的消息体报文时，云服务器可以通知手机601上传与该签名对应的消息体报文。若云服务器602确认本地存储器内存有与该签名对应的消息体报文。并执行步骤S626。

在步骤S626，云服务器602将与该签名对应的消息体报文发送给手机604。手机604接收到消息体报文后，解析该消息体报文。完成消息再次转发的过程。

本申请实施例的方法，发送侧电子设备，例如，手机602，在将用户转发的至少一条消息封装成消息体报文后，对该消息体报文进行签名，即对用户被选中的消息的整体进行签名，并且云服务器在第一次接收到转发的消息时，将消息体报文和对应签名存储在本地，当用户再次转发时，云服务器不需要手机601再将与签名对应的消息提报文上传，而是直接将消息体报文发送给接收侧电子设备。不再需要等待手机601上传消息体报文，提高了消息转发的速度。此外，手机601不需要再次上传消息体报文，减少云服务器接口的开销，且节约了流量。

下面对步骤S613中涉及的用于生成签名的信息进行详细的描述。

本申请的一个实施例，用于生成签名的信息包括发送方地址，以及用于表达被选中的消息的含义的数据信息，例如，消息ID、消息类型和消息内容等。如表1中所列举的内容可以作为必选字段生成唯一的签名。包括的必选字段为“发送方ID”、“消息ID”、“消息类型”、“消息内容”。其中，“发送方ID”用于标识发送方，例如，标识发送方地址，以使得接收方可获知该消息的唯一的发送方。“消息ID”用于标识一条消息的唯一性，例如，用于标记消息的数字标哈希值等。“消息类型”用于标识消息的类型，例如，纯文本、富媒体消息、小文件、表情和地理位置等。“消息内容”用于表达用户想要转发的文字信息内容，例如，用户想要转发的50条消息的文字内容。

表1

本申请的一些实施例中，如图表2所示，当转发的消息是富媒体文件时，用于生成签名的信息需要包括“文件ID”、“文件URL”、“文件名称”“文件大小”、“文件描述”，其中，文件ID为“富媒体文件ID”，文件URL为“富媒体文件URL”、文件名称为“富媒体文件名称”、文件大小为“富媒体文件大小”、文件描述为“富媒体文件的备注描述信息”等。

表2

在本申请的一个实施例中，如表3所示，当转发的消息是富媒体文件时，用于生成签名的信息还可以包括“文件时长”、“文件声波”、“文件备注”、“文件高度”、“文件高度”、“缩略图ID”“缩略图URL”“缩略图宽度”“缩略图高度”“经度”“纬度”“文件秘钥”“显示索引”“子文件索引”“联系卡”“文件类型”等，其具体描述可参考表3中的描述。

表3

需要说明的是，本申请实施例中的提及的用于签名的信息是示例性的说明，对于不同的信息类型时，用于生成签名的信息不同，预知表情文件的大小，表情包大小等。以满足签名的唯一性，在此并不作为限定。

下面对本申请中关于对用户被选中的至少一条消息的判断过程举例说明。

参考图7a，7a示出了发送侧手机对被选中的消息被再次转发的判断的流程图。结合图6和如图7a所示，举例说明，用户选中50条消息，并合并转发给手机603。步骤如下：

步骤S711，手机601接收用户针对50条消息的合并转发。该步骤与图6中的步骤S611的过程一致。

步骤S712，手机601将50条消息封装成消息体报文，并对该消息体报文生成唯一的签名。如图6中的步骤S612-S613。

步骤713，手机601判断50条消息是否被再次选中，并且用户欲将其再次转发。

在本申请的一个实施例中，手机601在每次转发的时候，可以将已经被转发的消息体报文或签名进行保存。

若，当手机601查询当前生成的50条消息的消息体报文对应的签名与其存储器内的签名相同，则手机601可以判断该消息体报文已经被转发过，则执行步骤S714，即手机601将该签名直接发送给云服务器，该步骤与图6中的步骤S624的过程一致。

若，当手机601查询当前生成的50条消息的消息体报文的签名并没有存储，则手机601可以判断这50条消息是第一次转发，则执行步骤S715，即手机601将步骤S720中生成的签名和消息体报文发送给云服务器。该步骤与图6中的步骤S614的过程一致。

步骤S716，云服务器602将签名对应的消息体报文发送给手机603。

本申请实施例的判断方法，操作简单，方便。同时，将判断是否再次被选中，转发的操作设置在发送端的手机601，可以减少云服务器判断的工作量。

在本申请的一些实施例中，当手机执行步骤S714，手机将签名直接发送给云服务器时，云服务器接收签名后还可以进一步判断云服务器的存储器内是否存储有与该签名对应的消息体报文，以避免用户想要转发的消息能够准确无误的到达发送侧的手机603。

参考图7b，7b示出了云服务器对被选中的消息被再次转发的判断的流程图。结合图6和如图7b所示，举例说明，用户选中50条消息，并合并转发给手机603。步骤如下：

步骤S721，手机601接收用户针对50条消息的合并转发。如图6中的步骤S611。

步骤S722，手机601将50条消息封装成消息体报文，并对该消息体报文生成唯一的签名。如图6中的步骤S612-S613。

步骤S723，手机601将签名发送给云服务器。也就是说，手机601在不确定是否为在此转发的情况下，都只发送签名给云服务器。由服务器来判断是否需要上传消息体报文。

步骤S724，云服务器602判断与签名对应的消息体报文是否被再次转发。云服务器602，根据签名从本地存储器内查询是否存储有与该签名相对应的消息体报文。

如图7b所示，当云服务器602查询本地存储器内存储有与该签名对应的消息体报文，则执行步骤S725。

在步骤S725，云服务器告知手机601不需要上传消息体报文。例如，云服务器可以通过发送通知，例如，发送确认字符(Acknowledge character，ACK)，以告知手机601无需在上传与该签名对应的消息体报文。

如图7b所示，当云服务器602查询本地存储器内被没有与该签名对应的消息体报文，则执行步骤S726-S727。

在步骤S726，云服务器602告知手机601需要上传消息体报文。例如，云服务器602发送一个消息，告知手机601云服务器内没有与该签名对应的消息体报文，或该消息转发的指令是首次执行，需要上传与该签名对应的消息体报文。

在步骤S727，手机将与签名对应的消息体报文上传云服务器602。其中，步骤S723，S724以及S726-S727完成如图6中的步骤S614。

在步骤S728，云服务器将与该签名对应的消息体报文直接透传给手机603。如图6中的步骤S626。

在该场景中，将判断用户针对消息的再次转发的判断设置在云服务器侧执行，从而减轻发送侧手机601的工作量。

在上述实施例图7a中描述的手机601判断是否再次转发的场景中，当手机601判断消息是被再次转发时，还可以通过界面显示提醒用户该被选中的消息是被再次转发，以提醒用户是否需要再次转发的操作。

参考图8a，图8a示出了手机界面的示意图，如图8a中的(1)所示，手机601的界面810显示消息栏811和选项栏812，其中消息栏811内显示用户已经选择的50条消息，以及选项栏内显示“删除”“转发”和“全选”选项，用户选择转发操作。如图8a中的(2)所示，用户选择转发后，界面810切换为界面820，界面820内弹出“逐条转发”和“合并转发”选项框821。当用户选择合并转发后，如图8a中的(3)所示，进入界面830，该界面830中显示可以选择的聊天对象。用户选择转发给”王梓江”后，手机601会首先判断这50条消息是否已经转发过，当手机601判断已经转发过，则如图8a中的(4)所示，手机601的界面840内的提示栏841内显示判断后的提示语言，例如“以下50条消息为再次转发，是否需要继续转发？”当用户选择确认后，手机601将与50条消息对应的消息体报文的签名发送给云服务器602。

此外，在一些实施例中，在图8a所示的场景下，手机601将与50条消息对应的消息体报文的签名发送给云服务器602。也可以通过界面提示用户。如图8b所示，界面850内内显示“同样的消息已经向王梓江转发”。该手机601能够做出这样的提示，是因为手机601核对了与50条消息对应的签名后，判断出为再次转发，因此通过提示框提示用户转发的消息已经被转发过。并且手机601不再向服务器将50条消息对应的消息体报文发送给服务器，而是只发送了消息体报文对应的签名，从而提高转发的速度。

在上述实施例的手机601的界面的显示中，以纯文本的消息为例进行说明。本省申请的一些实施例中，转发的文件还可以是富媒体文件等，例如，图片、音频文件、视频文件等。如图8c所示，图8c中的(1)中，手机界面861中的两条消息一个是图片，一个是PDF文件。用户选择“多选”后，如图8c中的(2)所示，界面862中，用户选择这两条消息后，选择转发。在如图8c中的(3)所示，界面863中，用户选择“合并转发”选项。进入聊天对象界面，如图8c中的(4)所示，用户选择“王梓江”后，进入界面865，在界面865中，提示用户“以下两条消息为再次转发，是否需要继续转发”，并且在用户悬着确认后，进入如图8b所示界面。本申请实施例的方法，在转发图片，音频、视频等较大文件时，可以避免重复将大文件上传，提高传输速度，同时，有效的节约流量。

下面对在服务器中判断被选中的消息是否再次转发的判断的界面示意图进行描述。

参考图9a，图9a示出了手机的界面示意图。结合图7b所示，当云服务器602判断出签名对应的消息体报文并没有上传后，并告知手机601需要上传消息体报文。手机601在接收到云服务器602的通知后，手机601将消息体报文上传云服务器602，并通过界面显示的方式提示用户已上传与签名对应的消息体报文。如图9a所示，界面910内显示“已上传被选中的消息内容”，即上传了与签名对应的消息体报文。

结合图7b所示，当云服务器602判断出签名对应的消息体报文已经上传后，并告知手机601不需要上传消息体报文。手机601在接收到云服务器602的通知后，通过界面显示的方式提示用户不需要上传与签名对应的消息体报文。如图9b所示，界面920内显示“不再上传被选中消息的内容”，即不需要上传被选中消息的消息体报文。

根据本申请实施例的方法，云服务器在第一次接收到转发的消息时，将消息体报文和对应签名存储在本地，当用户再次转发时，云服务器不需要发送侧电子设备再将与签名对应的消息提报文上传，而是直接将消息体报文发送给接收侧电子设备。不再需要等待发送侧电子设备上传消息体报文，提高了消息转发的速度。此外，发送侧电子设备不需要再次上传消息体报文，减少云服务器接口的开销，且节约了流量。

参考图10，本申请还提供一种消息转发的系统，图10示出了该消息转发系统的结构示意图，该系统包括发送侧电子设备1010、服务器1020、及作为消息接收方的多个接收侧电子设备1030，发送侧电子设备1010用于响应于用户针对至少一条消息的转发操作，将被选中的至少一条消息封装成消息体报文，并生成与消息体报文唯一对应的签名；其中，转发操作为电子设备将被选中的至少一条消息转发给多个接收侧电子设备1030中的至少一个接收侧电子设备1030的操作；发送侧电子设备1010用于将消息体报文及签名发送到服务器1020；服务器1020用于将消息体报文和签名存储在服务器1020中，并将消息体报文发送给接收侧电子设备1030；发送侧电子设备1010用于响应于用户对被选中的至少一条消息或消息体报文的再次转发操作，将消息体报文的签名发送给服务器1020；其中，再次转发操作为发送侧电子设备1010将之前转发的被选中的至少一条消息或消息体报文再次转发给多个接收侧电子设备1030中的至少一个接收侧电子设备1030；服务器1020用于基于签名确定服务器1020中存储有与签名对应的消息体报文，将服务器1020中存储的消息体报文发送给多个接收侧电子设备1030中的至少一个接收侧电子设备1030。

根据本申请实施例的消息转发的系统，发送侧电子设备1010对转发的至少一条消息封装成固定的消息体报文后，对消息体报文生成唯一的签名。当再次转发之前转发过的消息时，发送侧电子设备1010只要将该消息对应的签名发送给服务器1020，服务器1020根据签名确认其内部存储有与该签名对应的消息体报文后，直接将与该签名对应的消息体报文发送给接收方的设备，不在等待发送侧电子设备1010上传消息体报文，而是直接转发给接收侧电子设备1030，提高了消息转发的效率。

根据本申请的一个实施例，服务器1020还用于：服务器1020用于向发送侧电子设备1010发送不需要上传与该签名对应的消息体报文的通知，以使发送侧电子设备1010不再向服务器1020发送消息体报文。从而可以避免大量重复的消息内容被上传服务器1020，减少服务器1020接口的开销，且节约了流量。

根据本申请的一个实施例，转发操作包括用户选择对被选中的消息的逐条转发，或者用户选择对被选中的消息的合并转发。

根据本申请的一个实施例，发送侧电子设备1010具体用于：发送侧电子设备1010用于基于其自身的发送地址，以及用于表达被选中的消息的含义的数据信息生成唯一签名。

根据本申请的一个实施例，用于表达被选中的至少一条消息的含义的数据信息包括：被选中的消息中的每一条消息的唯一标识ID、消息的类型、以及消息内容中的一种或几种。

根据本申请的一个实施例，消息的类型包括纯文本、富媒体文件、小文件、预制表情和地理位置中的一种或几种；

其中，当消息的类型包括富媒体文件时，发送侧电子设备1010生成与消息体报文唯一对应的签名，还包括：发送侧电子还用于基于富媒体文件ID、富媒体文件对应的URL地址、富媒体文件名字、富媒体文件大小和富媒体文件备注描述信息生成唯一的签名。

根据本申请的一个实施例，富媒体文件包括语音、视频和图片中的一种或几种。

根据本申请的一个实施例，签名的加密算法包括通过安全哈希算法SHA256、SHA1、或消息摘要算法MD5。

本申请的消息转发系统中的个设备的工作流程在上述实施例的消息转发的方法中已经详细的描述，具体可参见上述实施例的消息转发方法，在此不在赘述。

参考图11，本申请还提供一种终端设备，该终端设备用于执行上述方法实施例。图11示出了终端设备的结构示意图。如图11所示，该终端设备包括：

存储器1110，用于存储由设备的一个或多个处理器执行的指令，以及

处理器1120，用于执行上述实施例图6所示的S611-S614以及S621-S624中的方法。

本申请还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器运行时，使得处理器执行上述实施例图6所示的方法。

参考图12，所示为根据本申请的一实施例的SoC(System on Chip，片上系统)1300的框图。在图12中，相似的部件具有同样的附图标记。另外，虚线框是更先进的SoC的可选特征。在图12中，SoC1300包括：互连单元1350，其被耦合至应用处理器1310；系统代理单元1380；总线控制器单元1390；集成存储器控制器单元1340；一组或一个或多个协处理器1320，其可包括集成图形逻辑、图像处理器、音频处理器和视频处理器；静态随机存取存储器(Static Random Access Memory，SRAM)单元1330；直接存储器存取(DMA)单元1360。在一个实施例中，协处理器1320包括专用处理器，诸如例如网络或通信处理器、压缩引擎、GPGPU、高吞吐量MIC处理器、或嵌入式处理器等。

静态随机存取存储器(SRAM)单元1330中可以包括用于存储数据和/或指令的一个或多个计算机可读介质。计算机可读存储介质中可以存储有指令，具体而言，存储有该指令的暂时和永久副本。该指令可以包括：由处理器中的至少一个单元执行时使Soc1300执行根据上述实施例中的通信连接建立方法，具体可参照上述实施例图6所示的方法，在此不再赘述。

本申请公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。

可将程序代码应用于输入指令，以执行本申请描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(Digital Signal Processor，DSP)、微控制器、专用集成电路(Application Specific Integrated Circuit，ASIC)或微处理器之类的处理器的任何系统。

程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本申请中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。

在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、光盘只读存储器(Compact Disc Read Only Memory，CD-ROMs)、磁光盘、只读存储器(Read OnlyMemory，ROM)、随机存取存储器(RAM)、可擦除可编程只读存储器(Erasable ProgrammableRead Only Memory，EPROM)、电可擦除可编程只读存储器(Electrically ErasableProgrammable Read Only Memory，EEPROM)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如，计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。

在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明书附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

需要说明的是，本申请各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本申请所提出的技术问题的关键。此外，为了突出本申请的创新部分，本申请上述各设备实施例并没有将与解决本申请所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本申请的某些优选实施例，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。