【鸿蒙开发】第二十三章 Location位置服务

25 篇文章 2 订阅
25 篇文章 4 订阅

1 简介

移动终端设备已经深入人们日常生活的方方面面,如查看所在城市的天气、新闻轶事、出行打车、旅行导航、运动记录。这些习以为常的活动,都离不开定位用户终端设备的位置。

当用户处于这些丰富的使用场景中时,系统的位置能力可以提供实时准确的位置数据。对于开发者,设计基于位置体验的服务,也可以使应用的使用体验更贴近每个用户。

当应用在实现基于设备位置的功能时,如:驾车导航,记录运动轨迹等,可以调用该模块的API接口,完成位置信息的获取。

1.1 Location Kit简介

位置子系统使用多种定位技术提供服务,如GNSS定位、基站定位、WLAN/蓝牙定位(基站定位、WLAN/蓝牙定位后续统称“网络定位技术”);通过这些定位技术,无论用户设备在室内或是户外,都可以准确地确定设备位置。

Location Kit除了提供基础的定位服务之外,还提供了地理围栏、地理编码、逆地理编码、国家码等功能和接口

  • 坐标
    系统以1984年世界大地坐标系统为参考,使用经度、纬度数据描述地球上的一个位置。

  • GNSS定位
    基于全球导航卫星系统,包含:GPS、GLONASS、北斗、Galileo等,通过导航卫星、设备芯片提供的定位算法,来确定设备准确位置。定位过程具体使用哪些定位系统,取决于用户设备的硬件能力。

  • 基站定位
    根据设备当前驻网基站和相邻基站的位置,估算设备当前位置。此定位方式的定位结果精度相对较低,并且需要设备可以访问蜂窝网络。

  • WLAN、蓝牙定位
    根据设备可搜索到的周围WLAN、蓝牙设备位置,估算设备当前位置。此定位方式的定位结果精度依赖设备周围可见的固定WLAN、蓝牙设备的分布,密度较高时,精度也相较于基站定位方式更高,同时也需要设备可以访问网络。

1.2 运作机制

位置能力作为系统为应用提供的一种基础服务,需要应用在所使用的业务场景,向系统主动发起请求,并在业务场景结束时,主动结束此请求,在此过程中系统会将实时的定位结果上报给应用。

1.3 约束与限制

使用设备的位置能力,需要用户进行确认并主动开启位置开关。如果位置开关没有开启,系统不会向任何应用提供定位服务。

设备位置信息属于用户敏感数据,所以即使用户已经开启位置开关,应用在获取设备位置前仍需向用户申请位置访问权限。在用户确认允许后,系统才会向应用提供定位服务。

2 位置服务开发

2.1 申请位置权限开发指导

2.2.1 场景概述

应用在使用Location Kit系统能力前,需要检查是否已经获取用户授权访问设备位置信息。如未获得授权,可以向用户申请需要的位置权限。

系统提供的定位权限有:

  • ohos.permission.LOCATION:用于获取精准位置,精准度在米级别
  • ohos.permission.APPROXIMATELY_LOCATION:用于获取模糊位置,精确度为5公里
  • ohos.permission.LOCATION_IN_BACKGROUND:用于应用切换到后台仍然需要获取定位信息的场景。

访问设备的位置信息,必须申请权限,并且获得用户授权。

当前位置相关能力仅支持WGS-84坐标系。
在这里插入图片描述

如果应用在后台运行时也需要访问设备位置,需要申请ohos.permission.LOCATION_IN_BACKGROUND权限或申请LOCATION类型的长时任务,这样应用在切入后台之后,系统可以继续上报位置信息。

应用如需使用ohos.permission.LOCATION_IN_BACKGROUND权限,需要在设置界面由用户手动授予,具体授权方式可参考ohos.permission.LOCATION_IN_BACKGROUND权限说明。

长时任务申请可参考长时任务。

开发者可以在应用配置文件中声明所需要的权限,具体可参考申请应用权限。

2.2 获取设备的位置信息开发指导

2.2.1 场景概述

开发者可以调用OpenHarmony位置相关接口,获取设备实时位置,或者最近的历史位置。

2.2.2 接口说明

对于位置敏感的应用业务,建议获取设备实时位置信息。如果不需要设备实时位置信息,并且希望尽可能的节省耗电,开发者可以考虑获取最近的历史位置。
在这里插入图片描述

2.2.3 开发步骤

  1. 获取设备的位置信息,需要有位置权限,位置权限申请的方法和步骤见申请位置权限开发指导。
  2. 导入geoLocationManager模块,所有与基础定位能力相关的功能API,都是通过该模块提供的。
import geoLocationManager from '@ohos.geoLocationManager';
  1. 实例化LocationRequest对象,用于告知系统该向应用提供何种类型的定位服务,以及位置结果上报的频率。

1) 方式一
为了面向开发者提供贴近其使用场景的API使用方式,系统定义了几种常见的位置能力使用场景,并针对使用场景做了适当的优化处理,应用可以直接匹配使用,简化开发复杂度。系统当前支持场景如下表所示。

定位场景类型说明:

  • 导航场景:NAVIGATION
    适用于在户外定位设备实时位置的场景,如车载、步行导航。
    在此场景下,为保证系统提供位置结果精度最优,主要使用GNSS定位技术提供定位服务,结合场景特点,在导航启动之初,用户很可能在室内、车库等遮蔽环境,GNSS技术很难提供定位服务。
    为解决此问题,我们会在GNSS提供稳定位置结果之前,使用系统网络定位技术,向应用提供定位服务,以在导航初始阶段提升用户体验。
    此场景默认以最小1秒间隔上报定位结果,使用此场景的应用必须申请ohos.permission.LOCATION权限,同时获得用户授权。

  • 轨迹跟踪场景:TRAJECTORY_TRACKING
    适用于记录用户位置轨迹的场景,如运动类应用记录轨迹功能。主要使用GNSS定位技术提供定位服务。
    此场景默认以最小1秒间隔上报定位结果,并且应用必须申请ohos.permission.LOCATION权限,同时获得用户授权。

  • 出行约车场景:CAR_HAILING
    适用于用户出行打车时定位当前位置的场景,如网约车类应用。
    此场景默认以最小1秒间隔上报定位结果,并且应用必须申请ohos.permission.LOCATION权限,同时获得用户授权。

  • 生活服务场景:DAILY_LIFE_SERVICE
    生活服务场景,适用于不需要定位用户精确位置的使用场景,如新闻资讯、网购、点餐类应用,做推荐、推送时定位用户大致位置即可。
    此场景默认以最小1秒间隔上报定位结果,并且应用至少申请ohos.permission.LOCATION权限,同时获得用户授权。

  • 无功耗场景:NO_POWER
    无功耗场景,适用于不需要主动启动定位业务。系统在响应其他应用启动定位业务并上报位置结果时,会同时向请求此场景的应用程序上报定位结果,当前的应用程序不产生定位功耗。
    此场景默认以最小1秒间隔上报定位结果,并且应用需要申请ohos.permission.LOCATION权限,同时获得用户授权。

export enum LocationRequestScenario {
     UNSET = 0x300,
     NAVIGATION,
     TRAJECTORY_TRACKING,
     CAR_HAILING,
     DAILY_LIFE_SERVICE,
     NO_POWER,
 }

以导航场景为例,实例化方式如下:

let requestInfo:geoLocationManager.LocationRequest = {'scenario': geoLocationManager.LocationRequestScenario.NAVIGATION, 'timeInterval': 0, 'distanceInterval': 0, 'maxAccuracy': 0};

1) 方式二
如果定义的现有场景类型不能满足所需的开发场景,系统提供了基本的定位优先级策略类型。

定位优先级策略类型说明:

  • 定位精度优先策略:ACCURACY
    定位精度优先策略主要以GNSS定位技术为主,在开阔场景下可以提供米级的定位精度,具体性能指标依赖用户设备的定位硬件能力,但在室内等强遮蔽定位场景下,无法提供准确的定位服务。

  • 快速定位优先策略:FIRST_FIX
    快速定位优先策略会同时使用GNSS定位基站定位和WLAN蓝牙定位技术,以便室内和户外场景下,通过此策略都可以获得位置结果,当各种定位技术都有提供位置结果时,系统会选择其中精度较好的结果返回给应用。因为对各种定位技术同时使用,对设备的硬件资源消耗较大,功耗也较大。

  • 低功耗定位优先策略:LOW_POWER
    低功耗定位优先策略主要使用基站定位WLAN蓝牙定位技术,也可以同时提供室内和户外场景下的定位服务,因为其依赖周边基站、可见WLAN、蓝牙设备的分布情况,定位结果的精度波动范围较大,如果对定位结果精度要求不高,或者使用场景多在有基站、可见WLAN、蓝牙设备高密度分布的情况下,推荐使用,可以有效节省设备功耗。

export enum LocationRequestPriority {
     UNSET = 0x200,
     ACCURACY,
     LOW_POWER,
     FIRST_FIX,
 }

以定位精度优先策略为例,实例化方式如下:

let requestInfo:geoLocationManager.LocationRequest = {'priority': geoLocationManager.LocationRequestPriority.ACCURACY, 'timeInterval': 0, 'distanceInterval': 0, 'maxAccuracy': 0};
  1. 实例化Callback对象,用于向系统提供位置上报的途径。 应用需要自行实现系统定义好的回调接口,并将其实例化。系统在定位成功确定设备的实时位置结果时,会通过该接口上报给应用。应用程序可以在接口的实现中完成自己的业务逻辑。
let locationChange = (location:geoLocationManager.Location):void => {
    console.log('locationChanger: data: ' + JSON.stringify(location));
};
  1. 启动定位。
geoLocationManager.on('locationChange', requestInfo, locationChange);
  1. (可选)结束定位。

如果不主动结束定位可能导致设备功耗高,耗电快;建议在不需要获取定位信息时及时结束定位。

geoLocationManager.off('locationChange', locationChange);

如果应用使用场景不需要实时的设备位置,可以获取系统缓存的最近一次历史定位结果。

import geoLocationManager from '@ohos.geoLocationManager';
import BusinessError from "@ohos.base";
try {
    let location = geoLocationManager.getLastLocation();
} catch (err) {
    console.error("errCode:" + (err as BusinessError.BusinessError).code + ",errMessage:" + (err as BusinessError.BusinessError).message);
}

2.3(逆)地理编码转化开发指导

2.3.1 场景概述

使用坐标描述一个位置,非常准确,但是并不直观,面向用户表达并不友好。系统向开发者提供了以下两种转化能力。

  • 地理编码转化:将地理描述转化为具体坐标。
  • 逆地理编码转化能力:将坐标转化为地理描述。

其中地理编码包含多个属性来描述位置,包括国家、行政区划、街道、门牌号、地址描述等等,这样的信息更便于用户理解。

2.3.2 接口说明

进行坐标和地理编码信息的相互转化,所使用的接口说明如下。
在这里插入图片描述

2.3.3 开发步骤

说明: GeoConvert需要访问后端服务,请确保设备联网,以进行信息获取。

  1. 导入geoLocationManager模块,所有与(逆)地理编码转化能力相关的功能API,都是通过该模块提供的。
import geoLocationManager from '@ohos.geoLocationManager';
  1. 查询geoCoder服务是否可用。
  • 调用isGeoServiceAvailable查询geoCoder服务是否可用,如果服务可用再继续进行步骤3。
import geoLocationManager from '@ohos.geoLocationManager';
import BusinessError from "@ohos.base";
try {
    let isAvailable = geoLocationManager.isGeocoderAvailable();
} catch (err) {
    console.error("errCode:" + (err as BusinessError.BusinessError).code + ",errMessage:" + (err as BusinessError.BusinessError).message);
}
  1. 获取转化结果。
  • 调用getAddressesFromLocation,坐标转化地理位置信息。
let reverseGeocodeRequest:geoLocationManager.ReverseGeoCodeRequest = {"latitude": 31.12, "longitude": 121.11, "maxItems": 1};
try {
    geoLocationManager.getAddressesFromLocation(reverseGeocodeRequest, (err, data) => {
        if (err) {
            console.log('getAddressesFromLocation err: ' + JSON.stringify(err));
        } else {
            console.log('getAddressesFromLocation data: ' + JSON.stringify(data));
        }
    });
} catch (err) {
    console.error("errCode:" + (err as BusinessError.BusinessError).code + ",errMessage:" + (err as BusinessError.BusinessError).message);
}

参考接口API说明Location Kit,应用可以获得与此坐标匹配的GeoAddress列表,应用可以根据实际使用需求,读取相应的参数数据。

  • 调用getAddressesFromLocationName位置描述转化坐标。
let geocodeRequest:geoLocationManager.GeoCodeRequest = {"description": "上海市浦东新区xx路xx号", "maxItems": 1};
try {
    geoLocationManager.getAddressesFromLocationName(geocodeRequest, (err, data) => {
        if (err) {
            console.log('getAddressesFromLocationName err: ' + JSON.stringify(err));
        } else {
            console.log('getAddressesFromLocationName data: ' + JSON.stringify(data));
        }
    });
} catch (err) {
    console.error("errCode:" + (err as BusinessError.BusinessError).code + ",errMessage:" + (err as BusinessError.BusinessError).message);
}

参考接口API说明Location Kit,应用可以获得与位置描述相匹配的GeoAddress列表,其中包含对应的坐标数据,请参考API使用。

如果需要查询的位置描述可能出现多地重名的请求,可以设置GeoCodeRequest,通过设置一个经纬度范围,以高效地获取期望的准确结果。

2.4 地理围栏开发指导

2.4.1 场景概述

地理围栏就是虚拟地理边界,当设备进入、离开某个特定地理区域时,可以接收自动通知和警告。

目前仅支持圆形围栏,并且依赖GNSS芯片的地理围栏功能。

应用场景举例:开发者可以使用地理围栏,在企业周围创建一个区域进行广告定位,在不同的地点,在移动设备上进行有针对性的促销优惠。

2.4.2 接口说明

地理围栏所使用的接口如下,详细说明参见:Location Kit。
在这里插入图片描述

2.4.3 开发步骤

使用地理围栏功能,需要有权限ohos.permission.APPROXIMATELY_LOCATION,位置权限申请的方法和步骤见申请位置权限开发指导。

  1. 导入geoLocationManager模块、wantAgent模块和BusinessError模块。
import geoLocationManager from '@ohos.geoLocationManager';
import wantAgent, {WantAgent as _wantAgent} from '@ohos.app.ability.wantAgent';
import BusinessError from "@ohos.base";
  1. 创建WantAgentInfo信息。
  • 场景一:创建拉起AbilityWantAgentInfo信息。
let wantAgentObj:_wantAgent|null = null; // 用于保存创建成功的wantAgent对象,后续使用其完成触发的动作。

// 通过WantAgentInfo的operationType设置动作类型
let wantAgentInfo:wantAgent.WantAgentInfo = {
    wants: [
        {
            deviceId: '',
            bundleName: 'com.example.myapplication',
            abilityName: 'EntryAbility',
            action: '',
            entities: [],
            uri: '',
            parameters: {}
        }
    ],
    operationType: wantAgent.OperationType.START_ABILITY,
    requestCode: 0,
    wantAgentFlags:[wantAgent.WantAgentFlags.CONSTANT_FLAG]
};
  • 场景二:创建发布公共事件的WantAgentInfo信息。
let wantAgentObj:_wantAgent|null = null; // 用于保存创建成功的WantAgent对象,后续使用其完成触发的动作。

// 通过WantAgentInfo的operationType设置动作类型
let wantAgentInfo:wantAgent.WantAgentInfo = {
    wants: [
        {
            action: 'event_name', // 设置事件名
            parameters: {},
        }
    ],
    operationType: wantAgent.OperationType.SEND_COMMON_EVENT,
    requestCode: 0,
    wantAgentFlags: [wantAgent.WantAgentFlags.CONSTANT_FLAG],
}
  1. 调用getWantAgent()方法进行创建WantAgent

并且在获取到WantAgent对象之后调用地理围栏接口添加围栏,当设备进入或者退出该围栏时,系统会自动触发WantAgent的动作。

// 创建WantAgent
wantAgent.getWantAgent(wantAgentInfo, (err, data) => {
    if (err) {
      console.error('getWantAgent err=' + JSON.stringify(err));
      return;
    }
    console.info('getWantAgent success');
    wantAgentObj = data;
    let requestInfo:geoLocationManager.GeofenceRequest = {'scenario': 0x301, "geofence": {"latitude": 31.12, "longitude": 121.11, "radius": 100, "expiration": 10000}};
    try {
        geoLocationManager.on('gnssFenceStatusChange', requestInfo, wantAgentObj);
    } catch (err) {
        console.error("errCode:" + (err as BusinessError.BusinessError).code + ",errMessage:" + (err as BusinessError.BusinessError).message);
    }
});

参考文献:
[1]OpenHarmoney应用开发文档

  • 28
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
要选择最佳的服务中心位置,需要考虑多方面因素,如人口密度、交通便利度、竞争对手的位置、服务范围等等。因此,需要对所有区域进行分析和比较,以确定最适合的位置。 首先,需要收集每个区域的人口数量和密度数据。因为服务中心的主要服务对象是人群,所以考虑到人口密度很重要。人口数量多而密度高的区域,通常更适合选址服务中心。 其次,交通便利度也是考虑的一个重要因素。地理位置离主要道路和交通枢纽比较近的区域,能够更快更方便地为周围的居民提供服务。而交通不便的地方,往往需要更多时间和资源来提供服务,因此不太适合选址服务中心。 还需要考虑竞争对手的位置。如果在一个区域已经有其他服务中心提供类似的服务,那么设置不同的位置可能更好。在竞争激烈的区域,需要深入研究市场,确定自己的竞争优势,并选择一个更有前途的区域来设置服务中心。 最后,考虑服务范围。服务中心的地理位置应该越接近到服务的对象越好。为了能够更好地满足客户的需求,需要确定服务中心的范围,并根据这个范围来确定最佳的位置。 综上所述,选择最佳的服务中心位置需要综合考虑人口密度、交通便利度、竞争对手的位置、服务范围等多个因素。只要在这些因素的基础上进行准确地分析和比较,就可以确定最适合的服务中心位置,并将其返回所有区域。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

__Yvan

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值