CN114741256A - 传感器监听方法、装置及终端设备 - Google Patents

Abstract

本申请提供了传感器监听方法、装置及终端设备，适用于数据处理技术领域，该方法包括：获取待监听传感器的第一传感器标识，以及待监听传感器关联的第一监听器信息，第一传感器标识为待监听传感器的唯一标识。获取第一映射表，并将第一传感器标识和第一监听器信息关联存储至第一映射表。对待监听传感器进行使能。从第一映射表中获取第一监听器信息，并确定第一监听器信息指向的第一监听器。利用第一监听器，对待监听传感器进行数据监听。本申请实施例可以实现对传感器高效灵活的监听。

Description

传感器监听方法、装置及终端设备

技术领域

本申请涉及传感器监听领域，尤其涉及一种传感器监听方法、装置及终端设备。

背景技术

安卓(Android)系统可以分为四层，从上至下分别为应用程序层，应用程序框架层(简称框架层)，系统运行库层以及内核层。框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。安卓系统API对传感器进行了统一抽象，并在框架层对传感器进行统一的监听管理。

监听管理可以包括注册监听和取消注册监听。其中，当应用程序需要获取某个传感器的数据时，会调用注册监听的API，并由框架层将传感器和监听器的信息添加至事件队列，实现对传感器的订阅监听。当需要获取多个传感器的数据时，则需要框架层将每个传感器以及对应的监听器，依次添加到事件队列中，以实现对多个传感器的订阅监听。相应的，若需要取消订阅监听某个传感器，则需要调用取消监听的API，由框架层将传感器及对应的监听器从事件队列中移除。上述方式虽然可以实现对传感器的监听管理，但监听管理的效率和有效性均较低，难以满足日益增长的用户需求。

发明内容

有鉴于此，本申请实施例提供了传感器监听方法、装置及终端设备，可以解决对传感器监听管理效率较低的问题。

本申请实施例的第一方面提供了一种传感器监听方法，包括：

获取待监听传感器的第一传感器标识，以及待监听传感器关联的第一监听器信息，第一传感器标识为待监听传感器的唯一标识。

获取第一映射表，并将第一传感器标识和第一监听器信息关联存储至第一映射表。

对待监听传感器进行使能。

从第一映射表中获取第一监听器信息，并确定第一监听器信息指向的第一监听器。

利用第一监听器，对待监听传感器进行数据监听。

在本申请实施例中，针对每个需要进行传感器数据获取的应用程序，均会创建映射表。在应用程序需要对某个传感器(每次处理的监听传感器数量为1)进行监听时。本申请实施例会将传感器标识和监听器信息记录至映射表。在成功记录至映射表之后，本申请实施例会利用监听器信息指向的监听器对传感器进行监听。

相对现有技术而言，本申请实施例优势在于：1、在每次需要进行传感器监听时，可以不重新创建映射表，只需要再对存储的映射表进行数据更新即可。因此监听操作更为高效且简单易行。2、映射表中可以记录大量的映射关系。且对于单个传感器而言，可以同时记录其对应的一个或多个监听器。因此即使所需监听的传感器数量较多，也不会出现溢出的情况。使得对传感器监听的性能更为可靠，稳定性更好。3、在映射表中，实现了对单个传感器级别的映射关系记录。因此在进行监听管理时，可以做到对单个传感器级别的精细管理，灵活性更高。适用的场景更加丰富。

在第一方面的第一种可能的实现方式中，获取待监听传感器的第一传感器标识，包括：

获取待监听传感器的第一传感器信息。

根据第一传感器信息，获取待监听传感器的第一传感器标识。

在本申请实施例中，通过传感器信息的方式确定传感器标识。使得应用程序仅需告知操作系统所需监听的传感器的信息即可，由操作系统实现对标识的确。因此对应用程序更为友好，也使得本申请实施例适用性更强，可以适用于更多应用程序。

在第一方面的第二种可能的实现方式中，在对待监听传感器进行使能的操作之前，还包括：

获取待监听传感器的第一传感器参数。

获取第二映射表，并将第一传感器标识和第一传感器参数关联存储至第二映射表。

对待监听传感器进行使能，包括：

根据第二映射表中的第一传感器参数，对待监听传感器进行使能。

本申请实施例会将传感器标识和传感器参数记录至映射表，以记录应用程序对该传感器的参数要求，如采样频率和上报延时等。在成功记录至映射表，并记录对应的传感器参数要求之后，再基于参数要求来进行传感器使能。因此本申请实施例可以利用参数要求使能传感器，精确满足不同应用程序对传感器监听的实际需求。相对仅能统一对一类传感器进行监听的方式而言，监听的灵活度高，且可以有效降低传感器功耗。

在第一方面的第一种或第二种可能的实现方式的基础上，作为第一方面的第三种可能实现的方式，将第一传感器标识和第一监听器信息关联存储至第一映射表，包括：

识别第一映射表中是否存在第一传感器标识。

若第一映射表中不存在第一传感器标识，则在第一映射表中关联存储第一传感器标识和第一监听器信息。

若第一映射表中存在第一传感器标识，则识别第一映射表中，第一传感器标识关联的监听器信息内是否包含第一监听器信息。

若第一传感器标识关联的监听器信息内不包含第一监听器信息，则将第一监听器信息添加至第一传感器标识关联的监听器信息内。

针对应用程序未订阅待监听传感器，以及应用程序订阅了待监听传感器，但是利用了其他监听器监听该传感器，两种映射表不包含传感器标识和监听器信息的映射关系的情况。本申请实施例依次进行了识别和处理，使得本申请实施例可以有效的记录传感器标识和监听器信息的映射关系。

在第一方面的第二种可能的实现方式的基础上，作为第一方面的第四种可能实现的方式，将第一传感器标识和第一传感器参数关联存储至第二映射表，包括：

识别第二映射表中是否存在第一传感器标识。

若第二映射表中不存在第一传感器标识，则在第二映射表中关联存储第一传感器标识和第一传感器参数。

若第二映射表中存在第一传感器标识，则识别第二映射表中，第一传感器标识关联的传感器参数，与第一传感器参数是否相同。

若第一传感器标识关联的传感器参数与第一传感器参数不相同，则根据第一传感器参数，更新第二映射表中第一传感器标识关联的传感器参数。

针对应用程序未设置过待监听传感器的参数，以及设置过待监听传感器的参数，但此次设置的参数与前一次的不同，两种参数映射表不包含传感器标识与传感器参数映射关系的情况。本申请实施例一次进行了识别和处理，使得本申请实施例可以有效记录传感器标识和传感器参数的映射关系。

在第一方面的第一种至第四种可能的实现方式的基础上，作为第一方面的第四种可能实现的方式，待监听传感器为应用程序所需使用的传感器，在对待监听传感器进行数据监听的过程中，包括：

获取应用程序的第一数据。

若第一数据中包含第二传感器信息和第二监听器信息，则根据第二传感器信息获取第三传感器标识。

对第三传感器标识指向的传感器取消使能。

从第一映射表内第三传感器标识关联的监听器信息中，删除第二监听器信息。

在本申请实施例中，应用程序可以根据需求传入所需取消订阅的相关数据(即第一数据)。若需要精确取消对某一个或几个监听器对一个或多个传感器的订阅监听，则应用程序可以同时将传感器信息和监听器信息传入操作系统。此时操作系统会根据传感器信息来确定对应的传感器标识，再对这些传感器标识对应的传感器取消使能。同时还会从映射表中，找出第三传感器标识，并从第三传感器标识关联的监听器信息中，删除第二监听器信息。从而实现对传感器的订阅监听的精确取消。

在第一方面的第一种至第五种可能的实现方式的基础上，作为第一方面的第六种可能实现的方式，待监听传感器为应用程序所需使用的传感器，在对待监听传感器进行数据监听的过程中，包括：

获取应用程序的第一数据。

若第一数据中包含第二监听器信息，且未包含传感器信息，则从第一映射表中筛选出第二监听器信息关联的第二传感器标识。

对第二传感器标识指向的传感器取消使能。

从第一映射表内删除第二监听器信息。

在本申请实施例中，应用程序可以根据需求传入所需取消订阅的相关数据(即第一数据)。若需要批量取消一些监听器对传感器的监听，则应用程序可以将这些监听器的监听器信息传入操作系统。此时操作系统会根据监听器信息来确定监听器监听的所有传感器。并会取消这些被监听的传感器的使能。同时会从映射表中删除这些监听器的监听器信息。从而实现了对监听器订阅监听传感器的批量取消。提高了取消订阅监听的效率。

应当说明地，第一方面的第五种和第六种可能实现方式可以结合应用。此时获取第一数据(即操作系统接收应用程序传入的第一数据)的步骤仅会执行一次。此时应用程序可以根据实际需求，灵活选用精确取消或者批量取消。使得取消订阅监听的操作更灵活高效。

在第一方面的第五种或第六种可能的实现方式的基础上，作为第一方面的第七种可能实现的方式，对单个传感器取消使能的过程，包括：

获取第二监听器信息指向的第二监听器。

获取该用于对该传感器进行数据监听的第三监听器。

若第三监听器中包含第二监听器以外的监听器，则不对该传感器取消使能，并判定对该传感器取消使能成功。

考虑到实际应用中，单个传感器可能会被多个监听器同时监听。其中包括两种可能的情况：1、单个应用程序通过多个不同的监听器监听同一传感器。2、多个应用程序通过不同的监听器监听同一传感器。

在这两种情况下，S502和S505在取消使能时，若直接取消对传感器的使能，会导致传感器的数据无法被其他监听器正常监听。从而使得应用程序难以正常使用传感器数据。为了解决这一问题，本申请实施例在取消使能之前，会先识别传感器标识是否还有其他对应的监听器。包含当前应用程序的监听器和其他应用程序的监听器。若存在其他监听器也在监听该传感器，则不对传感器进行取消使能，但会判定对传感器取消使能成功。从而使得其他监听器仍然可以正常进行传感器的数据监听。

本申请实施例的第二方面提供了一种传感器监听装置，包括：传感器API和传感器订阅管理。

传感器API，用于获取待监听传感器的第一传感器标识，以及待监听传感器关联的第一监听器信息，第一传感器标识为待监听传感器的唯一标识。

传感器订阅管理，用于获取第一映射表，并将第一传感器标识和第一监听器信息关联存储至第一映射表。

传感器订阅管理，还用于对待监听传感器进行使能。

传感器订阅管理，还用于从第一映射表中获取第一监听器信息，并确定第一监听器信息指向的第一监听器。

传感器订阅管理，还用于利用第一监听器，对待监听传感器进行数据监听。

本申请实施例的第三方面提供了一种终端设备，终端设备包括存储器、处理器，存储器上存储有可在处理器上运行的计算机程序，处理器执行计算机程序时，使得终端设备实现如上述第一方面中任一项传感器监听方法的步骤。

本申请实施例的第四方面提供了一种计算机可读存储介质，包括：存储有计算机程序，计算机程序被处理器执行时，使得终端设备实现如上述第一方面中任一项所述传感器监听方法的步骤。

本申请实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述传感器监听方法。

本申请实施例的第六方面提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述第一方面任一项所述的传感器监听方法。

其中，芯片系统可以是单个芯片或者，多个芯片组成的芯片模组。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请一实施例提供的传感器监听方法的流程示意图；

图2是本申请一实施例提供的传感器监听方法的流程示意图；

图3是本申请一实施例提供的应用场景示意图；

图4是本申请一实施例提供的传感器监听方法的流程示意图；

图5是本申请一实施例提供的取消监听方法的流程示意图；

图6是本申请一实施例提供的传感器监听方法所适用于的手机的结构示意图；

图7是本申请一实施例提供的终端设备的软件结构框图；

图8A是本申请一实施例提供的终端设备的软件结构框图；

图8B是本申请一实施例提供的终端设备的软件结构框图；

图8C是本申请一实施例提供的应用场景示意图；

图9是本申请一实施例提供的传感器监听方法的流程示意图；

图10是本申请一实施例提供的取消监听方法的流程示意图；

图11是本申请实施例提供的传感器监听装置的结构示意图。

具体实施方式

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

为了便于理解本申请，此处先对本申请实施例进行简要说明：

现有技术中，安卓系统API会对传感器进行统一抽象，并在框架层对传感器进行统一的传感器监听管理。当应用程序需要获取某个传感器的数据时，会调用注册监听的API，并由框架层将传感器和监听器的信息添加至事件队列，实现对传感器的注册监听。当需要获取多个传感器的数据时，则需要框架层将每个传感器以及对应的监听器，依次添加到事件队列中，以实现对多个传感器的注册监听。相应的，若需要取消注册监听某个传感器，则需要调用取消监听的API，由框架层将传感器及对应的监听器从事件队列中移除。这种方式虽然可以实现对传感器的监听管理(在本申请实施例中，传感器的注册和订阅的含义相同。为了方便理解，在解释安卓系统时沿用了“注册”，本申请实施例后续均采用“订阅”来进行说明)，但存在以下几个问题：

1、单个应用程序仅能存在一条事件队列，每次需要对传感器订阅监听时均需重新建立事件队列。因此导致对传感器的监听操作繁琐。

2、当所需监听的传感器数量较多，使得对事件队列添加的内容较多时。事件队列容易溢出。因此使得对传感器的监听稳定性较差。

3、对传感器进行统一抽象过程，导致在对相同的传感器进行监听管理时，仅能统一监听或者统一取消订阅监听。例如当终端设备中包含多个加速度传感器时，仅能统一对这些加速度传感器进行订阅，以实现统一监听。或者统一从事件队列中删除，以实现统一取消订阅监听。因此导致对传感器监听管理的精细度和灵活度较低，无法满足实际应用的需求。

综上所述，现有技术对传感器监听管理的效率、稳定性、精细度和灵活度等均较低。

为了提升对传感器监听管理的效率等指标，在本申请实施例中，针对每个需要进行传感器数据获取的应用程序，均会创建映射表。在应用程序需要对某个传感器进行监听，并传入待监听的传感器信息和监听器信息时。本申请实施例会将传感器信息对应的传感器标识和监听器信息记录至映射表。同时还会记录应用程序对该传感器的参数要求，如采样频率和上报延时等。在成功记录至映射表，并记录对应的传感器参数要求之后。本申请实施例会根据映射表来使能所需监听的传感器，并按照传感器参数要求对传感器进行监听。

相对现有技术而言，本申请实施例优势在于：

1、利用映射表来存储传感器和监听器的对应关系，使得对于单个应用程序而言，可以通过存储映射表的方式，实现对传感器监听的持续记录和管理。在下一次需要进行传感器监听时，可以不重新创建映射表，只需要再对存储的映射表进行数据更新即可。因此监听操作更为高效且简单易行。

2、映射表中可以记录大量的映射关系。且对于单个传感器而言，可以同时记录其对应的一个或多个监听器。因此即使所需监听的传感器数量较多，也不会出现溢出的情况。使得对传感器监听的性能更为可靠，稳定性更好。

3、在映射表中，实现了对单个传感器级别的映射关系记录。因此在进行监听管理时，可以做到对单个传感器级别的精细管理，灵活性更高。适用的场景更加丰富。例如当终端设备中包含多个加速度传感器时，本申请实施例可以实现对各个加速度传感器的独立监听或者取消订阅监听。因此精细度和灵活度较高。

同时，对本申请实施例中可能涉及到的一些名词进行说明如下：

映射表：又名Map表。映射表是一个多行两列结构的表格，左列称为键(key)，右列称为值(value)。映射表以键-值(key-value)对的形式保存数据，以记录数据键和值之间的映射关系。即键与值之间存在映射关系。在利用映射表查询数据时，则是根据键查找对应的值。

在本申请实施例中，映射表包含监听映射表和参数映射表两类。其中监听映射表用于记录传感器和监听器之间的映射关系。参数映射表用于记录传感器和传感器参数之间的映射关系。具体而言，在监听映射表中，会将传感器标识作为监听映射表中的键，将监听器信息作为表中的值。当单个传感器被多个监听器监听时，单个键对应的值内可以包含多个监听器信息。在参数映射表中，则会将传感器标识作为监听映射表中的键，将传感器参数作为表中的值。

本申请实施例提供的传感器监听方法可以应用于手机、平板电脑、机器人和可穿戴设备等终端设备上，此时终端设备即为本申请实施例提供的传感器监听方法的执行主体。本申请实施例对终端设备的具体类型不作任何限制。另外应当说明地，终端设备中的运行的操作系统并不构成对本申请的限制。技术人员可根据实际需求，将本申请实施例结合至不同操作系统的终端设备中应用。例如可以应用至基于安卓系统的终端设备，或者基于鸿蒙系统的终端设备。

为了说明本申请所述的技术方案，下面按照传感器订阅监听、取消订阅监听和适用软硬件场景的顺序，依次通过具体实施例来进行说明。其中，在对传感器进行监听管理的过程中，包含应用程序、操作系统和传感器三个主要部分。本申请的各个方法实施例的流程步骤，主要由终端设备内的操作系统完成。

一、订阅监听。

图1示出了本申请实施例提供的传感器监听方法的实现流程图，详述如下：

S100，在获取到应用程序传入的传感器查询请求时，查询终端设备内的传感器列表，根据传感器列表生成查询结果，并将查询结果返回至应用程序。

当应用程序需要使用传感器的数据时，首先需要确认终端设备中是否存在应用程序所需的传感器。例如，假设运动类型的应用程序需要获取加速度传感器和计步传感器的数据，那首先需要确认终端设备中是否存在这两个传感器。若存在，才会开始对传感器的订阅监听。而当不存在时，则无法实现后续的订阅监听。在本申请实施例中，将应用程序所需使用的传感器称为待监听传感器，亦可称为第一传感器。

为了确认传感器是否存在，应用程序首先会向操作系统传入一个传感器查询请求。

操作系统在接收到应用程序的传感器查询请求之后，会获取终端设备的传感器列表。并会根据传感器列表生成查询结果，反馈给应用程序。传感器列表中记录有终端设备所有可用的传感器。

其中，考虑到实际情况中，终端设备内安装的传感器可能会由于损坏等原因无法使用。这些无法使用的传感器理论上无法为应用程序提供数据。因此在本申请实施例中，可用的传感器，可以是终端设备已安装的所有传感器。也可以仅是指已安装的传感器中，所有可用的传感器。具体可由技术人员自行设定。

在本申请实施例中，操作系统的查询操作，可以包含两种可能的场景：

场景1、传感器查询请求中包含所需查询的传感器的信息，例如可以包含传感器名称、类型或者编号等。以告知操作系统其所需使用的传感器。

操作系统在接收到传感器查询请求后，可以明确确定出具体所需查询传感器。在此基础上，操作系统可以从传感器列表中查找该传感器。若查找到，则将传感器的状态告知应用程序。以使得应用层在或者这些传感器可用。若未查找到，则告知应用程序终端设备中没有其所需的传感器。此时就无法进行后续的传感器订阅监听。

场景2、传感器查询请求中不包含所需查询的传感器的信息。

在该场景下，操作系统在接收到传感器查询请求后，会查询终端设备内的传感器列表。并会将传感器列表直接反馈给应用程序，由应用程序自行判断是否存在其所需的传感器。

S101，获取应用程序传入的第一传感器信息、第一监听器信息以及第一传感器参数。并获取第一传感器信息对应的第一传感器标识。

应用程序在查询出终端设备内具有其所需的传感器之后，会向操作系统申请订阅传感器的数据。此时应用程序首先需要告知操作系统，其所需订阅的传感器、所使用的监听器以及对传感器使能时的传感器参数(即第一传感器信息、第一监听器信息以及第一传感器参数，此时第一传感器信息是单个传感器的信息)。其中，传感器参数用于控制传感器在使能之后的数据采集和上报等行为。传感器参数具体包含的参数内容此处不做过多限定，可由技术人员根据实际设定。例如可以包含采样频率和上报延时(即在采集到数据后延时多久上报应用程序)中的任意一个或多个。通过传感器参数，可以实现对不同传感器的差异化监听管理，提高对传感器监听管理的精细度。例如，通过设置不同的采样频率，可以实现对两个不同加速度传感器的不同频率采样，以满足不同应用程序的实际需求。在一些可选实施例中，应用程序可以以传感器对象和监听器对象的方式，实现对传感器信息和监听器信息的传入。此时可以在传入的传感器对象中携带传感器信息，在传入的监听器对象中携带监听器信息。操作系统则从传感器对象和监听器对象中解析出传感器信息和监听器信息。

其中，本申请实施例不对应用程序确定传感器、监听器和传感器参数的方法进行过多限定。可由应用程序根据实际需求确定。例如应用程序可以根据用户的操作来确定这些数据，也可以根据开发人员预先设定的算法逻辑来确定这些数据。

在本申请实施例中，应用程序会将自身所需监听的传感器、所使用的监听器以及相应的传感器参数告知操作系统。为了使得操作系统能准确确定出传感器和监听器，应用程序会将传感器信息和监听器信息(即第一传感器信息和第一监听器信息)传入操作系统。其中，传感器信息可以是传感器的名称、类型或者编号等信息，监听器信息亦可以是监听器的名称、类型或者编号等信息。以使得操作系统可以根据传感器信息和监听器信息确定出对应的传感器和监听器。

考虑到实际情况中，终端设备内可能会同时安装有多个相同的传感器。例如可能会有多个接近光传感器。为了实现对各个传感器的准确区分，本申请实施例会为每个终端设备中的每个传感器均设置一个唯一的传感器标识。操作系统在获取到传感器信息之后，会查询出对应的传感器标识(即第一传感器标识)。若传感器信息指向的是多个一类传感器，例如接近光传感器。说明此时应用程序需要监听该类下所有的传感器。因此此时本申请实施例会获取该类下所有传感器的传感器标识。其中，在可以唯一区分出各个传感器的前提下，本申请实施例不对传感器标识的类型和设置规则做过多的限定，可由技术人员根据实际需求设定。例如可以是一串随机生成的字符串，也可以是按照一定规则生成的数字编号或者身份标识(Identity document，ID)等。

作为本申请的一个可选实施例，为了保障对传感器订阅监听的有效进行。在获取传感器标识之前，本申请实施例还会对应用程序传入的传感器信息、监听器信息和传感器参数进行合法性校验，以判断这些传入数据是否合法可用。当校验结果为传入数据合法时，执行获取传感器标识的步骤。若不合法，则告知应用程序数据不合法。例如传感器信息和监听器信息的对象为空时，则判定为不合法，此时不会执行后续的订阅监听操作。由应用程序重新传入传感器信息、监听器信息和传感器参数。

作为本申请的一个可选实施例，为了实现对传感器的精细化管理。在本申请实施例中会根据传感器的功能，将传感器分为6个大类别，分别为：环境类、光线类、运动类、方向类、健康类和其他类。

其中，环境类的传感器，主要包括可以对环境信息进行检测的传感器。例如可以包括：温度传感器、磁场传感器、未校准磁场传感器、湿度传感器、气压计和比吸收率传感器等。

光线类的传感器，主要包括可以对光线和颜色等进行检测的传感器。例如可以包括：接近光传感器、ToF传感器、环境光传感器、色温传感器、RGB传感器和XYZ传感器等。

运动类的传感器，主要包括可以对各类运动数据进行检测的传感器。例如可以包括：加速度传感器、未校准加速度传感器、线性加速度传感器、重力传感器、陀螺仪、未校准陀螺仪、有效运动传感器、可进行跌落检测的传感器、计步检测传感器和计步传感器等。

方向类的传感器，主要包括对方向数据进行检测的传感器。例如可以包括：6自由度的惯性传感器、方向传感器、设备方向传感器、可检测终端设备旋转矢量的传感器和可检测地磁旋转矢量的传感器等。

健康类的传感器，主要包括可检测用户生理数据的传感器。例如可以包括：心率传感器和佩戴检测传感器。

其他类的传感器，包括上面除5种类别以外的其他传感器。例如霍尔传感器、手握检测传感器、按压检测传感器和磁铁支架传感器等。

在本申请实施例中，传感器标识是指传感器的ID，且ID由至少3部分编号组成，该3部分分别为：大类别、小类型和索引。其中，大类别是指上述6个大类别，如是运动类还是健康类。小类型，是指传感器具体的传感器类型，如是加速度传感器、陀螺仪还是心率传感器。索引是指具体在是该小类型下的哪个传感器。例如假设有两个加速度传感器分别为加速度传感器1和加速度传感器2，此时索引可以是1或者2。又例如有两个陀螺仪，分别为陀螺仪A和陀螺仪B，则索引可以是A或者B。

本申请实施例不对大类别、小类型和索引中，各个部分的表征方式和长度进行过多限定，可由技术人员根据实际需求设定。例如在一些可选实施例中，可以将ID设置为由0和1组成的编码。此时可以通过不同的数字编码来实现对不同大类别、小类型和索引的区分。

例如，在一些可选实施例中，可以设置为大类别部分的长度为3、小类型部分的长度为6，索引长度为3。并设置以000、001、010、100、101和110来表征环境类、光线类、运动类、方向类、健康类和其他类。温度传感器、磁场传感器和气压计的编码为：000001、000010和000100。且温度传感器有温度传感器1和温度传感器2，编码分别为：000和001。此时对于温度传感器1而言，其ID为：000 000001 000，而温度传感器2的ID则为：000 000001 001。

在一些实施例中，根据实际需求，技术人员可以在ID的大类别、小类型和索引基础上，再加上一些部分。此时ID可以由3个以上的部分构成。例如可以在索引之后再加上默认位作为扩展位，用于后续扩展需要。此时ID由4部分的编码组成，该4部分分别为：大类别、小类型、索引和默认位。

另外，在本申请的一些实施例中，为了可以顺利的将传感器的数据传输给应用程序。在接收到应用程序传入的传感器信息、监听器信息和传感器参数之后，本申请实施例会建立一个数据通道。该数据通道用于传输传感器的数据。以使得应用程序可以获取到所需的传感器数据。在本申请实施例中，单个应用程序可由对应有一个或多个数据通道，以满足不同传感器的数据传输需求。作为本申请的一个可选实施例，可以设置为单个应用程序仅有一个数据通道。在此基础上，在接收到传感器信息、监听器信息和传感器参数时，若该已存在该应用程序对应的数据通道。则可以不再建立数据通道，而是使用已有的数据通道传输新订阅的传感器的数据。

作为本申请的一个可选实施例，为了实现对传感器的精细化管理，实现对每个大类别传感器的数据监听。在本申请实施例中，会将监听器也设置为6个类别，分别为：环境类、光线类、运动类、方向类、健康类和其他类。其中每类监听器仅用于监听对应类别的传感器。因此应用程序在选择监听器时，可以根据实际所需监听的传感器的情况，来选取合适的监听器。

S102，获取应用程序关联的第一映射表，并识别第一映射表中是否记录有第一传感器标识和第一监听器信息的映射关系。第一映射表的左列中记录有至少一条传感器标识，右列中记录有至少一条监听器信息。

为了实现对传感器的订阅监听，本申请实施例会以映射表的方式记录传感器和监听之间的关系。因此在获取到传感器标识和监听器信息之后，本申请实施例会将传感器标识作为键记录至监听映射表(即第一映射表)的左列，将监听器信息作为传感器标识对应的值，记录至监听映射表右列。从而实现对传感器标识和监听器信息的关联存储。

具体而言，考虑到可能会存在应用程序重复订阅的情况。即可能存在已经在监听映射表中记录了当前传感器的传感器标识以及对应的监听器信息。此时理论上无需在重复将两个数据存储至监听映射表。因此本申请实施例在获取到传感器标识和监听器信息之后，会获取应用程序关联的监听映射表。并判断监听映射表中是否记录有传感器标识和监听器信息的映射关系，即查找监听映射表中，是否存在键为该传感器标识，以及对应的值包含该监听器信息。若存在，则说明当前已经订阅完成，本申请实施例无需再重复订阅。若不存在，则需要进行订阅，此时会执行S103的操作。

作为本申请的一个实施例，考虑到当应用程序首次订阅传感器时，以及应用程序关联的监听映射表被删除时。均会导致终端设备内没有应用程序关联的监听映射表。此时本申请实施例会创建一个新的映射表作为该应用程序关联的监听映射表。并会将传感器标识和监听器信息，以键和值的方式记录至该监听映射表。

S103，若第一映射表中不包含第一传感器标识和第一监听器信息的映射关系，则在第一映射表内记录第一传感器标识和第一监听器信息的映射关系。

对于已经存在监听映射表的情况，不包含传感器标识和监听器信息的映射关系，存在两种情况：

情况1、应用程序未订阅该传感器，因此监听映射表中未记录传感器标识以及对应的监听器信息。

情况2、应用程序订阅了该传感器，但是利用了其他监听器监听该传感器。此时监听映射表中记录有传感器标识，但对应的监听器信息中却不包含本次传入的监听器信息(即第一监听器信息)。

对于情况1，此时需要将传感器标识作为键，将监听器信息作为传感器标识对应的值，记录至监听映射表。从而实现对传感器标识和监听器信息的映射关系记录。

对于情况2，此时需要在监听映射表内，将新的监听器信息加入至传感器标识对应的值之中，从而实现对传感器标识和监听器信息的映射关系记录。

其中，对传感器标识和监听器信息的映射关系记录，亦可称为将传感器标识和监听器信息关联存储至映射表之中。其实质即为将传感器标识和监听器信息，以键和对应的值的方式记录至该监听映射表。

本申请实施例不对传感器标识和监听器信息的添加方式做过多的限定。可由技术人员根据实际需求添加。例如对于情况1，可以是直接在监听映射表中添加新的行，用于记录此次的传感器标识和监听器信息。也可以是先创建一个传感器的监听器列表，并将传感器标识对应的监听器信息记录至该监听器列表。再将该监听器列表添加至监听器映射表之中。对于情况2，则可以是直接在监听映射表内查找传感器标识对应的值，并将监听器信息添加进去。

在本申请实施例中，将传感器标识作为监听映射表的键，将监听器列表诶监听映射表的值。从而实现对传感器与监听器映射关系的记录。此时一个传感器可以被一个或多个监听器监听。对应的映射表数据结构可以为：

Map<Integer，List<CoreSensorDataCallback>>sensorIdListener＝newConcurrentHashMap<>()。

作为本申请的一个可选实施例，对应于情况1和情况2，参考图2，S102和S103可以替换为：

S201，获取应用程序关联的第一映射表，并识别第一映射表内是否存在第一传感器标识。

S202，若不存在第一传感器标识，则在第一映射表内记录第一传感器标识和第一监听器信息的映射关系。

S203，若存在第一传感器标识，则识别第一映射表中，第一传感器标识对应的监听器信息内是否包含第一监听器信息。

S204，若不包含第一监听器信息，则在第一传感器标识对应的监听器信息内添加第一监听器信息。

本申请实施例针对两种可能的情况依次进行了识别和处理，使得本申请实施例可以有效的记录传感器标识和监听器信息的映射关系。

S102-S103实现了对传感器标识和监听器信息映射关系的记录，使得操作系统可以准确获知应该使用哪个监听器去监听此次的传感器。由于传感器标识是单个传感器的唯一标识。因此本申请实施例可以实现对单个传感器精度的传感器订阅监听。在应用程序进行一次或多次传感器订阅之后，对于单个应用程序而言，监听映射表中可能会记录有以下几种情况：

情况a、一个监听器仅监听一个传感器。

情况b、一个监听器同时监听多个传感器。

情况c、多个监听器同时监听同一传感器。

情况d、多个传感器同时监听多个传感器。

其中，情况d是情况b和c同时出现时的混合情况。

以一实例进行举例说明，可以参考图3。假设有3个监听器，分别为：监听器1、监听器2和监听器3，有3个传感器，分别为：传感器1、传感器2和传感器3。

图3中，图3中的(a)部分对应的是情况a，此时监听器1仅监听传感器1。

图3中的(b)部分对应的是情况b，此时监听器1同时监听传感器1、传感器2和传感器3。即传感器1、传感器2和传感器3对应的值中，均包含监听器1的监听器信息。

图3中的(c)部分对应的是情况c，此时监听器1、监听器2和监听器3同时监听传感器1。即传感器1对应的值中，同时包含监听器1、监听器2和监听器3的监听器信息。

图3中的(d)部分对应的是情况d，此时监听器1同时监听传感器1和传感器2，监听器2同时监听器传感器1、传感器2和传感器3。监听器3同时监听传感器2和传感器3。相应的传感器1对应的值中，同时包含监听器1和监听器2的监听器信息。传感器2对应的值中，同时包含监听器1、监听器2和监听器3的监听器信息。传感器3对应的值中，同时包含监听器2和监听器3的监听器信息。

因此本申请实施例可以实现监听器与传感器一对一、一对多、多对一和多对多的订阅监听。

S104，获取应用程序关联的第二映射表。第二映射表的左列中记录有至少一条传感器标识，右列中记录有至少一条传感器参数。

为了实现对传感器更为精细灵活的管理，本申请实施例中应用程序可以根据需求设置传感器参数。例如传感器的采样频率和上报延时。操作系统则会对应用程序传入的传感器参数以参数映射表的方式，记录传感器与传感器参数之间的关系，并以此进行传感器使能。具体而言，本申请实施例会在完成对监听映射表的操作之后，获取应用程序关联的参数映射表(即第二映射表)。

其中，若终端设备中不存在应用程序关联的参数映射表。说明应用程序还没有设置过传感器参数，此次是首次设置。或者是应用程序的参数映射表被删除了。例如在取消订阅后，参数映射表可能被删除。或者由于物理损坏等意外原因，导致终端设备内的数据丢失，使得参数映射表被删除。此时本申请实施例会创建一个新的映射表作为该应用程序关联的参数映射表。并会将传感器标识和传感器参数，以键和值的方式记录至该监听映射表。

本申请实施例不对传感器标识和传感器参数的添加方式做过多的限定。可由技术人员根据实际需求添加。可以是直接在参数映射表中添加新的行，用于记录此次的传感器标识和传感器参数。也可以是先创建一个传感器的参数列表，并将传感器标识对应的传感器参数记录至该参数列表。再将该参数列表添加至监听器映射表之中。

在本申请实施例中，将传感器标识作为参数映射表的键，将传感器参数作为参数映射表的值。从而实现对传感器与监听器映射关系的记录。此时同一个传感器每次订阅监听的传感器参数可以相同或不同。对应的映射表数据结构可以为：

Map<Integer，List<Long>>sensorIdParameter＝new ConcurrentHashMap<>()。

S105，根据第一传感器标识和第一传感器参数，更新第二映射表。

进行参数映射表更新，是指将传感器标识和传感器参数记录至参数映射表。对于已经存在参数映射表的情况，可分为情况：

情况1、应用程序未设置过该传感器的参数，此时参数映射表中未记录传感器标识及对应的传感器参数。

情况2、应用程序设置过该传感器的参数，但此次设置的参数与前一次的不同。此时参数映射表中已经记录了传感器标识及对应的传感器参数，但记录的传感器参数与此次获取到的传感器参数(即第一传感器参数)存在差异。

情况3、应用程序设置过该传感器的参数，且此次设置的参数与前一次相同。此时参数映射表中已经记录了传感器标识及对应的传感器参数，且与此次获取到的传感器标识和传感器参数(即第一传感器参数)相同。

情况1和情况2均是参数映射表不包含传感器标识与传感器参数映射关系的情况。

对于情况1，此时需要将传感器标识作为键，将传感器参数作为传感器标识对应的值，记录至参数映射表。从而实现对传感器标识和传感器参数的映射关系记录。

对于情况2，此时需要将传感器参数作为传感器标识对应的值，更新参数映射表。即覆盖原来的值。从而实现对传感器标识和传感器参数的映射关系记录。

对于情况3，此时无需再更新第一映射表。因此，更新的操作可以不执行。

S106，根据第二映射表中的第一传感器参数，对第一传感器标识指向的第一传感器进行使能。若使能成功，则判定对第一传感器标识指向的第一传感器订阅成功。

在完成对参数映射表的更新之后，本申请实施例会根据传感器参数来使能传感器。即开启传感器(此时无论传感器原本是否开启，都会指向该动作、因此对于已开启的传感器，则是重新开启。)，并设置对应的传感器参数，使得传感器可以按照传感器参数执行数据采集等操作。例如可以控制传感器开启后的采样频率和上报延时。对于参数映射表没有更新，且传感器已经使能了的情况，则可以不进行传感器使能。

当成功使能并设置传感器参数，说明此时已经成功订阅了传感器。此时可以开始对传感器数据的监听。因此会执行S107的操作。

其中，作为本申请的一个可选实施例，若使能失败，则可以重新尝试使能。

S107，识别第一映射表中第一监听器信息指向的第一监听器，并利用第一监听器对第一传感器进行数据监听。

完成传感器订阅之后，本申请实施例会利用应用程序选择的监听器(即第一监听器)来实现对传感器的数据监听。

在数据监听过程中，操作系统会获取传感器采集的数据，并通过数据通道传输给应用程序。以供应用程序使用。

作为本申请的一个可选实施例，图1所示实施例中，也可以不对传感器进行参数设置。参考图4，此时S101可以被替换为：

S401，获取应用程序传入的第一传感器信息和第一监听器信息，并获取第一传感器信息对应的第一传感器标识。

相应的，S104-S106可以被替换为：

S402，对第一传感器标识指向的第一传感器进行使能。若使能成功，则判定对第一传感器标识指向的第一传感器订阅成功。

在本申请实施例中，针对每个需要进行传感器数据获取的应用程序，均会创建监听映射表和参数映射表。在应用程序需要对某个传感器进行监听，并传入待监听的传感器信息、监听器信息和传感器参数时。本申请实施例会将传感器信息对应的传感器标识和监听器信息记录至监听映射表。同时还会记录传感器标识和传感器参数至参数映射表。其中，对于传感器而言，传感器标识可以唯一确定出单个传感器。在成功记录监听映射表和参数映射表之后。本申请实施例会根据映射表来使能所需监听的传感器，并按照传感器参数要求对传感器进行监听。

相对现有技术而言，本申请实施例优势在于：

1、利用映射表来存储传感器和监听器的对应关系，使得对于单个应用程序而言，可以通过存储映射表的方式，实现对传感器监听的持续记录和管理。在下一次需要进行传感器监听时，可以不重新创建映射表，只需要再对存储的映射表进行数据更新即可。因此监听操作更为简单易行。

2、映射表中可以记录大量的映射关系。且对于单个传感器而言，可以同时记录其对应的一个或多个监听器。因此即使所需监听的传感器数量较多，也不会出现溢出的情况。使得对传感器监听的性能更为可靠，稳定性更好。

3、在映射表中，实现了对单个传感器级别的映射关系记录。因此在进行监听管理时，可以做到对单个传感器级别的精细管理，灵活性更高。适用的场景更加丰富。例如当终端设备中包含多个加速度传感器时，本申请实施例可以实现对各个加速度传感器的独立监听或者取消订阅监听。因此精细度和灵活度较高。

4、可以通过设置传感器参数的方式，精确满足不同应用程序对传感器监听的实际需求。相对仅能统一对一类传感器进行监听的方式而言，监听的灵活度高，且可以有效降低传感器功耗。

以一实例进行举例说明。假设终端设备为手机，且手机中包含两个加速度传感器。若仅能对单类传感器进行统一监听管理，此时对两个加速度传感器仅能使用相同的采样频率进行采样。而使用本申请实施例，可以对两个不同的加速度传感器分别设置不同的采用频率。因此采样的灵活度更高，同时可以降低两个加速度传感器的总功耗。因此可以满足更多的场景需求。

二、取消订阅监听。

图5示出了本申请实施例提供的取消监听方法的实现流程图，详述如下：

S501，获取应用程序传入的第一数据。

在本申请实施例中，应用程序可以自行确定是否需要取消对某个传感器的监听。在确定之后，本申请实施例提供至少两种取消的模式：1、精确取消。2、批量取消。

对于模式1精确取消，需要应用程序输入具体的监听器信息和传感器信息。此时第一数据内同时包含第二传感器信息以及第二监听器信息。对于模式2批量取消。则仅需要应用程序输入具体的监听器信息，而无需再输入传感器信息。因此此时第一数据内仅包含第二监听信息即可。

S502，若第一数据中仅包含第二监听器信息，获取应用程序关联的第一映射表，并筛选出第二监听器信息对应的第二传感器标识。将第二传感器标识指向的第二传感器均取消使能。

对于应用程序仅传入监听器信息的情况，说明需要批量取消订阅监听。因此此时本申请实施例会筛选出所有对应包含传入监听器信息(即第二监听器信息)的值，并将这些值对应的键，均判定为需要取消订阅的传感器标识。再将这些传感器标识对应的传感器取消使能。即关闭传感器。

S503，删除第一映射表中的第二监听器信息。

在完成取消使能之后，本申请实施例还会将监听映射表中的监听器信息剔除，以实现批量取消订阅。

S504，若第一数据中同时包含第二传感器信息以及第二监听器信息，则获取第二传感器信息对应的第三传感器标识。

对于应用程序同时传入传感器信息和监听器信息的情况，本申请实施例会获取传入的传感器信息对应的传感器标识(即第三传感器标识)。

S505，将第三传感器标识指向的传感器取消使能。并删除第一映射表中，第三传感器标识对应的第二监听器信息。

在获取到待取消订阅的传感器标识之后，本申请实施例会将这些传感器标识对应的传感器全部取消使能。即关闭传感器。并会从监听映射表中剔除这些传感器标识对应的监听器信息。

S506，判断第一映射表中，第三传感器标识对应的监听器信息是否为空，若为空，则从第一映射表中删除第三传感器标识。

在剔除传感器标识对应的监听器信息之后，监听映射表中传感器标识对应的监听器信息可能会为空，即全部剔除。若为空，说明已经没有监听器负责对该传感器进行监听。因此此时本申请实施例会将监听映射表中，值为空的传感器标识内容进行剔除。

S507，判断第一映射表中，应用程序对应的传感器标识是否为空，若为空则销毁应用程序关联的数据通道。

在S503或者S506完成监听映射表的更新之后，本申请实施例会继续判断当前应用程序对应的传感器标识是否均为空。为空应用程序说明已经不需要进行传感器订阅监听。因此此时本申请实施例会销毁应用程序的数据通道。

若传感器标识不为空，说明当前应用程序仍需要进行传感器监听。此时本申请实施例可以不销毁应用程序的数据通道。

作为本申请的一个实施例，在销毁完数据通道，或者判定无需销毁数据通道后。操作系统均会判定对传感器取消订阅监听成功。并会返回一个取消订阅结果给应用程序，以告知对传感器取消订阅监听成功。

若不进行S507的操作，而是在S503或者S506完成监听映射表的更新之后完成取消订阅监听。此时本申请实施例会在S503或者S506完成监听映射表的更新之后，判定对传感器取消订阅监听成功。并会返回一个取消订阅结果给应用程序，以告知对传感器取消订阅监听成功。

应当特别说明地，考虑到实际应用中，单个传感器可能会被多个监听器同时监听。

其中包括两种可能的情况：

1、单个应用程序通过多个不同的监听器监听同一传感器。

2、多个应用程序通过不同的监听器监听同一传感器。

在这两种情况下，S502和S505在取消使能时，若直接取消对传感器的使能，会导致传感器的数据无法被其他监听器正常监听。从而使得应用程序难以正常使用传感器数据。为了解决这一问题，本申请实施例在取消使能之前，会先识别传感器标识是否还有其他对应的监听器。包含当前应用程序的监听器和其他应用程序的监听器。

若存在其他监听器也在监听该传感器，则不对传感器进行取消使能，但会判定对传感器取消使能成功。

在本申请实施例中，应用程序可以根据实际需求来选择单个或者批量对传感器取消订阅监听操作。操作系统在接收端应用程序传入的数据之后，会根据实际传入的数据情况，来自动识别是何种取消模式。同时对于多个监听器同时监听同一传感器的情况，在需要取消对传感器的使能时。则不会真的取消使能，则是不取消使能但判定为取消使能。从而使得其他监听器仍然可以正常进行传感器的数据监听。

三、适用软硬件场景。

针对本申请实施例适用的硬件场景：

在本申请实施例中，终端设备可以是手机等设备。下文以终端设备是手机为例，图6示出了手机100的结构示意图。

手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及SIM卡接口195等。其中传感器模块180可以包括陀螺仪传感器180A，加速度传感器180B，气压传感器180C，磁传感器180D，环境光传感器180E，接近光传感器180G、指纹传感器180H，温度传感器180J，触摸传感器180K(当然，手机100还可以包括其它传感器，比如温度传感器，压力传感器、距离传感器、气压传感器、骨传导传感器等，图中未示出)。

可以理解的是，本发明实施例示意的结构并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(Neural-network Processing Unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

处理器110可以运行本申请实施例提供的传感器监听方法，提升用户的体验。处理器110可以包括不同的器件，比如集成CPU和GPU时，CPU和GPU可以配合执行本申请实施例提供的传感器监听方法，比如传感器监听方法中部分算法由CPU执行，另一部分算法由GPU执行，以得到较快的处理效率。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，手机100可以包括1个或N个显示屏194，N为大于1的正整数。显示屏194可用于显示由用户输入的信息或提供给用户的信息以及各种图形用户界面(graphical user interface，GUI)。例如，显示器194可以显示照片、视频、网页、或者文件等。再例如，显示器194可以显示图形用户界面。其中图形用户界面上包括状态栏、可隐藏的导航栏、时间和天气小组件(widget)、以及应用的图标，例如浏览器图标等。状态栏中包括运营商名称(例如中国移动)、移动网络(例如4G)、时间和剩余电量。导航栏中包括后退(back)键图标、主屏幕(home)键图标和前进键图标。此外，可以理解的是，在一些实施例中，状态栏中还可以包括蓝牙图标、Wi-Fi图标、外接设备图标等。还可以理解的是，在另一些实施例中，图形用户界面中还可以包括Dock栏，Dock栏中可以包括常用的应用图标等。当处理器检测到用户的手指(或触控笔等)针对某一应用图标的触摸事件后，响应于该触摸事件，打开与该应用图标对应的应用的用户界面，并在显示器194上显示该应用的用户界面。

在本申请实施例中，显示屏194可以是一个一体的柔性显示屏，也可以采用两个刚性屏以及位于两个刚性屏之间的一个柔性屏组成的拼接显示屏。

摄像头193(前置摄像头或者后置摄像头，或者一个摄像头既可作为前置摄像头，也可作为后置摄像头)用于捕获静态图像或视频。通常，摄像头193可以包括感光元件比如镜头组和图像传感器，其中，镜头组包括多个透镜(凸透镜或凹透镜)，用于采集待拍摄物体反射的光信号，并将采集的光信号传递给图像传感器。图像传感器根据所述光信号生成待拍摄物体的原始图像。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，应用程序(比如相机应用，微信应用等)的代码等。存储数据区可存储手机100使用过程中所创建的数据(比如相机应用采集的图像、视频等)等。

内部存储器121还可以存储本申请实施例提供的传感器监听方法对应的一个或多个计算机程序1210。该一个或多个计算机程序1210被存储在上述存储器121中并被配置为被该一个或多个处理器110执行，该一个或多个计算机程序1210包括指令，上述指令可以用于执行如图1至图10相应实施例中的各个步骤，该计算机程序1210可以包括帐号验证模块1211、优先级比较模块1212。其中，帐号验证模块1211，用于对局域网内的其它终端设备的系统认证帐号进行认证；优先级比较模块1212，可用于比较音频输出请求业务的优先级和音频输出设备当前输出业务的优先级。状态同步模块1213，可用于将终端设备当前接入的音频输出设备的设备状态同步至其它终端设备，或者将其它设备当前接入的音频输出设备的设备状态同步至本地。当内部存储器121中存储的传感器监听方法的代码被处理器110运行时，处理器110可以控制终端设备进行传感器监听管理。

此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

当然，本申请实施例提供的传感器监听方法的代码还可以存储在外部存储器中。这种情况下，处理器110可以通过外部存储器接口120运行存储在外部存储器中的传感器监听方法的代码，处理器110可以控制终端设备进行传感器数据处理。

下面介绍传感器模块180的功能。

陀螺仪传感器180A，可以用于确定手机100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180A确定手机100围绕三个轴(即，x，y和z轴)的角速度。即陀螺仪传感器180A可以用于检测手机100当前的运动状态，比如抖动还是静止。

当本申请实施例中的显示屏为可折叠屏时，陀螺仪传感器180A可用于检测作用于显示屏194上的折叠或者展开操作。陀螺仪传感器180A可以将检测到的折叠操作或者展开操作作为事件上报给处理器110，以确定显示屏194的折叠状态或展开状态。

加速度传感器180B可检测手机100在各个方向上(一般为三轴)加速度的大小。即陀螺仪传感器180A可以用于检测手机100当前的运动状态，比如抖动还是静止。当本申请实施例中的显示屏为可折叠屏时，加速度传感器180B可用于检测作用于显示屏194上的折叠或者展开操作。加速度传感器180B可以将检测到的折叠操作或者展开操作作为事件上报给处理器110，以确定显示屏194的折叠状态或展开状态。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。手机通过发光二极管向外发射红外光。手机使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定手机附近有物体。当检测到不充分的反射光时，手机可以确定手机附近没有物体。当本申请实施例中的显示屏为可折叠屏时，接近光传感器180G可以设置在可折叠的显示屏194的第一屏上，接近光传感器180G可根据红外信号的光程差来检测第一屏与第二屏的折叠角度或者展开角度的大小。

陀螺仪传感器180A(或加速度传感器180B)可以将检测到的运动状态信息(比如角速度)发送给处理器110。处理器110基于运动状态信息确定当前是手持状态还是脚架状态(比如，角速度不为0时，说明手机100处于手持状态)。

指纹传感器180H用于采集指纹。手机100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于手机100的表面，与显示屏194所处的位置不同。

示例性的，手机100的显示屏194显示主界面，主界面中包括多个应用(比如相机应用、微信应用等)的图标。用户通过触摸传感器180K点击主界面中相机应用的图标，触发处理器110启动相机应用，打开摄像头193。显示屏194显示相机应用的界面，例如取景界面。

手机100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。手机100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在手机100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。在本申请实施例中，移动通信模块150还可以用于与其它终端设备进行信息交互。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在手机100上的包括无线局域网(wireless localarea networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。本申请实施例中，无线通信模块160可以用于接入接入点设备，向其它终端设备发送和接收消息。

另外，手机100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。手机100可以接收按键190输入，产生与手机100的用户设置以及功能控制有关的键信号输入。手机100可以利用马达191产生振动提示(比如来电振动提示)。手机100中的指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。手机100中的SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和手机100的接触和分离。

应理解，在实际应用中，手机100可以包括比图6所示的更多或更少的部件，本申请实施例不作限定。图示手机100仅是一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

针对本申请实施例适用的软件场景：

1、本申请实施例中的操作系统，可以是安卓系统。详述如下：

终端设备的软件操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明终端设备的软件结构。图7是本发明实施例的终端设备的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图7所示，应用程序包可以包括电话、相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图7所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供终端设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.164，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

2、本申请实施例中的操作系统，也可以是鸿蒙系统。详述如下：

鸿蒙系统采用分层设计的思想，自下而上分为：内核层、系统基础服务层、框架层、应用层，如图8A所示。每层的主要功能如下：

内核层：采用多内核设计，如Linux内核、微内核、LiteOS，并通过内核抽象层屏蔽多内核的差异，为上层提供基础的内核能力。

系统基础服务层：主要包含系统基本能力、基础软件服务、增强软件服务、基础硬件服务、专有硬件服务等部分，为框架层面向的应用提供基础服务。

框架层：主要为三方应用和系统应用提供接口，并在框架层提供API的具体实现方案。框架层在系统起到承上启下的作用，向上为应用程序提供基本的API，向下与系统的基础服务层进行通信。

应用层：主要包含系统应用和三方应用。

传感器属于鸿蒙系统的基础硬件部分，对应于图8A，传感器在鸿蒙系统中涉及的架构示意图，可参考图8B(图8B中的传感器硬件内容仅为示例，实际应用中，需根据终端设备真实的传感器安装情况来确定传感器硬件内包含的内容。例如可以仅包含霍尔传感器，也可以包含其他的传感器)。其中，框架层主要包含传感器API(Sensor API)和传感器框架(Sensor Framework)。

其中，传感器API向应用程序提供传感器的基础API，如查询设备上的传感器列表、订阅或取消订阅传感器的数据等。

传感器框架提供传感器订阅管理的具体实现方案，并与传感器的服务管理进行通信。

Sensor Framework主要有两部分组成：传感器的传感器订阅管理(基于Java的框架层)以及传感器服务管理(基于C++的native层)。

传感器订阅管理，用于对传感器进行订阅操作，主要提供获取传感器的列表、订阅/取消订阅传感器的数据等功能。

传感器服务管理，用于使能或者取消使能传感器，会对传感器基础服务层的SensorService模块接口进行封装，并与SensorService进行通信。

传感器管理模块，用于对传感器数据进行统一管理，以决定将传感器数据传输对象。实现对传感器数据流的控制。

传感器权限管控，用于对一些涉及到用户授权的数据管理，包括用户手动授权(比如敏感数据)，以及自动授权。

数据处理模块，用于对传感器数据进行封装，以使得传感器数据可以满足上层维度要求。

在图8B的基础上，框架层提供对传感器订阅监听的管理服务。即每一类传感器的订阅监听和取消订阅监听，统一是在框架层进行的。

在将传感器分为6个大类别，分别为：环境类、光线类、运动类、方向类、健康类和其他类的基础上，对传感器的订阅监听和取消订阅监听的架构示意图可以参考图8C。

结合鸿蒙系统进行应用时，参考图9，图1所示实施例的传感器监听操作可以替换为：

S9001，传感器API获取应用程序传入的传感器查询请求，并发送给传感器订阅管理。

S9002，传感器订阅管理向传感器服务管理请求终端设备内的传感器列表。

S9003，传感器服务管理查询终端设备内的传感器列表，并返回给传感器订阅管理。

S9001-S9003是S100操作的细化。

S901，传感器API获取应用程序传入的第一传感器信息、第一监听器信息以及第一传感器参数，并获取第一传感器信息对应的第一传感器标识。

S902，传感器订阅管理获取应用程序关联的第一映射表，并识别第一映射表中是否记录有第一传感器标识和第一监听器信息的映射关系。第一映射表的左列中记录有至少一条传感器标识，右列中记录有至少一条监听器信息。

S903，若第一映射表中不包含第一传感器标识和第一监听器信息的映射关系，则传感器订阅管理在第一映射表内记录第一传感器标识和第一监听器信息的映射关系。

S904，传感器订阅管理获取应用程序关联的第二映射表。第二映射表的左列中记录有至少一条传感器标识，右列中记录有至少一条传感器参数。

S905，传感器订阅管理根据第一传感器标识和第一传感器参数，更新第二映射表。

S906，传感器订阅管理根据第二映射表中的第一传感器参数，对第一传感器标识指向的第一传感器进行使能。若使能成功，则判定对第一传感器标识指向的第一传感器订阅成功。

其中，由传感器服务管理反馈对传感器的使能结果。

S907，传感器订阅管理识别第一映射表中第一监听器信息指向的第一监听器，并利用第一监听器对第一传感器进行数据监听。

数据监听的过程中，由传感器服务管理获取传感器数据，并发送给传感器订阅管理，再由传感器订阅管理通过传感器API发送给应用程序。

其中，S901-S907与S101-S107是一一对应的步骤。S9001-S907的操作原理、细节和有益效果等说明，均可以参考图1所示实施例的相关说明，此处不予赘述。

参考图10，图5所示实施例的取消监听操作可以替换为：

S1001，传感器API获取应用程序传入的第一数据，并发送给传感器订阅管理。

S1002，若第一数据中仅包含第二监听器信息，传感器订阅管理获取应用程序关联的第一映射表，并筛选出第二监听器信息对应的第二传感器标识。

传感器服务管理将第二传感器标识指向的第二传感器均取消使能。

由传感器服务管理向传感器订阅管理返回取消使能的结果。

S1003，传感器订阅管理删除第一映射表中的第二监听器信息。

S1004，若第一数据中同时包含第二传感器信息以及第二监听器信息，传感器订阅管理则获取第二传感器信息对应的第三传感器标识。

S1005，传感器订阅管理将第三传感器标识指向的传感器取消使能。

传感器订阅管理删除第一映射表中，第三传感器标识对应的第二监听器信息。

S1006，传感器订阅管理判断第一映射表中，第三传感器标识对应的监听器信息是否为空，若为空，则从第一映射表中删除第三传感器标识。

S1007，传感器订阅管理判断第一映射表中，应用程序对应的传感器标识是否为空，若为空则销毁应用程序关联的数据通道。

此时由传感器订阅管理，通过传感器API向应用程序反馈取消订阅监听的结果。

其中，S1001-S1007与S501-S507是一一对应的步骤。S1001-S1007的操作原理、细节和有益效果等说明，均可以参考图5所示实施例的相关说明，此处不予赘述。

四、传感器的数据分发过程。

在本申请实施例中，传感器的数据分发过程包括三部分：

1、操作系统获取传感器对应的监听器列表(可以在监听映射表中读取传感器标识对应的监听器信息，以确定对应的监听列表)，并判断是否有精度要求。

该精度要求可由应用程序根据实际需求传入。

2、操作系统获取传感器采集的数据，并对数据进行封装，得到封装后的传感器数据。

其中封装后的传感器数据，可以包括：时间戳、传感器的基本数据和传感器的精度数据。具体根据需求设定。

3、开始分发数据。

分发的数据主要包括两种：传感器的基本数据和精度数据。

对于精度有要求的传感器，此时需要同时分发基本数据和精度数据两种。此时封装后的传感器数据中需要同时包含基本数据和精度数据。

对于没有精度要求的，则可以仅分发基本数据。此时封装后的传感器数据中需要基本数据。

在分发过程中，由监听器对封装后的传感器数据进行分发，操作系统的传感器API会对监听器分发的数据进行回调，再由应用层对传感器API获取的数据进行回调，以传输给应用程序。

对应于上文实施例的传感器监听方法，图11示出了本申请实施例提供的传感器监听装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图11，该传感器监听装置包括：传感器API 11和传感器订阅管理12。

传感器API 11，用于获取待监听传感器的第一传感器标识，以及待监听传感器关联的第一监听器信息，第一传感器标识为待监听传感器的唯一标识。

传感器订阅管理12，用于获取第一映射表，并将第一传感器标识和第一监听器信息关联存储至第一映射表。

传感器订阅管理12，还用于对待监听传感器进行使能。

传感器订阅管理12，还用于从第一映射表中获取第一监听器信息，并确定第一监听器信息指向的第一监听器。

传感器订阅管理12，还用于利用第一监听器，对待监听传感器进行数据监听。

作为本申请的一个实施例，获取待监听传感器的第一传感器标识，包括：

获取待监听传感器的第一传感器信息。

根据第一传感器信息，获取待监听传感器的第一传感器标识。

作为本申请的一个实施例，传感器API 11，还用于：

获取待监听传感器的第一传感器参数。

传感器订阅管理12，还用于获取第二映射表，并将第一传感器标识和第一传感器参数关联存储至第二映射表。

对待监听传感器进行使能，包括：

根据第二映射表中的第一传感器参数，对待监听传感器进行使能。

作为本申请的一个实施例，将第一传感器标识和第一监听器信息关联存储至第一映射表，包括：

识别第一映射表中是否存在第一传感器标识。

若第一映射表中不存在第一传感器标识，则在第一映射表中关联存储第一传感器标识和第一监听器信息。

若第一映射表中存在第一传感器标识，则识别第一映射表中，第一传感器标识关联的监听器信息内是否包含第一监听器信息。

若第一传感器标识关联的监听器信息内不包含第一监听器信息，则将第一监听器信息添加至第一传感器标识关联的监听器信息内。

作为本申请的一个实施例，将第一传感器标识和第一传感器参数关联存储至第二映射表，包括：

识别第二映射表中是否存在第一传感器标识。

若第二映射表中不存在第一传感器标识，则在第二映射表中关联存储第一传感器标识和第一传感器参数。

若第二映射表中存在第一传感器标识，则识别第二映射表中，第一传感器标识关联的传感器参数，与第一传感器参数是否相同。

若第一传感器标识关联的传感器参数与第一传感器参数不相同，则根据第一传感器参数，更新第二映射表中第一传感器标识关联的传感器参数。

作为本申请的一个实施例，传感器API 11，还用于获取应用程序传入的第一数据，并发送给传感器订阅管理。

传感器订阅管理12，还用于若第一数据中包含第二传感器信息和第二监听器信息，则根据第二传感器信息获取第三传感器标识。

传感器订阅管理12，还用于对第三传感器标识指向的传感器取消使能。

传感器订阅管理12，还用于从第一映射表内第三传感器标识关联的监听器信息中，删除第二监听器信息。

作为本申请的一个实施例，传感器API 11，还用于获取应用程序传入的第一数据，并发送给传感器订阅管理。

传感器订阅管理12，还用于若第一数据中包含第二监听器信息，且未包含传感器信息，则从第一映射表中筛选出第二监听器信息关联的第二传感器标识。

传感器订阅管理12，还用于对第二传感器标识指向的传感器取消使能。

传感器订阅管理12，还用于从第一映射表内删除第二监听器信息。

作为本申请的一个实施例，传感器订阅管理12对单个传感器取消使能的过程，包括：

获取第二监听器信息指向的第二监听器。

获取该用于对该传感器进行数据监听的第三监听器。

若第三监听器中包含第二监听器以外的监听器，则不对该传感器取消使能，并判定对该传感器取消使能成功。

本申请实施例提供的传感器监听装置中各模块实现各自功能的过程，具体可参考前述图1至图10所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

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

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的传感器监听方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

例如，所述终端设备可以是WLAN中的站点(STAION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(Session InitiationProtocol，SIP)电话、无线本地环路(WirelessLocal Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，STB)、用户驻地设备(customer premise equipment，CPE)和/或用于在无线系统上进行通信的其它设备以及下一代通信系统，例如，5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端设备等。

作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

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

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

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

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

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

最后应说明的是：以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种传感器监听方法，其特征在于，包括：

获取待监听传感器的第一传感器标识，以及所述待监听传感器关联的第一监听器信息，所述第一传感器标识为所述待监听传感器的唯一标识；

获取第一映射表，并将所述第一传感器标识和所述第一监听器信息关联存储至所述第一映射表；

获取所述待监听传感器的第一传感器参数；

获取第二映射表，并将所述第一传感器标识和所述第一传感器参数关联存储至所述第二映射表；

根据所述第二映射表中的所述第一传感器参数，对所述待监听传感器进行使能；

从所述第一映射表中获取所述第一监听器信息，并确定所述第一监听器信息指向的第一监听器；

利用所述第一监听器，对所述待监听传感器进行数据监听。

2.根据权利要求1所述的传感器监听方法，其特征在于，所述获取待监听传感器的第一传感器标识，包括：

获取所述待监听传感器的第一传感器信息；

根据所述第一传感器信息，获取所述待监听传感器的所述第一传感器标识。

3.根据权利要求1所述的传感器监听方法，其特征在于，所述将所述第一传感器标识和所述第一监听器信息关联存储至所述第一映射表，包括：

识别所述第一映射表中是否存在所述第一传感器标识；

若所述第一映射表中不存在所述第一传感器标识，则在所述第一映射表中关联存储所述第一传感器标识和所述第一监听器信息；

若所述第一映射表中存在所述第一传感器标识，则识别所述第一映射表中，所述第一传感器标识关联的监听器信息内是否包含所述第一监听器信息；

若所述第一传感器标识关联的监听器信息内不包含所述第一监听器信息，则将所述第一监听器信息添加至所述第一传感器标识关联的监听器信息内。

4.根据权利要求1所述的传感器监听方法，其特征在于，所述将所述第一传感器标识和所述第一传感器参数关联存储至所述第二映射表，包括：

识别所述第二映射表中是否存在所述第一传感器标识；

若所述第二映射表中不存在所述第一传感器标识，则在所述第二映射表中关联存储所述第一传感器标识和所述第一传感器参数；

若所述第二映射表中存在所述第一传感器标识，则识别所述第二映射表中，所述第一传感器标识关联的传感器参数，与所述第一传感器参数是否相同；

若所述第一传感器标识关联的传感器参数与所述第一传感器参数不相同，则根据所述第一传感器参数，更新所述第二映射表中所述第一传感器标识关联的传感器参数。

5.根据权利要求1至4任意一项所述的传感器监听方法，其特征在于，所述待监听传感器为应用程序所需使用的传感器，在对所述待监听传感器进行数据监听的过程中，包括：

获取所述应用程序的第一数据；

若所述第一数据中包含第二传感器信息和第二监听器信息，则根据所述第二传感器信息获取第三传感器标识；

对所述第三传感器标识指向的传感器取消使能；

从所述第一映射表内所述第三传感器标识关联的监听器信息中，删除所述第二监听器信息。

6.根据权利要求1至4任意一项所述的传感器监听方法，其特征在于，所述待监听传感器为应用程序所需使用的传感器，在对所述待监听传感器进行数据监听的过程中，包括：

获取所述应用程序的第一数据；

若所述第一数据中包含第二监听器信息，且未包含传感器信息，则从所述第一映射表中筛选出所述第二监听器信息关联的第二传感器标识；

对所述第二传感器标识指向的传感器取消使能；

从所述第一映射表内删除所述第二监听器信息。

7.根据权利要求5或6所述的传感器监听方法，其特征在于，对单个传感器取消使能的过程，包括：

获取所述第二监听器信息指向的第二监听器；

获取该用于对该传感器进行数据监听的第三监听器；

若所述第三监听器中包含所述第二监听器以外的监听器，则不对该传感器取消使能，并判定对该传感器取消使能成功。

8.一种传感器监听装置，其特征在于，包括：传感器API和传感器订阅管理；

所述传感器API，用于获取待监听传感器的第一传感器标识，以及所述待监听传感器关联的第一监听器信息，所述第一传感器标识为所述待监听传感器的唯一标识；

所述传感器订阅管理，用于获取第一映射表，并将所述第一传感器标识和所述第一监听器信息关联存储至所述第一映射表；

所述传感器API，还用于获取所述待监听传感器的第一传感器参数；

所述传感器订阅管理，还用于获取第二映射表，并将所述第一传感器标识和所述第一传感器参数关联存储至所述第二映射表；

所述传感器订阅管理，还用于根据所述第二映射表中的所述第一传感器参数，对所述待监听传感器进行使能；

所述传感器订阅管理，还用于从所述第一映射表中获取所述第一监听器信息，并确定所述第一监听器信息指向的第一监听器；

所述传感器订阅管理，还用于利用所述第一监听器，对所述待监听传感器进行数据监听。

9.一种终端设备，其特征在于，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1至7任一项所述方法的步骤。

11.一种芯片系统，其特征在于，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至7任一项所述的传感器监听方法。

Images