一、前言：

大家好，我是完美句号！欢迎来到 HarmonyOS 5 开发实战系列。本系列致力于为开发者提供实用的技术方案和即拿即用的代码示例，帮助大家快速掌握 HarmonyOS Next 应用开发中的核心功能。在HarmonyOS 5鸿蒙系统中，基于Location Kit（位置服务），我们将深入探讨如何在HarmonyOS 5鸿蒙系统中实现精准的定位功能。

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

---

二、位置服务 Location Kit简介

移动终端设备已经深入人们日常生活的方方面面，如查看所在城市的天气、新闻、出行打车、旅行导航、运动记录。这些习以为常的活动，都离不开基于定位用户终端设备的位置。当应用在实现基于设备位置的功能时，如：驾车导航，记录运动轨迹等，可以调用该模块的API接口，完成位置信息的获取。位置子系统使用多种定位技术提供服务，如GNSS定位、基站定位、WLAN/蓝牙定位（基站定位、WLAN/蓝牙定位后续统称“网络定位技术”）；通过这些定位技术，无论用户设备在室内或是户外，都可以准确地确定设备位置。Location Kit除了提供基础的定位服务之外，还提供了地理围栏、地理编码、逆地理编码、国家码等功能和接口。

2.1 运行机制：

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

2.2 约束与限制：

使用设备的位置能力，需要用户进行确认并主动开启位置开关。如果位置开关没有开启，系统不会向任何应用提供定位服务。设备位置信息属于用户敏感数据，所以即使用户已经开启位置开关，应用在获取设备位置前仍需向用户申请位置访问权限。在用户确认允许后，系统才会向应用提供定位服务。

---

三、Location Kit开发指南：

申请位置权限，系统提供的定位权限有：

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

开发步骤：

• 1. 开发者可以在应用配置文件中声明所需要的权限并向用户申请授权
• 2. 当APP运行在前台，且访问设备位置信息时，申请位置权限的方式如下表所示

{
  "name": "ohos.permission.APPROXIMATELY_LOCATION",
  "reason": "$string:fuzzy_location_permission",
  "usedScene": {
    "abilities": [
      "EntryAbility"
    ],
    "when": "inuse"
  }
},
{
  "name": "ohos.permission.LOCATION",
  "reason": "$string:location_permission",
  "usedScene": {
    "abilities": [
      "EntryAbility"
    ],
    "when": "inuse"
  }
}

当APP运行在后台时，申请位置权限的方式如下，如果应用在后台运行时也需要访问设备位置，除了按照步骤2申请权限外，还需要申请ohos.permission.LOCATION_IN_BACKGROUND权限或申请LOCATION类型的长时任务。

{
  "name": "ohos.permission.LOCATION_IN_BACKGROUND",
  "reason": "$string:background_location_permission",
  "usedScene": {
    "abilities": [
      "EntryAbility"
    ],
    "when": "inuse"
  }
}

获取设备的位置信息，开发者可以调用HarmonyOS Next位置相关接口，获取设备实时位置，或者最近的历史位置，以及监听设备的位置变化。对于位置敏感的应用业务，建议获取设备实时位置信息。如果不需要设备实时位置信息，并且希望尽可能的节省耗电，开发者可以考虑获取最近的历史位置。
开发步骤。

3.1 获取设备的位置信息，需要有位置权限：

atManager.requestPermissionsFromUser(this.context, CommonConstants.REQUEST_PERMISSIONS).then((data) => {
  if (data.authResults[0] !== 0 || data.authResults[1] !== 0) {
    return;
  }
}

3.2 导入geoLocationManager模块：

import geoLocationManager from '@ohos.geoLocationManager';

3.3 实例化LocationRequest对象，用于告知系统该向应用提供何种类型的定位服务，以及位置结果上报的频率：

方式一：为了面向开发者提供贴近其使用场景的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};

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

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

• 定位精度优先策略：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};

3.4 实例化Callback对象，用于向系统提供位置上报的途径：

应用需要自行实现系统定义好的回调接口，并将其实例化。系统在定位成功确定设备的实时位置结果时，会通过该接口上报给应用。应用程序可以在接口的实现中完成自己的业务逻辑。

LocationUtil.geolocationOn((location: geoLocationManager.Location) => {
  if (this.latitude === location.latitude && this.longitude === location.longitude) {
    return;
  }
  this.latitude = location.latitude;
  this.longitude = location.longitude;
}

3.5 启动定位：

geoLocationManager.on('locationChange', requestInfo, locationChange);

3.6 结束定位：

地理编码转化与逆地理编码转化，使用坐标描述一个位置，非常准确，但是并不直观，面向用户表达并不友好。系统向开发者提供了以下两种转化能力。• 地理编码转化：将地理描述转化为具体坐标。• 逆地理编码转化能力：将坐标转化为地理描述。其中地理编码包含多个属性来描述位置，包括国家、行政区划、街道、门牌号、地址描述等等，这样的信息更便于用户理解。

开发步骤

• 1. 导入geoLocationManager模块
• 2. 查询地理编码与逆地理编码服务是否可用
• 3. 获取转化结果。（用getAddressesFromLocation，把坐标转化为地理位置信息），用getAddressesFromLocationName把位置描述转化为坐标。

3.7 地理围栏：

地理围栏就是虚拟地理边界，当设备进入、离开某个特定地理区域时，可以接收自动通知和警告。目前仅支持圆形围栏，并且依赖GNSS芯片的地理围栏功能，仅在室外开阔区域才能准确识别用户进出围栏事件。应用场景举例：开发者可以使用地理围栏，在企业周围创建一个区域进行广告定位，在不同的地点，在移动设备上进行有针对性的促销优惠。

开发步骤

• 1. 使用地理围栏功能，需要有权限ohos.permission.APPROXIMATELY_LOCATION
• 2. 导入geoLocationManager模块，wantAgent模块和BusinessError模块。
• 3. 创建WantAgentInfo信息（场景一：创建拉起Ability的WantAgentInfo信息。场景二：创建发布公共事件的WantAgentInfo信息。）
• 4. 调用getWantAgent()方法进行创建WantAgent。并且在获取到WantAgent对象之后调用地理围栏接口添加围栏，当设备进入或者退出该围栏时，系统会自动触发WantAgent的动作。

requestPermissions(): void {
    let atManager = abilityAccessCtrl.createAtManager();
    try {
      atManager.requestPermissionsFromUser(this.context, CommonConstants.REQUEST_PERMISSIONS).then((data) => {
        if (data.authResults[0] !== 0 || data.authResults[1] !== 0) {
          return;
        }
        //实例化Callback对象，用于向系统提供位置上报的途径。 应用需要自行实现系统定义好的回调接口，
        // 并将其实例化。系统在定位成功确定设备的实时位置结果时，会通过该接口上报给应用。应用程序可以在接口的实现中完成自己的业务逻辑。
        LocationUtil.geolocationOn((location: geoLocationManager.Location) => {
          if (this.latitude === location.latitude && this.longitude === location.longitude) {
            return;
          }
          this.latitude = location.latitude;
          this.longitude = location.longitude;
          let reverseGeocodeRequest: geoLocationManager.ReverseGeoCodeRequest = {
            'locale': this.locale.toString().includes('zh') ? 'zh' : 'en',
            'latitude': this.latitude,
            'longitude': this.longitude
          };
          geoLocationManager.getAddressesFromLocation(reverseGeocodeRequest).then(data => {
            if (data[0].placeName) {
              this.currentLocation = data[0].placeName;
              this.GeoAddress = data[0]
            }
          }).catch((err: Error) => {
            Logger.error(TAG, 'GetAddressesFromLocation err ' + JSON.stringify(err));
          });
        });
      }).catch((err: Error) => {
        Logger.error(TAG, 'requestPermissionsFromUser err' + JSON.stringify(err));
      })
    } catch (err) {
      Logger.error(TAG, 'requestPermissionsFromUser err' + JSON.stringify(err));
    }
  }