通知消息的语音播报方法、装置、终端及存储介质

技术领域

本申请实施例涉及人机交互技术领域，特别涉及一种通知消息的语音播报方法、装置、终端及存储介质。

背景技术

在用户不方便查看通知消息时，通过语音播报的方式对通知消息进行播报是一种合适的交互方式。

相关技术中，将通知消息转换为语音主要是通过获取通知消息的文本描述信息，再通过语音转换技术将文本描述信息转换为语音信息，向用户进行播报。

然而，在实际应用中，采用相关技术向用户进行通知消息的语音播报往往无法向用户准确传达通知消息所展现的内容。

发明内容

本申请实施例提供了一种通知消息的语音播报方法、装置、终端及存储介质。所述技术方案如下：

一方面，本申请提供了一种通知消息的语音播报方法，所述方法包括：

对通知消息的消息内容以及所述通知消息的消息来源进行特征提取，得到所述通知消息的第一通知语义特征；

在所述通知消息包含结构化图形用户界面的情况下，对所述结构化图形用户界面中界面元素的元素属性信息进行特征提取，得到所述通知消息的第二通知语义特征；

基于所述第一通知语义特征以及所述第二通知语义特征，生成所述通知消息对应的消息提示文本；

对所述消息提示文本进行语音播报。

另一方面，本申请提供了一种通知消息的语音播报装置，所述装置包括：

第一特征提取模块，用于对通知消息的消息内容以及所述通知消息的消息来源进行特征提取，得到所述通知消息的第一通知语义特征；

第二特征提取模块，用于在所述通知消息包含结构化图形用户界面的情况下，对所述结构化图形用户界面中界面元素的元素属性信息进行特征提取，得到所述通知消息的第二通知语义特征；

文本生成模块，用于基于所述第一通知语义特征以及所述第二通知语义特征，生成所述通知消息对应的消息提示文本；

语音播报模块，用于对所述消息提示文本进行语音播报。

另一方面，本申请实施例提供了一种终端，所述终端包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如上述方面所述的通知消息的语音播报方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条程序代码，所述程序代码由处理器加载并执行以实现如上述方面所述的通知消息的语音播报方法。

另一方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的通知消息的语音播报方法。

本申请实施例中，终端通过对通知消息的消息内容、消息来源以及结构化图形用户而界面的元素属性信息进行特征提取，分别得到第一通知语义特征以及第二通知语义特征，进而得到通知消息的提示文本，向用户进行语音播报，一方面能够提取通知消息中的关键信息，使得提示文本尽量简洁且能够准确向用户传达通知消息的内容，另一方面，也能将一结构化图形用户界面形式的通知消息中离散的、割裂的信息整合成连贯、自然的文本描述，更利于用户理解通知消息。

附图说明

图1示出了本申请一示例性实施例提供的通知消息的语音播报方法的流程图；

图2示出了本申请一个示例性实施例提供的结构化图形用户界面展示的通知消息的示意图；

图3示出了本申请一示例性实施例提供的生成描述文本过程的流程图；

图4示出了本申请一示例性实施例提供的对得到第二通知语义特征的过程的流程图；

图5示出了本申请一示例性实施例提供的通知消息界面的示意图；

图6示出了本申请一示例性实施例提供的语音交互过程的流程图；

图7示出了本申请一个实施例提供的通知消息的语音播报装置的结构框图；

图8示出了本申请一个示例性实施例提供的终端的结构方框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

需要说明的是，本申请实施例均是在语音播报程序被触发后终端执行的，对于触发语音播报程序的方式本申请不进行限定。并且，本申请采集的所有结构化图形用户界面的数据都是在用户同意并授权的情况下进行采集的，且相关的用户数据的收集、使用和处理需要遵守国家和地区的相关法律法规和标准。

图1示出了本申请一示例性实施例提供的通知消息的语音播报方法的流程图，该方法包括：

步骤101，对通知消息的消息内容以及通知消息的消息来源进行特征提取，得到通知消息的第一通知语义特征。

终端需要向用户展示通知消息前，会先获取该通知消息的通知来源以及消息内容等信息，主要包括系统消息、用户消息、以及第三方消息等，通知消息的内容是指通知消息的文本内容，而消息来源是指通知来源的属性信息，包括应用类型、用户的历史应用记录等，例如，通知来源是新闻应用，终端在构建通知消息前能够获取到该通知消息的应用类型为新闻，过去一个月内用户历史应用频次为30次，用户历史适用时段为8:00-9:00。

终端获取到通知消息的消息内容以及消息来源后，对不同的内容采用不同的方式进行编码，可选的，对于消息内容可以采用文本编码的方式进行编码，对于消息来源中可以采用独热编码的方式对其进行编码。对二者分别进行编码后，将二者的编码结果拼接起来，得到通知消息对应的消息编码向量。

得到通知消息对应的消息编码向量后，终端可以通过Transformer模型、构造评估函数、skip-gram模型等方式进行特征提取，得到通知消息的第一语义特征。

可选的，终端通过Transformer模型进行特征提取，将消息编码向量输入Transformer模型中，依次通过编码器框架和解码器框架，其中每个编码器框架及解码器框架均由多个独立的特征提取器堆叠而成，最初输入的消息编码向量通过编码器框架后，能够得到一个矩阵或向量，该矩阵或向量类似于对消息编码向量的一个编码。解码器结构较为灵活，可根据具体应用场景不同对矩阵或向量进行解码，输出的结果即为通知消息的第一语义特征。

步骤102，在通知消息包含结构化图形用户界面的情况下，对结构化图形用户界面中界面元素的元素属性信息进行特征提取，得到通知消息的第二通知语义特征。

在实际应用中，终端可能会以结构化图形用户界面的形式展示，因此，只通过第一语义特征生成的消息提示文本可能无法准确清晰的表达通知消息所要崭新的内容，因此需要提取整个结构化图形用户界面的元素属性信息，并对他们进行特征提取，得到各个元素对应的元素语义信息，再将多个元素语义信息进行融合，即可得到通知消息的第二通知语义特征。

步骤103，基于第一通知语义特征以及第二通知语义特征，生成通知消息对应的消息提示文本。

其中消息提示文本用于描述通知消息中的关键信息。

终端获取到第一通知语义特征以及第二通知语义特征后，先将二者进行特征融合，再利用文本生成和文本摘要的方式生成该通知消息的消息提示文本。

可选的，采用从数值到文本的文本生成技术对结构化图形用户界面的语义特征进行处理，载利用文本摘要算法进行简化，最终生成消息提示文本。

步骤104，对消息提示文本进行语音播报。

终端生成消息提示文本后，会对消息提示文本的内容进行语音播报，在一种可能的实施方式中，终端通过TTS(Text To Speech，从文本到语音)技术将消息提示文本转换成语音信号。TTS主要包含语音分析以及声学系统两部分，语言分析主要是根据输入的消息提示文本的文字信息进行分析，对文本结构与语种进行判断，在将文本进行标准化处理随后将文本转换为音素，最后进行句读韵律预测；声学系统部分则是根据语言分析处理的结果，生成对应的音频，实现将消息提示文本转换成语音信号的功能。

如图2所示，对于第一通知消息201，终端在生成消息提示文本后，对该消息提示文本进行语音播报内容为：“收到一条航班助手信息。您所乘坐的东航MU5332次航班预计7月17日07:15从深圳宝安T3出发，预计09:35到达上海浦东T1。值机柜台为E01-E18，登机口为F28”。在用户乘坐的飞机降落后，通知消息会变为第二通知消息202。对于图2中的第二通知消息202，终端生成的消息提示文本为：“收到一条航班助手信息。您所乘坐的东航MU5332次航班已于09:35到达上海浦东T1，飞行时间为2小时20分，飞行距离1343KM，行李转盘为26”。

综上所述，本申请实施例中，终端通过对通知消息的消息内容、消息来源以及结构化图形用户而界面的元素属性信息进行特征提取，分别得到第一通知语义特征以及第二通知语义特征，进而得到通知消息的提示文本，向用户进行语音播报，一方面能够提取通知消息中的关键信息，使得提示文本尽量简洁且能够准确向用户传达通知消息的内容，另一方面，也能将一结构化图形用户界面形式的通知消息中离散的、割裂的信息整合成连贯、自然的文本描述，更利于用户理解通知消息。

终端获取到第一通知语义特征以及第二通知语义特征后，会将二者进行特征融合，得到通知消息的语义融合特征。

其中融合可以为直接融合也可以进行加权融合，可以采用的融合方法包括最大融合、MFB(Multimodal Factorized Bilinear pooling，多模态双线性矩阵分解池化方法)以及人工神经网络法等。

终端得到语义融合特征后，会将语义融合特征输入文本生成模型，得到通知消息对应的描述文本。

其中，文本生成模型具有文本生成以及文本摘要的功能，由文本生成架构和文本摘要架构共同构成了第一文本生成模型，将语义融合特征输入第一文本生成模型后，首先经过文本生成架构进行处理，初步生成一个与通知消息内容对应的初步描述文本，再将其输入文本摘要架构，将初步描述文本的内容进行简化，最终得到通知消息对应的第一描述文本。

在实际应用中，通过一个文本生成模型对语义融合特征进行文本生成与文本摘要处理，对于文本生成模型的处理能力要求较高，可能无法达到最佳的效果。因此，终端可以通过两个文本生成模型依次对语义融合特征进行文本生成和文本摘要的处理，以达到更好的文本处理效果。

终端获取到描述文本后，会基于描述文本，生成通知消息对应的消息提示文本。具体包含以下两种方式：

方式一，将描述文本第一消息提示模板结合，即可得到通知消息对应的消息提示文本。

其中，第一消息模板是简单的文字模板，用于将描述文本以更符合自然语言对话的方式展现出来，例如，第一消息模板为：“收到一条XXX消息。...”其中，“XXX”用于填充消息来源的名称，“...”用于填充通知消息对应的描述文本。

基于第一描述文本，生成通知消息对应的消息提示文本，就是将第一描述文本与第一消息模板相结合，得到通知消息对应的消息提示文本。

方式二，确定结构化图形用户界面中的可交互元素，从可交互元素的元素属性信息中提取可交互元素的元素描述文本；通过第二消息提示模板对描述文本以及元素描述文本进行拼接，得到消息提示文本。

通常情况下，通知消息的结构化图形用户界面中会包含部分可交互的元素，想用户进行语音播报时，也可以将这些可交互元素通过消息提示文本向用户进行传达，便于用户进行下一步的操作。

先确定结构化图形用户界面中的可交互元素，可以通过获取结构化图形用户界面视图树，读取视图树中的元素属性信息，通过读取元素属性信息中是否具有可交互属性，来判断该界面元素是否是可交互元素，可交互属性包括可点击属性以及可输入属性等。

再从可交互元素的元素属性信息中提取可交互元素的元素描述文本。其中，描述文本包括该界面元素的可见文本属性(即Text属性)以及非可见文本属性(即ContentDescription属性)。其中，Text属性是用户可见的，以文字形式显示在结构化图形用户界面的文本，ContentDescription属性是开发者写在界面元素内部的属性，用于描述界面元素功能的文本，是结构化图形用户界面中不可见的，开发者为使界面美观而将部分文本隐藏到ContentDescription文本属性中。

最后通过第二消息提示模板对描述文本以及元素描述文本进行拼接，得到消息提示文本。其中，第二消息提示模板是指简单的连接文本，用于拼接描述文本以及元素描述文本，例如，一个第二消息提示模板为：“收到一条XXX消息。...。如需进一步操作可以说***”，其中“XXX”用于填充消息来源的名称，“...”用于填充通知消息对应的描述文本，“***”用于填充可交互元素的描述文本。例如，终端针对图2中第一通知消息201所生成的一种消息提示信息为：“收到一条航班助手信息。您所乘坐的东航MU5332次航班预计7月17日07:15从深圳宝安T3出发，预计09:35到达上海浦东T1。值机柜台为E01-E18,登机口为F28。如需进一步操作，你可以说航班助手、查看订单、预定酒店”。

下面将通过一个示例性实施例对结合终端通过两个文本生成模型得到描述文本的过程进行说明。

图3示出了本申请一示例性实施例提供的生成描述文本过程的流程图，该过程包括：

步骤301，将语义融合特征输入第二文本生成模型，得到通知消息对应的第二描述文本，第二文本生成模型具有文本生成功能。

终端获取语义融合特征后，将语义融合特征输入第二文本描述模型进行文本生成处理，得到通知消息对应的第二描述文本。

在一种可能的实施方式中，第一文本生成模型的框架包括信号分析模块、数据阐释模块、文档规划模块以及微规划与实现模块。其中，信号分析模块的输入为语义融合特征，利用多种数据分析方法检测语义融合特征中的基本模式，输出离散性的数据模式。数据阐述模块的输入为语义融合特征中的基本模式与事件，通过对基本模式以及事件进行分析，推断出更加复杂和抽象的消息，并推断出各消息间的关系，最后输出高层消息以及消息之间的关系，例如因果关系、时序关系等。文档规划模块的输入为消息及消息间的关系，通过分析决定需要在第一描述文本中提及的消息，同时确定第一描述文本的结构，最后输出需要提及的消息以及文档结构。微规划与实现模块的输入为简化后需要提及的消息以及文档结构，通过自然语言生成技术输出第二描述文本。

通过第一文本生成模型，能够使最终生成的第二描述文本具有正确的语法、语态，并且具有结构化图形用户界面的信息。

步骤302，对第二描述文本以及消息来源进行特征提取，得到通知消息的第三通知语义特征。

终端得到第二描述文本后，将其与消息来源分别进行编码得到各自对应的编码向量，再将二者的编码向量进行融合，得到通知消息的第三通知语义特征。

步骤303，将第三通知语义特征输入第三文本生成模块，得到通知消息的第三描述文本，第三文本生成模型具有文本摘要功能。

终端采用第三文本生成模型将输入第三通知语义特征进行文本生成及摘要处理，文本摘要为第三文本生成模型的主要功能。

第三文本生成模型可以利用基于抽取的文章摘要或基于概要的文章摘要两种方式中的多种算法模型进行文本摘要的处理，本实施例在此不做赘述。

步骤304，基于第三描述文本，生成通知消息对应的消息提示文本。

基于第三描述文本生成消息提示文本的方式有两种，其一是直接将第三描述文本填充至第一消息提示模板中，其二是结合可交互元素的描述文本，将二者共同填充至第二消息提示模板，这两种方法的实施过程已在上述方式一、方式二中进行说明，本申请实施例在此不进行赘述。

本申请实施例中，终端将语义融合文本先经过第二文本生成模型进行文本生成，再将生成的第二描述文本与消息来源重新编码后，再经过第三文本生成模型进行文本摘要处理，最终获得消息提示文本。将文本生成与文本摘要的过程分割开来，降低了对于文本生成模型处理性能的要求，且生成的消息提示信息更能够代表通知消息所展现的内容，使得用户更高效的获知消息。

在生成通知消息对应的消息提示文本时，在通知消息是以结构化图形用户界面的形式呈现时，终端需要对界面元素的元素属性信息进行提取，得到第二通知语义特征，进而与第一通知语义特征进行融合，共同用于生成描述文本，然而，在结构化图形用户界面中存在的部分元素时不可见的，意味着即便是在视觉交互时，用户也无法看到这些不可见控件的内容，因此，在提取第二通知语义特征时，只需要对可视化界面元素的元素属性信息进行特征提取即可。

下面将通过一个示意性实施例对得到第二通知语义特征的过程进行说明。

图4示出了本申请一示例性实施例提供的对得到第二通知语义特征的过程的流程图，该过程包括：

步骤401，获取结构化图形用户界面的视图树。

其中，视图树(View Tree)由结构化图形用户界面中的界面元素构成，结构化图形用户界面用于对通知消息进行结构化展示。

通常情况下，用于展示通知消息的结构化图形用户界面在底层会被渲染组织成一个树状结构，就是视图树，视图树包含一份根节点，其内部节点都是ViewGroup类型的节点，叶子结点都是View类型，一个ViewGroup类型的节点中可以包含多个ViewGroup节点和View节点，其中View节点就是用户界面中实际显示内容的元素，例如，按钮、列表元素、文本框等。通过系统底层提供的服务可以获取到该用户界面的View Tree结构，也可以同时获取到View Tree中各个节点的元素属性，例如，显示内容、可点击性、位置坐标等信息。

步骤402，从视图树中提取界面元素的元素属性信息。

终端在获取视图树的同时，可以获取到界面元素的视图树中各个节点的元素属性信息。获取到元素属性信息后，终端将元素属性信息从视图树中提取出来，以备进行后续处理。

终端提取到元素属性信息后，对元素属性信息进行特征提取，得到界面元素的元素语义特征。在只针对结构化图形用户界面中的可视化界面元素的情况下，终端需要先确定出结构图形用户界面中的可视化界面元素，再对可视化界面元素的元素属性信息进行特征提取，得到元素语义特征。

步骤403，基于元素属性信息，确定结构化图形用户界面中的可视化界面元素。

终端可以根据获取到的元素属性信息判断一个界面元素是否是可视化界面元素，可通过遍历叶子结点或查询属性等方式进行可视化界面元素的筛选。

可选的，确定结构化图形用户界面中的可视化界面元素可通过检查界面元素的Visibility属性是否处于View.VISIBLE状态，这是最基本的检查界面元素是否可见的方法，或是利用该方式递归的检查该View以及其parentView的Visibility属性是否处于View.VISIBLE状态，处于View.VISIBLE状态的情况下，该界面元素为可见化界面元素。

步骤404，对可视化界面元素的元素属性信息进行特征提取，得到可视化界面元素的元素语义特征。

终端对元素属性信息进行特征提取时，首先针对界面元素的各个属性对应的属性信息采用不同的编码方式进行编码，例如，对文本属性采用文本编码器对其进行编码，采用归一化编码的方式对元素的位置坐标进行编码，采用独热编码的方式对元素的可点击性进行编码等等。

终端得到界面元素的各个属性的编码结果后，再将各个属性的编码结果进行拼接后得到该元素的元素语义特征。

步骤405，对元素语义特征进行特征提取以及融合，得到通知消息的第二通知语义特征。

终端得到元素语义特征后，需要将各个可视化界面元素的元素属性信息进行特征提取和融合，得到整个结构化图形用户界面中界面元素的语义特征，即为通知消息的第二通知语义特征。

可以采用神经网络模型的对元素语义特征进行提取与融合，例如，RNN(RecurrentNeural Network，循环神经网络)或Transformer模型等等。

在一种可能的实施方式中，终端采用Transformer模型对元素语义特征进行特征提取以及融合，Transformer模型的结构可以分为编码器和解码器两部分，使用Transformer模型对元素语义特征进行提取以及融合的核心思想为，已知存在输入向量K时输出向量V的映射关系，根据计算未知的编码输出向量Q与K的关系，可得到一组线性组合系数，Q向量的编码结果是由V向量与相应的线性组合系数得到的。在预先训练编码器时，将元素语义特征输入到计算网络中，自注意力机制会将输入的元素语义特征同时作为Q，K，V三组向量进行训练。在经过编码器进行训练后，可以得到相应的K向量和V向量，K和V两向量作为隐藏层接入解码器中，用于生成第二通知语义特征。

本申请实施例中，终端通过获取结构化图形用户界面的视图树，进而获取界面元素的元素属性信息，并且通过元素属性信息确定出可视化界面元素，再对可视化界面元素的元素属性信息进行特征提取，使得第二通知语义特征中具有更多的通知消息的可见内容的特征，进而使得生成的消息提示文本更加贴合视觉交互的情况下用户所能获取到的信息，更有利于避免消息提示文本内容冗余，并且，终端通过获取视图树的方式，能够避免进行应用的适配，适用性更强。

在实际应用中，一部分的通知消息是不重要的通知消息，例如，购物软件的物品推荐、短视频软件的视频推送或是新闻软件推送的每日新闻等，因此，终端可以先对通知消息的重要性进行判断，在通知消息为重要消息的情况下，终端对通知消息进行通知提醒。此外，存在一些通知消息对于实时性要求并不强或是该通知消息的消息来源用户不常用到等情况，因此，终端可以先对通知消息是否需要进行语音播报进行判断，在该通知消息需要进行语音播报的情况下对该通知消息进行语音播报。一些通知消息的内容较为简短或是其消息内容较为特助，可以不对该通知消息进行特征提取，直接对该通知消息的内容进行播报，例如，通知消息的消息来源应用为社交应用的好友信息，终端则可以对该通知消息直接进行语音播报。

综合上述三种情况，终端通知消息属于重要消息、且通知消息具有语音提示需求、且通知消息具有内容提取需求的情况下，生成消息提示文本。

其中，对于通知消息的重要性、是否具有语音提示需求、以及是否具有内容提取需求的判断，主要可以通过以下两种方式：

方式一，通过预定义的逻辑规则进行判断。

预定义的逻辑规则可以是用户自行设定的规则，也可以是终端根据消息来源的类型以及历史使用情况进行设定的。

将逻辑规则设定成规则表，该逻辑规则是基于消息来源、消息内容以及设备状态共同确定的，在通知消息符合规则表中重要消息以及具有语音提示需求的情况下，对通知消息进行语音播报；在通知消息符合规则表中重要消息条件，但不具有语音提示需求的情况下，对通知消息进行音效或响铃提醒；在该通知消息即不满足重要消息条件，又不具有语音提示需求的条件下，不对其进行提醒或采用静默提醒的方式进行展示。

在确定该通知消息需要进行语音播报的情况下，根据定义的逻辑规则对通知消息的内容提取需求进行判断，该逻辑规则是基于消息来源以及消息内容确定的，在判断出该通知消息具有内容提取需求后，终端对结构化图形用户界面以及消息内容分别进行特征提取后得到该通知消息的第一通知语义特征以及第二通知语义特征，再基于第一通知语义特征以及第二通知语义特征，生成通知消息对应的消息提示文本，并进行语音播报。

方式二，通过神经网络模型进行检测。

在判断通知消息是否需要进行语音提醒时，同样可以采用神经网络模型对其进行判断。终端将通知消息的第一通知语义特征以及第二通知语义特征进行融合后得到的语义融合特征作为神经网络模型的输入，采用两个神经网络模型分别对通知消息重要性以及是否具有语音提示需求进行判断。该神经网络可以采用卷积神经网络、循环神经网络等等。

在确定该通知消息需要进行语音播报的情况下，终端基于消息来源以及消息内容，对通知消息进行分类，得到分类结果，分类结果用于指示通知消息是否具有内容提取需求。

在一种可能的实施方式中，终端采用通知消息分类模型判断通知消息是否具有内容提取需求。预先训练通知消息分类模型，该模型用于计算通知消息具有内容提取需求的概率。终端将语义融合特征输入通知消息分类模型找那个，可得到输出结果，该输出结果用于表示通知消息具有内容提取需求的概率，将概率高于阈值的通知消息确定为具有内容提取需求的通知消息。该通知消息分类模型是基于大量样本通知消息的语义融合特征训练得到的。

事实上，对于通知消息的是否为重要消息以及是否具有语音提醒需求的判断，同样可以通过分类模型实现，其判断过程与上述对于通知消息是否具有内容提取需求的判断方式相类似，本实施例在此不做赘述。

图5示出了本申请一示例性实施例提供的通知消息界面的示意图。如图5，其中包含多个通知消息，分别为第一通知消息501、第二通知消息502、三通知消息503以及第四通知消息504。终端接收到多个通知消息后，先对内各个通知消息进行是否需要进行语音播报以及内容提取的判断。首先，终端获取到当前的设备状态为驾驶状态，并基于通知消息的消息内容以及消息来源判断出第一通知消息501，第二通知消息502以及第四通知消息504为重要消息。再对这三个通知消息进行进一步的判断，由于第四通知消息所指示事件的触发事件不紧急，因此，终端判定第四通知消息不具有语音提醒需求。终端确定需要对第一通知消息501和第二通知消息502进行语音提醒的情况下，基于该通知消息的消息内容以及消息来源，可以判定该通知消息不具有内容提取需求。因此，终端对用户进行语音播报内容为：“收到来自张X的短信，我们一会儿在店门口集合。”以及“收到来自李X的微X消息，明天我会带上资料。”

在终端进行语音播报后，终端可以响应于用户语音指令，触发语音指令所指示的元素，进一步完成语音交互过程。

图6示出了本申请一示例性实施例提供的语音交互过程的流程图，该过程包括：

步骤601，在接收到语音指令的情况下，生成语音指令对应的指令文本。

终端接收到语音指令后，通过对语音指令依次执行波束成形算法、前端信号处理以及ASR(Automatic Speech Recognition，自动语音识别)算法生成语音指令对应的指令文本。

可选的，前端信号处理采用ANC(Active Noise Cancellation，主动噪声消除)算法，用于消除环境噪音；AEC(Acoutic Echo Cancellation，声学回声消除)算法，用于消除终端语音播报的语音回声；AGC(Automatic Gain Control)算法，用于调整语音信号的幅值范围使得处理后输出的信号幅值平稳。

步骤602，确定通知消息中与指令匹配的匹配文本。

终端生成指令文本后，将其与结构化图形用户界面中界元素进行匹配，能够确定出结构化图形用户界面中与指令文本相匹配的匹配文本。其中匹配操作可通过文本匹配算法实现，本实施例在此不做赘述。

终端确定匹配文本后，可以基于匹配文本所属元素的位置，执行语音指令所指示的操作。然而，在实际应用中，可能会出现匹配文本不可交互的情况，因此，为了避免程序执行错误，在执行语音指令指示的操作前，需要先判断该匹配文本是否是可交互元素，再进行后续操作。

步骤603，在匹配文本所属元素属于可交互元素的情况下，基于匹配文本所属元素的位置，执行语音指令所指示的操作。

可交互元素是通过查询元素属性信息中是否具有可交互属性判断得出的，终端确定匹配文本所属的界面元素属于可交互元素的情况下，根据指令文本，对该界面元素执行相应操作。例如，针对图2中的第一用户界面201，用户发出语音指令为：“查看订单”，终端可以确定出匹配文本为第一用户界面201中的文本“查看订单”，其对应界面元素203，终端根据该元素的元素属性信息判断出该元素为可交互元素，因此，触发界面元素203，跳转至“查看订单”对应的用户界面。

步骤604，在匹配文本所属元素不属于可交互元素的情况下，进行交互提示。

在确定匹配文本所属元素不属于可交互元素的情况下，终端根据指令文本的内容，对用户进行不可交互提示，并向用户播报该结构化图形用户界面中的可交互元素的文本属性。

例如，针对图2中的第一图形用户界面201，用户发出语音指令为：“点击值机柜台”，终端根据界面元素的元素属性信息判断出第一图形用户界面201中“值机柜台”为不可交互元素，此时终端的语音播报内容可以为：“您所指示的值机柜台不支持交互，如需进一步操作，你可以说航班助手、查看订单、预定酒店”。

本申请实施例中，终端获取用户语音信号后，确定与指令文本匹配的文本，再对匹配文本的元素的可交互性进行判断，对于可交互元素，终端触发相应元素执行语音指令指示的操作，对于不可交互元素，终端对用户进行提示并提供可交互元素，使得终端能够仅通过语音的方式实现用户与终端的完整交互，且能够对用户进行引导，使用户更清晰的得知通知消息中的可交互元素，能够更加顺利的进行语音交互。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图7示出了本申请一个实施例提供的通知消息的语音播报装置的结构框图。该装置可以包括：

第一特征提取模块701，用于对通知消息的消息内容以及所述通知消息的消息来源进行特征提取，得到所述通知消息的第一通知语义特征；

第二特征提取模块702，用于在所述通知消息包含结构化图形用户界面的情况下，对所述结构化图形用户界面中界面元素的元素属性信息进行特征提取，得到所述通知消息的第二通知语义特征；

文本生成模块703，用于基于所述第一通知语义特征以及所述第二通知语义特征，生成所述通知消息对应的消息提示文本；

语音播报模块704，用于对所述消息提示文本进行语音播报。

可选的，所述文本生成模块703，包括：

特征融合单元，用于对所述第一通知语义特征以及所述第二通知语义特征进行特征融合，得到所述通知消息的语义融合特征；

第一文本生成单元，用于将所述语义融合特征输入文本生成模型，得到所述通知消息对应的描述文本；

第二文本生成单元，用于基于所述描述文本，生成所述通知消息对应的所述消息提示文本。

可选的，所述第二本生成单元，用于：

将所述描述文本填充至第一消息提示模板，得到所述消息提示文本；

或，

确定所述结构化图形用户界面中的可交互元素；从所述可交互元素的所述元素属性信息中提取所述可交互元素的元素描述文本；通过第二消息提示模板对所述描述文本以及所述元素描述文本进行拼接，得到所述消息提示文本。

可选的，所述第一文本生成单元，用于：

将所述语义融合特征输入第一文本生成模型，得到所述通知消息对应的第一描述文本，所述第一文本生成模型具有文本生成以及文本摘要功能；

所述第二文本生成单元，用于：

基于所述第一描述文本，生成所述通知消息对应的所述消息提示文本。

可选的，所述第一文本生成单元，用于：

将所述语义融合特征输入第二文本生成模型，得到所述通知消息对应的第二描述文本，所述第二文本生成模型具有文本生成功能；

对所述第二描述文本以及所述消息来源进行特征提取，得到所述通知消息的第三通知语义特征；

将所述第三通知语义特征输入第三文本生成模块，得到所述通知消息的第三描述文本，所述第三文本生成模型具有文本摘要功能；

所述第二文本生成单元，用于：

基于所述第三描述文本，生成所述通知消息对应的所述消息提示文本。

可选的，所述第二特征提取模块702，用于：

获取所述结构化图形用户界面的视图树；

从所述视图树中提取所述界面元素的所述元素属性信息；

对所述元素属性信息进行特征提取，得到所述界面元素的元素语义特征；

对所述元素语义特征进行特征提取以及融合，得到所述通知消息的所述第二通知语义特征。

可选的，所述第二特征提取模块702，用于：

基于所述元素属性信息，确定所述结构化图形用户界面中的可视化界面元素；

对所述可视化界面元素的所述元素属性信息进行特征提取，得到所述可视化界面元素的所述元素语义特征。

可选的，所述装置还包括：

提示文本生成模块，用于在所述通知消息属于重要消息、且所述通知消息具有语音提示需求、且所述通知消息具有内容提取需求的情况下，生成所述消息提示文本。

可选的，所述装置还包括：

消息分类模块，用于基于所述消息来源以及所述消息内容，对所述通知消息进行分类，得到分类结果，所述分类结果用于指示所述通知消息是否具有内容提取需求。

可选的，所述装置还包括：

指令文本生成模块，用于在接收到语音指令的情况下，生成所述语音指令对应的指令文本；

匹配文本确定模块，用于确定所述结构化图形用户界面中与所述指令匹配的匹配文本；

指令操作执行模块，用于基于所述匹配文本所属元素的位置，执行所述语音指令指示的操作。

可选的，所述指令操作执行模块，用于：

在所述匹配文本所属元素属于可交互元素的情况下，基于所述匹配文本所属元素的位置，执行所述语音指令所指示的操作；

所述装置还包括：

交互提示模块，用于在所述匹配文本所属元素不属于可交互元素的情况下，进行交互提示。

请参考图8，其示出了本申请一个示例性实施例提供的终端的结构方框图。该终端800可以实现成为上述各个实施例中的终端。终端800可以包括一个或多个如下部件：处理器810和存储器820。

处理器810可以包括一个或者多个处理核心。处理器810利用各种接口和线路连接整个终端800内的各个部分，通过运行或执行存储在存储器820内的指令、程序、代码集或指令集，以及调用存储在存储器820内的数据，执行终端800的各种功能和处理数据。可选地，处理器810可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。处理器810可集成中央处理器(Central ProcessingUnit，CPU)、图像处理器(Graphics Processing Unit，GPU)、神经网络处理器(Neural-network Processing Unit，NPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责触摸显示屏所需要显示的内容的渲染和绘制；NPU用于实现人工智能(Artificial Intelligence，AI)功能；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器810中，单独通过一块芯片进行实现。

存储器820可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。可选地，该存储器820包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器820可用于存储指令、程序、代码、代码集或指令集。存储器820可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等；存储数据区可存储根据终端800的使用所创建的数据(比如音频数据、电话本)等。

除此之外，本领域技术人员可以理解，上述附图所示出的终端800的结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，终端800中还包括显示屏、摄像组件、麦克风、扬声器、射频电路、输入单元、传感器(比如加速度传感器、角速度传感器、光线传感器等等)、音频电路、WiFi模块、电源、蓝牙模块等部件，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有至少一条程序代码，所述程序代码由处理器加载并执行以实现如上各个实施例所述的通知消息的语音播报方法。

本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的通知消息的语音播报方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外，本文中描述的步骤编号，仅示例性示出了步骤间的一种可能的执行先后顺序，在一些其它实施例中，上述步骤也可以不按照编号顺序来执行，如两个不同编号的步骤同时执行，或者两个不同编号的步骤按照与图示相反的顺序执行，本申请实施例对此不作限定。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。