CN116055462A - 一种数据传输方法、终端设备、存储介质以及芯片系统 - Google Patents

Abstract

本申请实施例公开了一种数据传输方法、终端设备、存储介质以及芯片系统，适用于数据传输技术领域，该方法包括：终端设备在同时使用目标通信方式以及与目标通信方式同频段的同频通信方式时，检测两种无线通信方式的数据传输拥堵情况：检测目标通信方式对多媒体数据传输的卡顿情况：若存在数据传输拥堵且存在卡顿，则降低对多媒体数据的编码码率，并基于降低后的编码码率对多媒体数据进行编码，再使用目标通信方式传输编码后的多媒体数据。本申请实施例可以提高对多媒体数据传输的稳定性。

Description

一种数据传输方法、终端设备、存储介质以及芯片系统

技术领域

本申请涉及数据传输领域，尤其涉及一种数据传输方法、终端设备、存储介质以及芯片系统。

背景技术

用户在使用终端设备的过程中，有时会出现多种同频段无线通信方式一起使用的场景。例如终端设备可以同时使用2.4GHz频段的蓝牙(Bluetooth，BT)和无线高保真(Wireless Fidelity，Wi-Fi)来进行数据传输。当使用多种同频段的无线通信方式时，可能会出现部分无线通信方式的业务受到影响的情况。此时受到影响的无线通信方式中，若存在需要进行多媒体数据传输的无线通信方式，则会导致这部分无线通信方式稳定性较差，出现多媒体数据传输卡顿的情况。

发明内容

有鉴于此，本申请实施例提供了数据传输方法、终端设备、存储介质以及芯片系统，可以解决终端设备在使用多种同频段无线通信方式时，无线通信方式的多媒体数据传输稳定性较差的问题。

本申请实施例的第一方面提供了一种数据传输方法，应用于终端设备，终端设备在使用目标通信方式传输多媒体数据的过程中，包括：

若终端设备使用与目标通信方式通信频段相同的同频通信方式，则检测目标通信方式与同频通信方式的数据传输拥堵情况，目标通信方式与同频通信方式均为无线通信方式。检测目标通信方式对多媒体数据传输的卡顿情况。若检测到数据传输拥堵情况为存在数据传输拥堵，且卡顿情况为存在卡顿，则降低对多媒体数据的编码码率。再基于降低后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

其中，目标通信方式可选的确定方式包括至少两种：

确定方式1：技术人员可以根据实际需求，预先选定一种或多种无线通信方式。此时将这些预先选定的无线通信方式称为目标通信方式。

确定方式2：终端设备将进行多媒体数据传输的部分或全部无线通信方式作为目标通信方式。

在本申请实施例中，技术人员可以根据需求预先设定一种或多种需要进行多媒体数据传输优化的目标通信方式。在此基础上，对于出现多媒体数据传输问题的目标通信方式，本申请实施例会动态的降低其对多媒体数据的编码码率，再进行相应的多媒体数据编码和传输。由于此时低码率的多媒体数据传输时所需的带宽更小，因此在与其他无线通信方式同频段数据传输的过程中，所受影响更小。使得目标通信方式可以更为顺畅的传输多媒体数据，稳定性更好，不易出现卡顿情况。在用户侧多媒体数据可以流畅的播放，从而提升用户使用体验。

在第一方面的第一种可能的实现方式中，在检测目标通信方式与同频通信方式的数据传输拥堵情况之前，包括：监测终端设备使用的无线通信方式中，是否有属于预设的监测范围内，且与目标通信方式通信频段相同的同频通信方式。若有则执行检测目标通信方式与同频通信方式的数据传输拥堵情况的操作。

在本申请实施例中，通过设定监测范围，可以适应不同实际使用场景的需求，以达到如监测全面或者功耗降低等不同的效果。

在第一方面的第二种可能的实现方式中，在检测目标通信方式与同频通信方式的数据传输拥堵情况之前，还包括：

若监测到预设的监测触发条件，则执行若终端设备使用与目标通信方式通信频段相同的同频通信方式，则检测目标通信方式与同频通信方式的数据传输拥堵情况的操作。

在本申请实施例中，通过设定监测触发条件，可以适应不同实际使用场景中对监测功耗的需求。

在第一方面的第三种可能的实现方式中，检测目标通信方式与同频通信方式的数据传输拥堵情况，包括：获取同频通信方式的数据传输任务量，并根据数据传输任务量和预设的任务量阈值，检测目标通信方式与同频通信方式的数据传输拥堵情况。

本申请实施例通过检测数据传输任务量是否较大的方式，可以实现对数据传输拥堵情况(即是否频段拥挤)快速准确的识别。

在第一方面的第四种可能的实现方式中，在检测目标通信方式与同频通信方式的数据传输拥堵情况之前，还包括：检测终端设备是否使用属于预设的通信方式清单内，且与目标通信方式通信频段相同的同频通信方式。其中，通信方式清单内记录有至少一种无线通信方式。

在本申请实施例中，通过通信方式清单的方式，可以使得对无线通信方式频段拥挤分析和优化的针对性处理。以适应实际使用场景的针对性分析需求。

在第一方面的第五种可能的实现方式中，检测目标通信方式对多媒体数据传输的卡顿情况，包括：获取多媒体数据的数据包重传个数以及数据包被同频通信方式拒绝传输次数。并根据获取到的数据包重传个数和数据包被同频通信方式拒绝传输次数，检测目标通信方式对多媒体数据传输的卡顿情况。

数据包重传个数以及数据包被同频通信方式拒绝传输次数，可以较好的反映真实的多媒体数据传输实时卡顿情况。因此选用多媒体数据数据包重传个数以及数据包被同频无线通信方式拒绝传输的次数作为参数指标，来进行多媒体数据传输卡顿的检测。可以提高对卡顿情况监测的准确性和有效性。

在第一方面的第五种可能的实现方式的基础上，作为第一方面的第六种可能的实现方式，根据获取到的数据包重传个数和数据包被同频通信方式拒绝传输次数，检测目标通信方式对多媒体数据传输的卡顿情况，包括：

若数据包重传个数大于预设的上限个数阈值，且数据包被同频通信方式拒绝传输次数大于预设的上限次数阈值，则判定目标通信方式对多媒体数据传输的卡顿情况为存在卡顿。

在第一方面的第一种至第五种中任一可能的实现方式的基础上，作为第一方面的第七种可能的实现方式，在检测目标通信方式对多媒体数据传输的卡顿情况之后，还包括：

若检测到卡顿情况为无卡顿，则提高对多媒体数据的编码码率。再基于提高后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

本申请实施例通过在发现终端设备因频段拥挤导致多媒体数据传输卡顿时，及时降低对多媒体数据的编码码率。而在发现多媒体数据传输无卡顿时，又及时提高对多媒体数据的编码码率。从而实现了根据实际多媒体数据传输情况，对多媒体数据编码码率的动态调整。在提高无线通信方式对多媒体数据传输的稳定性基础上，本申请实施例还可以充分适应和利用频段的带宽资源，实现多媒体数据传输稳定性和传输质量的动态平衡。最终实现在使用多种同频段无线通信方式时，能稳定传输较高质量的多媒体数据的效果。因此可以极大地提升用户端对多媒体数据的感官体验，提升最终的用户体验。

在第一方面的第七种可能的实现方式的基础上，作为第一方面的第八种可能的实现方式，在检测目标通信方式对多媒体数据传输的卡顿情况之后，还包括：

若检测到卡顿情况为正常传输，则基于当前使用的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

在本申请实施例中，第七种可能的实现方式内的无卡顿，亦可以称为流畅传输。本申请实施例将卡顿情况分为存在卡顿、正常传输和流畅传输三种，并将其中的流畅传输作为无卡顿情况处理。由于本申请实施例在动态降低和提高多媒体数据编码码率的基础上，增加了一种在多媒体数据传输正常时保持编码码率不变的中间情况。因此本申请实施例可以降低终端设备对多媒体数据编码码率的切换频率。使得整体对多媒体数据的传输质量更加平稳。还可以使得输出的音频数据的音质更加平稳，不会频繁的降低或提高音频数据的音质，使得用户侧的感官体验更加平稳自然。

在第一方面的第五种可能的实现方式的基础上，作为第一方面的第九种可能的实现方式，标通信方式为2.4GHz频段的蓝牙，同频通信方式为2.4GHz频段的Wi-Fi。

获取多媒体数据的数据包重传个数以及数据包被同频通信方式拒绝传输次数，包括：获取LOG_ID_STATS_ACT_CONN信息，并从LOG_ID_STATS_ACT_CONN信息中解析出多媒体数据的数据包重传个数以及数据包被Wi-Fi拒绝传输次数。

实际应用中，可以通过解析LOG_ID_STATS_ACT_CONN信息的方式，实现对数据包重传个数以及数据包被Wi-Fi拒绝传输次数的快速准确获取。

第二方面，本申请实施例提供一种数据传输装置，包括:

拥堵检测模块，用于在终端设备使用目标通信方式传输多媒体数据的过程中，在终端设备使用与目标通信方式通信频段相同的同频通信方式时，检测目标通信方式与同频通信方式的数据传输拥堵情况：目标通信方式与同频通信方式均为无线通信方式。

卡顿检测模块，用于在终端设备使用目标通信方式传输多媒体数据的过程中，检测目标通信方式对多媒体数据传输的卡顿情况：

码率调整模块，用于在检测到数据传输拥堵情况为存在数据传输拥堵，且卡顿情况为存在卡顿时，降低对多媒体数据的编码码率。

编码传输模块，用于基于降低后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

第三方面，本申请实施例提供一种终端设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面任一项的方法，或者实现如上述第二方面任一项的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面任一项的方法，或者实现如上述第二方面任一项的方法。

第五方面，本申请实施例提供一种芯片系统，该芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现如上述第一方面任一项所述的方法，或者实现如上述第二方面任一项的方法。该芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。

第六方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面任一项所述的方法，或者实现如上述第二方面任一项的方法。

可以理解的是，上述第三方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1为本申请实施例提供的手机结构框图；

图2为本申请实施例提供的手机同时使用多种无线通信方式的场景示意图；

图3为本申请实施例提供的数据传输方法的一种流程示意图；

图4为本申请实施例提供的一种多媒体数据传输的卡顿情况分类的场景示意图；

图5为本申请实施例提供的数据传输方法的又一种流程示意图；

图6为本申请实施例提供的移动终端与蓝牙耳机通信时的流程示意图；

图7为本申请实施例提供的数据传输方法的又一种流程示意图；

图8为本申请实施例提供的一种数据传输装置的结构示意图；

图9为本申请实施例提供的终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

在本申请实施例中，“多种”是指两种或两种以上。相应的，多种无线通信方式，是指两种或两种以上的无线通信方式。

在本申请实施例中，终端设备可以是手机、可穿戴设备(如智能手表、智能手环、智能眼镜、智能首饰等)、平板电脑、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)以及其他具有网络连接功能的电子设备。上述终端设备也可以是其他电子设备，诸如具有触敏表面(例如触控面板)的膝上型计算机(laptop)等，本申请实施例对终端设备的具体类型不做任何限制。此时终端设备即为本申请实施例提供的数据传输方法的执行主体。

下文以终端设备是手机为例。图1示出的是与本申请实施例提供的手机的部分结构的框图。参考图1，手机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，以及SIM卡接口195等。其中传感器模块180可以包括陀螺仪传感器180A，加速度传感器180B，气压传感器180C，磁传感器180D，环境光传感器180E，距离传感器180F，接近光传感器180G、指纹传感器180H，温度传感器180J，触摸传感器180K(当然，手机100还可以包括其它传感器，比如压力传感器、气压传感器、骨传导传感器等，图中未示出)。

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

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

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

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在手机100上的包括无线局域网(wireless localarea networks，WLAN)(如Wi-Fi网络)，蓝牙，全球导航卫星系统(global navigationsatellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(nearfield communication，NFC)，红外技术(infrared，IR)、紫蜂(Zig Bee)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。本申请实施例中，无线通信模块160可以用于接入接入点设备，向其它终端设备发送和接收消息。

应理解，图示手机100仅是一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了更好地理解本申请实施例，以下先对本申请实施例进行简要说明：

实际应用中，用户经常会同时使用终端设备的多种无线通信方式，以满足自身实际使用需求。例如可以参考图2，用户在通过手机蓝牙(如无特殊说明，本申请实施例中的蓝牙，均是指工作在2.4GHz频段的蓝牙)连接蓝牙耳机听歌的同时，还可以Wi-Fi来后台下载文件，并使用NFC来刷门禁。每种无线通信方式都有自身数据传输的通信频段，终端设备在同时使用多种无线通信方式时，可能会出现其中部分无线通信方式通信频段相同的情况。即存在同时使用多种同频段的无线通信方式。

对于用户在使用终端设备的过程中，多种同频段无线通信方式一起使用的场景。由于每种无线通信方式都需要进行数据传输，因此很容易出现频段拥挤(即该频段内传输的数据量较大，导致数据传输拥堵)的情况。此时可能会导致其中的一部分无线通信方式业务受到影响。而当受到影响的无线通信方式需要进行多媒体数据传输时，则会导致这些无线通信方式的多媒体数据传输卡顿，稳定性较差。从而导致用户在接收端无法正常使用这些多媒体数据，使得用户体验下降。仍以图2所示场景为例，假设此时手机使用的蓝牙和Wi-Fi的频段都是2.4GHz。由于蓝牙与Wi-Fi使用的频段相同，此时可能会导致蓝牙传输音频数据不稳定，从而导致蓝牙耳机出现音频播放卡顿的情况，影响用户体验。

为了提升终端设备在使用多种同频段无线通信方式时，多媒体数据传输的稳定性。本申请实施例首先会识别终端设备在使用目标通信方式传输多媒体数据的场景。在识别出该场景的基础上，一方面监测目标通信方式与同频段无线通信方式是否存在频段拥挤的情况，另一方面检测目标通信方式是否出现了数据传输卡顿。当检测到频段拥挤且多媒体数据传输出现卡顿时，则说明目标通信方式由于频段拥挤的原因，出现了多媒体数据传输卡顿。此时对于出现多媒体数据传输问题的无线通信方式，本申请实施例会动态的降低其对多媒体数据的编码码率，再进行相应的多媒体数据编码和传输。由于此时低码率的多媒体数据传输时所需的带宽更小，因此在与其他无线通信方式同频段数据传输的过程中，所受影响更小。使得无线通信方式可以更为顺畅的传输多媒体数据，稳定性更好，不易出现卡顿情况。在接收端多媒体数据可以流畅播放，从而提升用户使用体验。

本申请实施例提供的数据传输方法，可以适用于多种需要提升多媒体数据传输稳定性的场景。下面结合附图，对一些可能应用的场景进行说明。

参考图3，是本申请实施例提供的数据传输方法的流程实现图，详述如下：

S101，终端设备在使用目标通信方式传输多媒体数据的过程中，监测终端设备使用中的无线通信方式中，是否存在与目标通信方式同频段的同频通信方式。若检测到终端设备使用与目标通信方式同频段的同频通信方式，则执行S102。

其中，目标通信方式可选的确定方式包括至少两种：

确定方式1：技术人员可以根据实际需求，预先选定一种或多种无线通信方式。此时将这些预先选定的无线通信方式称为目标通信方式。

确定方式2：终端设备将进行多媒体数据传输的部分或全部无线通信方式作为目标通信方式。在一些可选实施例中可以设置为部分。例如可以预先设置一个包含一种或多种无线通信方式的通信方式清单。此时将所有进行多媒体数据传输，且属于该清单里的无线通信方式做为目标通信方式。清单的范围可由技术人员自行设置，此处不做限定。此时清单外的无线通信方式，无论是否有多媒体传输业务，或者多媒体数据传输是否卡顿，均不作为目标通信方式处理。

对于确定方式1，此时技术人员可以根据实际应用的需求，选择对终端设备支持或可能支持的部分无线通信方式进行数据传输优化。本申请实施例不对目标通信方式包含的具体无线通信方式做过多限定。且对于支持多种频段工作的无线通信方式，本申请实施例可以以单个频段作为独立的处理对象。即可以仅将其中工作在部分频段的该无线通信方式作为目标通信方式，而工作在其他频段的该无线通信方式则不作为目标通信方式。例如在一些可选实施例中，目标通信方式可以设置为仅蓝牙。而在另一些可选实施例中，目标通信方式可以设置为蓝牙和2.4GHz频段的Wi-Fi，此时5GHz频段的Wi-Fi则不作为目标无线通信方式。

实际应用中，每种无线通信方式都可以使用至少一种频段进行数据传输，有些无线通信方式甚至可以同时使用多种频段进行数据传输。例如一些双频Wi-Fi，可以同时使用2.4GHz和5GHz频段进行数据传输。因此首先需要对本申请实施例中的“同频段”进行说明：

在本申请实施例中，同频段是指不同无线通信方式使用的通信频段之间有重叠的频段。其中重叠包括部分频段相同和全部频段相同至少两种情况。以一实例进行举例说明，假设终端设备同时连接了蓝牙和2.4GHz频段的Wi-Fi，则此时蓝牙和Wi-Fi两种无线通信方式的频段相同，属于本申请实施例中的频段重叠情况，即为本申请实施例中的“同频段”。又假设终端设备在连接了蓝牙的基础上，同时连接了2.4GHz和5GHz的双频Wi-Fi。则此时蓝牙和Wi-Fi两种无线通信方式的部分频段相同，亦属于本申请实施例中的频段重叠情况，即为本申请实施例中的“同频段”。但若终端设备在连接了蓝牙的基础上，仅连接了5GHz的Wi-Fi。则此时蓝牙和Wi-Fi两种无线通信方式不存在频段重叠，因此此时则不属于“同频段”的两种无线通信方式。

在上述同频段标准的基础上，终端设备会检测自身同时使用的无线通信方式中，是否有与目标通信方式同频段的无线通信方式。为了便于说明，申请实施例将终端设备检测到的与目标通信方式同频段且处于使用中的无线通信方式，称为同频通信方式。并将目标通信方式所使用的频段称为目标频段。其中，本申请实施例不对具体监测范围和时机等操作细节做过多的限定，可由技术人员根据实际需求进行设定。例如，在一些可选实施例中，可以设定为每次新使用一种的无线通信方式时，对正在使用的所有无线通信方式逐一进行频段匹配，识别是否有同频段的无线通信方式。

作为本申请中进行同频段无线通信方式监测的一种可选实现方式。本申请实施例从监测的范围和时间方面，提供了几种可选的方案，以满足不同实际应用场景的需求。详述如下：

1、监测范围。

在本申请实施例中，提供以下几种可选的监测范围。实际操作时，技术人员可以根据实际需求来使用其中任意一种监测范围并进行相应的参数设置。在此基础上，终端设备在执行S101的操作时，可以不判断是否有与监测范围外的无线通信方式同频段的其他无线通信方式。此时S101可以被替换为：终端设备在使用目标通信方式传输多媒体数据的过程中，监测终端设备使用中的无线通信方式中，是否存在属于预设的监测范围内，且与目标通信方式同频段的同频通信方式。

监测范围(1)：终端设备使用的所有无线通信方式。

此时终端设备会对所有无线通信方式都进行同频段的监测，监测范围最大。因此可以适应各种实际场景的应用需求。

监测范围(2)：预先设定的多种无线通信方式。此时对预先设定之外的其他无线通信方式则不进行监测。

监测范围(3)：除预先设定的一种或多种无线通信方式之外，其他所有的无线通信方式。

此时对预先设定的一种或多种无线通信方式不进行监测。对预先设定之外的其他无线通信方式则进行监测。

在一些应用场景中，可能有减少同频段监测工作量，减少终端设备功耗等需求。为了满足该需求，在监测范围(2)和监测范围(3)中，技术人员可以选择性的仅针对部分无线通信方式进行监测。其中区别在于：监测范围(2)的针对性更强，可以针对终端设备可能的应用场景来制定所需监测的无线通信方式。监测范围(3)则可以用于排除一些技术人员认为无需监测的无线通信方式。例如在一些可选实施例中，当终端设备为可穿戴手表或者手机时，可以参考监测范围(2)设定仅对蓝牙和Wi-Fi进行监测，亦可以参考监测范围(3)设定不对蜂窝网络进行监测。其中，监测范围(2)和监测范围(3)中具体包含的无线通信方式，此处不做过多限定，可由技术人员根据需求设定。

其中，当采用监测范围(2)时，可以设置仅对一种无线通信方式进行监测。对于支持多种频段工作的无线通信方式，则可以设置仅对单个频段的该无线通信方式监测。例如可以设置目标通信方式为蓝牙，同频段的监测范围设置为：2.4GHz频段的Wi-Fi。

监测范围(4)：工作在预先设定的一种或多种频段内的所有无线通信方式。此时对工作在设定频段之外其他频段工作的无线通信方式，则不进行监测。

考虑到实际应用中，容易出现频段拥挤的频段数量有限。为了满足减少同频段监测工作量，减少终端设备功耗等需求。本申请实施例中，可以选择对部分频段内工作的无线通信方式进行监测。例如，在一些可选实施例中，可以设置对在2.4GHz频段和5GHz频段工作的无线通信方式进行监测。对于在2.4GHz频段和5GHz频段之外的频段工作的无线通信方式，则可以不进行监测。其中，监测范围(4)具体包含的频段，可由技术人员根据需求设定。对于确定方式1，则此时监测范围(4)中即为目标频段。

2、监测时机(亦可称为监测触发条件)。

在本申请实施例中，提供多种可选的监控时机，技术人员可以根据实际需求选取其中的一种或多种来作为实际监测时机设置。当满足对应的监测时机时，则执行S101的监测操作。此时S101可以被替换为：终端设备在使用目标通信方式传输多媒体数据的过程中，若监测到预设的监测触发条件，监测终端设备使用中的无线通信方式中，是否存在与目标通信方式同频段的同频通信方式。每种监控时机详述如下：

监测时机(1)：终端设备每次新使用无线通信方式。

在本申请实施例中，对于需要多个设备互连之后才能使用的无线通信方式。此时在终端设备通过这些无线通信方式与其他设备连接之后，即可认定为在使用这些无线通信方式。而对于一些无需多设备互连亦可使用的无线通信方式，则在终端设备开启这些无线通信方式之后，亦可认定为在使用这些无线通信方式。

监测时机(2)：切换或者新增无线通信方式使用的频段。

对于支持多种频段的无线通信方式而言，根据终端设备的软硬件配置，以及通信对端设备的软硬件配置。实际应用中可能会出现以下2种情况：

情况a、对于该无线通信方式，通信对端设备以支持多频通信的单个信号的方式对外提供通信服务。终端设备在连接该信号之后，终端设备和通信对端设备可以通过切换使用频段的方式，来实现该无线通信方式在不同频段上的数据传输。例如在一些应用场景中，无线路由器A可以发出一个支持2.4GHz和5GHz双频段的Wi-Fi信号。在此基础上，终端设备连接到该Wi-Fi信号之后，可以再通过切换频段的方式，使用2.4GHz频段和5GHz频段的Wi-Fi来传输数据。

情况b、对于该无线通信方式，通信对端设备针对该无线通信方式支持的每种频段，分别发出独立的信号，以对外提供通信服务。终端设备可以连接其中一种或多种信号，以实现对该无线通信方式在不同频段上的数据传输。例如在一些应用场景中，无线路由器A可以发出一个支持2.4GHz频段的Wi-Fi信号，以及一个支持5GHz频段的Wi-Fi信号。在此基础上，终端设备可以根据实际的需求，选择连接2.4GHz频段的Wi-Fi信号，或者连接5GHz频段的Wi-Fi信号，或者同时连接这两个信号。通过连接不同频段对应的信号，可以实现不同频段Wi-Fi的数据传输。

基于上述2种可能的应用情况，在本申请实施例中，可以将“出现切换或者新增一种使用中无线通信方式的频段”的情况，作为一种可选的监测时机。以灵活应对实际应用需求。

监测时机(3)：以预设的频率或时间间隔或时间点来执行S101的操作。

其中，具体的频段、时间间隔和时间点，可由技术人员根据实际需求自行设定，此处不做过多限定。

实际应用中，技术人员可以根据实际需求来选取或设定相应的监测范围和监测时机。既可以从本实施例中选取一种监测范围和任意种监测时机来实现对同频段无线通信方式的监测，亦可以仅选取一种监测范围，或者选择一种或多种监测时机来实现对同频段无线通信方式的监测。此处不做过多限定。

作为本申请的一个可选实施例，当S101未监测到使用同频段通信方式时，终端设备则可以根据监测时机的设置，继续执行S101的操作。直至检测到终端设备使用同频段通信方式，或者由于其他终端设备设置、用户操作或者其他设备交互等原因，停止对S101的操作。

S102，终端设备检测目标通信方式和同频通信方式是否存在频段拥挤。

在本申请实施例中，频段拥挤是指某一频段上传输的数据量较大，导致在该频段上传输数据的部分或全部无线通信方式，存在数据传输拥堵的情况。频段拥挤可能会导致无线通信方式在该频段上的数据传输速度变慢稳定性变差，容易出现数据丢包、重传、中断、出错等情况。

为了准确识别出终端设备在某一频段是否存在频段拥挤的情况。在本申请实施例中，可以针对性地分析终端设备在该频段内的数据传输业务情况。其中，本申请实施例不对具体频段拥挤的检测方法做过多限定，可由技术人员根据实际需求设定。例如，在一些可选实施例中，可以以终端设备在该频段内的数据传输任务总量为参考指标，并设置一个任务总量阈值。当数据传输总任务量超过任务量阈值时，则判定为存在频段拥挤的情况。

作为本申请中检测频段拥挤的一种可选实现方法，在本申请实施例中，提供了多种可选的参考指标以及对应的判断方案。实际应用中，技术人员可以根据需要进行选取和设置。对提供的方案1和方案2，详述如下：

方案1：检测使用该频段的无线通信方式，在该频段上的数据传输任务量是否较大。即检测目标通信方式和同频通信方式，在目标频段上的数据传输任务量是否较大。

在方案1中，终端设备会以同频段中所有使用该频段的无线通信方式为对象，进行数据传输任务量的分析。其中，分析的方式既可以是所有无线通信方式的数据传输任务总量是否较大，也可以是单种无线通信方式的数据传输任务量是否较大，亦可以是两者结合分析。例如，在一些可选实施例中，可以设定为：当检测出数据传输任务总量较大时，判定为该频段存在频段拥挤。在另一些可选实施例中，可以设定为：当检测出有无线通信方式的数据传输量较大时，判定为该频段存在频段拥挤。此时最少只要有一种无线通信方式的数据传输量较大即可。而在又一些可选实施例中，可以设定为：在检测出数据传输任务总量较大，和/或有一种或多种有无线通信方式的数据传输量较大时，判定为该频段存在频段拥挤。

其中，对于数据传输任务量是否较大的判断方法，本申请实施例不做过多限定。例如，在一些可选实施例中，可以针对所有无线通信方式的数据传输任务总量和单种无线通信方式的数据传输任务量，分别设置一个任务总量阈值和任务量阈值。在数据传输任务总量达到任务总量阈值时，判定所有无线通信方式的数据传输任务总量较大。在单种无线通信方式的数据传输任务量超过任务量阈值时，则判定该无线通信方式的数据传输任务量较大。其中任务总量阈值的具体数据，可由技术人员根据实际需求设置。而单种无线通信方式的任务量阈值，则可以由技术人员根据实际需求设置，或者，由终端设备中该无线通信方式对应的软硬件内置的参数确定。

作为本申请中对单种无线通信方式数据传输量是否较大判断的一种可选实现方式。可以基于该无线通信方式的实时吞吐率等参数指标，判断该无线通信方式实时数据传输量是否较大，并以此确定数据传输任务量是否较大。其中，本申请实施例不对具体实时数据传输量判断方法做过多限定，可由技术人员自行设定。例如在一些可选实施例中，可以选定一种或多种可以反映实时数据传输量的参数指标，并设置对应的指标阈值。实时该无线通信方式的这些参数指标是否超过对应的指标阈值，若超过则判定数据传输量较大，数据传输任务量较大。

作为本申请的一个可选实施例，当终端设备中单种无线通信方式对应的软硬件，具有独立判断数据传输任务量是否较大的功能或能力时。则前述对单种无线通信方式数据传输任务量是否较大的判断，可以交由单种无线通信方式对应的软硬件。此时技术人员可以不对具体的判断方法、判断条件和参考指标等做过多的设定。终端设备读取对应的软硬件判断结果即可。例如，假设终端设备中无线通信方式A对应的软硬件，可以自动判断无线通信方式A实时数据传输量是否较大，并可以主动将判断结果告知终端设备的主控。此时终端设备读取对应的判断结果即可。

方案2：筛选出终端设备中使用该频段且当前没有多媒体数据传输业务的无线通信方式，并检测这些无线通信方式在该频段上的数据传输任务量是否较大。即仅检测同频通信方式在目标频段上的数据传输任务量是否较大。

应当说明地，在本申请实施例中，即使某一无线通信方式具备多媒体数据传输能力，但在当前没有需要处理的多媒体数据传输业务的情况下，也会被视为没有多媒体数据传输业务。

在本申请实施例中，方案2和方案1的基本原理相同，因此对数据传输任务量是否较大的操作细节等说明，均可以参考前述对方案1的说明，此处不予赘述。此处仅对方案2与方案1的区别之处进行说明：

考虑到本申请实施例的目的是：终端设备在使用多种同频段无线通信方式时，提高目标通信方式对多媒体数据传输的稳定性。因此需要研究的是无多媒体数据传输业务的无线通信方式，对有多媒体数据传输业务的无线通信方式的影响。在此基础上，方案2针对的是当前没有多媒体数据传输业务的无线通信方式进行分析，以判断这些无线通信方式是否造成了判断拥挤的情况。即相对方案1而言，方案2分析数据传输任务量是否较大的对象针对性更强。

S103，终端设备在使用目标通信方式传输多媒体数据的过程中，检测目标通信方式对多媒体数据传输的卡顿情况。

实际应用中发现，频段拥挤不是一定就会造成多媒体数据卡顿。比如实际应用中可能目标通信方式本身就是造成频段拥挤的主要原因，其自身对多媒体数据的传输，反而可能没什么影响。又比如可能在频段拥挤的情况中，待传输的多媒体数据量本身就很小，频段拥挤对其影响极小或者没有影响，使得多媒体数据在传输过程并没有出现卡顿情况。基于这些实际情况的考量，本申请实施例在检测频段拥挤同时，还会检测目标通信方式是不是出现了多媒体数据传输卡顿的情况。

实际应用中数据传输卡顿的检测方式有多种，本申请实施例对此不做过多的限定，可由技术人员根据实际需求设定。例如，可以选择任意一种或多种可体现出数据传输卡顿情况的参数指标，并根据这些参数指标的情况来识别是否卡顿。如在一些可选实施例中，可以选择数据传输过程中的丢包率、数据包重传个数以及数据包被其他无线通信方式拒绝传输的次数作为参数指标，并预先设置对应的参数阈值。在检测出这些参数指标超出对应的参数阈值时，则判定为数据传输存在卡顿。

作为本申请的一个可选实施例。考虑到实际应用中，目标通信方式在频段拥挤的情况下传输多媒体数据时，较容易出现多媒体数据的数据包传输失败，导致多媒体数据传输卡顿的情况。此时则需要重传这些传输失败的数据包。因此数据包重传个数，能够较好的反映真实的多媒体数据传输实时卡顿情况。同时实际应用中，在多种无线通信方式使用同一频段进行数据传输时，正在使用该频段进行数据传输的无线通信方式，可以拒绝其他通信方式的数据传输请求。因此目标通信方式在频段拥挤的情况下传输多媒体数据时，也容易出现多媒体数据的数据包被其他无线通信方式拒绝传输(下文简称为数据包被拒绝传输)的情况，从而导致多媒体数据传输卡顿的情况。因此多媒体数据的数据包被其他无线通信方式拒绝传输的次数，也能够较好的反映真实的多媒体数据传输实时卡顿情况。基于这些实际情况考量，在本申请实施例中，选用多媒体数据数据包重传个数以及数据包被其他无线通信方式拒绝传输的次数作为参数指标，来进行多媒体数据传输卡顿的检测。此时S103可以被替换为：S1031和S1032。

S1031，终端设备获取在使用目标通信方式传输多媒体数据的过程中，获取多媒体数据的数据包重传个数，以及数据包被同频通信方式拒绝传输次数。

其中，本申请实施例不对终端设备在使用目标通信方式的过程中，具体目标通信方式传输的数据包重传个数以及数据包被拒绝传输次数的获取方式做过多限定。可由技术人员自行设定，或者根据实际应用情况确定。例如在一些可选实施例中，对于蓝牙而言，可以由终端设备中的蓝牙固件(即蓝牙芯片内的固话软件)定期主动上报包含这两项数据的信息。再由终端设备从上报信息中确定出最终的数据包重传个数以及数据包被拒绝传输次数。而对于其他无线通信方式，亦可以参考蓝牙的方式进行处理。由无线通信方式对应的软硬件进行主动上报，再由终端设备从上报信息中确定出最终的数据。

应当特别说明地，在本申请实施例中“多媒体数据的数据包重传个数，以及数据包被拒绝传输次数”的数据范围，可技术人员设定，或者由终端设备根据实际的应用情况确定。例如，考虑到两个参数指标均是统计后得到的数据。相应的，在一些可选实施例中，此时数据范围，可为数据统计时对应的统计时间范围。而在另一些可选实施例中，亦可由技术人员自行设定此时的数据范围，该范围可以与统计时间范围相同或不同。例如，假设终端设备每0.2秒统计一次前0.1秒内多媒体数据的数据包重传个数。若技术人员无特别设定，则此时数据包重传个数，可以是指终端设备最新获取到的，时间跨度为0.1秒的多媒体数据的数据包重传个数。而若技术人员有自行设定，则以自行设定的为准。如假设技术人员设定范围为1秒。则此时数据包重传个数，可以是指终端设备最新获取到的1秒内的多媒体数据的数据包重传个数。

S1032，终端设备根据获取到的数据包重传个数，以及数据包被同频通信方式拒绝传输次数，检测目标通信方式对多媒体数据传输的卡顿情况。

本申请实施例会针对数据包重传个数设置对应的个数阈值，对数据包被拒绝传输次数设置对应的次数阈值。在获取到数据包重传个数和数据包被拒绝传输的次数的基础上，本申请实施例会对这两个参数指标进行分析，判断是否大于对应的个数阈值或次数阈值。若大于，则可判定该参数指标较大。其中，具体的个数阈值和次数阈值大小，此处不做过多限定，可由技术人员根据需求自行设定。例如，在一些实施例中，若想提高对多媒体数据传输卡顿识别的灵敏度，则可以将个数阈值和次数阈值设置的较小。而在另一些实施例中，若想提高对多媒体数据传输卡顿识别的准确度，则可以将个数阈值和次数阈值设置的较大。

同时，根据参数指标是否较大，本申请实施例提供以下2种可选的判断多媒体数据卡顿情况的处理方案：

处理方案a：数据包重传个数较大，或者数据包被拒绝传输次数较多，均可判定为多媒体数据传输存在卡顿。

处理方案b：数据包重传个数较大，且数据包被拒绝传输次数较多，则可判定为多媒体数据传输存在卡顿。

在处理方案a中，单个参数指标即可作为多媒体数据传输卡顿的判断依据。因此对多媒体数据传输卡顿的检测灵敏度更高。而在处理方案b中，则需两个参数指标同时较大才能作为多媒体数据传输卡顿的判断依据。因此对多媒体数据传输卡顿的检测准确度更高。实际应用中，技术人员可以根据需求来自行选取或设定。此处不做过多限定。

作为本申请的一个可选实施例，目标通信方式对多媒体数据传输的卡顿情况，不仅可以分为存在卡顿和不存在卡顿2种情况。还可以针对不存在卡顿的情况细分为：正常传输和流畅传输。此时S103和S1032卡顿情况的检测结果则可分为3种(亦可称为3类检测结果)：存在卡顿、正常传输和流畅传输。其中，流畅传输是指当前多媒体数据的传输较为流畅，较少出现或没有出现传输问题，如较少出现或没有出现数据丢包、重传、中断、出错等问题。此时多媒体数据传输的稳定性较佳，对多媒体数据的传输能力存在一定的冗余度。参考图4，正常传输是介于存在卡顿和流畅传输之间的一种中间过渡情况。正常传输的情况下，多媒体数据传输存在一些传输问题，例如可能数据丢包、重传、中断、出错等问题中的一种或多种，但所存在的传输问题均不严重。对多媒体数据传输的稳定性正常。此时多媒体数据的接收端，对多媒体数据的接收和播放均可以正常进行。

终端设备在正常传输或流畅传输多媒体数据时，多媒体数据的接收端，对多媒体数据的接收和播放均可以正常进行。参考图4，其区别在于，正常传输的稳定性弱于流畅传输，对外部因素干扰的容忍度相对较弱。因此较容易受到外部因素的干扰，从正常传输转变为存在卡顿的情况。而终端设备在处于流畅传输多媒体数据的情况下，若受到外部因素的干扰，一般会先转变为正常传输的情况。若受到外部因素的干扰较大，也有可能会出现没有中间过渡的正常传输情况，而是转变为存在卡顿的情况。

以一实例进行示例说明，假设终端设备是手机，目标通信方式为蓝牙，同时手机还在使用2.4GHz频段的Wi-Fi上网。手机通过蓝牙与蓝牙耳机连接，通过蓝牙传输音频数据至蓝牙耳机，并通过蓝牙耳机来播放音频。此时若蓝牙对音频数据的传输存在卡顿，则蓝牙耳机对音频的播放也会出现卡顿的情况，如出现中断和断续等情况。而若蓝牙对音频数据正常传输或流畅传输，则蓝牙耳机对音频的播放则较为流畅，一般没有卡顿情况。此时对于正常传输的情况而言，若Wi-Fi传输的数据量变大，如用户需要下载一个大体积的文件。此时可能会导致手机对音频数据的传输卡顿，即变成存在卡顿的情况。但对于流畅传输的情况而言，若Wi-Fi传输的数据量变大。此时手机对音频数据的传输情况则先会向正常传输转变。

其中对于在卡顿情况检测过程中，存在卡顿的判断方法，可以参考S103、S1031和S1032中的相关说明，此处不予赘述。而对于正常传输和流畅传输，则可以在所使用的存在卡顿判断方法的基础上进行细化。例如，当选择单种可体现出数据传输卡顿情况的参数指标来识别卡顿情况时，可以设置上限参数阈值和下限参数阈值。当参数指标超出上限参数阈值时，判定为多媒体数据传输存在卡顿。当参数指标低于下限参数阈值时，判定为多媒体数据流畅传输。而当参数指标处于上限参数阈值和下限参数阈值之间时，判定为多媒体数据正常传输。又例如，当选择多种可体现出数据传输卡顿情况的参数指标来识别卡顿情况时，可以针对每种参数指标分别设置对应的上限参数阈值和下限参数阈值。并划分出存在卡顿、正常传输和流畅传输3种情况下，每种情况参数指标与上限参数阈值和下限参数阈值的大小关系。最后根据实际多种参数指标的值与上限参数阈值和下限参数阈值的大小关系，来确定多媒体数据卡顿情况。其中，各个阈值的具体大小，均可以技术人员根据实际需求设置，此处不予限定。

作为本申请中基于图4的一个可选实施例。为了实现对正常传输和流畅传输的识别，在S1031和S1032对应实施例的基础上，本申请实施例对S1032进行细化。其中，对数据包重传个数设置对应的上限个数阈值和下限个数阈值。对数据包被拒绝传输次数设置对应的上限次数阈值和下限次数阈值。相应的，处理方案a和处理方案b可以被细化为：处理方案a’和处理方案b’。

处理方案a’：

当数据包重传个数大于上限个数阈值，或者数据包被拒绝传输次数大于上限次数阈值时，判定为多媒体数据传输存在卡顿。

当数据包重传个数小于下限个数阈值，且数据包被拒绝传输次数小于下限次数阈值时，判定为多媒体数据流畅传输。

对于上述存在卡顿和流畅传输以外的情况，均可视为多媒体数据正常传输。

处理方案b’：

当数据包重传个数大于上限个数阈值，且数据包被拒绝传输次数大于上限次数阈值时，判定为多媒体数据传输存在卡顿。

当数据包重传个数小于下限个数阈值，且数据包被拒绝传输次数小于下限次数阈值时，判定为多媒体数据流畅传输。

对于上述存在卡顿和流畅传输以外的情况，均可视为多媒体数据正常传输。

S104，根据是否存在频段拥挤和目标通信方式对多媒体数据传输的卡顿情况，判断目标通信方式对多媒体数据传输稳定性。若稳定性较差，则执行S205的操作。

由对S103的说明可知，频段拥挤不一定会导致目标通信方式的多媒体数据传输卡顿。同时实际应用中发现，多媒体数据传输卡顿也不是一定因为同频段拥挤导致的。例如无线通信方式的网络信号不佳，也可能会导致多媒体数据传输卡顿。因此，本申请实施例会同时参考频段是否拥挤以及多媒体数据传输卡顿情况，两个维度的结果。当同时检测到频段拥挤且多媒体数据传输存在卡顿时，则说明目标通信方式由于频段拥挤的原因，出现了多媒体数据传输卡顿。此时可以判定出目标通信方式对多媒体数据传输的稳定性较差。

应当说明地，本申请实施例会不对频段拥挤检测和多媒体数据传输卡顿情况检测的顺序做过多限定，可由技术人员自行设定。例如可以设置一个S101和S103的先后执行顺序，亦可以选择同步执行。

S105，终端设备降低目标通信方式对应的多媒体数据编码码率。

S106，终端设备基于降低后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

为了提升对多媒体数据传输的稳定性。在检测出目标通信方式对多媒体数据传输稳定性较差的时候，本申请实施例会动态降低目标通信方式下对多媒体数据的编码码率。其中，降低编码码率，是指切换为比当前编码码率更低的编码码率。具体的编码码率切换方法，以及降低的码率幅度，此处均不做过多限定。可由技术人员根据实际需求设定。

在降低码率之后，终端设备会使用降低后的码率继续对未传输完成的多媒体数据进行编码，并继续使用原无线通信方式来传输，以实现对多媒体数据的稳定传输。

在本申请实施例中，技术人员可以根据需求预先设定一种或多种需要进行多媒体数据传输优化的目标通信方式。或者从在进行数据传输任务的无线通信方式中选取出一种或多种目标通信方式。在此基础上，终端设备在使用目标通信方式传输多媒体数据的过程中，会识别是否有与目标通信方式同频段的同频通信方式。并检测目标通信方式是否出现了数据传输卡顿。在识别出有同频的场景基础上，再监测目标通信方式和同频通信方式是否存在频段拥挤的情况。当检测到频段拥挤且目标通信方式多媒体数据传输出现卡顿时，则说明目标通信方式由于频段拥挤的原因，出现了多媒体数据传输卡顿。此时对于出现多媒体数据传输问题的目标通信方式，本申请实施例会动态的降低其对多媒体数据的编码码率，再进行相应的多媒体数据编码和传输。由于此时低码率的多媒体数据传输时所需的带宽更小，因此在同频通信方式同频段数据传输的过程中，所受影响更小。使得目标通信方式可以更为顺畅的传输多媒体数据，稳定性更好，不易出现卡顿情况。在用户侧，接收端中的多媒体数据可以流畅的播放，从而提升用户使用体验。

相对确定方式2，当采用确定方式1来确定目标通信方式时，对所需优化的目标通信方式针对性更强。可以快速检测和优化目标通信方式，检测更加自由且灵活的更高，从而减少了终端设备对多媒体数据传输优化的工作量，减少终端设备的功耗。更适合一些功耗控制需求较高的终端设备，如手机、平板电脑等移动终端以及智能手表、智能眼镜等可穿戴设备。

作为本申请的一个可选实施例。在S104判断出多媒体数据传输稳定性较差时，图3所示实施例会降低对多媒体数据的编码码率，以提高传输的稳定性。而由对S103、S1031和S1032的说明可知，实际应用中终端设备在某一频段中无论是否出现频段拥挤，目标通信方式对多媒体数据传输都有可能出现卡顿或者不存在卡顿的情况。因此在S105降低对多媒体数据的编码码率之后，若频段中的带宽资源被释放，使得目标通信方式在该频段中可以不存在卡顿的传输多媒体数据。则此时持续低码率的数据传输无法充分利用释放的带宽资源，同时用户侧也无法使用较高质量的多媒体数据。为了能给用户带来稳定且较高质量的多媒体数据使用效果。参考图3，本申请实施例还包括：S107和S108。

若S103中检测出目标通信方式对多媒体数据传输无卡顿，则执行S107。

在本申请实施例中，对于多媒体数据传输卡顿情况的分类可以有以下两种：

分类1：将多媒体数据传输卡顿情况分为：存在卡顿和不存在卡顿，共2种情况。此时可以将不存在卡顿的情况，视为目标通信方式对多媒体数据传输无卡顿，并执行S107的操作。

分类2：在分类1的基础上，将不存在卡顿的情况细分为多种情况，并将细分出的多种情况中的某一种或多种情况，定义为无卡顿的情况。例如可以参考图4所示实施例，将不存在卡顿的情况细分为正常传输和流畅传输。在此基础上，可以将“流畅传输”情况，定义为本申请实施例中的无卡顿情况。相应的，在S103检测出目标通信方式对多媒体数据流畅传输时，则视为目标通信方式对多媒体数据传输无卡顿，并执行S107的操作。

其中，对于存在卡顿、不存在卡顿、正常传输和流畅传输的判断方法，可参考S103、S1031、S1032和图4所示实施例的相关说明，此处不做过多说明。例如对于分类1，可以设置针对参考指标设置单个参数阈值，并利用单个参数阈值来划分存在卡顿和不存在卡顿2种情况。对于分类2，可以参考图4所示实施例中，关于处理方案a’和处理方案b’的说明进行处理。

S107，终端设备提高目标通信方式对应的多媒体数据编码码率。

S108，终端设备基于提高后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

在检测出目标通信方式对多媒体数据传输无卡顿的时候，本申请实施例会动态提高目标通信方式下对多媒体数据的编码码率。其中，提高编码码率，是指切换为比当前编码码率更高的编码码率。具体的编码码率切换方法，以及提高的码率幅度，此处均不做过多限定。可由技术人员根据实际需求设定。在提高码率之后，终端设备会使用提高后的码率继续对未传输完成的多媒体数据进行编码，并继续使用原无线通信方式来传输。

本申请实施例通过在发现终端设备因频段拥挤导致多媒体数据传输卡顿时，及时降低对多媒体数据的编码码率。而在发现多媒体数据传输无卡顿时，又及时提高对多媒体数据的编码码率。从而实现了根据实际多媒体数据传输情况，对多媒体数据编码码率的动态调整。在提高无线通信方式对多媒体数据传输的稳定性基础上，本申请实施例还可以充分适应和利用频段的带宽资源，实现多媒体数据传输稳定性和传输质量的动态平衡。最终实现在使用多种同频段无线通信方式时，能稳定传输较高质量的多媒体数据的效果。因此可以极大地提升用户端对多媒体数据的感官体验，提升最终的用户体验。

作为本申请中基于S107和S108所示实施例的一个可选实施例，在分类2：将不存在卡顿的情况细分为多种情况，并将细分出的多种情况中的某一种或多种情况定义为无卡顿的情况的基础上。本申请实施例对于存在卡顿和无卡顿以外的情况，都可以视为当前对多媒体数据的传输处于正常情况。此时在传输稳定性和传输质量两个维度上平衡较好，实现对频段带宽资源情况的自适应和充分利用。因此对于传输处于正常的情况可以不执行S105或S107的操作，而是继续维持当前使用的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。例如可以将本申请实施例与图4所示实施例结合，并将“流畅传输”情况定义为本申请实施例中的无卡顿情况，将“正常传输”情况定义为本申请实施例中的传输处于正常的情况。此时可以参考图3，对于检测出目标通信方式对多媒体数据正常传输的情况，则执行：S109，终端设备维持当前使用的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

本申请实施例在动态降低和提高多媒体数据编码码率的基础上，增加了一种在多媒体数据传输正常时保持编码码率不变的中间情况。因此本申请实施例可以降低终端设备对多媒体数据编码码率的切换频率。使得整体对多媒体数据的传输质量更加平稳。用户在接收端接收和使用多媒体数据时，对多媒体数据的感官体验也更加平稳自然，进而提升用户体验。

同时，本申请实施例通过同步监测目标通信方式频段拥挤和卡顿情况，且卡顿情况可以在使用目标通信方式的过程中自由执行。从而使得本申请实施例的卡顿情况检测操作灵活性更高，对提高或保持多媒体数据编码码率的灵活性也更高。在提升对多媒体数据传输稳定性的同时，还有利于提升对多媒体数据的传输质量。

应当特别说明地，实际应用中，若在检测目标通信方式对多媒体数据传输卡顿情况时，使用的参数指标是统计才能得到的数据(下文简称为统计数据)。例如S1031和S1032对应的实施例，利用统计出的多媒体数据的数据包重传个数以及数据包被拒绝传输次数，来检测目标通信方式对多媒体数据传输卡顿情况。由于统计数据具有一定的滞后性，因此若对无线通信方式的多媒体数据传输情况检测的频率较高，可能会导致终端设备对多媒体数据编码码率的切换频率较高的情况。而在多媒体数据传输正常时保持编码码率不变，可以避免由于统计数据滞后性造成的多媒体数据编码码率切换频率较高的情况。从而使得本申请实施例可以提升对多媒体数据传输卡顿情况的改善效果，使得多媒体数据的传输更加稳定且传输质量更加平稳。例如在一些实施例中，当传输的多媒体数据为音频数据时。本申请实施例的应用，一方面在存在卡顿时及时降低音频数据传输码率，可以使得终端设备对音频数据的传输稳定性提升，使得音频数据传输卡顿更少。另一方面由于编码码率切换频率较低且可控，还可以使得输出的音频数据的音质更加平稳，不会频繁的降低或提高音频数据的音质，使得用户侧的感官体验更加平稳自然。

另外，在本说明书内的各个实施例之间也可以进行组合，从而得到新的实施例。同时组合得到的实施例的操作原理、操作细节和有益效果等，均可以参考组合前各个实施例的相关说明，此处不予赘述。

作为本申请的一个可选实施例，对于上述需要调整多媒体数据编码码率的实施例。在本申请实施例中，对码率的提高或降低，可以是逐档调整，即每次仅提高或降低一个档位的码率。亦可以是跨档调整，即每次提高或降低多个档位的码率。可由技术人员根据实际需求进行选取调整多媒体数据编码码率的方式。其中当选择跨档调整的方式时，则还可以设定对应跨档的方案，如每次提高或降低多少个档位。

以一实例进行举例说明。假设目标通信方式为蓝牙，且终端设备对蓝牙传输的数据有一档码率、二挡码率和三挡码率，共3个档位的编码码率。其中一档码率最低，二挡码率其次，三挡码率最高。在此基础上，假设终端设备当前使用的是二挡码率来编码蓝牙传输的多媒体数据，设置采用逐档调整。则此时可以根据需求将编码码率提高至三挡码率，或者降低至一档码率。假设终端设备当前使用的是一挡码率来编码蓝牙传输的多媒体数据，设置采用跨档调整，且每次跨档调整的单位为2个档。此时所需要提高多媒体数据编码码率，则可以将编码码率由一挡码率提高至三挡码率。

需要特别说明地，本说明书中的所有实施例仅用以说明本申请的技术方案，而非对其限制。尽管参照本说明书的实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

例如在上述方法实施例中，对于终端设备对是否存在同频通信方式的监测步骤、是否存在频段拥挤的检测步骤以及对多媒体数据传输卡顿情况的检测步骤。实际应用中，在没有逻辑冲突的情况下，也可以采用与上述各个实施例不同的顺序执行这三个步骤。例如在图3所示实施例的基础上，可以参考图5，将“是否存在同频段通信方式的监测步骤”和“是否存在频段拥挤的检测步骤”一起执行，并合并成一个步骤。此时可以将S101和S102合并为：S100。

S100，终端设备在使用目标通信方式传输多媒体数据的过程中，从终端设备使用中的无线通信方式中，检测出与目标通信方式同频段且存在频段拥挤的同频通信方式。

作为本申请的一个可选实施例，为了实现对是否使用了同频通信方式的检测。在预先选定好目标通信方式、目标频段以及对同频通信方式的检测范围的基础上。可以针对每种可能的同频通信方式，确定其在使用时，终端设备所需使用的对应接口。此时可以通过判断终端设备是否使用了对应接口的方式，来确定是否使用了该接口对应的同频通信方式。

例如，假设设定目标通信方式为蓝牙，同频通信方式的监测范围仅包含2.4GHz频段的Wi-Fi。由于终端设备在使用2.4GHz频段的Wi-Fi，和使用5GHz频段的Wi-Fi时，所使用的接口不同。因此可以通过确定终端设备实际是否使用了2.4GHz频段的Wi-Fi对应的接口，来判断是否使用了与蓝牙同频段的2.4GHz频段的Wi-Fi。其中作为一个可选实施例，当使用了Wi-Fi接口时，亦可以从接口传输的数据内解析判断实际Wi-Fi的工作频段。当接口传输的数据内解析出该接口使用的是2400MHz-2478MHz频段工作时，可以判定为是2.4GHz频段的Wi-Fi对应的接口。

亦可以将S103对多媒体数据传输卡顿情况的检测步骤置于S101对是否存在同频无线段通信方式的监测步骤之后。此时终端设备在S201监测到同频无线段通信方式之后，再执行S102和S103。S103则可以对应修改为：检测目标通信方式对多媒体数据传输的卡顿情况。

以下以终端设备是移动终端为例，结合实例对图5所示实施例进行示例说明。

用户同时使用移动终端中的2.4GHz频段的蓝牙和2.4GHz频段的Wi-Fi，是一种较为常见的使用场景。例如用户在使用手机的蓝牙连接蓝牙耳机，并使用蓝牙耳机听音乐或者打电话的同时，还可以使用手机连接2.4GHz频段的Wi-Fi，用来看在线视频或下载文件等。由于单频段的带宽资源有限，而Wi-Fi业务的数据交互量一般又较大，比较占带宽资源。从而导致实际使用场景中，很容易出现频段内剩余的带宽不够蓝牙使用，使得蓝牙的多媒体数据传输稳定性较差，蓝牙耳机出现音频播放卡顿的情况。

在本申请实施例中，设定目标通信方式为蓝牙。为了解决上述问题，终端设备会监测蓝牙对多媒体数据传输的卡顿情况。并根据实际卡顿情况，来动态调整移动终端对多媒体数据的编码码率，再利用蓝牙进行传输。从而使得本申请实施例中终端设备可以自适应蓝牙传输情况，来实现对蓝牙传输多媒体数据稳定性的提升。

假设终端设备在使用2.4GHz频段的蓝牙向蓝牙耳机传输音乐数据、使用2.4GHz频段的Wi-Fi开始下载一个大体积的游戏安装包，同时使用13.56MHz频段的NFC刷门禁。同时假定以下条件：

频段拥挤的判断方案为：有没有多媒体数据传输业务的无线通信方式的数据传输任务量是否较大。其中，蓝牙耳机支持LDAC编码方案，终端设备可以以LDAC编码方案支持的330kbps、660kbps和990kbps共三挡码率，对音乐数据进行编码并使用蓝牙进行传输。对编码码率的调整方案为逐档调整。将多媒体数据卡顿情况分为：存在卡顿、正常传输和流畅传输。同频通信方式的监测范围为仅包含2.4GHz频段的Wi-Fi。

在本申请实施例中，步骤“Sxxx’”与图5中的步骤“Sxxx”一一对应，属于图5的步骤在具体场景下的具体内容。为了便于与图5所示实施例区分，因此对各个步骤也进行了对应的区分命名。例如，在本申请实施例中步骤S101’对应着图5所示实施例中的步骤S101，步骤S102’对应着步骤S102，以此类推。由于每个步骤的操作原理、操作细节和有益效果等，均已在图3至图5所示实施例中进行说明，因此本申请实施例不予赘述。具体可参考图3至图5所示实施例的相关说明。本申请实施例仅对部分必要的细节进行说明。本申请实施例包括：

S100’，终端设备在使用蓝牙传输音乐数据的过程中，检测所使用Wi-Fi是否存在与蓝牙同频段，且存在频段拥挤情况。

此时可以通过检测终端设备所使用的的Wi-Fi接口，来判断是否为2.4GHz频段的Wi-Fi。

由于本申请实施例的场景中，Wi-Fi刚开始下载一个大体积的游戏安装包。即Wi-Fi数据传输任务量较大。因此此时可以判定为蓝牙和Wi-Fi存在频段拥挤。

S103’，终端设备在使用蓝牙传输音乐数据的过程中，检测蓝牙对音乐数据的传输卡顿情况。若卡顿情况为正常传输，则执行S109’的操作。若卡顿情况为流畅传输，则执行S107’和S108’的操作。

在本申请实施例中，可以选择将音乐数据的数据包重传个数以及数据包被Wi-Fi拒绝传输的次数作为参数指标，来判断蓝牙对音乐数据的卡顿情况。

S104’，终端设备根据蓝牙和Wi-Fi是否存在频段拥挤，以及蓝牙对音乐数据的传输卡顿情况，判断蓝牙对音乐数据传输稳定性。若稳定性较差则执行S105’。

S105’，终端设备降低一档对音乐数据的编码码率。

S106’，终端设备基于降低一档后的编码码率对音乐数据进行编码，并使用蓝牙向蓝牙耳机传输编码后的音乐数据。

假设在执行S105’时，终端设备使用的实时编码码率为990kbps。则此时本申请实施例会切换为低一档的码率660kbps对音乐数据进行编码和传输。

S109’，终端设备维持当前使用的编码码率对音乐数据进行编码，并使用蓝牙向蓝牙耳机传输编码后的音乐数据。

S107’，终端设备提高一档对音乐数据的编码码率。

S108’，终端设备基于提高一档后的编码码率对音乐数据进行编码，并使用蓝牙向蓝牙耳机传输编码后的音乐数据。

假设在在执行S107’时，终端设备使用的实时编码码率为330kbps。则此时本申请实施例会切换为高一档的码率660kbps对音乐数据进行编码和传输。

在本申请实施例中，终端设备根据蓝牙和Wi-Fi涉外频段拥挤情况，以及蓝牙对音乐数据的传输卡顿情况，自适应地动态调整对音乐数据传输时的编码码率。在提升对音乐数据传输稳定性的同时，还可以实现较为平稳地输出适宜频段带宽资源情况的较高音质的音乐数据。因此通过本申请实施例，即使在终端设备使用多种同频段无线通信方式的情况下，用户仍可以在蓝牙耳机侧听到传输稳定、音质较高，且音质相对平稳的音乐数据。

以下以终端设备是移动终端为例，结合另一实例对图5所示实施例进行示例说明。

在本申请实施例中，设定目标通信方式为蓝牙。为了解决2.4GHz频段的蓝牙和2.4GHz频段的Wi-Fi同时使用时，蓝牙传输音乐数据稳定性差，传输卡顿的问题，终端设备会监测蓝牙对多媒体数据传输的卡顿情况。并根据实际卡顿情况，来动态调整移动终端对多媒体数据的编码码率，再利用蓝牙进行传输。从而使得本申请实施例中终端设备可以自适应蓝牙传输情况，来实现对蓝牙传输多媒体数据稳定性的提升。

此处先对本申请实施例中可能涉及到的一些名词进行说明如下：

Wi-Fi模块：移动终端中提供Wi-Fi功能的软硬件模块总称。

蓝牙耳机(BT headset)：利用蓝牙方式进行通信，并可以播放音频的耳机。本申请实施例对蓝牙耳机的耳机类型、支持的编解码方案等均不做限定。

蓝牙固件(BT firmware)：写入于移动终端蓝牙芯片中的固化软件。

编码器(Encoder)：特指移动终端中蓝牙对应的编码器，用于对蓝牙所需传输数据进行编码的虚拟功能模块。实际应用中，需根据移动终端与蓝牙耳机实际使用的编解码方案来确定具体的编码器类型。例如，当移动终端与蓝牙耳机采用LDAC编解码方案时，则编码器为LDAC编码器。

蓝牙主机(BT host)：即移动终端的处理器。

蓝牙音频接口：移动终端内部负责蓝牙音频数据传输的虚拟接口。在一些手机中，蓝牙音频接口可以命名为bt_a2dp_hw。其中，hw是硬件Hardware的缩写。

音频模块(AUDIO)：移动终端中管理音频的软硬件模块总称。在一些实施例中，亦可以是移动终端的音频芯片。

在本申请实施例中，假设目标通信方式设置为蓝牙，同频通信方式的监测范围设置为2.4GHz频段的Wi-Fi。同时假设蓝牙传输的多媒体数据为音频数据。将蓝牙对音频数据的卡顿情况分为三种：存在卡顿、正常传输和流畅传输。且在编码器在调整对音频数据的编码码率时，每次调整一个码率档位。

可以参考图6，是移动终端在与蓝牙耳机进行通信，使用蓝牙耳机播放音频时的常规流程示意图，说明如下：

步骤1、音频模块将原始音频数据的流数据分成音频数据包发给蓝牙音频接口。

步骤2、蓝牙音频接口将音频数据包发给编码器。

步骤3、编码器对音频数据包进行编码，并将编码后的音频数据包发给蓝牙固件。

步骤4、蓝牙固件将编码后的音频数据包发给蓝牙耳机。

由上述说明可知，一般情况下，编码器在对音频数据传输的过程中，无法获知当前传输是否发生了卡顿，也无法得知蓝牙是否有与其他无线通信方式发生频段拥挤。因此，在一般的蓝牙通信过程中，移动终端无法很好的应对频段拥挤导致的蓝牙传输卡顿的情况。

参考图7，是本申请实施例提供的数据传输方法的流程示意图，详述如下：

S300，在移动终端使用蓝牙传输音频数据的过程中，音频模块将音频数据发送给蓝牙音频接口。

本申请实施例将音频数据、音频数据的流数据以及音频数据包等，统称为音频数据。

S301，蓝牙音频接口将音频数据发给编码器。

S302，在移动终端使用蓝牙传输音频数据的过程中，Wi-Fi模块判断是否连接了2.4GHz频段的Wi-Fi。若连接了2.4GHz频段的Wi-Fi，则执行S303。

此时可以通过识别Wi-Fi传输所使用的接口的方式，确定是否连接了2.4GHz频段的Wi-Fi。

S303，Wi-Fi模块检测Wi-Fi与蓝牙是否存在频段拥挤。并在检测到Wi-Fi与蓝牙存在频段拥挤时，将检测结果告知蓝牙主机。

由于Wi-Fi模块是提供Wi-Fi功能的软硬件模块，对Wi-Fi的连接情况以及数据传输情况等数据监测直接高效。因此本申请实施例中，可以由移动终端中的Wi-Fi模块负责监测2.4GHz频段的Wi-Fi是否连接，以及是否存在频段拥挤的判断。从而可以降低移动终端对2.4GHz频段的Wi-Fi监测的功耗。

其中，关于频段拥挤的判断方法此处不做限定。例如在一些实施例中，可以由Wi-Fi模块根据Wi-Fi的数据吞吐率等指标是否超过预设的阈值，来判断Wi-Fi的数据交互量是否过大。即是否在做大流量的数据交互。若数据吞吐率等指标超过预设的阈值，则判定为数据交互量大，存在频段拥挤。

作为本申请的一个可选实施例，S303对Wi-Fi与蓝牙是否存在频段拥挤的检测，亦可以不交由Wi-Fi模块，而是交由移动终端中的其他软硬件模块处理。例如可以交给移动终端处理器来处理。相应的，此时S303的执行主体可以修改为移动终端处理器。

在S303交由移动终端处理器来处理时，对频段拥挤的判断方法可以有更多种。例如既可以利用Wi-Fi的数据吞吐率等指标是否超过预设的阈值，来判断是否存在频段拥挤。亦可以识别移动终端的业务场景中，Wi-Fi传输的数据量是否较大。若较大则判定为存在频段拥挤。其中Wi-Fi传输的数据量是否较大的判断标准此处不予限定，包括但不限于如设定一个数据量阈值，并在Wi-Fi传输的数据量大于该数据量阈值时判定为存在频段拥挤。

S304，在移动终端使用蓝牙传输音频数据的过程中，蓝牙固件获取音频数据的数据包重传个数以及数据包被Wi-Fi拒绝传输的次数，并将数据包重传个数以及数据包被Wi-Fi拒绝传输的次数发给蓝牙主机。

在本申请实施例中，采用音频数据的数据包重传个数以及数据包被Wi-Fi拒绝传输的次数，来判断蓝牙对音频数据的传输卡顿情况。其中，为了实现对两个数据的获取，蓝牙固件可以读取本地的LOG_ID_STATS_ACT_CONN信息。作为LOG_ID_STATS_ACT_CONN信息的一个示例。该信息中包含音频数据的数据包重传个数(LocalReturns)，以及被数据包被Wi-Fi拒绝传输的次数(CxmDenials)。

在读取到LOG_ID_STATS_ACT_CONN信息之后，蓝牙固件可以选择先解析其中的数据包重传个数以及数据包被Wi-Fi拒绝传输的次数，再将解析出的2个数据信息上报给蓝牙主机。亦可以选择将该信息上报给蓝牙主机。此时S305中蓝牙主机可以通过自行解析该信息来获得数据包重传个数以及数据包被Wi-Fi拒绝传输的次数。作为本申请的一个可选实施例，可以将蓝牙固件上报的信息称为event信息。

S305，蓝牙主机根据数据包重传个数以及数据包被Wi-Fi拒绝传输的次数，判断蓝牙对音频数据的传输卡顿情况。若检测到卡顿情况为存在卡顿，执行S306。若检测到卡顿情况为正常传输，则向编码器下发命令保持对音频数据的编码码率。若检测到卡顿情况为流畅传输，则向编码器下发命令提高对音频数据的编码码率。

本申请实施例会针对数据包重传个数设置对应的上限个数阈值和下限个数阈值，对数据包被拒绝传输次数设置对应的上限次数阈值和下限次数阈值。蓝牙主机在接收到或通过协议栈解析event信息得到数据包重传个数以及数据包被Wi-Fi拒绝传输的次数之后，会对这两个参数指标进行分析，判断与对应的次数阈值和个数阈值关系。

当数据包重传个数大于上限个数阈值，且数据包被拒绝传输次数大于上限次数阈值时，判定为音频数据传输存在卡顿。

当数据包重传个数小于下限个数阈值，且数据包被拒绝传输次数小于下限次数阈值时，判定为音频数据流畅传输。

对于上述存在卡顿和流畅传输以外的情况，均可视为音频数据正常传输。

当检测出存在卡顿时，则继续判断对音频数据的传输稳定性。而在检测到流畅传输时，则说明此时对音频数据的传输稳定性较好，频段内带宽资源可能较为充裕。因此此时会编码器向下发命令提高对音频数据的编码码率，以提高音频数据传输质量。

其中，本申请实施例不对上限个数阈值、下限个数阈值、上限次数阈值和下限次数阈值的具体取值做限定，可由技术人员根据实际需求设置。例如在一些可选实施例中，上限个数阈值可以设置为300到500中的任一值，下限个数阈值可以设置为50到200中的任一值。上限次数阈值可以设置为200到400中的任一值，下限次数阈值可以设置为50到100中的任一值。

S306，蓝牙主机若接收到Wi-Fi与蓝牙存在频段拥挤的检测结果，且检测到卡顿情况为存在卡顿，则向编码器下发命令降低对音频数据的编码码率。

在本申请实施例中，将同频段的无线通信方式存在频段拥挤，导致其中的目标通信方式对多媒体数据传输存在卡顿，传输稳定性较差的情况，称为共存卡顿。蓝牙主机在确定出当前存在共存卡顿的情况时，为了提高对音频数据传输稳定性，会向编码器下发命令降低对音频数据的编码码率。

S307，编码器根据接收到的蓝牙主机发送的命令，确定对音频数据的编码码率。若命令为降低音频数据的编码码率，则将当前对音频数据的编码码率降低一个档位。若命令为保持音频数据的编码码率，则将保持当前对音频数据的编码码率。若命令为提高音频数据的编码码率，则将当前对音频数据的编码码率提高一个档位。

S308，编码器根据确定出的编码码率，对蓝牙音频接口发送的音频数据进行编码，并将编码后的音频数据发送至蓝牙固件。

编码器在接收到蓝牙主机下发的命令之后，根据具体命令要求来确定是否调整对音频数据的编码码率，以及如果要调整的话，该如何调整对音频数据的编码码率。

应当说明地，本申请实施例不对移动终端与蓝牙耳机采用的编解码方案做过多限定，支持多种编码码率的编解码方案均可以。包括但不限于如：SBC、AAC、APTX和LDAC等编解码方案。本申请实施例以采用LDAC编解码方案，编码器为LDAC编码器为例进行说明：

LDAC编码方案支持的330kbps、660kbps和990kbps共三挡码率。支持LDAC编解码方案的蓝牙耳机，为了实现音频数据的无损压缩，往往会使用990kbps的码率进行数据编码，此时需要的带宽为990KB。当Wi-Fi传输数据量较大时，由于2.4GHz频段带宽有限，留给蓝牙的带宽有时不足990KB，此时蓝牙的音频数据会出现一个时隙传输不完，传输卡顿的情况。

在S307中，根据LDAC编码器当前使用编码码率的情况，可以有以下几种操作：

当接收到的命令为降低音频数据的编码码率时。若当前使用的是990kbps码率，则将编码码率调整为660kbps。若当前使用的是660kbps码率，则将编码码率调整为330kbps。

当接收到的命令为提高音频数据的编码码率时。若当前使用的是660kbps码率，则将编码码率调整为990kbps。若当前使用的是330kbps码率，则将编码码率调整为660kbps。

当接收到的命令为保持音频数据的编码码率。则无需当前编码码率。

在再确定出所需使用的编码码率之后，编码器再采用该编码码率对音频数据进行编码并发给蓝牙固件。

S309，蓝牙固件将接收到的编码后的音频数据发送至蓝牙耳机。

蓝牙耳机根据接收到的音频数据进行解码和音频播放。

在本申请实施例中，通过动态调整蓝牙对应的音频数据编码码率。一方面可以在共存卡顿的情况降低编码码率下，减少音频数据传输对频段带宽的需求，从而提高音频数据传输稳定性。另一方面，又可以在流畅传输的时候提高编码码率，从而充分利用频段带宽资源，提高音频数据传输质量。此外，在正常传输的时候保持当前编码码率，以防止频繁调整编码码率，导致传输的音频数据质量不稳定，用户体验不佳的情况出现。因此本申请实施例在有同频段Wi-Fi传输干扰的情况下，可以有效的实现蓝牙对音频数据稳定且相对较高质量的传输。

作为本申请的又一实施例，在应用上述各个方法实施例时，终端设备的操作可以包括：

S401，终端设备基于第一码率，通过蓝牙向蓝牙设备传输音频数据。

其中，第一码率是终端设备实时使用的编码码率。终端设备通过第一码率对音频数据进行编码，并通过蓝牙将编码后的音频数据发送至蓝牙设备(即本申请实施例中的接收端)。蓝牙设备是具有蓝牙功能的电子设备通称，实际应用中可以是蓝牙耳机、蓝牙音响等。

S402，终端设备在通过蓝牙传输音频数据的过程中，通过2.4GHz频段的Wi-Fi进行数据传输。

S403，终端设备检测到由于Wi-Fi导致蓝牙对音频数据传输失败。

在本申请实施例中，终端设备对蓝牙和Wi-Fi的硬件模块可以是相互独立的，亦可以是同一模块。例如可以使用一个无线通信模块来同时支持蓝牙和Wi-Fi。以单个无线通信模块同时支持蓝牙和Wi-Fi为例。当Wi-Fi在2.4GHz频段内传输的数据量较大时，无线通信模块可以不发送蓝牙传输音频数据。此时无线通信模块还可以上报终端设备，此时蓝牙被Wi-Fi拒绝传输音频数据。终端设备即可判定检测到由于Wi-Fi导致蓝牙对音频数据传输失败。例如，在一些实施例中，可以从LOG_ID_STATS_ACT_CONN信息中解析出音频数据的数据包被Wi-Fi拒绝传输次数，并在该次数较大时判定为检测到由于Wi-Fi导致蓝牙对音频数据传输失败。

S404，终端设备基于第二码率，通过蓝牙向蓝牙设备传输音频数据。其中，第二码率低于第一码率。

在确定出蓝牙所需传输的音频数据，被Wi-Fi拒绝传输导致传输失败后。终端设备会降低对音频数据的编码码率，再传输音频数据。其中，第二码率具体值此处不做限定，小于第一码率即可。

实际应用中，技术人员可以在终端设备传输音频数据的过程中，对终端设备和蓝牙设备进行空中接口抓包，分析蓝牙所使用的音频数据编码码率。例如一些使用场景中，可以抓取hci log等信息，并从中确定出蓝牙所使用的音频数据编码码率，从而确定出实际使用的第一码率和第二码率。

对应于上文实施例所述的数据传输方法，图8示出了本申请实施例提供的数据传输装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

对应于图3至图7，参照图8，该数据传输装置包括：

拥堵检测模块81，用于在终端设备使用目标通信方式传输多媒体数据的过程中，在终端设备使用与目标通信方式通信频段相同的同频通信方式时，检测目标通信方式与同频通信方式的数据传输拥堵情况：目标通信方式与同频通信方式均为无线通信方式。

卡顿检测模块82，用于在终端设备使用目标通信方式传输多媒体数据的过程中，检测目标通信方式对多媒体数据传输的卡顿情况：

码率调整模块83，用于在检测到数据传输拥堵情况为存在数据传输拥堵，且卡顿情况为存在卡顿时，降低对多媒体数据的编码码率。

编码传输模块84，用于基于降低后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

作为本申请的一个可选实施例，拥堵检测模块81，具体用于：

获取同频通信方式的数据传输任务量，并根据数据传输任务量和预设的任务量阈值，检测目标通信方式与同频通信方式的数据传输拥堵情况。

作为本申请的一个可选实施例，卡顿检测模块82，包括：

参数获取模块，用于获取多媒体数据的数据包重传个数以及数据包被同频通信方式拒绝传输次数。

卡顿检测子模块，用于根据获取到的数据包重传个数和数据包被同频通信方式拒绝传输次数，检测目标通信方式对多媒体数据传输的卡顿情况。

作为本申请的一个可选实施例，卡顿检测子模块，具体用于：

在数据包重传个数大于预设的上限个数阈值，且数据包被同频通信方式拒绝传输次数大于预设的上限次数阈值，则判定目标通信方式对多媒体数据传输的卡顿情况为存在卡顿。

作为本申请的一个可选实施例，码率调整模块83，还用于：

在检测到卡顿情况为无卡顿时，提高对多媒体数据的编码码率。

编码传输模块84，还用于基于提高后的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

作为本申请的一个可选实施例，码率调整模块83，还用于：

在检测到卡顿情况为正常传输时，保持当前使用的编码码率。

编码传输模块84，还用于基于当前使用的编码码率对多媒体数据进行编码，并使用目标通信方式传输编码后的多媒体数据。

作为本申请的一个可选实施例，目标通信方式为2.4GHz频段的蓝牙，同频通信方式为2.4GHz频段的Wi-Fi。

参数获取模块，具体用于：

获取LOG_ID_STATS_ACT_CONN信息，并从LOG_ID_STATS_ACT_CONN信息中解析出多媒体数据的数据包重传个数以及数据包被Wi-Fi拒绝传输次数。

本申请实施例提供的两种数据传输装置中各模块实现各自功能的过程，具体可参考前述图3至图7所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

图9是本申请一实施例提供的终端设备的结构示意图。如图9所示，该实施例的终端设备9包括：至少一个处理器90(图9中仅示出一个)、存储器91，所述存储器91中存储有可在所述处理器90上运行的计算机程序92。所述处理器90执行所述计算机程序92时实现上述各个数据传输方法实施例中的步骤，例如图3所示的步骤S101至S109。或者，所述处理器90执行所述计算机程序92时实现上述各装置实施例中各模块/单元的功能，例如图8所示模块82至84的功能。

所述终端设备9可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器90、存储器91。本领域技术人员可以理解，图9仅仅是终端设备9的示例，并不构成对终端设备9的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器90可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器91在一些实施例中可以是所述终端设备9的内部存储单元，例如终端设备9的硬盘或内存。所述存储器91也可以是所述终端设备9的外部存储设备，例如所述终端设备9上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(SecureDigital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器91还可以既包括所述终端设备9的内部存储单元也包括外部存储设备。所述存储器91用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器91还可以用于暂时地存储已经发送或者将要发送的数据。

另外，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种终端设备，所述终端设备包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端设备实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

Claims (11)

1.一种数据传输方法，其特征在于，应用于终端设备，所述终端设备在使用目标通信方式传输多媒体数据的过程中，包括：

若所述终端设备使用与所述目标通信方式通信频段相同的同频通信方式，则检测所述目标通信方式与所述同频通信方式的数据传输拥堵情况：所述目标通信方式与所述同频通信方式均为无线通信方式；

检测所述目标通信方式对所述多媒体数据传输的卡顿情况：

若检测到所述数据传输拥堵情况为存在数据传输拥堵，且所述卡顿情况为存在卡顿，则降低对所述多媒体数据的编码码率；

基于降低后的所述编码码率对所述多媒体数据进行编码，并使用所述目标通信方式传输编码后的所述多媒体数据。

2.根据权利要求1所述的数据传输方法，其特征在于，所述检测所述目标通信方式与所述同频通信方式的数据传输拥堵情况，包括：

获取所述同频通信方式的数据传输任务量，并根据所述数据传输任务量和预设的任务量阈值，检测所述目标通信方式与所述同频通信方式的所述数据传输拥堵情况。

3.根据权利要求1所述的数据传输方法，其特征在于，所述检测所述目标通信方式对所述多媒体数据传输的卡顿情况，包括：

获取所述多媒体数据的数据包重传个数以及数据包被所述同频通信方式拒绝传输次数；

根据获取到的所述数据包重传个数和所述数据包被所述同频通信方式拒绝传输次数，检测所述目标通信方式对所述多媒体数据传输的所述卡顿情况。

4.根据权利要求3所述的数据传输方法，其特征在于，所述根据获取到的所述数据包重传个数和所述数据包被所述同频通信方式拒绝传输次数，检测所述目标通信方式对所述多媒体数据传输的卡顿情况，包括：

若所述数据包重传个数大于预设的上限个数阈值，且所述数据包被所述同频通信方式拒绝传输次数大于预设的上限次数阈值，则判定所述目标通信方式对所述多媒体数据传输的卡顿情况为所述存在卡顿。

5.根据权利要求1至4任一所述的数据传输方法，其特征在于，在所述检测所述目标通信方式对所述多媒体数据传输的卡顿情况之后，还包括：

若检测到所述卡顿情况为无卡顿，则提高对所述多媒体数据的编码码率；

基于提高后的所述编码码率对所述多媒体数据进行编码，并使用所述目标通信方式传输编码后的所述多媒体数据。

6.根据权利要求5所述的数据传输方法，其特征在于，在所述检测所述目标通信方式对所述多媒体数据传输的卡顿情况之后，还包括：

若检测到所述卡顿情况为正常传输，则基于当前使用的编码码率对所述多媒体数据进行编码，并使用所述目标通信方式传输编码后的所述多媒体数据。

7.根据权利要求3所述的数据传输方法，其特征在于，所述目标通信方式为2.4GHz频段的蓝牙，所述同频通信方式为2.4GHz频段的Wi-Fi；

所述获取所述多媒体数据的数据包重传个数以及数据包被所述同频通信方式拒绝传输次数，包括：

获取LOG_ID_STATS_ACT_CONN信息，并从所述LOG_ID_STATS_ACT_CONN信息中解析出所述多媒体数据的所述数据包重传个数以及数据包被所述Wi-Fi拒绝传输次数。

8.一种数据传输方法，其特征在于，应用于终端设备，包括：

所述终端设备基于第一码率，通过蓝牙向接收端传输音频数据；

所述终端设备在通过所述蓝牙传输所述音频数据的过程中，通过2.4GHz频段的Wi-Fi进行数据传输；

若由于所述Wi-Fi导致所述蓝牙对所述音频数据传输失败，则所述终端设备基于第二码率，通过所述蓝牙向所述接收端传输所述音频数据，其中，所述第二码率和所述第一码率均为所述终端设备对所述音频数据的编码码率，且所述第二码率低于所述第一码率。

9.一种终端设备，其特征在于，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至7任一项所述方法的步骤，或者实现根据权利要求8所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1至7任一项所述方法的步骤，或者实现根据权利要求8所述方法的步骤。

11.一种芯片系统，其特征在于，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至7任一项所述的数据传输方法，或者实现根据权利要求8所述方法的步骤。

Images