通过

GNSS_GEOFENCE_STATE枚举 (gnssdriver.h)

  • 项目

GNSS_GEOFENCE_STATE枚举单个地理围栏的各种状态。

语法

typedef enum {
  GNSS_GeofenceState_Unknown,
  GNSS_GeofenceState_Entered,
  GNSS_GeofenceState_Exited
} GNSS_GEOFENCE_STATE;

常量

 
GNSS_GeofenceState_Unknown
地理围栏的状态未知。
GNSS_GeofenceState_Entered
已输入地理围栏。
GNSS_GeofenceState_Exited
地理围栏已退出。

注解

HLOS 使用以下位掩码来请求地理围栏的状态更改警报：

#define GNSS_GEOFENCEALERTTYPE_ENTRY  GNSS_GeofenceState_Entered    // Enter Geofence
#define GNSS_GEOFENCEALERTTYPE_EXIT   GNSS_GeofenceState_Exited     // Exit Geofence

当地理围栏的上一个状态未知或退出，并且设备现在已进入地理围栏时，将引发入口警报。

当进入地理围栏的以前状态且设备现在已退出地理围栏时，将引发退出警报。 如果地理围栏以前的状态未知，并且设备当前位于地理围栏之外，则不会生成退出警报。

仅当围栏的上一个已知状态在围栏内时，位置平台才会向应用发送退出触发器。 这是一个设计决策，以避免地理围栏配置上的退出事件聊天 (例如，当不期望在家配置退出围栏的用户需要收到通知时，如果他们已经不在家) 配置通知。 不过，位置平台可以处理 GNSS 驱动程序发送退出事件的位置，但不建议这样，因为 GNSS 适配器和 GNSS 驱动程序之间的交互将变得非常详细。 鉴于用户进入地理围栏的可能性远小于地理围栏外部的用户，此行为可减少 GNSS 驱动程序与 GNSS 适配器之间所需的交互。 例如，如果推送到 GNSS 驱动程序有 100 个地理围栏，并且用户位于所有地理围栏之外，如果没有此行为，则需要向 GNSS 适配器 100 发送退出通知。 在入口事件中发生类似情况的可能性非常小。

地理围栏状态转换和关联的警报如下所示。 为简单起见，隐含滞后和地理围栏边界条件。

GNSS 地理围栏状态图。

此状态图的关键方面包括：

  • 从GNSS_GeofenceState_Unknown转换到GNSS_GeofenceState_Exited状态时，不会引发警报。

  • 当 GNSS 引擎根本无法跟踪任何地理围栏时，需要引发单个全局跟踪状态警报，而不是针对每个地理围栏引发一个警报。 GNSS 引擎可以保留每个围栏的最后一个已知状态，而不是转换为GNSS_GeofenceState_Unknown状态，以便在能够再次跟踪时，可以根据新的进入/退出检测引发所需的地理围栏警报。

    但是，目前没有必要保持此最新已知状态，因为一旦 GNSS 驱动程序引发gnss_geofences_tracking_status为 FAILURE 的事件，HLOS 中的位置平台将开始执行地理围栏跟踪。 在此期间，如果可以再次跟踪地理围栏，则 GNSS 引擎应继续以电源优化的方式检查。 IHV 可以使用优化在低功耗下进行此检测。 用于优化的常见技术包括：

    • 渐进式后退

    • 等待指示设备移动的低成本信号，例如加速器数据或手机网络/WiFi 更改通知。

    • 使用公共地理位置 WinRT API 从 HLOS 请求低准确度距离跟踪会话。

    • 卫星信号的低功耗检查。

    当 GNSS 引擎能够再次跟踪地理围栏时，它会通过将gnss_geofence_tracking_status设置为 SUCCESS 到 GNSS 适配器/HLOS 来进行通信

    GNSS 适配器将发出GNSS_ResetGeofenceTracking命令，并使用每个地理围栏的当前进入/退出条件重新添加当前活动的地理围栏。 如果要跟踪的地理围栏集已更改或处于任何地理围栏的状态已更改，则需要执行此操作。

要求

要求 值
Header gnssdriver.h