CN110582054A

CN110582054A - 一种数据处理方法、装置和机器可读介质

Info

Publication number: CN110582054A
Application number: CN201810581977.5A
Authority: CN
Inventors: 张亚楠; 吴兴昊; 张培阳; 邵茂材
Original assignee: Alibaba Group Holding Ltd
Current assignee: Banma Zhixing Network Hongkong Co Ltd
Priority date: 2018-06-07
Filing date: 2018-06-07
Publication date: 2019-12-17

Abstract

本申请实施例提供了一种数据处理方法、装置、设备和机器可读介质，所述的方法包括：判断是否符合场景检测条件；若符合场景检测条件，则检测设备是否处于所述场景；其中，所述场景包括：兴趣点场景，所述判断是否符合场景检测条件，包括：判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。本申请实施例可以降低设备耗费的资源。

Description

一种数据处理方法、装置和机器可读介质

技术领域

本申请涉及通信技术领域，特别是涉及一种数据处理方法、一种数据处理装置、一种装置和一种机器可读介质。

背景技术

随着通信技术的发展，各大互联网企业开始不断推出各种基于移动互联的服务，其中LBS(基于位置服务，Location Based Services)正逐渐受到重视。 LBS是通过定位方式获取终端的位置信息，在地理信息系统平台的支持下，为用户提供相应服务的一种增值业务。例如，检测到用户进入某个店铺后，向用户提供该店铺的促销信息、优惠券等。

目前，终端提供服务的过程具体包括：对传感器如GPS(全球定位系统， GlobalPositioning System)数据进行周期性采集，依据传感器数据，判断是否符合服务提供条件，若是，则提供服务，否则返回执行周期性采集的操作。

在实际应用中，以传感器为GPS为例，GPS数据的采集过程通常包括：接收多个GPS卫星的信号，依据多个GPS卫星的信号，计算GPS卫星与终端之间的距离，并依据该距离确定终端的位置。上述GPS数据的采集过程通常需要耗费较多的资源，如CPU和流量等资源。并且，为了实现服务的实时性，周期性采集所对应周期的数量级通常为秒，这使得周期性采集的频率较高，从而进一步增加终端对于资源的消耗。

发明内容

本申请实施例所要解决的技术问题是提供一种数据处理方法，可以降低设备耗费的资源。

相应的，本申请实施例还提供了一种数据处理装置、一种装置以及一种机器可读介质，用以保证上述方法的实现及应用。

为了解决上述问题，本申请实施例公开了一种数据处理方法，包括：

判断是否符合场景检测条件；

若符合场景检测条件，则检测设备是否处于所述场景；

其中，所述场景包括：兴趣点场景，所述判断是否符合场景检测条件，包括：

判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。

另一方面，本申请实施例还公开了一种数据处理装置，包括：

第一判断模块，用于判断是否符合场景检测条件；以及

场景检测模块，用于在符合场景检测条件的情况下，检测设备是否处于所述场景；

其中，所述场景包括：兴趣点场景，所述第一判断模块包括：

第一判断子模块，用于判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。

再一方面，本申请实施例还公开了一种装置，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述设备执行前述一个或多个所述的方法。

又一方面，本申请实施例公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得设备执行前述一个或多个所述的方法。

与现有技术相比，本申请实施例包括以下优点：

本申请实施例提出场景检测条件的概念，在符合场景检测条件下检测设备是否处于所述场景；由于在不符合场景检测条件的情况下，可以不检测设备是否处于所述场景，因此可以降低检测设备是否处于所述场景所消耗的资源。

本申请实施例的场景具体可以包括：兴趣点场景，上述判断是否符合场景检测条件，具体可以包括：判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。由于设备所对应网络信息的检测为低频低功耗检测，而在设备处于所述兴趣点所对应周围网络的覆盖范围内的情况下，才检测设备是否处于所述场景，而在设备不处于所述兴趣点所对应周围网络的覆盖范围内的情况下，可以不检测设备是否处于所述场景，因此可以降低检测设备是否处于所述场景所消耗的CPU、流量等资源。

附图说明

图1是本申请的一种数据处理方法的应用环境的示意；

图2是本申请的一种数据处理方法实施例一的步骤流程图；

图3是传统技术与本申请实施例的场景检测的对比示意；

图4是本申请的一种数据处理方法实施例二的步骤流程图；

图5是本申请的一种数据处理方法实施例三的步骤流程图；

图6是本申请的一种数据处理方法实施例四的步骤流程图；

图7是本申请实施例的一种数据处理系统的结构示意图；

图8是本申请实施例的一种数据处理系统的交互示意图；

图9是本申请的一种数据处理装置实施例的结构框图；以及

图10是本申请一实施例提供的装置的结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请的构思易于进行各种修改和替代形式，其具体实施例已经通过附图的方式示出，并将在这里详细描述。然而，应该理解，上述内容并不是用来将本申请的构思限制为所公开的具体形式，相反地，本申请的说明书和附加权利要求书意欲覆盖所有的修改、等同和替代的形式。

本说明书中的“一个实施例”，“实施例”，“一个具体实施例”等，表示所描述的实施例可以包括特定特征、结构或特性，但是每个实施例可以包括或可以不必然包括该特定特征、结构或特性。此外，这样的短语不一定指的是同一实施例。另外，在联系一个实施例描述特定特征、结构或特性的情况下，无论是否明确描述，可以认为本领域技术人员所知的范围内，这样的特征、结构或特性也与其他实施例有关。另外，应该理解的是，“在A，B和C 的至少一个”这种形式所包括的列表中的条目中，可以包括如下可能的项目： (A)；(B)；(C)；(A和B)；(A和C)；(B和C)；或(A，B和C)。同样，“A，B或C中的至少一个”这种形式列出的项目可能意味着(A)；(B)； (C)；(A和B)；(A和C)；(B和C)；或(A，B和C)。

在一些情况下，所公开的实施例可以被实施为硬件、固件、软件或其任意组合。所公开的实施例也可以实现为携带或存储在一个或多个暂时的或者非暂时的机器可读(例如计算机可读)存储介质中的指令，该指令可以被一个或多个处理器执行。机器可读存储介质可以实施为用于以能够被机器读取的形式存储或者传输信息的存储装置、机构或其他物理结构(例如易失性或非易失性存储器、介质盘、或其他媒体其它物理结构装置)。

在附图中，一些结构或方法特征可以以特定的安排和/或排序显示。然而，优选地，这样的具体安排和/或排序并不是必要的。相反，在一些实施方案中，这样的特征可以以不同的方式和/或顺序排列，而不是如附图中所示。此外，特定的附图中的结构或方法特征中所包含的内容，不意味着暗示这种特征是在所有实施例是必须的，并且在一些实施方案中，可能不包括这些特征，或者可能将这些特征与其它特征相结合。

本申请实施例提供了一种数据处理方案，该方案可以判断是否符合场景检测条件；若符合场景检测条件，则检测设备是否处于所述场景。

本申请实施例中，场景是影视行业的一个专业术语，指在某一时间和地点、由一定的人物和人物活动所组成的生活画面。延伸到通信技术领域，是指商家为了满足一类用户的特定需求，而推出的一个产品或者应用。比如，用户来到京东商城，想要购买一台苹果电脑；或者，用户打开微信，了解一下朋友圈的八卦等；或者，用户来到加油站，需要加油；或者，用户来到咖啡馆，需要放松；或者，用户来到景点，需要游览等，这些都是场景。

场景对应的环境数据可以指在相对于物体或用户的设备使用的实例期间收集的所有场景数据和交互数据(例如，日期，当日时间，地点，行为，动作，位置，形态，时空元素等)。设备可以交互的物体包括但不限于：其他用户设备(例如，手机)，外围设备例如蓝牙手机，键盘和服务器设备等，或者在直接环境内的实体，例如地标等，机器，车辆等。

可选地，可以通过场景模型对场景进行定义。场景模型可以包括：环境数据对应的若干个字段，如时间字段、位置字段、设备状态(如车辆的速度等)字段中的任一或者组合。可以理解，商家或者本领域技术人员可以根据实际应用需求，设置所需的任意场景，本申请实施例对于具体的场景和场景模型不加以限制。

传统技术通常需要周期性检测设备是否处于场景，检测设备是否处于场景的过程可以包括：对传感器如GPS数据进行周期性采集，依据传感器数据，判断是否符合服务提供条件。然而，上述GPS数据的采集过程通常需要耗费较多的资源。

本申请实施例提出场景检测条件的概念，在符合场景检测条件下才检测设备是否处于所述场景；由于在不符合场景检测条件的情况下，可以不检测设备是否处于所述场景，因此可以降低检测设备是否处于所述场景所消耗的资源。

本申请实施例在设备处于场景的情况下，还可以向用户提供该场景对应的服务。例如，在用户来到加油站的情况下，向用户提供该加油站对应的加油优惠信息(如优惠券、代金券等)；或者，在用户来到咖啡馆的情况下，向用户提供该咖啡馆对应的特惠信息(如今日特卖)；或者，在用户来到景点的情况下，向用户提供该景点对应的游览指南信息、或者该景点内的超市信息等。可以理解，本领域技术人员可以根据实际应用需求，确定场景对应的服务，本申请实施例对于场景对应的具体服务不加以限制。

本申请实施例提供的数据处理方法可应用于图1所示的应用环境中，如图1所示，客户端100与服务器200位于有线或无线网络中，通过该有线或无线网络，客户端100与服务器200进行数据交互。

可选地，客户端可以运行在设备上，例如，该客户端可以为设备上运行的APP，如电子商务APP、即时通讯APP、输入法APP、或者操作系统自带的APP等，本申请实施例对于客户端所对应的具体APP不加以限制。可选地，上述设备具体可以包括但不限于：智能手机、平板电脑、电子书阅读器、MP3(动态影像专家压缩标准音频层面3，Moving Picture ExpertsGroup Audio Layer III)播放器、MP4(动态影像专家压缩标准音频层面4， MovingPicture Experts Group Audio Layer IV)播放器、膝上型便携计算机、车载电脑、台式计算机、机顶盒、智能电视机、可穿戴设备等等。可以理解，本申请实施例对于具体的设备不加以限制。

方法实施例一

参照图2，示出了本申请的一种数据处理方法实施例一的步骤流程图，具体可以包括如下步骤：

步骤201、判断是否符合场景检测条件；

步骤202、若符合场景检测条件，则检测设备是否处于所述场景。

本申请实施例可以提供如下场景的示例：

示例1、

示例1中，所述场景可以包括：POI(兴趣点，Point of interest)场景，所述场景对应的环境数据可以包括：所述兴趣点对应的位置数据。

POI的例子可以包括：加油站、停车场、购物场所、店铺等。POI场景可用于在用户到达POI的情况下，向用户提供POI对应的服务。该服务可以为：POI对应的指南或者优惠信息等。

示例2、

示例2中，所述场景可以包括：设备状态场景，所述场景对应的环境数据可以包括：所述设备的预设状态数据。

以车辆为例，设备状态场景可以包括：车辆超速、车辆油量低等。以空调、净化器等设备为例，设备状态场景可以包括：设备参数在预设范围内等。设备状态场景可用于在设备处于某种设备状态的情况下，向用户发出提醒，以提升用户的使用体验。例如，在车辆超速的情况下，向用户发出提醒，以避免事故或者被拍照等。又如，在车辆油量低的情况下，向用户发出加油提醒等。再如，在净化器的空气参数表明控制质量不良的情况下，向用户发出模式切换提醒等。相应地，还可以在特定场景下，向用户发出车辆的保养提醒等。

示例3、

示例3中，所述场景可以包括：模式场景，所述环境数据可以包括：所述模式对应的历史数据。

以车辆为例，模式场景可以包括：路线切换场景，例如，在用户选择的导航路线拥堵的情况下，进行导航路线的切换。以空调、净化器等设备为例，模式场景可以包括：模式切换场景等，例如，在净化器的空气参数表明控制质量不良的情况下，进行工作模式的切换，例如，将净化器从第一工作模式切换为第二工作模式，其中，第一工作模式的净化速度低于第二工作模式的净化速度等。

以上通过示例1至示例3对场景及场景对应的环境数据进行了详细介绍，可以理解，本领域技术人员可以根据实际应用需求，采用示例1至示例 3中的任一或者组合，或者，还可以采用其他场景，本申请实施例对于具体的场景、以及场景对应的具体环境数据不加以限制。

场景检测条件可用于作为检测设备是否处于所述场景的触发条件，本领域技术人员可以根据实际应用需求，针对场景确定上述场景检测条件。

本申请实施例可以提供判断是否符合场景检测条件的如下判断方案：

判断方案1、

判断方案1中，所述场景可以包括：兴趣点场景，所述步骤201判断是否符合场景检测条件的过程，可以包括：判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。判断方案1中的设备可以为手机、平板电脑、车载设备等设备。

本申请实施例中，可选的是，所述周围网络的覆盖范围可以与所述兴趣点对应的周围区域相匹配。周围区域可以指环绕着兴趣点的区域。可选地，周围区域与兴趣点之间的距离可以不超过距离阈值，距离阈值的例子可以包括：50米、100米等，可以理解，本申请实施例对于周围区域与兴趣点之间的具体距离不加以限制。

在本申请的一种可选实施例中，所述周围网络的使用频率或者出现频率可以符合频率条件。在实际应用中，可以对兴趣点对于的周围网络的使用频率或者出现频率进行统计，上述频率条件可以包括：使用频率或者出现频率超过第一频率阈值，或者，依据使用频率或者出现频率对周围网络进行排序，排序位置在前N(N为自然数)位等；上述预置条件可以将高频的周围网络用于场景检测条件的确定。

在本申请的一种可选实施例中，所述周围网络的类型可以包括：移动网络和/或WIFI(无线保真网络，Wireless Fidelity)。

在本申请的一种应用示例中，可以挖掘兴趣点周围50米左右高频被设备检测到的基站和/或WIFI，作为兴趣点对应的周围网络；这样，可以判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内，若是，则可以认为符合场景检测条件，否则，则可以认为不符合场景检测条件。

需要说明的是，设备对应的网络信息(基站和/或WIFI)通常由设备的操作系统获取，具体地，操作系统获取设备对应的网络信息，并按照预设周期更新缓存，上述缓存用于存储设备对应的网络信息。由于设备所对应GPS 数据的检测为高频高功耗检测，而设备所对应网络信息的检测为低频低功耗检测，具体地，GPS数据的检测周期为秒，而网络信息的检测周期由网络信息的变化确定；由于在设备处于所述兴趣点所对应周围网络的覆盖范围内的情况下，才检测设备是否处于所述场景，而在设备不处于所述兴趣点所对应周围网络的覆盖范围内的情况下，可以不检测设备是否处于所述场景，因此可以降低检测设备是否处于所述场景所消耗的CPU、流量等资源。

参照图3，示出了传统技术与本申请实施例的场景检测的对比示意，其中，传统技术的场景检测过程具体为：检测设备是否处于场景区域，该检测为高频高功耗检测；而本申请实施例的场景检测过程具体包括：通过第一检测，检测设备是否处于场景附近区域，若是，则通过第二检测，检测设备是否处于场景区域，否则循环执行第一检测。由于第一检测为低频低功耗检测，故可以降低检测设备是否处于场景区域所消耗的CPU、流量等资源。其中，场景区域可以指场景对应的区域，具体为兴趣点所在的区域；场景附近区域可以指与场景区域之间的距离不超过距离阈值的区域。

判断方案2

判断方案2中，所述场景可以包括：设备状态场景，所述设备可以包括：车辆，所述步骤201判断是否符合场景检测条件的过程，具体可以包括：判断所述车辆所在的道路上是否存在测速装置。

设备状态场景具体可以包括：车辆超速场景。测速装置用于进行车辆测速，目前的车辆测速方式具体可以包括：雷达测速、区间测速和地埋线圈测速等，雷达测速、区间测速和地埋线圈测速等测速方式对应的测速装置分别为：雷达、道路卡点的摄像机、地埋线等，可以理解，本申请实施例对于具体的测速装置不加以限制。

传统技术的场景检测过程具体为：当车辆在所有道路的行驶过程中，周期性计算车辆的速度，并判断速度是否超过速度阈值(如120公里/小时)，导致消耗的资源较多。而本申请实施例的场景检测过程具体可以包括：判断所述车辆所在的道路上是否存在测速装置，若是，则周期性计算车辆的速度，并判断速度是否超过速度阈值。由于当车辆在存在测速装置的部分道路的行驶过程中，本申请实施例才会进行超速检测，相比全程检测，可以降低设备耗费的资源。

判断方案3

判断方案3中，所述场景可以包括：设备状态场景，所述设备可以包括：车辆，所述步骤201判断是否符合场景检测条件的过程，具体可以包括：判断车辆所处的位置与预置居所的位置之间的距离是否小于距离阈值。

设备状态场景具体可以包括：车辆油量不足场景。传统技术的场景检测过程具体为：实时检测车辆的油量，并判断车辆的油量是否低于油量阈值。而本申请实施例的场景检测过程具体包括：判断车辆所处的位置与预置居所的位置之间的距离是否小于距离阈值，若是，则可以认为用户即将到达预置居所，因此可以检测车辆的油量，并判断车辆的油量是否低于油量阈值，若是，则向用户发出加油提醒。其中，预置居所可以为用户的住址，本申请实施例对于具体的预置居所不加以限制。

本申请实施例中，油量阈值可以为预设值，也可以为依据车辆对应的行程确定的油量值。依据车辆对应的行程确定油量阈值的过程，具体可以包括：针对车辆的一个行程，依据该行程开始前的第一油量值和该行程结束后的第二油量值，确定该行程对应的油量值。该行程可以为设备的时间对应的行程，如工作日行程(例如上班行程、下班行程等)和节假日行程等，工作日行程为家庭与单位之间的行程等。在一种示例中，可以可以依据车辆的历史行程，确定工作日行程对应的油量值，该油量阈值可以超过该工作日行程对应的油量值。当然，本申请实施例对于具体的油量阈值不加以限制。

判断方案4

判断方案4中，所述场景可以包括：模式场景，所述设备可以包括：车辆，所述步骤201判断是否符合场景检测条件的过程，具体可以包括：判断所述车辆所在道路的拥堵概率是否超过概率阈值。

模式场景可以包括：路线切换场景。传统技术的场景检测过程具体为：当车辆在所有道路的行驶过程中，周期性(如每隔2分钟)查询前方是否拥堵，若是，则切换路线，上述周期性查询耗费较多的资源。而本申请实施例可以通过数据挖掘，确定道路的拥堵概率；这样，在车辆的行驶过程中，可以判断所述车辆所在道路的拥堵概率是否超过概率阈值，若是，则查询前方是否拥堵，若是，则切换路线。由于可以只在拥堵概率大的道路上进行是否切换路线的检测，故可以节省设备的资源。

判断方案5

判断方案5中，所述场景可以包括：模式场景，所述设备可以包括：车辆，所述步骤201判断是否符合场景检测条件的过程，具体可以包括：判断所述车辆所在道路的事故频率是否超过第二频率阈值。

模式场景可以包括：安全模式场景。车辆的工作模式可以包括：普通模式和安全模式，相对于普通模式，安全模式可以提供更多的安全性信息或者更多的功能，例如，可以提示具有危险性的地点，如急弯、桥、隧道、道口等，又如，可以关闭打扰开车的功能，如音乐功能或者视频功能或者通话功能等。

传统技术的场景检测过程具体为：当车辆在所有道路的行驶过程中，周期性(如每隔2分钟)查询前方是否出现事故，若是，则进入安全模式，上述周期性查询耗费较多的资源。而本申请实施例可以通过数据挖掘，确定道路的事故频率；这样，在车辆的行驶过程中，可以判断所述车辆所在道路的事故频率是否超过第二频率阈值，若是，则查询前方是否出现事故，若是，则进入安全模式。由于可以只在事故频率大的道路上进行是否进入安全模式的检测，故可以节省设备的资源。

以上通过判断方案1至判断方案5对判断是否符合场景检测条件的过程进行了详细介绍，可以理解，本领域技术人员可以根据实际应用需求，采用判断方案1至判断方案5中的任一或者组合，可以理解，本申请实施例对于判断是否符合场景检测条件的具体过程不加以限制。

步骤202可以在符合场景检测条件的情况下，检测设备是否处于所述场景。例如，对于兴趣点场景，检测设备是否处于所述场景的过程可以包括：周期性获取设备对应的GPS数据，依据获取的GPS数据确定设备对应的位置数据(如经纬度数据)，并将设备对应的位置数据与兴趣点对应的位置数据进行匹配，若匹配成功，则确定设备处于兴趣点场景。当然，本申请实施例对于检测设备是否处于所述场景的具体过程不加以限制。

在本申请的一种可选实施例中，所述步骤202若符合场景检测条件，则检测设备是否处于所述场景的过程，具体可以包括：若任务对应的场景符合场景检测条件，则将任务添加至调度列表；从所述调度列表中获取目标任务；检测设备是否处于所述目标任务对应的场景。

综上，本申请实施例的数据处理方法，提出场景检测条件的概念，在符合场景检测条件下检测设备是否处于所述场景；由于在不符合场景检测条件的情况下，可以不检测设备是否处于所述场景，因此可以降低检测设备是否处于所述场景所消耗的资源。

方法实施例二

参照图4，示出了本申请的一种数据处理方法实施例二的步骤流程图，具体可以包括如下步骤：

步骤401、依据设备的事件信息，判断是否符合触发条件；

步骤402、若符合触发条件，则判断是否符合场景检测条件；

步骤403、若符合场景检测条件，则检测设备是否处于所述场景。

相对于图2所示方法实施例一，本申请实施例的判断是否符合场景检测条件可以对应有触发条件，本申请实施例依据设备的事件信息，判断是否符合触发条件，这样，可以依据设备的事件信息，智能地调整触发条件，不仅可以降低设备的功耗，而且可以提升用户的使用体验。

步骤401中，事件可以指设备在运行过程中的外部和/或内部事件。外部事件的例子可以包括：I/O(输入/输出，Input/Output)事件等。内部事件的例子可以包括：应用程序的操作事件等，如对于页面中某控件的触发事件等、对于某信息的输入事件等。可以理解，用户可以根据实际的数据采集需求，确定上述配置文件中的事件。

可选地，该事件可对应有触发对象和/或被触发对象。其中，触发事件的对象称为触发对象；接收事件的对象称为被触发对象。例如，事件为用户点击了页面中的某个控件、或者在某个文本框中输入了内容，该事件对应的触发对象为用户，该事件对应的被触发对象为控件或者文本框。又如，在IOT (物联网，Internet of things)业务场景下，事件为控制设备或者传感器设备对应的控制应用针对物联网设备发送控制指令、或者控制设备或者传感器设备对应的控制应用接收物联网设备发送的数据等，该事件对应的触发对象可以为控制设备或者传感器设备对应的控制应用，该事件对应的被触发对象可以为物联网设备。

在本申请的一种可选实施例中，所述事件可以包括但不限于如下事件中的至少一种：电量事件、网络事件、流量事件、位移事件、以及任务接收事件；所述任务对应有场景。

其中，电量事件可以指与设备电池的电量相关的事件，如设备电池的电量(简称设备的电量)达到某个特定值，或者设备是否处于充电状态等。

网络事件可以指与设备网络相关的事件，如设备是否连接网络，或者设备所连接网络的类型等。

流量事件可以指设备通过运营商的无线网络，上传和下载数据所产生的流量，上述流量事件可以包括：设备已消耗的流量、或者设备拥有的流量上限等。

位移事件可以指设备产生的实时位移。

任务接收事件可以指设备接收到的任务，尤其地，从服务器接收到的任务。

本申请实施例可以提供依据设备的事件信息，判断是否符合触发条件的如下技术方案：

技术方案A1

技术方案A1中，所述步骤401依据设备的事件信息，判断是否符合触发条件的过程，具体可以包括：

若设备的电量超过电量阈值，则符合触发条件；或者

若设备的电量不超过电量阈值且检测到充电事件，则符合触发条件；或者

若设备的电量不超过电量阈值且未检测到充电事件，则不符合触发条件。

其中，电量阈值可由本领域技术人员依据实际应用需求确定，例如，电量阈值可以为30％、50％等数值。本申请实施例依据设备的电量，智能地调整触发条件，具体地，若设备的电量超过电量阈值，则符合触发条件，或者，若设备的电量不超过电量阈值且检测到充电事件，则符合触发条件；或者，若设备的电量不超过电量阈值且未检测到充电事件，则不符合触发条件；这样，对于手机或者可穿戴设备等对于电量和功耗较为敏感的设备而言，可以智能地调整触发条件，因此可以节省设备的电量。

技术方案A2

技术方案A2中，所述步骤401依据设备的事件信息，判断是否符合触发条件的过程，具体可以包括：

若设备的流量超过流量阈值，则符合触发条件；或者

若设备的流量不超过流量阈值且设备接入局域网，则符合触发条件；或者

若设备的流量不超过流量阈值且设备未接入局域网，则不符合触发条件。

其中，流量阈值可由本领域技术人员依据实际应用需求确定，例如，流量阈值可以为50M、20M等数值。本申请实施例依据设备的流量，智能地调整触发条件，具体地，若设备的流量超过流量阈值，则符合触发条件，或者，若若设备的流量不超过流量阈值且设备接入局域网，则符合触发条件；或者，若若设备的流量不超过流量阈值且设备未接入局域网，则不符合触发条件；这样，对于手机或者可穿戴设备等对于流量较为敏感的设备而言，可以智能地调整触发条件，因此可以节省设备的流量。

技术方案A3

技术方案A3中，所述步骤401依据设备的事件信息，判断是否符合触发条件的过程，具体可以包括：

若设备在预设时间段内的位移不超过位置阈值，则不符合触发条件；或者

若设备在预设时间段内的位移超过位置阈值，则依据预设时间间隔判断是否符合触发条件。

其中，预设时间段、流量阈值可由本领域技术人员依据实际应用需求确定，例如，预设时间段的长度可以为1S(秒)、2S、3S、4S、5S等，设备在预设时间段内的位移可以表征设备的速度。技术方案A3可以适用于与位置有关的场景，此种情况下，可以根据设备在预设时间段内的位移，确定是否符合触发条件。具体地，若设备在预设时间段内的位移不超过位置阈值，如设备静止，则可以不符合触发条件；若设备在预设时间段内的位移超过位置阈值，则依据预设时间间隔判断是否符合触发条件，可选地，设备在预设时间段内的位移越大，则预设时间间隔越小，反之，设备在预设时间段内的位移越小，则预设时间间隔越大。

技术方案A4

技术方案A4中，所述步骤401依据设备的事件信息，判断是否符合触发条件的过程，具体可以包括：若检测到任务接收事件，则符合触发条件。

本申请实施例中，任务可用于触发场景检测，该任务可由本领域技术人员或者业务运营商确定。任务的信息可以包括：场景的信息，如场景的标识等。作为一种示例，任务可以与店铺“星巴克(西单大悦城店)”相关，任务的信息可以包括：店铺的信息，如店铺的名称、店铺的位置数据等。客户端可以将服务器下发的任务保存至任务列表，该任务列表对应的数据结构可以包括但不限于：队列、数组等。

需要说明的是，上述技术方案A1至技术方案A4为判断是否符合触发条件的可选实施例，实际上本领域技术人员可以根据实际应用需求，确定判断是否符合触发条件的具体过程，并且，上述触发条件可由服务器或者用户配置，例如，可以将触发条件配置在任务的配置信息中，本申请实施例对于具体的触发条件不加以限制。

综上，本申请实施例的数据处理方法，判断是否符合场景检测条件可以对应有触发条件，本申请实施例依据设备的事件信息，判断是否符合触发条件，这样，可以依据设备的事件信息，智能地调整触发条件，不仅可以降低设备耗费的资源，而且可以提升用户的使用体验。

方法实施例三

参照图5，示出了本申请的一种数据处理方法实施例三的步骤流程图，具体可以包括如下步骤：

步骤501、判断是否符合场景检测条件；

步骤502、若符合场景检测条件，则确定用于检测所述场景的场景检测代码、以及所述场景检测代码对应的环境数据；

步骤503、执行所述场景检测代码；其中，在所述场景检测代码的执行过程中，依据所述环境数据和设备的数据，检测设备是否处于所述场景。

相对于图2所示方法实施例一，图5所示实施例通过步骤502和步骤503 细化了检测设备是否处于所述场景的过程。

本申请实施例中，场景检测代码用于进行场景检测，也即用于检测设备是否处于某种场景。本申请实施例的场景检测代码具有动态性，其可被服务器动态下发给客户端，以使客户端利用该场景检测代码进行场景检测，进而可以根据场景检测结果提供场景对应的服务；由于场景检测代码可支持到客户端的添加和更新，因此可以缩短场景所对应服务的实现周期，且可以提高场景检测的灵活性和扩展性。

本申请实施例中，代码可以指程序员用开发工具所支持的语言写出来的源文件，是一组由字符、符号或信号码元以离散形式表示信息的明确的规则体系。

在本申请的一种实施例中，场景检测代码的类型可以包括：解释型代码。解释型代码可以指可被解释执行的代码。解释型代码的例子可以包括： JavaScript(JS)脚本代码、JAVA代码等。解释型代码可由解析引擎解释执行，而可以不被编译，因此可以增强场景检测代码的添加和更新的便利性，进而可以缩短场景检测代码的实现周期。

在本申请的另一种实施例中，场景检测代码的类型可以包括：编译型代码。与场景检测代码的种类(可执行场景检测代码在特定情况下会涉及场景检测代码种类)无关，所述编译型代码可被理解成其包括在可执行场景检测代码的运行过程中能由一个或多个计算模块或处理模块来读取并执行/运行的指令。本领域技术人员知晓术语“编译型代码”和“指令”的含义。编译型代码是例如应用程序、软件程序或软件系统的代码。编译型代码可以为二进制形式的代码，在实际应用中，可以预先将例如C++的代码编译为编译型代码。

解释型代码或者编译型代码与具体的语言无关，故可以使得场景检测代码具有跨语言和跨平台的特性；因此，本申请实施例的场景检测代码可以不关注平台的具体实现，故能够很好地与平台解耦，这样，可以使不同平台基于该场景检测代码进行场景检测，因此本申请实施例的场景检测代码具有跨平台的特性，方便场景检测的移植。

在本申请的一种可选实施例中，步骤502确定场景检测代码、以及所述场景检测代码对应的环境数据的过程，具体可以包括：对任务的信息与场景检测代码的信息进行匹配；依据匹配结果，确定场景检测代码、以及所述场景检测代码对应的环境数据。

本申请实施例中，客户端可以接收服务器下发的任务，该任务可用于触发场景检测，该任务可由本领域技术人员或者业务运营商确定。任务的信息可以包括：场景的信息，如场景的标识等。作为一种示例，任务可以与店铺“星巴克(西单大悦城店)”相关，任务的信息可以包括：店铺的信息，如店铺的名称、店铺的位置数据等。客户端可以将服务器下发的任务保存至任务列表，该任务列表对应的数据结构可以包括但不限于：队列、数组等。

场景检测代码的信息中也可以包括：场景的信息。因此可以对任务的信息与场景检测代码的信息进行匹配，将匹配成功的场景检测代码作为任务对应的场景检测代码、也即需要执行的场景检测代码。

在本申请的一种实施例中，在对任务的信息与场景检测代码的信息进行匹配之前，可以利用调度算法，对任务列表中的任务进行调度，以得到目标任务，则可以对目标任务的信息与场景检测代码的信息进行匹配。其中，调度算法依据的因素可以包括但不限于：任务的优先级、任务的资源配额等。

其中，优先级是在处理多个任务的情况下、决定一个任务接受处理的优先等级的参数，通常优先级高的被优先处理。资源配额可用于对任务所占用资源进行控制，该资源配额可以为任务所占用资源的上限等，上述资源包括但不限于：流量、计算负荷、功耗等。在实际应用中，若一个任务实际占用的资源超过资源配额，则该任务可以不具备被调度的条件，否则，若一个任务实际占用的资源未超过资源配额，则该任务具备被调度的条件。

步骤503执行步骤502确定的场景检测代码，以得到对应的执行数据。

根据一种实施例，场景检测代码可以为解释型代码，则可以利用解释引擎，执行所述场景检测代码。解释引擎的例子可以包括：JavaScript引擎，可以利用JavaScript引擎执行JS脚本代码。

根据另一种实施例，场景检测代码可以为编译型代码，编译型代码可被携带在后缀为.so(共享对象，shared object)的文件中，则客户端100可以直接执行.so文件。

本申请实施例在所述场景检测代码的执行过程中，依据所述环境数据和设备的数据，检测所述设备是否处于所述场景检测代码对应的场景。可选地，设备的数据可以包括：设备的传感器数据。传感器是一种检测装置，能感受到被测量的信息，并能将感受到的信息，按一定规律变换成为电信号或其他所需形式的信息输出，以满足信息的传输、处理、存储、显示、记录和控制等要求。上述传感器可以包括但不限于：加速度传感器、GPS传感器、重力传感器、指纹传感器、气压传感器、心率传感器、距离传感器、空气质量传感器、温度传感器等，可以理解，本申请实施例对于具体传感器不加以限制。

在本申请的一种可选实施例中，可以预先设置传感器接口，以通过调用该传感器接口，获取设备的传感器数据。传感器接口可以位于HAL(硬件抽象层，HardwareAbstraction Layer)或者HAL以上，可以隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台,使其具有硬件无关性,可在多种平台上进行移植。

可选地,依据所述环境数据和设备的数据，检测所述设备是否处于所述场景检测代码对应的场景的过程，具体可以包括：对所述环境数据和设备的传感器数据进行匹配，若匹配成功，则确定所述设备处于所述场景检测代码对应的场景。

以兴趣点场景为例，环境数据可以为兴趣点对应的位置数据(如经纬度数据、基站数据、WIFI数据等)，设备的传感器数据可以为设备的位置数据，则可以对兴趣点对应的位置数据与设备的位置数据进行匹配。

以设备状态场景为例，可以将设备的预设状态数据与设备的实时状态数据进行匹配。例如，对于车辆超速场景，将车辆的速度上限与车辆的实时速度进行匹配；又如，对于车辆油量低场景，将车辆的油量下限与车辆的实时油量进行匹配；再如，对于家居设备状态场景，将家居设备的预设状态数据与家居设备的实时状态数据进行匹配等。

以模式场景为例，可以将模式对应的特征数据与设备的实时数据进行匹配。

在本申请的另一种可选实施例中，在执行场景检测代码之前，还可以对环境数据进行预处理，上述预处理可以对环境数据进行格式转换，以将环境数据转换为预设格式。该预设格式可以为与场景检测代码相匹配的格式，可以理解，本申请实施例对于具体的预设格式不加以限制。

本申请实施例得到执行数据可以包括如下数据中的至少一种：检测结果、检测依据数据、执行错误数据。其中，检测结果可以包括：处于场景、或者不处于场景；检测依据数据可以指检测所述设备是否处于所述场景检测代码对应的场景的依据；执行错误数据可以指在场景检测代码的执行出现错误的情况下，对应的错误数据。

在本申请的一种可选实施例中，在检测结果为处于场景的情况下，可以根据场景的配置，向设备的预设应用发送场景的信息，以使预设应用提供该场景对应的服务；或者，可以向服务器发送场景的信息，以使服务器进行二次检测，以检测所述设备是否处于所述场景检测代码对应的场景，此种情况下，可以接收服务器的二次检测结果，并依据该二次检测结果进行进一步处理。

在本申请的一种可选实施例中，本申请实施例的方法还可以包括：向服务器发送所述场景检测代码对应的执行数据。上述执行数据可以使服务器分析客户端上场景检测代码的执行情况。

综上，本申请实施例的数据处理方法，场景检测代码具有动态性，其可被服务器动态下发给客户端，以使客户端利用该场景检测代码进行场景检测，进而可以根据场景检测结果提供场景对应的服务；由于场景检测代码可支持到客户端的添加和更新，因此可以缩短场景所对应服务的实现周期，且可以提高场景检测的灵活性和扩展性。

并且，本申请实施例中，场景检测代码用于检测设备是否处于所述场景检测代码对应的场景，该场景检测代码便于添加和更新，且利于业务的扩展。

另外，场景检测代码的类型可以包括：编译型代码、或者解释型代码，编译型代码、或者解释型代码可以不受客户端上实现语言的影响，便于维护。

并且，本申请实施例便于场景检测代码的灰度发布。灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing(A/B 测试)，即让一部分用户继续用场景检测代码A，一部分用户开始用场景检测代码B，如果用户场景检测代码B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到场景检测代码B上面来。灰度发布可以提高产品的稳稳定性，在初始灰度的时候就可以发现、调整问题，以提高产品的影响度。

在本申请的一种应用示例中，假设业务运营商需要的场景A为：在车辆进入加油站并熄火的时候得到通知，以便推送信息，则本申请实施例的服务器可以挖掘出加油站的位置数据，编写对应的场景检测代码A，该场景检测代码A的检测依据为：判断车辆当前是否处于加油站的区域内、以及是否熄火，若是，则认为车辆处于场景；并向客户端下发该场景检测代码A、以及加油站的位置数据。

客户端在接收到该场景检测代码A、以及加油站的位置数据后，可以执行场景检测代码A，以检测设备是否处于场景A，若是，则向服务器或者预设应用发送检测结果，以使服务器或者预设应用向业务运营商发送对应的通知。

方法实施例四

参照图6，示出了本申请的一种数据处理方法实施例四的步骤流程图，具体可以包括如下步骤：

步骤601、从设备接收场景检测代码对应的执行数据；

步骤602、依据所述执行数据，对所述场景检测代码进行更新。

本申请实施例的方法包括的至少一个步骤可由服务器执行，服务器可以从客户端接收场景检测代码对应的执行数据，当然，本申请实施例对于步骤对应的具体执行主体不加以限制。

本申请实施例可以在服务器接入数据分析系统，该数据分析系统可用于分析客户端上场景检测代码的运行情况，以便更新和改进场景检测代码。

本申请实施例中，所述执行数据可以包括如下数据中的至少一种：检测结果、检测依据数据、执行错误数据。

在本申请的一种可选实施例中，上述步骤602依据所述执行数据，对所述场景检测代码进行更新的过程，包括：若所述设备的数据与所述检测结果不匹配，则对所述场景检测代码进行更新。

在本申请的一种实施例中，设备的数据可以来自设备本身，也可以来自第三方平台。第三方平台可以包括：第三方定位平台、第三方停车平台、第三方加油平台等，其中，第三方定位平台可以提供设备的轨迹数据，第三方停车平台可以提供车辆的停车数据，第三方加油平台可以提高车辆的加油数据，可以理解，本申请实施例对于具体的第三方平台不加以限制。

所述设备的数据与所述检测结果不匹配，包括：

1)设备的位置数据与所述检测结果不匹配；例如，检测结果与第三方定位平台提供的轨迹数据不匹配；又如，检测结果与第三方停车平台提供的停车数据不匹配等，具体地，检测结果为车辆进入停车场，而第三方停车平台反馈车辆并未进入停车场等等。

2)设备的行为数据与所述检测结果不匹配。例如，检测结果为车辆在某时间T1加过油，而第三方加油平台提供的加油数据表明：车辆在时间T1 并未加油等。

在本申请的一种可选实施例中，可以针对场景检测代码，确定设备的数据与所述检测结果不匹配的出现概率，并依据该出现概率，更新场景检测代码。

在本申请的一种应用示例中，服务器可以挖掘出景点的位置数据，获取景点的场景检测代码，并向客户端下发该场景检测代码。

进一步，服务器可以从客户端接收场景检测代码对应的执行数据，并依据所述执行数据，对所述场景检测代码进行更新。例如，场景检测代码B的检测依据为：判断车辆原来不在景点内部，现在在景点内部；则对车辆的轨迹数据与场景检测代码B的检测结果进行发现，发现存在：车辆未进入景点但检测到车辆进入景点的情况，此种情况下，可能说明针对景点挖掘得到的位置数据不精准、或者设备的定位结果存在偏差，故可以进一步改进景点的位置数据、或者优化设备的定位算法。

可选地，可以对场景检测代码B的检测依据进行改进，将场景检测代码B的检测依据修改为：判断车辆的轨迹点是否横穿景点的大门。在更新场景检测代码B后，可以向客户端下发更新后的场景检测代码B’、以及环境数据，以使客户端利用场景检测代码B’，进行场景检测。

在本申请的另一种可选实施例中，在执行数据包括执行错误数据的情况下，可以检测场景检测代码的逻辑，并依据相应的检测结果对场景检测代码的逻辑进行更新。

综上，本申请实施例的数据处理方法，可以依据客户端上传的场景检测代码的执行数据，确定场景检测代码的运行情况，以便依据该运行情况更新和改进场景检测代码。

参照图7，示出了本申请实施例的一种数据处理系统的结构示意图，具体可以包括：服务器701和客户端702；

其中，客户端702可以包括：数据交互模块721、运行时机模块722、传感器抽象模块723、任务调度模块724、场景检测模块725和场景触发模块726；

其中，数据交互模块721与服务器701进行交互，具体地，数据交互模块721接收服务器701发送的任务，并向服务器701发送任务的执行数据。

运行时机模块722用于针对任务对应的场景，判断是否符合场景检测条件；其中，判断是否符合场景检测条件可以为低功耗粗感知的检测；并且，运行时机模块722可以根据触发条件和设备的事件信息，自适应动态地确定运行时间。

传感器抽象模块723，用于抽象传感器数据的获取接口，供运行时机模块722和场景检测模块725调用。

任务调度模块724用于对符合场景检测条件的任务进行调度；可选地，可以按照任务的优先级对任务进行调度。

场景检测模块725，用于检测设备是否处于所述场景；具体地，可以执行所述场景检测代码；其中，在所述场景检测代码的执行过程中，依据所述环境数据和设备的数据，检测设备是否处于所述场景。场景检测模块725可以得到检测结果，并向场景触发模块726发送检测结果。

场景触发模块726，用于依据检测结果进行场景触发，具体地，可以根据任务的配置信息，向预设应用发送任务的信息，或者，可以向服务器701 发送任务的信息，以使服务器701检测设备是否处于所述场景，以得到更为精确的检测结果。可以理解，服务器701还可以向数据交互模块721发送更为精确的检测结果。

综上，本申请实施例提出可配置、运行时机可自适应调整的运行时机模块722，达到低功耗智能感知的目的。

参照图8，示出了本申请实施例的一种数据处理系统的交互示意图，其具体可以包括：应用层、系统服务层、云服务层、云数据查询层和云数据挖掘层；

其中，应用层可以包括：业务方也即业务运营商方对应的应用；

系统服务层可以包括：代码生成模块801、数据挖掘模块802、运行时机模块803、任务调度模块804、代码执行模块805、场景触发模块806、第一定位模块807和数据采集模块809；

其中，代码生成模块801用于生成场景检测代码；

数据挖掘模块802用于挖掘场景对应的环境数据；

运行时机模块803、任务调度模块804、代码执行模块805和场景触发模块806，可以参照图7，在此不作赘述。其中，运行时机模块803可由任务触发；代码执行模块805利用的数据可以包括：场景检测代码、场景指纹 (例如店铺的WIFI指纹)和场景对应传感器数据等，其中场景指纹和场景对应的传感器数据可以作为场景对应的环境数据；场景触发模块806可以按照服务器下发的动作配置，进行触发通知；运行时机模块803和代码执行模块805可以从传感器获取所需的数据。

第一定位模块807用于进行客户端所对应设备的定位；

数据采集模块809用于采集用户通过设备产生的行为数据，包括但不限于：POI数据、店铺数据、个人行为数据等。

需要说明的是，系统服务层的代码生成模块801和数据挖掘模块802位于服务器，系统服务层的运行时机模块803、任务调度模块804、代码执行模块805、场景触发模块806、第一定位模块807和数据采集模块809位于客户端。

云服务层的模块可以位于服务器端，该服务器可以为云服务器，云服务层可以包括：第二定位模块808、数据收集模块810和场景智能感知模块811； 3个模块分别与客户端进行交互，以采集客户端的定位数据、行为数据和场景数据。

可选地，数据挖掘模块802与场景智能感知模块811之间的传输通道可以包括但不限于：Https(安全套接字层超文本传输协议，Hyper Text Transfer Protocol overSecure Socket Layer)、cmns(连接模式网络服务， connection-mode network service)等。

云数据挖掘层可用于收集客户端产生的行为数据。云数据查询层可用于对上述行为数据进行存储，存储所采用的数据库可以包括：RDS(关系型数据库服务，RelationalDatabase Service)模型、Tair(分布式数据库)等。

综上，本申请实施例通过运行时机模块803解决功耗和实时感知的矛盾，可以达到持续感知的效果，又可以降低设备的功耗、流量。具体地，运行时机模块803在场景附近在激活场景检测，其他时间只进行低频低功耗的场景区域探知检测，故解决场景检测低功耗、高实时的矛盾。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

本申请实施例还提供了一种数据处理装置。

参照图9，示出了本申请的一种数据处理装置实施例的结构框图，具体可以包括如下模块：

第一判断模块901，用于判断是否符合场景检测条件；以及

场景检测模块902，用于在符合场景检测条件的情况下，检测设备是否处于所述场景；

其中，所述场景可以包括：兴趣点场景，所述第一判断模块901可以包括：

第一判断子模块911，用于判断设备是否处于所述兴趣点所对应周围网络的覆盖范围内。

可选地，所述周围网络的覆盖范围与所述兴趣点对应的周围区域相匹配。

可选地，所述周围网络的使用频率或者出现频率符合频率条件。

可选地，所述周围网络的类型可以包括：移动网络和/或无线保真网络。

可选地，所述场景还可以包括：设备状态场景，所述设备可以包括：车辆，所述第一判断模块901还可以包括：

第二判断子模块，用于判断所述车辆所在的道路上是否存在测速装置。

可选地，所述场景还可以包括：模式场景，所述设备可以包括：车辆，所述第一判断模块901还可以包括：

第三判断子模块，用于判断所述车辆所在道路的拥堵概率是否超过概率阈值。

第四判断子模块，用于判断车辆所处的位置与预置居所的位置之间的距离是否小于距离阈值。

第五判断子模块，用于判断所述车辆所在道路的事故频率是否超过第二频率阈值。

可选地，所述场景检测模块902可以包括：

确定子模块，用于确定用于检测所述场景的场景检测代码、以及所述场景检测代码对应的环境数据；以及

代码执行子模块，用于执行所述场景检测代码；其中，在所述场景检测代码的执行过程中，依据所述环境数据和设备的数据，检测设备是否处于所述场景。

可选地，所述场景可以包括：兴趣点场景，所述环境数据可以包括：所述兴趣点对应的位置数据；或者

所述场景可以包括：设备状态场景，所述环境数据可以包括：所述设备的预设状态数据；或者

所述场景可以包括：模式场景，所述环境数据可以包括：所述模式对应的特征数据。

可选地，所述装置还可以包括：

发送模块，用于向服务器发送所述场景检测代码对应的执行数据。

可选地，所述执行数据可以包括如下数据中的至少一种：检测结果、检测依据数据、执行错误数据。

可选地，所述第一判断模块901可以包括：

第六判断子模块，用于针对任务对应的场景，判断是否符合场景检测条件。

可选地，所述场景检测模块902可以包括：

添加子模块，用于若任务对应的场景符合场景检测条件，则将任务添加至调度列表；

目标任务确定子模块，用于从所述调度列表中确定目标任务；以及

检测子模块，用于检测设备是否处于所述目标任务对应的场景。

本申请实施例的实施例可被实现为使用任意适当的硬件和/或软件进行想要的配置的系统或装置。图10示意性地示出了可被用于实现本申请中所述的各个实施例的示例性装置1100。

对于一个实施例，图10示出了示例性装置1100，该装置1100可以包括：一个或多个处理器1102、与处理器1102中的至少一个耦合的系统控制模块(芯片组)1104、与系统控制模块1104耦合的系统存储器1106、与系统控制模块1104耦合的非易失性存储器(NVM)/存储装置1108、与系统控制模块1104耦合的一个或多个输入/输出设备1110，以及与系统控制模块1106 耦合的网络接口1112。该系统存储器1106可以包括：指令1162，该指令1162 可被一个或多个处理器1102执行。

处理器1102可包括一个或多个单核或多核处理器，处理器1102可包括通用处理器或专用处理器(例如图形处理器、应用程序处理器、基带处理器等)的任意组合。在一些实施例中，装置1100能够作为本申请实施例中所述的服务器、目标设备、无线设备等。

在一些实施例中，装置1100可包括具有指令的一个或多个机器可读介质(例如，系统存储器1106或NVM/存储装置1108)以及与该一个或多个机器可读介质相合并被配置为执行指令、以实现前述装置包括的模块、从而执行本申请实施例中所述的动作的一个或多个处理器1102。

一个实施例的系统控制模块1104可包括任何适合的接口控制器，用于提供任何适合的接口给处理器1102中的至少一个和/或与系统控制模块1104 通信的任意适合的装置或部件。

一个实施例的系统控制模块1104可包括一个或多个存储器控制器，用于提供接口给系统存储器1106。存储器控制器可以是硬件模块、软件模块和/或固件模块。

一个实施例的系统存储器1106可被用于加载和存储数据和/或指令 1162。对于一个实施例，系统存储器1106可包括任何适合的易失性存储器，例如，适合的DRAM(动态随机存取存储器)。在一些实施例中，系统存储器1106可包括：双倍数据速率类型四同步动态随机存取存储器 (DDR4SDRAM)。

一个实施例的系统控制模块1104可包括一个或多个输入/输出控制器，以向NVM/存储装置1108及(一个或多个)输入/输出设备1110提供接口。

一个实施例的NVM/存储装置1108可被用于存储数据和/或指令1182。 NVM/存储装置1108可包括任何适合的非易失性存储器(例如闪存等)和/或可包括任何适合的(一个或多个)非易失性存储设备，例如，一个或多个硬盘驱动器(HDD)、一个或多个光盘(CD)驱动器和/或一个或多个数字通用光盘 (DVD)驱动器等。

NVM/存储装置1108可包括在物理上是装置1100被安装在其上的装置的一部分的存储资源，或者其可被该装置访问而不必作为该装置的一部分。例如，NVM/存储装置1108可经由网络接口1112通过网络和/或通过输入/输出设备1110进行访问。

一个实施例的(一个或多个)输入/输出设备1110可为装置1100提供接口以与任意其他适当的设备通信，输入/输出设备1110可以包括通信组件、音频组件、传感器组件等。

一个实施例的网络接口1112可为装置1100提供接口以通过一个或多个网络和/或与任何其他适合的装置通信，装置1100可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信，例如接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合进行无线通信。

对于一个实施例，处理器1102中的至少一个可与系统控制模块1104的一个或多个控制器(例如，存储器控制器)的逻辑封装在一起。对于一个实施例，处理器1102中的至少一个可与系统控制模块1104的一个或多个控制器的逻辑封装在一起以形成系统级封装(SiP)。对于一个实施例，处理器 1102中的至少一个可与系统控制模块1104的一个或多个控制器的逻辑集成在同一新品上。对于一个实施例，处理器1102中的至少一个可与系统控制模块1104的一个或多个控制器的逻辑集成在同一芯片上以形成片上系统 (SoC)。

在各个实施例中，装置1100可以包括但不限于：台式计算设备或移动计算设备(例如，膝上型计算设备、手持计算设备、平板电脑、上网本等)等计算设备。在各个实施例中，装置1100可具有更多或更少的组件和/或不同的架构。例如，在一些实施例中，装置1100可以包括一个或多个摄像机、键盘、液晶显示器(LCD)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(ASIC)和扬声器。

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

本申请实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在装置时，可以使得该装置执行本申请实施例中各方法的指令(instructions)。

在一个示例中提供了一种装置，包括：一个或多个处理器；和，其上存储的一个或多个机器可读介质中的指令，由所述一个或多个处理器执行时，导致所述装置执行如本申请实施例中的方法，该方法可以包括：图2或图3 或图4或图5或图6或图7或图8所示的方法。

在一个示例中还提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如本申请实施例中的方法，该方法可以包括：图2或图3或图4或图5或图6或图7或图8所示的方法。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本申请实施例是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理装置的处理器以产生一个机器，使得通过计算机或其他可编程数据处理装置的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理装置以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理装置上，使得在计算机或其他可编程装置上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程装置上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者装置中还存在另外的相同要素。

以上对本申请所提供的一种数据处理方法、一种数据处理装置、一种装置、以及一种机器可读介质，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种数据处理方法，其特征在于，包括：

判断是否符合场景检测条件；

若符合场景检测条件，则检测设备是否处于所述场景；

2.根据权利要求1所述的方法，其特征在于，所述周围网络的覆盖范围与所述兴趣点对应的周围区域相匹配。

3.根据权利要求1所述的方法，其特征在于，所述周围网络的使用频率或者出现频率符合频率条件。

4.根据权利要求1所述的方法，其特征在于，所述周围网络的类型包括：移动网络和/或无线保真网络。

5.根据权利要求1所述的方法，其特征在于，所述场景还包括：设备状态场景，所述设备包括：车辆，所述判断是否符合场景检测条件，包括：

判断所述车辆所在的道路上是否存在测速装置。

6.根据权利要求1所述的方法，其特征在于，所述场景还包括：模式场景，所述设备包括：车辆，所述判断是否符合场景检测条件，还包括：

判断所述车辆所在道路的拥堵概率是否超过概率阈值。

7.根据权利要求1所述的方法，其特征在于，所述场景还包括：设备状态场景，所述设备包括：车辆，所述判断是否符合场景检测条件，还包括：

判断车辆所处的位置与预置居所的位置之间的距离是否小于距离阈值。

8.根据权利要求1所述的方法，其特征在于，所述场景还包括：模式场景，所述设备包括：车辆，所述判断是否符合场景检测条件，还包括：

判断所述车辆所在道路的事故频率是否超过第二频率阈值。

9.根据权利要求1至8中任一所述的方法，其特征在于，所述检测设备是否处于所述场景，包括：

确定用于检测所述场景的场景检测代码、以及所述场景检测代码对应的环境数据；

执行所述场景检测代码；其中，在所述场景检测代码的执行过程中，依据所述环境数据和设备的数据，检测设备是否处于所述场景。

10.根据权利要求9所述的方法，其特征在于，所述场景包括：兴趣点场景，所述环境数据包括：所述兴趣点对应的位置数据；或者

所述场景包括：设备状态场景，所述环境数据包括：所述设备的预设状态数据；或者

所述场景包括：模式场景，所述环境数据包括：所述模式对应的特征数据。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

向服务器发送所述场景检测代码对应的执行数据。

12.根据权利要求11所述的方法，其特征在于，所述执行数据包括如下数据中的至少一种：检测结果、检测依据数据、执行错误数据。

13.根据权利要求1至8中任一所述的方法，其特征在于，所述判断是否符合场景检测条件，包括：

针对任务对应的场景，判断是否符合场景检测条件。

14.根据权利要求1至8中任一所述的方法，其特征在于，所述若符合场景检测条件，则检测设备是否处于所述场景，包括：

若任务对应的场景符合场景检测条件，则将任务添加至调度列表；

从所述调度列表中确定目标任务；

检测设备是否处于所述目标任务对应的场景。

15.一种数据处理装置，其特征在于，包括：

第一判断模块，用于判断是否符合场景检测条件；以及

16.根据权利要求15所述的装置，其特征在于，所述周围网络的覆盖范围与所述兴趣点对应的周围区域相匹配。

17.根据权利要求15所述的装置，其特征在于，所述周围网络的使用频率或者出现频率符合频率条件。

18.根据权利要求15所述的装置，其特征在于，所述周围网络的类型包括：移动网络和/或无线保真网络。

19.根据权利要求15所述的装置，其特征在于，所述场景还包括：设备状态场景，所述设备包括：车辆，所述第一判断模块还包括：

20.根据权利要求15所述的装置，其特征在于，所述场景还包括：模式场景，所述设备包括：车辆，所述第一判断模块还包括：

21.根据权利要求15所述的装置，其特征在于，所述场景还包括：设备状态场景，所述设备包括：车辆，所述第一判断模块还包括：

22.根据权利要求15所述的装置，其特征在于，所述场景还包括：模式场景，所述设备包括：车辆，所述第一判断模块还包括：

23.根据权利要求15至22中任一所述的装置，其特征在于，所述场景检测模块包括：

24.根据权利要求23所述的装置，其特征在于，所述场景包括：兴趣点场景，所述环境数据包括：所述兴趣点对应的位置数据；或者

25.根据权利要求23所述的装置，其特征在于，所述装置还包括：

26.根据权利要求25所述的装置，其特征在于，所述执行数据包括如下数据中的至少一种：检测结果、检测依据数据、执行错误数据。

27.根据权利要求15至22中任一所述的装置，其特征在于，所述第一判断模块包括：

28.根据权利要求15至22中任一所述的装置，其特征在于，所述场景检测模块包括：

29.一种装置，其特征在于，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行如权利要求1-14中一个或多个所述的方法。

30.一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如权利要求1-14中一个或多个所述的方法。