一种音频缺陷定位方法、装置及终端设备与流程

文档序号:21312820发布日期:2020-06-30 20:39阅读:263来源:国知局
一种音频缺陷定位方法、装置及终端设备与流程

本发明属于数据处理技术领域,尤其涉及音频缺陷定位方法及终端设备。



背景技术:

安卓系统在进行音频数据播放时,应用程序将音频数据传输给安卓系统本地层(native层)进行处理传输,并与音频硬件进行交互,从而实现对音频数据的播放。具体而言,由本地层内的安卓本地框架api类声轨(audiotrack)进行应用程序数据交互操作,接收应用程序的音频数据,再将接收到的音频数据传输至本地层的音频管理器(audioflinger),由音频管理器进行音频数据的重采样、音效、声道转换等音频处理操作,并将处理后的音频数据传输至音频硬件抽象层,由音频硬件抽象层与音频硬件设备进行硬件设备数据交互操作,将接收到的音频数据传输至音频硬件设备进行音频数据的播放。

在实际应用中发现,本地层的各个传输处理操作都可能出现问题,这些问题都可能导致音频数据产生丢帧或片段丢失等缺陷,从而使得最终音频硬件设备播放音频数据时出现断续卡顿等情况,而现有技术中的安卓日志中并不会记录本地层传输处理操作的详细数据,因此即使实际应用中出现了音频数据播放断续卡顿等情况,现有技术也无法对本地层进行分析,确定出音频数据产生缺陷的具体传输处理操作,因此,现有技术中急需一种在音频数据播放出现断续卡顿等情况时,对本地层各个传输处理操作进行音频数据产生缺陷操作的准确定位。



技术实现要素:

有鉴于此,本发明实施例提供了一种音频缺陷定位方法及终端设备,以解决现有技术中无法在音频数据播放出现断续卡顿等情况时,对本地层进行分析,确定出音频数据产生缺陷的具体传输处理操作的问题。

本发明实施例的第一方面提供了一种音频缺陷定位方法,包括:

接收音频检测指令,并基于所述音频检测指令中包含的音频数据信息,读取本地层中多个操作分别对应的多个音频缓存;

对多个所述音频缓存按照多个所述操作的执行顺序依次进行分析,直至查找出其中首个存在音频缺陷的音频缓存;

将负责对所述首个存在音频缺陷的音频缓存对应的音频数据进行处理的所述操作,判定为产生音频缺陷的操作。

本发明实施例的第二方面提供了一种音频缺陷定位装置,包括:

缓存读取模块,用于接收音频检测指令,并基于所述音频检测指令中包含的音频数据信息,读取本地层中多个操作分别对应的多个音频缓存;

缓存分析模块,用于对多个所述音频缓存按照多个所述操作的执行顺序依次进行分析,直至查找出其中首个存在音频缺陷的音频缓存;

缺陷定位模块,用于将负责对所述首个存在音频缺陷的音频缓存对应的音频数据进行处理的所述操作,判定为产生音频缺陷的操作。

本发明实施例的第三方面提供了一种终端设备,所述终端设备包括存储器、处理器,所述存储器上存储有可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如上所述的音频缺陷定位方法的步骤。

本发明实施例与现有技术相比存在的有益效果是:通过预先对本地层每步操作得到的音频数据均进行缓存得到对应的多个音频缓存,并在音频数据播放出现断续卡顿等情况,需要对本地层进行分析时,对本地层每个操作对应的音频缓存数据依次进行分析,确定出其中存在音频缺陷的音频缓存,最后再确定出该存在音频缺陷的音频缓存对应的操作,即可实现对本地层各个传输处理操作后音频数据是否产生了缺陷的快速准确识别,实现了对安卓系统本地层中,音频数据产生缺陷的具体传输处理操作的快速准确定位。

附图说明

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

图1是本发明实施例一提供的音频缺陷定位方法的实现流程示意图;

图2是本发明实施例二提供的音频缺陷定位方法的实现流程示意图;

图3是本发明实施例三提供的音频缺陷定位方法的实现流程示意图;

图4是本发明实施例四提供的音频缺陷定位方法的实现流程示意图;

图5是本发明实施例五提供的音频缺陷定位方法的实现流程示意图;

图6是本发明实施例六提供的音频缺陷定位方法的实现流程示意图;

图7是本发明实施例七提供的音频缺陷定位方法的实现流程示意图;

图8是本发明实施例八提供的音频缺陷定位装置的结构示意图;

图9是本发明实施例九提供的终端设备的示意图。

具体实施方式

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

为了说明本发明所述的技术方案,下面通过具体实施例来进行说明。

为了便于理解本发明,此处先对本发明实施例进行简要说明,由于本地层各个传输处理等操作步骤中都有可能出现问题,从而使得音频数据出现丢帧或片段丢失等缺陷,而现有技术中又没有对本地层各个操作相关数据进行记录,因此即使已知了本地层中可能存在问题,现有技术中也无法实现对出现问题操作进行准确定位,从而无法实现针对性的处理。为了实现对出现问题操作的准确定位,本发明实施例中对本地层设置了缓存机制,即会对本地层中每个操作处理的音频数据进行音频缓存,并在用户需要进行问题操作的定位时,对这些音频缓存进行分析,确定出存在缺陷的音频缓存,进而实现对问题操作的定位。

在本发明实施例中,进行音频缺陷操作定位的执行主体,既可以是安卓设备本身,也可以是其他终端设备,当执行主体为其他终端设备时,执行主体与安卓设备建立数据连接,并读取安卓设备中对本地层中多个操作分别对应的多个音频缓存,以下以执行主体为安卓设备为例进行说明,详述如下:

图1示出了本发明实施例一提供的音频缺陷定位方法的实现流程图,详述如下:

s101,接收音频检测指令,并基于音频检测指令中包含的音频数据信息,读取本地层中多个操作分别对应的多个音频缓存。

本发明实施例中,音频检测指令用于指示安卓设备进行音频缺陷操作定位。在本发明实施例中,会预先对本地层中每个操作处理的音频数据进行缓存,在需要对本地层进行分析确定音频数据产生缺陷的操作时,用户只需确定好自己所需分析的音频数据(即具体存在缺陷的音频数据),输入对应的包含用户选取音频数据的信息的音频检测指令即可。其中,音频数据信息既可以是音频数据的名称,也可以是其他可以确定音频数据的音频属性信息。多个操作具体包含的操作由技术人员根据实际需求设定,既可以是本地层中包含的所有操作,也可以是包含的部分操作,例如由本地层audiotrack负责的应用程序数据交互操作、audioflinger负责的音频处理操作以及硬件抽象层负责的硬件设备数据交互操作。

在接收到音频检测指令时,说明本地层中可能有操作出现了问题导致了音频数据出现缺陷,此时本发明实施例读取本地层操作对应的音频缓存进行分析,由于本地层处理过的音频数据很能有很多,从而使得每个操作都有可能对应有多个不同的音频缓存,因此,本发明实施例中会根据音频检测指令中的音频数据信息,从已存储的本地层操作对应的音频缓存中,查找出用户所需分析的音频数据的音频缓存。其中,每个操作对应着一个音频缓存。

s102,对多个音频缓存按照多个操作的执行顺序依次进行分析,直至查找出其中首个存在音频缺陷的音频缓存。

当某一操作对应的音频数据出现缺陷时,在其之后的操作所接受到的音频数据必然也会存在缺陷,因此,在确定出每个操作分别对应的音频缓存之后,本发明实施例会按照本地层中操作的实际执行顺序来依次对各个操作对应的音频缓存进行分析,并查找其中首个存在音频缺陷的音频缓存,从而避免了后续的重复无用操作。其中,具体的音频缺陷分析方法可由技术人员自行设定,包括但不限于如检查音频缓存中的空白音频数据段等,或者参考本发明实施例七和本发明实施例八进行处理。

s103,将负责对首个存在音频缺陷的音频缓存对应的音频数据进行处理的操作,判定为产生音频缺陷的操作。

应当理解地,在本发明实施例中,对每个操作进行音频数据缓存至少包含两种可选的缓存方案,1、对每个操作而言,将其接收到的音频数据进行缓存。2、对于每个操作而言,将其处理操作完成后得到的音频数据进行缓存。具体选取何种缓存方案此处不予限定,技术人员可以根据实际需求自行设定,但由于两者缓存方案的音频缓存时机存在差异,从而导致了音频缓存实际对应音频缺陷产生的操作存在了差异,对于方案1而言,由于其对应缓存的是每个操作步骤接收到的音频数据,即是上一操作才是负责处理该音频缓存对应的音频数据的操作,当该音频缓存存在音频缺陷时,说明上一操作是产生音频缺陷的操作,对于方案2而言,由于其对应缓存的是每个操作步骤自行处理后得到的音频数据,因此其自身就是负责处理该音频缓存对应的音频数据的操作,当该音频缓存存在音频缺陷时,其自身就是产生音频缺陷的操作。

例如假设操作a负责对音频数据进行a处理,操作b负责对a处理之后音频数据进行b处理,对于方案1而言,操作b缓存的是其上一操作a在a处理之后得到的音频数据,当操作b缓存的音频缓存出现缺陷时,说明负责对该音频缓存对应的音频数据进行a处理的操作a是产生音频缺陷的操作,而对于方案2而言,操作a缓存的是a处理之后得到的音频数据,操作b缓存的是b处理后得到的音频数据,因此当操作b缓存的音频缓存出现缺陷时,说明负责对该音频缓存对应的音频数据进行b处理的操作b是产生音频缺陷的操作。

由上述说明可知,当查找出首个存在音频缺陷的音频缓存,说明负责处理该音频缓存对应的音频数据的操作必然存在问题,因此本发明实施例会直接将负责处理该音频缓存对应的音频数据的操作判定为产生音频缺陷的操作,例如上述实例之中,假设操作b缓存的音频缓存出现缺陷,当是采用方案1进行缓存时,则可以直接判定操作a为产生音频缺陷的操作,当是采用方案2进行缓存时,则可以直接判定操作b为产生音频缺陷的操作。

本发明实施例通过预先对本地层每步操作得到的音频数据均进行缓存得到对应的多个音频缓存,并在音频数据播放出现断续卡顿等情况,需要对本地层进行分析时,对本地层每个操作对应的音频缓存数据依次进行分析,确定出其中存在音频缺陷的音频缓存,最后再确定出该存在音频缺陷的音频缓存对应的操作,即可实现对本地层各个传输处理操作后音频数据是否产生了缺陷的快速准确识别,实现了对安卓系统本地层中,音频数据产生缺陷的具体传输处理操作的快速准确定位。

作为本发明实施例一中对本地层操作进行音频数据缓存的一种具体实现方式,本发明实施例二中多个操作包括:由本地层audiotrack负责的应用程序数据交互操作、audioflinger负责的音频处理操作以及硬件抽象层负责的硬件设备数据交互操作,如图2所示,在接收音频检测指令之前,本地层对音频数据进行处理以播放音频数据时,本发明实施例二,包括:

s201,接收应用程序传输的音频数据,控制本地层依次对音频数据执行应用程序数据交互操作、音频处理操作以及硬件设备数据交互操作以实现对音频数据的播放,并对每个操作接收的音频数据进行缓存,得到与每个操作分别对应的音频缓存。

在本发明实施例中,采用了本发明实施例一中的缓存方案1来作为每个操作对应的缓存机制,即对每个操作而言,缓存其接收到的上一个操作处理完成之后的音频数据。在安卓系统中,audiotrack是java层应用程序在本地层的实例,audioflinge在本地的服务,audioflinger管理着多个服务端播放线程,用于处理播放数据;每个客户端audiotrack在audioflinger中都对应着一个服务端播放线程中的一个track,硬件抽象层负责操控输出设备,诸如喇叭、耳机等硬件,在本发明实施例中,针对的是本地层中audiotrack负责的应用程序数据交互操作、audioflinger负责的音频处理操作以及硬件抽象层负责的硬件设备数据交互操作在音频数据播放过程中进行音频数据的缓存,以实现对这三个操作是否存在问题的识别定位。

作为本发明的另一个实施例,可以采用本发明实施例一中的缓存方案2来作为每个操作对应的缓存机制,即对每个操作而言,缓存其自身处理完成之后的音频数据。

作为本发明实施例二中对每个操作进行音频数据缓存的一种具体实现方式,如图3所示,本发明实施例三,包括:

s301,接收应用程序传输的音频数据,控制本地层执行应用程序数据交互操作,并对接收的音频数据进行缓存,得到与应用程序数据交互操作对应的音频缓存。

s301,控制本地层对执行应用程序数据交互操作后的音频数据进行音频处理操作,并对执行应用程序数据交互操作后的音频数据进行缓存,得到与音频处理操作对应的音频缓存。

s301,控制本地层执行硬件设备数据交互操作,将进行音频处理操作后的音频数据传输至对应的音频硬件设备,并对音频处理操作后的音频数据进行缓存,得到与硬件设备数据交互操作对应的音频缓存。

本发明实施例中,在本地层对音频数据进行应用程序数据交互操作、音频处理操作和硬件设备数据交互操作同时,会对每步操作缓存其接收到的上一操作处理完成后的音频数据进行缓存,从而得到每一步操作对应的音频缓存。

作为本发明实施例四,考虑到实际情况中安卓设备的存储资源有限,而音频数据播放本身就是一个较为频繁的行为,因此本发明实施例会对音频数据缓存占用的存储资源进行限制,以节约安卓设备存储资源的,如图4所示,包括:

s401,将音频数据缓存至对应的本地缓存文件,并判断本地缓存文件的文件体积是否大于预设体积阈值。

本发明实施例中会将每次缓存的音频数据都存储于一个本地缓存文件之中,若缓存时已存在该本地缓存文件,则直接按照从先到后的时间顺序将音频数据缓存于该本地缓存文件,若不存在该本地缓存文件,则新建一个本地缓存文件并按照从先到后的时间顺序将音频数据缓存于该本地缓存文件。为了实现对缓存占用存储资源的限制,本发明实施例中由技术人员预先设置一个缓存文件体积上限的体积阈值,并会在每次音频缓存后,检测本地缓存文件是否超出该体积阈值。其中,预设阈值的具体值大小可由技术人员根据实际需求自行设定,优选地,可以设置为240兆。

s402,若本地缓存文件的文件体积大于预设体积阈值,按照缓存时间的从先到后顺序,对本地缓存文件中包含的音频缓存进行删除,直至本地缓存文件的文件体积小于或等于预设体积阈值。

当本地缓存文件的文件体积大于预设的体积阈值,说明缓存的数据量过大占用存储资源过多,此时本发明实施例会对本地缓存文件中的音频缓存按照缓存的时间顺序进行删除,即仅保留最新的音频缓存,直至删除后的本地缓存文件的文件体积小于或等于体积阈值。

作为本发明进行音频缓存占用存储资源限制的又一实施例,也可以设置多个本地缓存文件来存储音频缓存,此时本发明实施例会对每一个本地缓存文件都设置一个对应的体积阈值,并在本地缓存文件体积大于体积阈值时,删除其中旧的音频缓存。

作为本发明实施例五,考虑到实际情况中安卓设备的存储资源有限,而音频数据播放本身就是一个较为频繁的行为,因此本发明实施例会对音频数据缓存占用的存储资源进行限制,以节约安卓设备存储资源的,如图5所示,包括:

s501,将音频数据缓存至对应的缓存文件夹内,并判断缓存文件夹内包含音频缓存的文件体积是否大于预设体积阈值。

s502,若缓存文件夹内包含音频缓存的文件体积大于预设体积阈值,按照缓存时间的从先到后顺序,对缓存文件夹内包含的音频缓存进行删除,直至本地缓存文件的音频缓存大小小于或等于预设体积阈值。

作为存储资源限制的另一种方案,本发明实施例中会设置一个固定的用于音频缓存文件存储的目录,即会将所有的音频缓存均存储在同一缓存文件夹之中,并在音频数据缓存之后,检测该缓存文件夹下所有音频缓存文件的总文件体积是否超出预设的体积阈值,若超出,则对音频缓存按照缓存的时间顺序进行删除,即仅保留最新的音频缓存,直至删除后缓存文件夹包含的音频缓存文件总体积小于或等于体积阈值。其中,体积阈值的具体值大小可由技术人员自行设定,优选地,可以设置为240兆。

作为本发明的一个实施例,考虑到实际情况中安卓设备的存储资源有限,而音频数据播放本身就是一个较为频繁的行为,因此为了节约音频缓存占用存储资源,在上述本发明实施例一至五的基础上,本发明实施例,包含:

对音频数据进行压缩,并对压缩后的音频数据进行缓存,得到对应的音频缓存。和/或对缓存得到的音频缓存进行文件压缩处理。

本发明实施例中,技术人员可以根据实际需求,选择对音频数据和/或音频缓存进行文件压缩,从而使得最终存储的音频缓存都是进过压缩后的文件,相对不经任何压缩处理得到的音频缓存体积更小,占用存储资源更少。

作为本发明实施例一中进行音频缓存缺陷分析的一种具体实现方式,本发明实施例会通过音频缓存的时长和振幅进行分析,以识别出是否存在卡顿断续等缺陷,如图6所示,本发明实施例六,包括:

s601,对音频缓存进行时长和振幅分析,判断是否存在时长大于预设时长阈值,且振幅均小于预设振幅阈值的音频数据段。

s602,若存在音频数据段,判定音频缓存存在音频缺陷。

当存在卡顿断续等缺陷时,说明音频数据中存在至少一段数据在连续一段时间内振幅极小,如连续1秒振幅为0,因此本发明实施例会对音频缓存进行时长和振幅的分析,以查找音频缓存中是否存在连续一段时间内振幅极小的音频数据段,其中,具体的预设时间阈值和预设振幅阈值大小,可由技术人员自行设置。

作为本发明实施例一中进行音频缓存缺陷分析的一种具体实现方式,本发明实施例会通过音频缓存的时长进行分析,以识别出是否存在丢帧等缺陷,如图7所示,本发明实施例七,包括:

s701,获取音频缓存对应的音频数据的第一音频时长,并统计音频缓存的第二音频时长,并判断第一音频时长与第二音频时长是否相等。

s702,若第一音频时长与第二音频时长不相等,判定音频缓存存在音频缺陷。

由于在出现丢帧缺陷时音频数据虽然不会出现连续振幅极小,但丢失的音频数据帧会直接导致音频时长变小,因此本发明实施例会统计音频缓存的实际音频时长,以及对应的音频数据的理论音频时长(这个在音频数据中会记录,在进行音频数据缓存时也会一并缓存记录,直接读取即可),并将两个时长进行对比,若不相等,则说明出现了丢帧情况。

对应于上文实施例的方法,图8示出了本发明实施例提供的音频缺陷定位装置的结构框图,为了便于说明,仅示出了与本发明实施例相关的部分。图8示例的音频缺陷定位装置可以是前述实施例一提供的音频缺陷定位方法的执行主体。

参照图8,该音频缺陷定位装置包括:

缓存读取模块81,用于接收音频检测指令,并基于所述音频检测指令中包含的音频数据信息,读取本地层中多个操作分别对应的多个音频缓存。

缓存分析模块82,用于对多个所述音频缓存按照多个所述操作的执行顺序依次进行分析,直至查找出其中首个存在音频缺陷的音频缓存。

缺陷定位模块83,用于将负责对所述首个存在音频缺陷的音频缓存对应的音频数据进行处理的所述操作,判定为产生音频缺陷的操作。

进一步地,该音频缺陷定位装置,还包括:

音频缓存模块,用于接收应用程序传输的所述音频数据,控制所述本地层依次对所述音频数据执行所述应用程序数据交互操作、所述音频处理操作以及所述硬件设备数据交互操作以实现对所述音频数据的播放,并对每个所述操作接收的所述音频数据进行缓存,得到与每个所述操作分别对应的所述音频缓存。

进一步地,音频缓存模块,包括:

接收应用程序传输的所述音频数据,控制所述本地层执行所述应用程序数据交互操作,并对接收的所述音频数据进行缓存,得到与所述应用程序数据交互操作对应的所述音频缓存;

控制所述本地层对执行所述应用程序数据交互操作后的所述音频数据进行所述音频处理操作,并对执行所述应用程序数据交互操作后的所述音频数据进行缓存,得到与所述音频处理操作对应的所述音频缓存;

控制所述本地层执行所述硬件设备数据交互操作,将进行所述音频处理操作后的所述音频数据传输至对应的音频硬件设备,并对所述音频处理操作后的所述音频数据进行缓存,得到与所述硬件设备数据交互操作对应的所述音频缓存。

进一步地,音频缓存模块,还包括:

将所述音频数据缓存至对应的本地缓存文件,并判断所述本地缓存文件的文件体积是否大于预设体积阈值。

若所述本地缓存文件的文件体积大于所述预设体积阈值,按照缓存时间的从先到后顺序,对所述本地缓存文件中包含的所述音频缓存进行删除,直至所述本地缓存文件的文件体积小于或等于所述预设体积阈值。

进一步地,音频缓存模块,还包括:

将所述音频数据缓存至对应的缓存文件夹内,并判断所述缓存文件夹内包含所述音频缓存的文件体积是否大于预设体积阈值。

若所述缓存文件夹内包含所述音频缓存的文件体积大于所述预设体积阈值,按照缓存时间的从先到后顺序,对所述缓存文件夹内包含的所述音频缓存进行删除,直至所述本地缓存文件的所述音频缓存大小小于或等于所述预设体积阈值。

进一步地,音频缓存模块,还包括:

对所述音频数据进行压缩,并对压缩后的所述音频数据进行缓存,得到对应的所述音频缓存。和/或

对缓存得到的所述音频缓存进行文件压缩处理。

进一步地,缓存分析模块82,包括:

对所述音频缓存进行时长和振幅分析,判断是否存在时长大于预设时长阈值,且振幅均小于预设振幅阈值的音频数据段。

若存在所述音频数据段,判定所述音频缓存存在音频缺陷。

进一步地,缓存分析模块82,包括:

获取所述音频缓存对应的音频数据的第一音频时长,并统计所述音频缓存的第二音频时长,并判断所述第一音频时长与所述第二音频时长是否相等。

若所述第一音频时长与所述第二音频时长不相等,判定所述音频缓存存在音频缺陷。

本发明实施例提供的音频缺陷定位装置中各模块实现各自功能的过程,具体可参考前述图1所示实施例一的描述,此处不再赘述。

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

还应理解的是,虽然术语“第一”、“第二”等在文本中在一些本发明实施例中用来描述各种元素,但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如,第一表格可以被命名为第二表格,并且类似地,第二表格可以被命名为第一表格,而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格,但是它们不是同一表格。

图9是本发明一实施例提供的终端设备的示意图。如图9所示,该实施例的终端设备9包括:处理器90、存储器91,所述存储器91中存储有可在所述处理器90上运行的计算机程序92。所述处理器90执行所述计算机程序92时实现上述各个音频缺陷定位方法实施例中的步骤,例如图1所示的步骤101至103。或者,所述处理器90执行所述计算机程序92时实现上述各装置实施例中各模块/单元的功能,例如图8所示模块81至83的功能。

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

所称处理器90可以是中央处理单元(centralprocessingunit,cpu),还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor,dsp)、专用集成电路(applicationspecificintegratedcircuit,asic)、现成可编程门阵列(field-programmablegatearray,fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器91可以是所述终端设备9的内部存储单元,例如终端设备9的硬盘或内存。所述存储器91也可以是所述终端设备9的外部存储设备,例如所述终端设备9上配备的插接式硬盘,智能存储卡(smartmediacard,smc),安全数字(securedigital,sd)卡,闪存卡(flashcard)等。进一步地,所述存储器91还可以既包括所述终端设备9的内部存储单元也包括外部存储设备。所述存储器91用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器91还可以用于暂时地存储已经发送或者将要发送的数据。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

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

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1