用于IOS的拾音识别方法及系统与流程

本发明涉及智能语音领域，尤其涉及一种用于ios的拾音识别方法及系统。

背景技术：

目前市面上有很多在ios系统上通过ble外设进行音频采集并通过云端进行语音识别的app，对于app在前台时，这个功能没有任何阻碍点，但是当app退回到后台时，无论是音频采集还是云端识别都会遇到很多阻碍点。

通常会有以下解决办法：

1、仅支持前台交互：app在前台与ble外设进行连接，然后发送指令，进行音频数据传输，云端语音识别，app进入后台，ble断开连接，数据传输中断。

2、音频文件保存到本地：app在前台与ble外设进行连接，然后发送指令，进行音频数据传输，当app进入后台，获取的音频保存到本地，下次打开app，重新上传云端进行识别。

3、同时支持前台和后台交互：app在前台与ble外设进行连接，当进入后台时，为了保证网络在不断开，比较常用的有两种方式，一种是需要设置当前音频采集模式为录音模式，这种模式能保证在后台时网络能正常连接不断开，还有一种是用一段空白音频在后台不停播放，这两种方式都是利用了ios系统的特性，实现app保活，无论是app在前台还是后台都可以发送指令，进行音频数据传输，语音识别。

在实现本发明过程中，发明人发现相关技术中至少存在如下问题：

1、仅支持前台的交互方案：

app在前台与ble外设进行配对连接，连接上之后就可以发送蓝牙指令，传输音频数据，app端开启websocket连接，在获取音频数据时将数据传输到云端进行语音识别，获取到识别的文字进行保存展示或者是播报，所有操作都是在前台操作，app一旦退出，蓝牙就会断开，所有操作都会终止。只能用于前台交互，进入后台就无法进行拾音并进行音频上传识别，具有很强的局限性。

2、音频文件保存到本地方案：这种方式针对一些需要实时播报识别结果，以及后台需要实时对话的场景不适用，纯粹作为一种拾音方式，功能的扩展性不强。

3、同时支持前台和后台交互方案：app在前台与ble外设进行配对连接，连接上之后就可以发送蓝牙指令，传输音频数据。这个时候app为了保证后台还能连接着websocket，获取服务端的数据，会选择两种方式。第一种方式是设置当前音频采集模式为录音模式，在这种模式下ios系统会把app当作在前台一样处理，不会断开websocket连接，但是这种模式很耗电，而且在手机上方会出现蓝色的提示条，标示现在有app采用这种模式在后台运行。第二种方式是在后台用一段空白音频循环播放，这是利用了ios系统的一个特点，在后台有音频播放时，websocket连接也是不会断开的。但是这种方式也很耗电，而且如果本身就有app有播放音频的需求，会出现逻辑混乱的情况，但是无论是设置当前音频采集模式为录音模式或者是空白音频循环播放，都有缺陷，如耗电大，体验差，容易逻辑混乱，app内需要做很多兼容性逻辑，不是最佳方案。

技术实现要素：

为了至少解决现有技术中已有几种模式的缺陷的问题。

第一方面，本发明实施例提供一种用于ios的拾音识别方法，包括：

响应于ble外设连接，为所述ble外设提供usesbluetoothleaccessories后台运行模式，以实现对所述ble外设进行系统级保存；

每次接收到所述ble外设发送的音频数据，都需要检测与服务端的websocket是否连接，在ios系统预设时间内，进行websocket重连并将所述音频数据发送至所述服务端；

获取所述服务端确定的音频识别结果进行存储，不进行与ui相关的逻辑处理；

当切换回前台时，基于所述音频识别结果刷新所述ui，以展示音频识别结果。

第二方面，本发明实施例提供一种用于ios的拾音识别系统，包括：

后台模式程序模块，用于响应于ble外设连接，为所述ble外设提供usesbluetoothleaccessories后台运行模式，以实现对所述ble外设进行系统级保存；

传输程序模块，用于每次接收到所述ble外设发送的音频数据，都需要检测与服务端的websocket是否连接，在ios系统预设时间内，进行websocket重连并将所述音频数据发送至所述服务端；

存储程序模块，用于获取所述服务端确定的音频识别结果进行存储，不进行与ui相关的逻辑处理；

ui刷新程序模块，用于当切换回前台时，基于所述音频识别结果刷新所述ui，以展示音频识别结果。

第三方面，提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明任一实施例的用于ios的拾音识别方法的步骤。

第四方面，本发明实施例提供一种存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现本发明任一实施例的用于ios的拾音识别方法的步骤。

本发明实施例的有益效果在于：本方法解决app在后台无法获取拾音数据以及无法转写的痛点，实现了只要app连接着ble外设，无论在前台还是后台，app都能获取到音频数据，以及进行实时转写。在这种方案下，所有数据都能完整保存到服务端，而且可以根据需求，做很多变种。

附图说明

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

图1是本发明一实施例提供的一种用于ios的拾音识别方法的流程图；

图2是本发明一实施例提供的一种用于ios的拾音识别方法的ble外设配对流程图；

图3是本发明一实施例提供的一种用于ios的拾音识别方法的后台流程图；

图4是本发明一实施例提供的一种用于ios的拾音识别方法的websocket检测流程图；

图5是本发明一实施例提供的一种用于ios的拾音识别方法的前台流程图；

图6是本发明一实施例提供的一种用于ios的拾音识别系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示为本发明一实施例提供的一种用于ios的拾音识别方法的流程图，包括如下步骤：

s11：响应于ble外设连接，为所述ble外设提供usesbluetoothleaccessories后台运行模式，以实现对所述ble外设进行系统级保存；

s12：每次接收到所述ble外设发送的音频数据，都需要检测与服务端的websocket是否连接，在ios系统预设时间内，进行websocket重连并将所述音频数据发送至所述服务端；

s13：获取所述服务端确定的音频识别结果进行存储，不进行与ui相关的逻辑处理；

s14：当切换回前台时，基于所述音频识别结果刷新所述ui，以展示音频识别结果。

在本实施方式中，通过长时间大量的试验测试以及对日志进行分析发现，现有技术中大部分开发者认为ios系统的保活是保证app在后台时能跟在前台一样工作，这是一种很普遍的而且是很典型的一种误解，在这种想法局限下，会尝试当前音频采集模式为录音模式或者是空白音频循环播放这种方案。而本方法考虑到应用程序在前台和应用程序在后台两个部分使用不同的工作方式。

如图2所示，为ble外设与应用配对连接的过程，以及连接上ble之后的绑定characteristic的逻辑，绑定成功之后，外设与应用app就能通信了。这部分的功能是一个基础功能，无论是前台后台都需要执行这个步骤。

对于步骤s11，ble(bluetoothlowenergy，蓝牙低功耗)外设在保持同等通信范围的同时显著降低功耗和成本。如图3所示，为了实现拾音识别，预先准备好app程序来搭载本方法，同时可以与ble外设以及流服务、asr服务等连接通信。用户在使用时，操作都是再此app上。

对于设备后台模式，这是ios的一种机制，如果app需要在后台与ble外设进行通信，需要勾选一个usesbluetoothleaccessories，实现逻辑中对当前连接上的ble外设进行系统级保存。

对于步骤s12，ble外设开始录音，会发开启录音的结果给ios系统中的app，app接收到指令之后开启websocket连接，与流服务、asr服务等进行连接，并发送连接成功的结果到ble外设，这样就可以继续通信。

ble外设开始发送音频数据到app，app在每次接收到ble外设发送的音频数据，都需要检测websocket是否连接着，这个流程如图4所示，如果websocket连接着，则发送音频数据到服务端(流服务、asr服务)，如果websocket已断开，则需要重连websocket，这个重连以及数据发送必须要在ios系统预设时间内完成，具体来说，这个时间为10s。如果过了这个时间，网络连接不上数据也会发送失败。重连上之后开始发送数据，同时服务端将识别结果返回到app。这个流程是每次接收到设备发送过来的音频数据必不可少的执行步骤。

对于步骤s13，服务端在处理完成后，确定ble外设拾音的识别结果，此时，如果服务端将识别结果发送给app时，app会对识别结果进行获取，获取到识别结果后，会将识别结果的数据保存在app或服务端，此时处于后台，不能做任何有关ui更改的逻辑，例如，数字的更改，颜色的变化等。如果app在后台频繁更新ui，app会被ios系统杀掉。

对于步骤s14，在经过一个完整的数据发送流程，ble外设结束录音，同时将结束录音指令发送给app。app在接收到结束录音的指令之后，断开websocket连接，返回结果给设备，此时，如果app回到前台，会根据服务端的识别结果的数据或者保存在app内的识别结果的数据来刷新ui，展示所有结果。

通过该实施方式可以看出，本方法解决app在后台无法获取拾音数据以及无法转写的痛点，实现了只要app连接着ble外设，在后台时，app都能获取到音频数据，以及进行实时转写。在这种方案下，所有数据都能完整保存到服务端，而且可以根据需求，做很多变种。比如，跟siri一样，在后台接收到音频进行服务端识别之后，进行播报，从而实现app在后台对话功能；比如录音笔通过这种方案可以实时后台录音转写等。

作为一种实施方式，在本实施例中，所述方法还包括：

当在usesbluetoothleaccessories后台运行模式中，不获取所述服务端确定的音频识别结果进行存储时，响应于切换回前台时，接收所述服务端传输的音频识别结果；

基于所述音频识别结果刷新所述ui，以展示音频识别结果。

在本实施方式中，考虑到另一种方式来应对不同的场景，例如，不需要对识别结果进行下一步处理的场景。在这种场景下，当在usesbluetoothleaccessories后台运行模式中，

在接收到ble外设的音频数据时，可以只将音频数据传输到服务端，服务端不返回音频的处理结果，也就不获取所述服务端确定的音频识别结果。等app到前台后，再对识别结果进行统一获取，以及统一处理展示，这种方式的处理更为简洁。

通过该实施方式可以看出，这种方式实现逻辑更为简单，并且数据处理速度更加快速，提高效率。

作为一种实施方式，在本实施例中，在所述后台运行模式中，来自ble外设的音频数据需要从主线程通信。

在本实施方式中，来自ble外设的音频数据需要从主线程返回，考虑到ios系统中，后台最多有10min，所有的网络连接以及子线程都会被杀掉。这样进一步地从主线程考虑，避免了在后台拾音时app被系统杀掉。

作为一种实施方式，在本实施例中，所述方法还包括：

在切换至前台后，接收ble外设发送的音频数据，通过websocket连接将所述音频数据发送至服务端；

接收所述服务端确定的音频识别结果，基于所述音频转写结果刷新所述ui，以展示音频转写结果。

在本实施方式中，还考虑了前台模式，如图5所示为app在前台的流程图，以下对各流程详细说明：

1、app内开启录音，ble外设接收到录音指令，进入录音模式，返回开启结果到app；

2、app接收到结果，开启websocket连接，与流服务、asr服务建立连接；

3、ble外设开始录音，不停的传输音频到app；

4、app接收到音频，结果处理之后，传输到服务端中；

5、服务端在进行音频处理之后，将识别结果返回app；

6、在经过一次完整的数据传输和识别之后，app发送结束录音指令给ble外设，ble外设返回结果到app；

7、app断开websocket的连接。

在整个ble外设传输音频给app，app传输给服务器的过程中，app与服务端的websocket是一直连接着的，所以整个过程比较稳定。

通过该实施方式可以看出，本方法解决app前台时拾音识别，确保了拾音识别的稳定，提供所有数据都能完整保存到服务端，而且可以根据需求，做很多变种。

如图6所示为本发明一实施例提供的一种用于ios的拾音识别系统的结构示意图，该系统可执行上述任意实施例所述的用于ios的拾音识别方法，并配置在终端中。

本实施例提供的一种用于ios的拾音识别系统10包括：后台模式程序模块11，传输程序模块12，存储程序模块13和ui刷新程序模块14。

其中，后台模式程序模块11用于响应于ble外设连接，为所述ble外设提供usesbluetoothleaccessories后台运行模式，以实现对所述ble外设进行系统级保存；传输程序模块12用于每次接收到所述ble外设发送的音频数据，都需要检测与服务端的websocket是否连接，在ios系统预设时间内，进行websocket重连并将所述音频数据发送至所述服务端；存储程序模块13用于获取所述服务端确定的音频识别结果进行存储，不进行与ui相关的逻辑处理；ui刷新程序模块14用于当切换回前台时，基于所述音频识别结果刷新所述ui，以展示音频识别结果。

进一步地，所述系统还用于：当在usesbluetoothleaccessories后台运行模式中，不获取所述服务端确定的音频识别结果进行存储时，响应于切换回前台时，接收所述服务端传输的音频识别结果；

基于所述音频识别结果刷新所述ui，以展示音频识别结果。

进一步地，在所述后台运行模式中，来自ble外设的音频数据需要从主线程通信。

进一步地，所述系统还用于：在切换至前台后，接收ble外设发送的音频数据，通过websocket连接将所述音频数据发送至服务端；

接收所述服务端确定的音频识别结果，基于所述音频转写结果刷新所述ui，以展示音频转写结果。

本发明实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的用于ios的拾音识别方法；

作为一种实施方式，本发明的非易失性计算机存储介质存储有计算机可执行指令，计算机可执行指令设置为：

响应于ble外设连接，为所述ble外设提供usesbluetoothleaccessories后台运行模式，以实现对所述ble外设进行系统级保存；

每次接收到所述ble外设发送的音频数据，都需要检测与服务端的websocket是否连接，在ios系统预设时间内，进行websocket重连并将所述音频数据发送至所述服务端；

获取所述服务端确定的音频识别结果进行存储，不进行与ui相关的逻辑处理；

当切换回前台时，基于所述音频识别结果刷新所述ui，以展示音频识别结果。

作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本发明实施例中的方法对应的程序指令/模块。一个或者多个程序指令存储在非易失性计算机可读存储介质中，当被处理器执行时，执行上述任意方法实施例中的用于ios的拾音识别方法。

非易失性计算机可读存储介质可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据装置的使用所创建的数据等。此外，非易失性计算机可读存储介质可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，非易失性计算机可读存储介质可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本发明实施例还提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明任一实施例的用于ios的拾音识别方法的步骤。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备:这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括:pda、mid和umpc设备等，例如平板电脑。

(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)其他具有数据处理功能的电子装置。

在本文中，术语“包括”、“包含”，不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。