服务数据的处理方法、系统、存储介质及终端

技术领域

本申请涉及车载以太网技术领域，尤其涉及一种服务数据的处理方法、系统、存储介质及终端。

背景技术

在车辆(汽车)中通常会采用面向服务的架构(Service Oriented Architecture，SOA)来将车辆中的各个控制系统以可调用、具有接口(Interface)的服务(Service)来进行展现，由此通过车载应用软件来实现车辆与互联网的互联互通，并通过实现用户与车辆的交互。

采用SOA架构可以实现以车辆以太网作为主要通信协议的功能。然而，对于SOA中的车载服务数据，通常是以excel等表格的形式对其进行存储，这种存储方式会降低对车载服务数据的维护效率，也对服务数据的应用造成了不便。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本申请的目的在于提供一种服务数据的处理方法、系统、存储介质及终端，提高对服务数据的管理效率。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请的第一个方面，提供一种服务数据的处理方法，该方法包括：以知识图谱的形式对服务数据进行存储，其中，所述知识图谱包含不同实体之间的关联关系，所述实体包括服务；对所述知识图谱中存储的服务数据进行应用。

上述方案中，本申请所提供的服务数据处理方法以知识图谱的形式对服务数据进行存储。凭借知识图谱对复杂数据格式和元素间关系的良好支持性，可以实现维护各种复杂格式和关系的服务数据，从而实现了服务数据的数据库存储。

在本申请一个实施例中，所述以知识图谱的形式对服务数据进行存储，包括：确定所述实体的类型以及确定所述实体之间的关联关系，以构建预设模式，其中，所述实体还包括接口、参数、以及信号中的一种或多种，所述关联关系包括调用关系和/或依赖关系；将所述服务数据导入至所述预设模式中，以实现以知识图谱的形式存储所述服务数据。

上述方案中，在构建知识图谱之前，首先设计服务数据的知识图谱预设模式schema。通过设计实体的类型和关系的类型，来构建可以适用于不同服务数据的预设模式，方便了服务数据的导入与知识图谱的生成。

在本申请一个实施例中，在所述将所述服务数据导入至所述预设模式中之前，所述方法还包括：获取原始服务数据；对所述原始服务数据进行数据抽取处理和/或数据清洗处理，得到所述服务数据。

上述方案中，在将服务数据导入预设模式schema之前，还对原始的服务数据进行了预处理，预处理包括数据抽取处理和/或数据清洗处理，从而可以将不正确或不相关的数据进行修改和过滤，以提高所导入的服务数据的质量。

在本申请一个实施例中，所述通过所述知识图谱实现对所述服务数据的应用，包括：根据所述知识图谱中所述服务以及所述服务的关联关系，实现对所述服务数据的查询。

在本申请一个实施例中，所述通过所述知识图谱实现对所述服务数据的应用，包括：根据所述服务以及所述服务的关联关系，确定所述服务数据之间的关联度；将关联度大于预设值的多个服务数据作为关联数据进行推荐。

在本申请一个实施例中，所述通过所述知识图谱实现对所述服务数据的应用，包括：将所述服务以及所述服务的关联关系进行批量导出。

在本申请一个实施例中，所述方法还包括：基于所述知识图谱构建应用，其中，所述应用用于实现所述服务。

上述方案中，对知识图谱中的服务数据可以进行多种实际应用。以知识图谱进行数据存储，可以方便用户以各种维度查询服务数据，也可以为用户提供服务数据的批量导入导出功能，并且也能够提高用户使用服务数据构建应用程序的效率。

根据本申请的第二个方面，提供一种服务数据的处理系统，所述系统包括：存储模块，用于：以知识图谱的形式对服务数据进行存储，其中，所述知识图谱包含不同实体之间的关联关系，所述实体包括服务；应用模块，用于：对所述知识图谱中存储的服务数据进行应用。

根据本申请的第三个方面，提供一种终端，包括存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时，使得上述终端执行上述第一个方面所述的服务数据的处理方法。

根据本申请的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时实现上述第一个方面所述的服务数据的处理方法。

需要解释的是，以知识图谱形式存储数据具体为以图数据结构的形式来存储和查询数据的数据库。

本申请的实施例提供了一种服务数据的处理方法、系统、存储介质及终端，具备以下技术效果：

本申请通过知识图谱的形式存储车载服务数据，以凭借知识图谱对复杂数据格式和元素间关系的良好支持性，来实现对各种复杂格式和关联关系的服务数据的维护，从而提高对服务数据的管理效率。

进一步的，本申请还可以对知识图谱中的服务数据进行多种实际应用。由于服务数据以知识图谱的形式存储，而知识图谱中各实体之间存在多维度的关联关系(即一种类型的实体可能与其他多种类型的实体存在关联关系)，因此，可以方便用户以各种维度对服务数据进行查询。

并且，由于事先确定了预设模式，从而使得每个服务数据的导入导出都有了明确的模式。因此本申请还可以为用户提供服务数据的批量导入导出功能，从而节省用户导入导出服务数据的时间。

另外，通过知识图谱的形式来存储车载服务数据还可以使得用户高效地创建车载应用，用户只需要编写少量的业务处理代码来设计一些定制化的业务，便可以完成车载应用的开发，从而能够提高用户使用服务数据构建应用程序的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一例服务数据的处理方法的示意性流程图；

图2是本申请实施例提供的一例以知识图谱的形式对服务数据进行存储的示意性流程图；

图3是本申请实施例提供的一例预设模式schema的示意图；

图4是本申请实施例提供的一例方向盘加热系统(Steering Wheel Heating)的知识图谱的示意图；

图5是本申请实施例提供的一例服务数据的处理系统的示意性结构图；

图6是本申请实施例提供的一例终端的示意性框图。

具体实施方式

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

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

相关技术中，SOA架构可以实现例如自动驾驶或驾驶辅助的视频流信息、车内影音娱乐信息(音视频播放、副驾及后座娱乐系统互动、导航等图像信息传输、收音机、CD等功能)、诊断及刷写等功能，还可以与车外互联网实现互联互通的功能，例如获取车载摄像头的信息，例如通过手机等终端设备远程获取车辆周围环境；获取车辆运行状态信息，例如通过云端获取用户的驾驶习惯；远程控制车辆中的舒适性设备，例如通过手机等终端设备远程打开车辆空调；远程控制车辆安全性设备，例如通过手机等终端设备为代驾远程开锁和启动车辆运行，等等。

在SOA架构中，通常会对服务、接口、参数、信号等元素进行定义而生成服务数据。例如，对于服务会定义服务编号、服务名称、服务命名空间等；对于接口会定义接口编号、接口名称等；对于参数会定义入参名称、入参数据类型、返回参数名称、返回参数数据类型等；对于信号会定义信号编号、信号名称、信号方向、信号位段定义、周期频率、触发方式等。而对于服务数据则通常采用excel等表格的形式进行存储，这种存储方式无法应对复杂的数据格式和元素之间的关系，并且会对服务数据的编写和维护造成不便。

针对上述相关技术中所存在的问题，本申请提出了一种服务数据的处理方法、系统、存储介质及终端，以解决相关技术中无法高效处理服务数据的问题。

下面，将结合附图及实施例对本示例实施方式中的服务数据的处理方法的各个步骤进行更详细的说明。

图1示出了根据本申请一示例性的实施例中服务数据的处理方法的流程图。

S110，以知识图谱的形式对服务数据进行存储，其中，知识图谱包含不同实体之间的关联关系，实体包括服务。

一种可能的实现方式中，图2示出了根据本申请一示例性的实施例中以知识图谱的形式对服务数据进行存储的流程图。

S210，获取原始服务数据。

示例性的，原始的服务数据可以从原始的数据库中获取，例如从excel表格获取原始服务数据。原始服务数据中存储有对服务、接口、参数、以及信号等元素的定义。

S220，对原始服务数据进行数据抽取处理和/或数据清洗处理，得到服务数据。

示例性的，这些原始服务数据可能存在不完整、不正确的部分，或者存在与所需要的服务数据不相关的部分(例如注释)。因此需要对原始服务数据进行数据抽取、数据清洗等预处理。其中，数据抽取是指从原始服务数据中抽取与所需要的服务数据相关的部分，而过滤掉例如注释等不相关的内容。数据清洗是指识别原始服务数据中的脏数据，例如不完整、不正确或不准确的数据，并对脏数据进行替换、修改、或删除等处理。经过数据抽取、数据清洗等处理后，最终得到可用的高质量服务数据。

S230，确定实体的类型以及确定实体之间的关联关系，以构建预设模式，其中，实体还包括接口、参数、以及信号中的一种或多种，关联关系包括调用关系和/或依赖关系。

示例性的，本申请采用知识图谱的形式对上述服务数据进行存储：将服务、接口、参数、以及信号等元素视为知识图谱中的实体，将服务、接口、参数、以及信号之间的调用关系、依赖关系等视为实体之间的关联关系。

示例性的，在生成知识图谱之前，可以预先构建知识图谱的预设模式schema，其中，schema用于对知识图谱中的实体及关联关系进行明确的界定。构建schema结构时需要对每个实体的类型和关联关系进行设定，即确定每个实体为服务、接口、参数、或信号的中的一种，并确定每个实体之间的关联关系。

示例性的，参考图3所示的预设模式schema的示意图，其示出了一种可能的schema结构。如图3所示，图中的每一个圆圈即代表一个实体。其中的“系统”表示此预设模式schema具体用于哪一个控制系统中，其中，控制系统可以包括方向盘加热系统、安全驾驶系统、影音娱乐系统等等。实体包括该系统中的服务、接口、参数、以及信号等。

示例性的，对于实体之间的关联关系，可以设定为服务到接口的调用关系、信号到接口的自动触发的关系、接口到信号的自动变更的关系、服务之间的依赖关系、接口之间的订阅和发布关系等等。

其中，服务到接口的调用关系表示服务的执行需要通过调用对应的接口来实现。

其中，信号到接口的自动触发的关系表示输入至此控制系统中的信号会触发接口的调用。

其中，接口到信号的自动变更的关系表示接口被调用时，自动变更关联的信号的状态信息。

其中，服务之间的依赖关系表示一个服务需要在其他的服务都成功启动后才能启动。

其中，接口之间的订阅和发布关系表示有的接口是支持订阅类型的，例如订阅一个接口后，就会按照订阅频率自动接收到接口的发布数据。

示例性的，对上述实体的类型和关联关系进行设定后，便完成了schema的构建。需要说明的是，图3所示的schema结构仅为简单的示例，schema中可以存在更多的实体以及更多的实体间关系。并且，上述实体和关联关系同样仅为示例。在实际应用中可以根据具体情况对实体、关联关系、以及schema结构进行不同的设定，本实施例中不做限制。

S240，将服务数据导入至预设模式中，以实现以知识图谱的形式存储服务数据。

示例性的，在完成对预设模式schema的构建后，便可以将服务数据进行导入。由于已经预先构建了schema，因此在将服务数据导入schema时(例如，将服务数据中的服务导入至schema中对应的服务实体节点，将接口导入至schema中对应的接口实体节点，等等)，可以进行数据的批量导入，从而节省导入数据的时间。

示例性的，服务数据中存储有对上述实体的定义。例如，对于服务的定义可以包括服务编号、服务名称、服务命名空间等；对于接口的定义可以包括接口编号、接口名称等；对于参数的定义可以包括输入参数名称、输入参数数据类型、返回参数名称、返回参数数据类型等；对于信号的定义可以包括信号编号、信号名称、信号方向、信号位段定义、周期频率、触发方式等。

示例性的，参考图4所示的方向盘加热系统(Steering Wheel Heating)的知识图谱的示意图。如图4所示，其中对于服务命名空间的定义为方向盘加热系统(Body.SteerWhlHeat)，表示此知识图谱用于存储方向盘加热系统的服务数据。

示例性的，继续参考图4，对于方向盘加热系统中两个服务的服务名称的定义分别为方向盘加热控制服务(SteerWhlHeatCtrlSrv)和方向盘加热状态服务(SteerWhlHeatStSrv)。另外，还可以定义两个服务的服务编号，从而可以方便对服务进行管理，并可以区分命名相同的服务。例如，定义方向盘加热控制服务的服务编号为0x2501，方向盘加热状态服务的服务编号为0x2502。

示例性的，继续参考图4，对于方向盘加热控制服务对应的接口的名称，可以定义其为方向盘加热控制接口(SteerWhlHeatCtrl)。其中，方向盘加热控制服务与方向盘加热控制接口之间的关系为调用关系。另外，还可以定义接口的接口编号，从而可以方便对接口进行管理，并可以区分命名相同的接口。例如，定义方向盘加热控制接口的接口编号为0x0001。

示例性的，定义了接口编号后，方向盘加热控制服务在调用方向盘加热控制接口时，可以通过接口编号来实现对具体接口的调用。例如，方向盘加热控制服务通过调用接口编号为0x0001的接口，便可指定对图4中的方向盘加热控制接口的调用。

示例性的，继续参考图4，方向盘加热控制接口会接收到信号(CIntID，例如方向盘中的加热按钮发送的加热关闭的控制信号)以及控制操作(Command)生成的输入参数，以及会对控制操作进行响应(Response)并生成输出(返回)参数。

示例性的，继续参考图4，对于信号的名称可以定义为方向盘加热控制信号值(SteerWhlHeatCtrl_CIntID_Enum)，并可以定义其取值为0.0、1.0、2.0、3.0等数值。另外，还可以定义信号的编号为0x0003；信号的输出端为电子控制单元(Electronic ControlUnit，ECU)中的CCU_A芯片，信号的输入端为ECU中的CCU_BD芯片；信号的位段为：0x0位为无动作，0x1位为开启，0x2位为关闭；信号周期频率为50ms；等等。

其中，信号到方向盘加热控制接口存在着自动触发的关系，方向盘加热控制接口到信号存在着自动变更的关系。

示例性的，继续参考图4，对于输出(返回)参数可以定义输出参数的名称为方向盘加热控制输出参数(SteerWhlHeatCtrl_Response_Enum)，并可以定义其取值为0.0、1.0等数值。另外，还可以定义输出参数的数据类型。例如，定义方向盘加热控制输出参数的数据类型为unit8(8位无符号整型)。

示例性的，继续参考图4，对于输入参数可以定义输入参数的名称为方向盘加热控制输入参数(SteerWhlHeatCtrl_Command_Enum)，并可以定义其取值为0.0、1.0、2.0、3.0、4.0等数值。另外，还可以定义输入参数的数据类型。例如，定义方向盘加热控制输入参数的数据类型为unit8(8位无符号整型)。

示例性的，如图4所示，对于方向盘加热状态服务对应的接口的名称，可以定义其为方向盘加热状态接口(SteerWhlHeatSt)。其中，方向盘加热状态服务与方向盘加热状态接口之间的关系为调用关系。另外，还可以定义接口的接口编号，从而可以方便对接口的管理，并可以区分命名相同的接口。如图4中，方向盘加热状态服务便使用重载(Overloading)调用了两个名称相同的接口。因此，可以定义其中一个方向盘加热状态接口的接口编号为0x4001，另一个的接口编号为0x9001。

示例性的，定义了接口编号后，方向盘加热状态服务在调用方向盘加热状态接口时，可以通过接口编号来实现对具体接口的调用。例如，方向盘加热状态服务通过调用接口编号为0x4001的接口，便可指定对图4中的其中一个方向盘加热状态接口的调用，从而避免出现同时调用具有相同名称的接口的情况。

示例性的，继续参考图4，对于方向盘加热状态接口中所包含的参数，可以定义参数名称为方向盘加热状态参数(SteerWhlHeatSt_Enum)，并可以定义其取值为0.0、1.0等数值。另外，还可以定义参数的数据类型。例如，定义方向盘加热状态参数的数据类型为unit8(8位无符号整型)。

示例性的，对于服务来说，其对应的接口、参数、信号等会发生升级变更，即会有不同的版本，因此，对于服务可以创建不同版本的知识图谱。

示例性的，将服务数据导入schema后，便以知识图谱的形式对服务数据进行了存储。需要说明的是，上述服务数据的内容仅为示例，对于服务、接口、参数、信号等的相关定义可以根据具体实际情况进行更改，本实施例中不做限制。对于车辆中其他控制系统的知识图谱的生成也可参照上述实施例中所描述的方法，本实施例中不再赘述。

S120，对知识图谱中存储的服务数据进行应用。

示例性的，对于知识图谱中所存储的服务数据，可以通过其中的服务以及服务之间的关联关系，实现对服务数据的多维度查询和关联查询。

示例性的，还可以根据服务以及服务的关联关系来确定服务数据之间的关联度，并将关联度大于预设值的多个服务数据作为关联数据进行组合推荐。

示例性的，除了可以批量导入服务数据外，还可以对服务以及服务之间的关联关系进行批量的导出。

示例性的，用户还可以基于知识图谱中的服务数据来方便地创建车载应用。其中，车载应用主要是对控制信号、状态信号等的操作和处理。车辆中各控制系统之间的交互可以采用服务接口进行通信，服务接口则主要采用汽车开放系统架构(Automotive OpenSystem Architecture，AUTOSAR)的通信协议和框架。应理解，AUTOSAR本质上是一种软件设计的方法论，它为具体如何实现SOA的软件架构提供了标准化的服务设计和实现方式。例如，AUTOSAR定义了为了运行自适应AUTOSAR(Adaptive AUTOSAR)的应用程序，操作系统需要具备可移植操作系统接口(POSIX)，操作系统应通过在启动和运行时的动态调度和通信路径的动态配置来支持应用程序的动态行为。

示例性的，根据知识图谱中的服务数据便可以生成AUTOSAR体系的通信代码，然后根据知识图谱中实体之间的关联关系便可以生成接口操作、处理信号的代码，从而生成代码工程。而用户只需要编写少量的业务处理代码来设计一些定制化的业务，便可以完成车载应用的开发，从而实现服务与用户之间的交互。

本申请所提供的服务数据的处理方法，以知识图谱的形式对服务数据进行存储，相比于传统的以excel表格对服务数据进行存储的方式，可以方便对服务数据的编写与维护。另外，本申请所提供的服务数据的处理方法还能够对知识图谱中存储的服务数据进行实际应用，可以方便用户以各种维度查询服务数据，也可以为用户提供服务数据的批量导入导出功能，拓宽了服务数据的应用广度与应用效率，并且能够提高用户开发车载应用时的开发效率。

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

其中，图5示出了根据本申请一示例性的实施例中服务数据的处理系统的结构图。

本申请实施例中的服务数据的处理系统500包括：存储模块510，以及应用模块520。

具体地：存储模块510，用于：以知识图谱的形式对服务数据进行存储，其中，知识图谱包含不同实体之间的关联关系，实体包括服务；

应用模块520，用于：对知识图谱中存储的服务数据进行应用。

一种可能的实现方式中，上述存储模块510具体用于：确定实体的类型以及确定实体之间的关联关系，以构建预设模式，其中，实体还包括接口、参数、以及信号中的一种或多种，关联关系包括调用关系和/或依赖关系；将服务数据导入至预设模式中，以实现以知识图谱的形式存储服务数据。

一种可能的实现方式中，上述存储模块510还用于：获取原始服务数据；对原始服务数据进行数据抽取处理和/或数据清洗处理，得到服务数据。

一种可能的实现方式中，上述应用模块520具体用于：根据知识图谱中服务以及服务的关联关系，实现对服务数据的查询。

一种可能的实现方式中，上述应用模块520具体用于：根据服务以及服务的关联关系，确定服务数据之间的关联度；将关联度大于预设值的多个服务数据作为关联数据进行推荐。

一种可能的实现方式中，上述应用模块520具体用于：将服务以及服务的关联关系进行批量导出。

一种可能的实现方式中，上述应用模块520具体用于：基于知识图谱构建应用，其中，应用用于实现服务。

需要说明的是，上述实施例提供的服务数据的处理系统500在执行服务数据的处理方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的服务数据的处理系统500与服务数据的处理方法实施例属于同一构思，因此对于本申请系统实施例中未披露的细节，请参照本申请上述的服务数据的处理方法的实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

图6示出了根据本申请一示例性的实施例中终端的结构图。请参见图6所示，终端600包括有：处理器601和存储器602。

本申请实施例中，处理器601为计算机系统的控制中心，可以是实体机的处理器，也可以是虚拟机的处理器。处理器601可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器601可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable GateArray，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器601也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(CentralProcessing Unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。

在本申请实施例中，上述处理器601具体用于：

以知识图谱的形式对服务数据进行存储，其中，上述知识图谱包含不同实体之间的关联关系，上述实体包括服务；对上述知识图谱中存储的服务数据进行应用。

进一步地，在本申请一个实施例中，上述处理器601具体用于：确定上述实体的类型以及确定上述实体之间的关联关系，以构建预设模式，其中，上述实体还包括接口、参数、以及信号中的一种或多种，上述关联关系包括调用关系和/或依赖关系；将上述服务数据导入至上述预设模式中，以实现以知识图谱的形式存储上述服务数据。

可选的，上述处理器601还用于：获取原始服务数据；对上述原始服务数据进行数据抽取处理和/或数据清洗处理，得到上述服务数据。

可选的，上述处理器601具体用于：根据上述知识图谱中上述服务以及上述服务的关联关系，实现对上述服务数据的查询。

可选的，上述处理器601具体用于：根据上述服务以及上述服务的关联关系，确定上述服务数据之间的关联度；将关联度大于预设值的多个服务数据作为关联数据进行推荐。

可选的，上述处理器601具体用于：将上述服务以及上述服务的关联关系进行批量导出。

可选的，上述处理器601具体用于：基于上述知识图谱构建应用，其中，上述应用用于实现上述服务。

存储器602可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器602还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储终端、闪存存储终端。在本申请的一些实施例中，存储器602中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器601所执行以实现本申请实施例中的方法。

一些实施例中，终端600还包括有：外围设备接口603和至少一个外围设备。处理器601、存储器602和外围设备接口603之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口603相连。具体地，外围设备包括：显示屏604、摄像头605和音频电路606中的至少一种。

外围设备接口603可被用于将输入/输出(Input/Output，I/O)相关的至少一个外围设备连接到处理器601和存储器602。在本申请的一些实施例中，处理器601、存储器602和外围设备接口603被集成在同一芯片或电路板上；在本申请的一些其他实施例中，处理器601、存储器602和外围设备接口603中的任意一个或两个可以在单独的芯片或电路板上实现。本申请实施例对此不作具体限定。

显示屏604用于显示用户界面(UserInterface，UI)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏604是触摸显示屏时，显示屏604还具有采集在显示屏604的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器601进行处理。此时，显示屏604还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在本申请的一些实施例中，显示屏604可以为一个，设置终端600的前面板；在本申请的另一些实施例中，显示屏604可以为至少两个，分别设置在终端600的不同表面或呈折叠设计；在本申请的再一些实施例中，显示屏604可以是柔性显示屏，设置在终端600的弯曲表面上或折叠面上。甚至，显示屏604还可以设置成非矩形的不规则图形，也即异形屏。显示屏604可以采用液晶显示屏(Liquid CrystalDisplay，LCD)、有机发光二极管(OrganicLight-EmittingDiode，OLED)等材质制备。

摄像头605用于采集图像或视频。可选地，摄像头605包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及虚拟现实(VirtualReality，VR)拍摄功能或者其它融合拍摄功能。在本申请的一些实施例中，摄像头605还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路606可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器601进行处理。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端600的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。

电源607用于为终端600中的各个组件进行供电。电源607可以是交流电、直流电、一次性电池或可充电电池。当电源607包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

本申请实施例中示出的终端结构框图并不构成对终端600的限定，终端600可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一实施例方法的步骤。其中，计算机可读存储介质可以包括但不限于任何类型的盘，包括软盘、光盘、DVD、CD-ROM、微型驱动器以及磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪速存储器设备、磁卡或光卡、纳米系统(包括分子存储器IC)，或适合于存储指令和/或数据的任何类型的媒介或设备。

在本申请中，术语“第一”、“第二”等仅用于描述的目的，而不能理解为指示或暗示相对重要性或顺序；术语“多个”则指两个或两个以上，除非另有明确的限定。术语“安装”、“相连”、“连接”、“固定”等术语均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；“相连”可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

本申请的描述中，需要理解的是，术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或单元必须具有特定的方向、以特定的方位构造和操作，因此，不能理解为对本申请的限制。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。