具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供的数据处理方法可应用于任何具有数据处理能力的系统。图1为本申请实施例提供的数据处理方法的场景示意图。在图1所示的场景中，随着基于互联网的事务的进行，例如，线上销售等事务，会产生大量的事务数据。通常由数据源获取各种事务数据，例如，通过多种类型的数据库来获取这些事务数据并且进行存储。在本申请实施例中，诸如数据库的数据源可以在存储事务数据之前，先对事务数据进行一定的预处理，例如数据清洗或者去除噪声的处理，之后再对预处理之后的事务数据进行存储。

在现有技术中，通常是由专业的数据人员对数据源存储的数据进行监控，以便于在发现事务数据中出现异常时及时通知用户。但是随着互联网技术的发展，线上事务的规模越来越大，产生的事务数据的规模也出现了爆炸式增长。在这样的情况下，对于人工监控事务数据也施加了巨大的压力。特别是异常数据通常是低频率事件，即并非是频繁发生的事件。因此，在事务数据的数据量不大的情况下，人工监控的效果尚能够令用户满意。但是在如今事务数据如此爆炸性增长的情况下，由人工来监控大量的事务数据以图找到异常数据就变得较为困难，甚至于还会出现漏报或错报的情况。而从用户的角度来说，则希望能够及时获得自己相关的事务数据的异常情况的及时且准确的汇报。因此，需要能够准确且及时发现异常数据并发送给用户的方案。

如图1中所示，本申请实施例中，数据处理系统可以从存储有事务数据的数据源来获取事务数据，具体地，数据源的数据可以来自于产生这些事务数据的各种事务，例如这些事务可以是运行在图1中所示的服务器上的应用程序产生的，也可以是由于数据中心中的数据使用而产生的或者也可以是由于在云平台上运行的虚拟机或各种在线服务产生的。这里的事务数据可以被称为原始数据，其是用户的事务在执行时产生的数据，例如线上销售数据。数据处理系统可以在获取了这些事务数据之后对这些事务数据进行异常检测。本申请实施例中，异常检测可以是数据处理系统根据系统内置的规则对数据进行检查以确定是否存在异常的处理。例如，数据处理系统可以将销售额高于预定阈值的销售事务数据确定为异常数据，从而需要汇报给客户。在确定了这样的异常数据之后，可以根据异常数据来生成异常推送消息。在本申请实施例中，可以以预定的形式来基于检测出的异常数据生成符合用户(如图1中所示的用户1至用户n)汇报要求的异常推送消息。例如，当检测到销售额或销售数量过高的异常销售数据时，可以基于该异常销售数据针对的用户进行分组，以便于将数据发送给对应的用户来提醒用户注意。例如，图1中所示的用户2至用户4同属一个用户组1，则，可以向用户组1中的各用户发送相同的异常推送消息。在此基础上，也可以基于异常销售数据来生成各种消息组件，例如折线图、柱状图等等，并且将数据和生成的消息组件进行结合来生成最终的异常推送消息。在该情况下，这样的消息比单纯向用户发送异常数据能够具有更丰富的格式，使得用户能够更清楚地了解异常事务。

最后，本申请实施例的数据处理系统可以将生成的异常推送消息发送给用户，例如发送给用户的客户端。特别地，在本申请实施例中，如上所述，可以在生成推送消息时按用户进行分组，因此，在发送时可以按不同的用户进行推送消息的发送。

因此，本申请实施例提供的数据处理方案能够通过在检测到异常数据时，生成对应的推送消息并主动推送给用户，从而使得用户无需人工监控来确定异常数据，提高了数据处理的效率。

上述实施例是对本申请实施例的技术原理和示例性的应用框架的说明，下面通过多个实施例来进一步对本申请实施例具体技术方案进行详细描述。

图2为本申请提供的数据处理方法一个实施例的流程图。该方法的执行主体可以为具有数据处理能力的各种终端或服务器设备，也可以为集成在这些设备上的装置或芯片。如图2所示，该数据处理方法包括如下步骤。

S201，对从数据源获取到的原始数据进行异常检测，并且将原始数据中检测为存在异常的原始数据确定为异常数据。

在本申请实施例中，当用户的在线事务产生了大量的事务数据时，作为数据源的各种数据库可以将这些事务数据进行存储。在本申请实施例中，数据源可以是各种存储数据的数据库，包括关系型型数据库、非关系型数据库、系统接口、对接日志中的一种或多种。因此，诸如数据库的数据源可以在存储事务数据之前，先对事务数据进行一定的预处理，例如数据清洗或者去除噪声的处理，之后再对预处理之后的事务数据进行存储。

在本申请实施例中，上述事务数据可以被称为原始数据，并且对这些原始数据进行的异常检测可以是根据预置的规则对数据进行检查以确定是否存在异常的处理。例如，可以将销售额高于预定阈值的销售事务数据确定为异常数据，即需要汇报给客户的数据。

S202，根据原始数据中的异常数据生成异常推送消息。

在步骤S201中确定了原始数据中的异常数据之后，可以根据步骤S201中确定的异常数据来生成异常推送消息。对于用户来说，除了关注其事务数据的整体状况之外，事务数据中的异常数据也是非常重要的，而且对于异常数据的了解的及时性也非常重要。换言之，当用户的在线事务产生了异常数据，例如，过高的销售量时，这很可能是由于某一商品的价格设置错误导致的，这时，如果不能立即将这样的异常数据推送给客户，那么等客户通过浏览当天事务数据整体时再发现，可能已经给客户造成了很大的损失。因此，在本申请实施例中，能够利用步骤S201实时对数据源存储的事务数据进行异常检测，并且在该步骤S202中根据检测到的异常数据来生成用于向用户汇报该异常情况的异常推送消息。

在本申请实施例中，可以以预定的形式来基于检测出的异常数据生成符合用户汇报要求的异常推送消息。例如，当检测到销售额或销售数量过高的异常销售数据时，可以基于该异常销售数据针对的用户进行分组，以便于将数据发送给对应的用户来提醒用户注意。

此外，也可以基于异常数据来生成各种消息组件，例如折线图、柱状图等等，并且将数据和生成的消息组件进行结合来生成最终的异常推送消息。在本申请实施例中，这样的消息组件可以包括折线图组件、柱状图组件、饼状图组件、散点图组件、标题组件、段落组件、脚注组件中的一种或多种。

S203，将异常推送消息发送至用户的客户端。

因此，本申请实施例提供的数据处理方案能够通过在检测到异常数据时，生成对应的推送消息并主动推送给用户，从而使得用户无需人工监控来确定异常数据，提高了数据处理的效率。

图3为本申请提供的数据处理方法另一个实施例的流程图。如图3所示，该数据处理方法包括如下步骤。

S3012，获取用户预先设置的由多个检测条件组合成的逻辑表达式。

在本申请实施例中，考虑到不同用户对于自己的事务数据的检测要求的差异，因此可以在对数据源的原始数据进行异常检测之前，先获取用户预设的检测条件，特别地，可以获取由多个检测条件组合成的逻辑表达式。例如，对于销售异常的情况，可以获取销售价格低于历史售价并且销售量超过预设的销售量阈值的组合条件，以便于在后续的检测过程中，能够为用户检测出更符合用户的实际需求的异常数据。

S3021，将原始数据输入到逻辑表达式。

S3022，根据逻辑表达式的输出结果确定原始数据中的异常数据。

在步骤S3012获取了用户预先设置的检测条件的逻辑表达式的情况下，在本申请实施例中，可以将从数据源获取的原始数据输入到所获取的逻辑表达式中来进行异常检测。当输入的原始数据符合逻辑表达式所表示的检测条件时，可以确定该原始数据属于异常数据。

此外，由于异常检测需要消耗计算资源，因此为异常检测的启动设置触发条件。例如，在本申请的方案中，可以进一步包括：

S3011，接收用于启动异常检测操作的触发信号。

在本申请实施例中，通过接收触发信号，可以根据实际需要来选择性地进行异常检测。例如，触发信号可以包含定时触发信号、消息触发信号、手动触发信号、超文本传输协议触发中的一种或多种。在本申请实施例中，可以通过定时出发信号来定时地进行异常检测。这往往适用于事务数据量非常巨大的情况，例如，每隔一个小时触发进行异常检测，从而能够避免事务数据的堆积，影响正常在线事务的进行。此外，在本申请的实施例中，可以根据特定的消息来触发异常检测，这可以发挥监控人员的经验优势，将已知的一些反映异常的消息设置为触发消息，从而当出现这样的消息时就立即启动异常检测。

除了上述检测方式之外，本申请实施例的数据处理方法还可以包括下述步骤来进行检测处理。

S3031，获取原始数据的目标字段。

S3032，当目标字段的取值在预设阈值范围内时，确定该目标子段所属于的原始数据为异常数据。

在本申请实施例中，可以通过检测原始数据中的特定字段的取值来确定是否为异常数据。例如，在确定销售事务数据是否存在异常时，可以检测销售事务数据中的销售额字段，或者购买者字段，并且进而通过判断该特定字段的取值是否满足预设的检测条件，例如，销售额字段的取值，即销售额是否超过十万或百万元，则判断该事务数据为异常数据。因此，通过这样的对特定字段的取值的判断，可以更加有针对性地进行检测。

除了上述检测方式之外，本申请实施例的数据处理方法还可以包括下述步骤来进行检测处理。

S3041，将原始数据按时间顺序组成数列。

S3042，对数列进行异常检测。

随着在线事务的发展，很多事务变得非常复杂，从而对其生成的事务数据的异常检测也需要更为复杂和全面的考虑。例如，在线销售的事务中，异常销售可能并不能够从单个的销售数据来反映，而是需要考虑一段时间段内的一系列销售数据，并且进而通过判断这一系列数据的变化趋势来确定是否存在异常。因此，在本申请实施例中，在对原始数据进行检测时，可以将一定量的原始数据按时间顺序排成数列，并进而对组成的数列进行检测，例如判断其变化趋势等等，从而来确定是否存在异常。通过这样的方式，能够对原始数据进行更全面的检测。

在确定的异常数据之后，本申请实施例的数据处理方法可以接下来包括下述步骤来生成关于异常数据的推送消息。

S3051，生成针对异常数据的消息组件。

S3052，对消息组件进行组合，以生成异常推送消息。

对于用户来说，除了关注其事务数据的整体状况之外，事务数据中的异常数据也是非常重要的，而且对于异常数据的了解的及时性也非常重要。换言之，当用户的在线事务产生了异常数据，例如，过高的销售量时，这很可能是由于某一商品的价格设置错误导致的，这时，如果不能立即将这样的异常数据推送给客户，那么等客户通过浏览当天事务数据整体时再发现，可能已经给客户造成了很大的损失。因此，在本申请实施例中，能够利用步骤S3021至S3022、S3031至S3032或S3041至S3042实时对数据源存储的事务数据进行异常检测，并且在该步骤S3051至S3052中根据检测到的异常数据来生成用于向用户汇报该异常情况的异常推送消息。

在本申请实施例中，可以以预定的形式来基于检测出的异常数据生成符合用户汇报要求的异常推送消息。例如，当检测到销售额或销售数量过高的异常销售数据时，可以基于该异常销售数据针对的用户进行分组，以便于将数据发送给对应的用户来提醒用户注意。

因此，可以通过步骤S3051来基于检测步骤中检测到的异常数据来生成各种消息组件，例如折线图、柱状图等等，并且在步骤S3052中将数据和生成的消息组件进行结合来生成最终的异常推送消息。在本申请实施例中，这样的消息组件可以包括折线图组件、柱状图组件、饼状图组件、散点图组件、标题组件、段落组件、脚注组件中的一种或多种。因此，通过根据异常数据来生成不同形式的消息组件，并且通过拼接组件的方式进行渲染来生成完整的推送消息，从而能够获得格式丰富的消息体形式。特别地，在本申请实施例中，也可以提供交互界面，由用户来通过拖拽等方式配置出符合自己要求的消息组件的各种形式。

此外，在本申请实施例中，可以结合用户的客户端的类型，来采用不同形式的消息组件进行组合，以生成不同样式的异常推送消息。例如，可以根据用户客户端的屏幕进行适配，当用户客户端为手机时，则推送的消息中可以不包括柱状图组件；当用户客户端为智能手表时，则可以只推送简单的文字消息。

S3061，根据异常推送消息中的关键字，确定与关键字关联的一个或多个用户。

S3062，将异常推送消息发送至一个或多个用户的客户端。

在本申请实施例中，在步骤S3051-S3052中生成了推送消息之后，可以进一步按照原始数据所属于的客户来进行分组，并且按照分组来将推送消息发送至对应的客户。

在本申请实施例中，在向客户端发送异常推送消息时，可以控制客户端对用户进行相关的提示。例如，在客户端配置有显示屏幕的情况下，可以控制客户端的显示屏幕上显示各种提示信息，或者可以控制客户端的显示屏幕的亮度变高，从而提示用户注意。在客户端配置有扬声器的情况下，可以控制客户端的扬声器发出各种声音，例如蜂鸣声或以语音播报的形式提醒用户注意异常信息。此外，在客户端配置有震动组件的情况下，也可以控制客户端的震动组件在收到异常消息推送的情况下启动震动，从而使得能够通过使用户感受到震动而提醒用户。

因此，本申请实施例提供的数据处理方案能够通过在检测到异常数据时，生成对应的推送消息并主动推送给用户，从而使得用户无需人工监控来确定异常数据，提高了数据处理的效率。

图4为本申请提供的数据处理装置一个实施例的结构示意图。可用于执行如图2所示的方法步骤。如图4所示，该数据处理装置可以包括：检测模块41、推送消息生成模块42和发送模块43。

检测模块41可以用于对从数据源获取到的原始数据进行异常检测，并且将所述原始数据中检测为存在异常的原始数据确定为异常数据。

在本申请实施例中，当用户的在线事务产生了大量的事务数据时，作为数据源的各种数据库可以将这些事务数据进行存储。在本申请实施例中，数据源可以是各种存储数据的数据库，包括关系型型数据库、非关系型数据库、系统接口、对接日志中的一种或多种。因此，诸如数据库的数据源可以在存储事务数据之前，先对事务数据进行一定的预处理，例如数据清洗或者去除噪声的处理，之后再对预处理之后的事务数据进行存储。

在本申请实施例中，上述事务数据可以被称为原始数据，并且对这些原始数据进行的异常检测可以是根据预置的规则对数据进行检查以确定是否存在异常的处理。例如，可以将销售额高于预定阈值的销售事务数据确定为异常数据，即需要汇报给客户的数据。

例如，在该情况下，根据本申请实施例的数据处理装置可以进一步包括获取模块44，该获取模块44可以用于获取用户预先设置的由多个检测条件组合成的逻辑表达式。

在本申请实施例中，考虑到不同用户对于自己的事务数据的检测要求的差异，因此可以在对数据源的原始数据进行异常检测之前，先获取用户预设的检测条件，特别地，可以获取由多个检测条件组合成的逻辑表达式。例如，对于销售异常的情况，可以获取销售价格低于历史售价并且销售量超过预设的销售量阈值的组合条件，以便于在后续的检测过程中，能够为用户检测出更符合用户的实际需求的异常数据。

因此，检测模块41可以进一步用于将所述原始数据输入到所述逻辑表达式，以及根据所述逻辑表达式的输出结果确定所述原始数据中的所述异常数据。

在获取模块44获取了用户预先设置的检测条件的逻辑表达式的情况下，在本申请实施例中，检测模块41可以用于将从数据源获取的原始数据输入到获取模块44所获取的逻辑表达式中来进行异常检测。当输入的原始数据符合逻辑表达式所表示的检测条件时，检测模块41可以确定该原始数据属于异常数据。

此外，本申请的数据处理装置还可以进一步包括信号接收模块45，该信号接收模块45可以用于接收用于启动异常检测操作的触发信号，

在本申请实施例中，通过接收触发信号，可以根据实际需要来选择性地进行异常检测。例如，触发信号可以包含定时触发信号、消息触发信号、手动触发信号、超文本传输协议触发中的一种或多种。在本申请实施例中，可以通过定时出发信号来定时地进行异常检测。这往往适用于事务数据量非常巨大的情况，例如，每隔一个小时触发进行异常检测，从而能够避免事务数据的堆积，影响正常在线事务的进行。此外，在本申请的实施例中，可以根据特定的消息来触发异常检测，这可以发挥监控人员的经验优势，将已知的一些反映异常的消息设置为触发消息，从而当出现这样的消息时就立即启动异常检测。

此外，在本申请实施例中，检测模块41可以进一步用于执行下述处理：获取所述原始数据的目标字段，并且当所述目标字段的取值在预设阈值范围内时，确定该目标子段所属于的原始数据为所述异常数据。

在本申请实施例中，可以通过检测原始数据中的特定字段的取值来确定是否为异常数据。例如，在确定销售事务数据是否存在异常时，可以检测销售事务数据中的销售额字段，或者购买者字段，并且进而通过判断该特定字段的取值是否满足预设的检测条件，例如，销售额字段的取值，即销售额是否超过十万或百万元，则判断该事务数据为异常数据。因此，通过这样的对特定字段的取值的判断，可以更加有针对性地进行检测。

除了上述检测方式之外，本申请实施例的检测模块41还可以进一步用于执行下述处理：将所述原始数据按时间顺序组成数列，并且对所述数列进行异常检测。

随着在线事务的发展，很多事务变得非常复杂，从而对其生成的事务数据的异常检测也需要更为复杂和全面的考虑。例如，在线销售的事务中，异常销售可能并不能够从单个的销售数据来反映，而是需要考虑一段时间段内的一系列销售数据，并且进而通过判断这一系列数据的变化趋势来确定是否存在异常。因此，在本申请实施例中，在检测模块41对原始数据进行检测时，可以将一定量的原始数据按时间顺序排成数列，并进而对组成的数列进行检测，例如判断其变化趋势等等，从而来确定是否存在异常。通过这样的方式，能够对原始数据进行更全面的检测。

推送消息生成模块42可以用于根据所述原始数据中的所述异常数据生成异常推送消息。

推送消息生成模块42可以根据检测模块41确定的异常数据来生成异常推送消息。对于用户来说，除了关注其事务数据的整体状况之外，事务数据中的异常数据也是非常重要的，而且对于异常数据的了解的及时性也非常重要。换言之，当用户的在线事务产生了异常数据，例如，过高的销售量时，这很可能是由于某一商品的价格设置错误导致的，这时，如果不能立即将这样的异常数据推送给客户，那么等客户通过浏览当天事务数据整体时再发现，可能已经给客户造成了很大的损失。因此，在本申请实施例中，能够通过检测模块41实时对数据源存储的事务数据进行异常检测，并且通过推送消息生成模块42根据检测模块41检测到的异常数据来生成用于向用户汇报该异常情况的异常推送消息。

在本申请实施例中，推送消息生成模块42可以进一步包括消息组件生成单元421和组合单元422。

消息组件生成单元421可以用于生成针对所述异常数据的消息组件，并且组合单元422可以用于对所述消息组件进行组合，以生成所述异常推送消息。

在本申请实施例中，推送消息生成模块42可以以预定的形式来基于检测出的异常数据生成符合用户汇报要求的异常推送消息。例如，当检测模块41检测到销售额或销售数量过高的异常销售数据时，推送消息生成模块42可以基于该异常销售数据针对的用户进行分组，以便于将数据发送给对应的用户来提醒用户注意。

因此，可以通过消息组件生成单元421来基于检测步骤中检测到的异常数据生成各种消息组件，例如折线图、柱状图等等，并且通过组合单元422来根据数据和生成的消息组件进行结合来生成最终的异常推送消息。在本申请实施例中，这样的消息组件可以包括折线图组件、柱状图组件、饼状图组件、散点图组件、标题组件、段落组件、脚注组件中的一种或多种。因此，通过根据异常数据来生成不同形式的消息组件，并且通过拼接组件的方式进行渲染来生成完整的推送消息，从而能够获得格式丰富的消息体形式。特别地，在本申请实施例中，也可以提供交互界面，由用户来通过拖拽等方式配置出符合自己要求的消息组件的各种形式。

此外，在本申请实施例中，组合单元422可以结合用户的客户端的类型，来采用不同形式的消息组件进行组合，以生成不同样式的异常推送消息。例如，可以根据用户客户端的屏幕进行适配，当用户客户端为手机时，则推送的消息中可以不包括柱状图组件；当用户客户端为智能手表时，则可以只推送简单的文字消息。

发送模块43可以用于将异常推送消息发送至用户的客户端。由于在线事务往往涉及到很多用户的不同的事务，并且获取模块44在获取原始数据时，往往是按照原始数据的生成顺序来获取原始数据，因此大量不同用户的原始数据会混在一起由检测模块41进行检测。因此在本申请实施例中，发送模块43可以进一步包括用户确定单元431和发送单元432。

用户确定单元431可以用于根据所述异常推送消息中的关键字，确定与所述关键字关联的一个或多个用户。

发送单元432可以用于根据用户确定单元431的确定结果，将所述异常推送消息发送至所述一个或多个用户的客户端。

在本申请实施例中，在发送单元432向客户端发送异常推送消息时，可以控制客户端对用户进行相关的提示。例如，在客户端配置有显示屏幕的情况下，可以控制客户端的显示屏幕上显示各种提示信息，或者可以控制客户端的显示屏幕的亮度变高，从而提示用户注意。在客户端配置有扬声器的情况下，可以控制客户端的扬声器发出各种声音，例如蜂鸣声或以语音播报的形式提醒用户注意异常信息。此外，在客户端配置有震动组件的情况下，也可以控制客户端的震动组件在收到异常消息推送的情况下启动震动，从而使得能够通过使用户感受到震动而提醒用户。

因此，本申请实施例提供的数据处理装置能够通过在检测到异常数据时，生成对应的推送消息并主动推送给用户，从而使得用户无需人工监控来确定异常数据，提高了数据处理的效率。

以上描述了数据处理装置的内部功能和结构，该装置可实现为一种电子设备。图5为本申请提供的电子设备实施例的结构示意图。如图5所示，该电子设备包括存储器51和处理器52。

存储器51，用于存储程序。除上述程序之外，存储器51还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器51可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器52，不仅仅局限于中央处理器(CPU)，还可能为图形处理器(GPU)、现场可编辑门阵列(FPGA)、嵌入式神经网络处理器(NPU)或人工智能(AI)芯片等处理芯片。处理器52，与存储器51耦合，执行存储器51所存储的程序，以用于：

对从数据源获取到的原始数据进行异常检测，并且将所述原始数据中检测为存在异常的原始数据确定为异常数据；

根据所述原始数据中的所述异常数据生成异常推送消息；

将所述异常推送消息发送至用户的客户端。

进一步，如图5所示，电子设备还可以包括：通信组件53、电源组件54、音频组件55、显示器56等其它组件。图5中仅示意性给出部分组件，并不意味着电子设备只包括图5所示组件。

通信组件53被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G，3G，4G或5G，或它们的组合。在一个示例性实施例中，通信组件53经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件53还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件54，为电子设备的各种组件提供电力。电源组件54可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件55被配置为输出和/或输入音频信号。例如，音频组件55包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器51或经由通信组件53发送。在一些实施例中，音频组件55还包括一个扬声器，用于输出音频信号。

显示器56包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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