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_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设置为 GNSS 适配器/HLOS 来进行通信
GNSS 适配器将发出GNSS_ResetGeofenceTracking命令，并使用每个地理围栏的当前进入/退出条件重新添加当前活动地理围栏。 若要跟踪的地理围栏集已更改或处于任何地理围栏已更改状态，则需要执行此作。
要求
| 要求 | 价值 |
|---|---|
| 标头 | gnssdriver.h |