鸿蒙上React Native实现持续定位：从TurboModule到后台任务

1. 为什么说鸿蒙上的Geolocation不是改两行配置的事

做 React Native 开发的老手都知道，跨端最舒服的是 UI 那套逻辑，最难受的永远是原生能力。尤其是"持续定位"这种既要权限、又要后台、还要考虑耗电的功能，在 Android/iOS 上都有各种坑，换到鸿蒙上更是如此。React Native for OpenHarmony（后面统一叫 RNOH）这两年成熟了不少，UI 层、基础模块、网络模块基本能跑通，但定位这类偏系统能力的模块，官方覆盖还远没有到"开箱即用"的程度。

这篇文章就基于我最近一个实际项目来聊：在 RNOH 工程里，从 0 到 1 实现 Geolocation 持续定位更新。包含鸿蒙侧原生模块怎么封装、JS 侧怎么订阅、权限怎么声明、后台定位怎么做、以及我在真机上踩过的一串坑。如果你正在做鸿蒙版的 RN 应用，或者准备从 0 搭一个带定位功能的 RNOH 工程，这篇可以直接参考。

1.1 RNOH能给你什么，不能给你什么

先对齐一下 RNOH 的现状。现在网上一搜"react native 鸿蒙"，很多教程还在讲怎么跑 Hello World，但实际上 RNOH 已经能支撑相当复杂的企业级应用了。官方脚手架 @react-native-oh-tpl/cli 可以快速初始化工程，react-native-openharmony 这个包提供了 RN 核心库的鸿蒙实现，包括 Metro 打包、组件渲染、基础事件分发、网络请求这些。也就是说，你原来 RN 工程里的大部分 JS 代码，搬到鸿蒙上是可以直接跑的。

但这里有个核心边界：RNOH 提供的是一套运行时和核心模块，不是所有社区 Native 模块都自动有鸿蒙端实现。比如 @react-native-community/geolocation，它在 Android 和 iOS 都有原生实现，但在 RNOH 里你去引用它，直接会报 TurboModuleRegistry.getEnforcing(... 'Geolocation' could not be found) 之类的错，因为在鸿蒙侧根本没有对应的原生模块注册。

所以针对 Geolocation 这件事，我的结论很明确：不要指望社区库，自己写一个鸿蒙侧的 TurboModule，把系统的定位能力桥接给 JS 用，这才是最可控的方案。而且鸿蒙的定位 API 本身设计得比较清爽，封装的工作量比 Android 的 FusedLocationProviderClient 那条链路小很多。

1.2 鸿蒙定位API和Android定位API的差异

鸿蒙定位走的是 @ohos.geoLocationManager，在最新 SDK 里推荐从 @kit.LocationKit 引入。它跟 Android 定位最大的差别有几点：

第一，权限拆分更细。鸿蒙在 API 9 之后把定位权限拆成了 ohos.permission.APPROXIMATELY_LOCATION（模糊位置）和 ohos.permission.LOCATION（精确位置），后台持续定位还要额外声明 ohos.permission.LOCATION_IN_BACKGROUND。Android 上虽然有模糊/精确的概念，但鸿蒙这里是两个独立的权限项，申请逻辑上要分开处理。

第二，定位回调模型不一样。Android 里你一般是 requestLocationUpdates 传入一个 LocationListener；鸿蒙里则是先 on('locationChange', callback) 注册监听，再调用 requestLocationUpdates 去激活定位。停止更新时要同时 off('locationChange')，否则监听还挂在系统那边，容易泄漏。

第三，场景化配置很强。鸿蒙定位请求参数里有 scenario 概念，比如日常生活、导航、运动健康等，系统会根据场景自动调整定位策略。这个对做持续定位来说很重要，后面我会专门讲参数怎么配。

把这两套差异理解透了，再看下面的代码就不会觉得陌生。

2. 工程准备：RNOH工程、权限声明和真机环境

2.1 搭建RNOH工程

如果你还没有 RNOH 工程，我建议直接用官方脚手架，不要自己手动去拼，否则版本对齐会折腾死你。

bash复制npx @react-native-oh-tpl/cli@latest init RNHarmonyGeoDemo

注意初始化时会有一个选项让你选择 react-native 的版本和 @react-native-openharmony 的版本，这里建议保持默认，除非你有明确的兼容性要求。初始化完成之后，工程结构是标准的 RN + HarmonyOS 双端工程，entry/src/main/ets 目录下面就是鸿蒙侧的 ArkTS 代码。

如果你已有现成的 RNOH 工程，只需要确认一下 oh-package.json5 里已经依赖了 @rnoh/react-native-openharmony，并且版本跟你用的 react-native 版本匹配。我自己遇到过 react-native 0.72 + RNOH 0.72.x 和 0.73.x 的 API 差异，所以强烈建议先看一眼依赖树，别小版本不一致还硬调。

2.2 module.json5权限声明：三件套缺一不可

定位权限在鸿蒙这边属于 user_grant 类型，光在 module.json5 里声明还不够，运行时必须弹出授权弹窗让用户同意。但如果不声明，你连弹窗都触发不了。这一步很容易漏。

我工程的 entry/src/main/module.json5 里是这样声明的：

json复制{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.APPROXIMATELY_LOCATION",
        "reason": "$string:location_reason",
        "usedScene": {
          "abilities": ["EntryAbility"],
          "when": "foreground"
        }
      },
      {
        "name": "ohos.permission.LOCATION",
        "reason": "$string:location_reason",
        "usedScene": {
          "abilities": ["EntryAbility"],
          "when": "foreground"
        }
      },
      {
        "name": "ohos.permission.LOCATION_IN_BACKGROUND",
        "reason": "$string:location_background_reason",
        "usedScene": {
          "abilities": ["EntryAbility"],
          "when": "background"
        }
      }
    ]
  }
}

reason 字段是给用户在授权弹窗里看的说明，不能空着，系统会校验。usedScene 里的 when 表示前台还是后台使用，建议跟前台定位/后台定位的实际情况一一对应。LOCATION_IN_BACKGROUND 如果只做前台定位可以不声明，但做持续定位更新，用户一按 Home 键退后台，定位就会断，所以这个权限最好一起加上。

另外提醒一句：如果你的应用真的是导航或运动类，需要在后台持续跑定位，那还要在 abilities 节点里配置：

json复制{
  "name": "EntryAbility",
  "backgroundModes": ["location"]
}

这个配置在鸿蒙上对应"长时任务"能力。不加它，就算权限给了，系统也可能在应用退到后台一段时间后把定位进程挂起。

2.3 真机与模拟器的选择

我在这件事上浪费过整整一天。鸿蒙模拟器在 UI 调试、布局预览上很好用，但定位功能的体验非常差。模拟器默认拿不到真实的 GPS 信号，有些版本连手动模拟位置的路口都没有，导致坐标要么一直返回 0，要么压根不触发 locationChange。如果你是用 hdc shell 去模拟位置，不同 DevEco Studio 版本的行为也不一致。

所以我建议：做定位功能，直接从真机开始，别在模拟器上浪费生命。真机调试时把 hdc 连接好，日志过滤打开，比模拟器上猜来猜去高效得多。

3. 持续定位的实现原理：Native回调 vs JS轮询

3.1 鸿蒙geoLocationManager的核心API

鸿蒙侧核心 API 是 geoLocationManager，我实际用到的主要是四个：

• geoLocationManager.on('locationChange', callback)：订阅位置变化。
• geoLocationManager.requestLocationUpdates(requestInfo, callback)：按指定策略启动定位更新。
• geoLocationManager.off('locationChange', callback)：取消订阅。
• geoLocationManager.getCurrentLocation()：获取单次定位，适合不关心连续变化的场景。

持续定位的关键就在于 requestLocationUpdates 和 locationChange 的组合。requestLocationUpdates 不只启动定位，还决定更新频率、精度、距离阈值。它的核心参数是 LocationRequest：

typescript复制let requestInfo: geoLocationManager.LocationRequest = {
  'scenario': geoLocationManager.LocationRequestScenario.SCENE_DAILY_LIFE_SERVICE,
  'maxAccuracy': 200,
  'distanceInterval': 0,
  'intervalMs': 5000,
  'maxPushSize': 1
};

scenario 选 SCENE_DAILY_LIFE_SERVICE 表示日常服务，系统会平衡功耗和精度；如果是导航场景用 SCENE_NAVIGATION，系统会更激进地拉高频率。intervalMs 是期望的回调时间间隔，distanceInterval 是距离变化多少米才回调一次，设 0 表示不考虑距离，只看时间。maxAccuracy 表示期望的最大误差范围，单位是米。

这里有个反直觉的点：intervalMs 不是你设多少系统就严格按多少回。鸿蒙定位策略会根据场景、信号环境、功耗做动态调整，特别是室内信号差的时候，回调间隔可能明显大于你设置的值。所以不要把业务逻辑建立在"每 5 秒必回调"这个假设上。

3.2 TurboModule + NativeEventEmitter的桥接链路

我选择用 RNOH 的 TurboModule 机制做桥接。RNOH 从 0.72 开始提供了比较完整的 TurboModule 生命周期支持，你可以在 ArkTS 侧声明一个继承 TurboModule 的类，然后在 RNInstance 注册时把这个模块挂上去，JS 侧就能通过 NativeModules.XxxModule 拿到它。

JS 侧要接收持续的回调，不能靠 getCurrentPosition 这种一次性调用，需要事件推送。最标准的是鸿蒙侧用 NativeEventEmitter（RNOH 对 RN 事件机制的封装）把 locationChange 事件发到 JS 侧。链路是这样的：

code复制鸿蒙定位服务
  -> geoLocationManager.on('locationChange') 回调
  -> TurboModule 内收到 location 对象
  -> this.context.rnInstance.emitEvent('onLocationChange', locationJson)
  -> JS 侧 NativeEventEmitter.addListener('onLocationChange', callback)

用事件驱动，比 JS 侧主动去 pull 数据要自然，而且跨桥次数少。

3.3 为什么用JS轮询做持续定位是错的

可能有人会想：既然社区 geolocation 库不能用，我干脆在 JS 里 setInterval 每 5 秒调一次 getCurrentPosition 不就行了？

在部分场景下确实能跑，但它有三个硬伤：

第一，JS 线程唤醒成本高。RN 的 JS 运行在独立的 JS 线程，定时器回调需要跨桥通知，频繁唤醒不仅耗电，还会抢占 UI 线程资源。

第二，应用退到后台后，JS 定时器会被系统挂起。RN 的 JS 定时器在没有后台任务保护的情况下，不保证按时执行。你本来要做"持续定位更新"，结果用户一锁屏，定位就停了，这在导航类应用里是致命的。

第三，单次定位接口的触发逻辑和持续定位不同。getCurrentLocation 每次都会重新请求定位，GPS 冷启动耗时可能很长，连续调用还会增加系统负载。

真正的持续定位，必须由原生侧维护一个长驻的定位请求，位置变化之后主动推给 JS。这也是我为什么要写一个完整的 NativeModule 而不是在 JS 里偷懒。

4. 从0到1实现持续定位模块：鸿蒙侧代码

4.1 创建TurboModule并注册

在 entry/src/main/ets/GeolocationModule/GeolocationModule.ts 里创建一个类：

typescript复制import { TurboModule } from '@rnoh/react-native-openharmony';
import { geoLocationManager } from '@kit.LocationKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { abilityAccessCtrl, Permissions } from '@kit.AbilityKit';
import { UIAbilityContext } from '@kit.AbilityKit';

export class GeolocationModule extends TurboModule {
  static readonly NAME = 'GeolocationModule';

  private locationCallback: (location: geoLocationManager.Location) => void =
    (location) => {
      this.emitLocation(location);
    };

  constructor(ctx: UIAbilityContext) {
    super(ctx);
    // 如果当前 RNOH 版本构造函数签名不同，按你的工程提示调整
  }

  getConstants(): Record<string, Object> {
    return {};
  }

  private emitLocation(location: geoLocationManager.Location) {
    const data = {
      latitude: location.latitude,
      longitude: location.longitude,
      accuracy: location.accuracy,
      speed: location.speed,
      timeStamp: location.timeStamp,
      direction: location.direction,
    };
    this.ctx.getReactNativeApp() // 具体获取 rnInstance 的方式以工程版本为准
      ?.getInstance()
      .emitEvent('onLocationChange', data);
  }

  startLocationUpdates(options: Record<string, number>) {
    const intervalMs = options.intervalMs ?? 5000;
    const maxAccuracy = options.maxAccuracy ?? 200;
    const distanceInterval = options.distanceInterval ?? 0;

    try {
      geoLocationManager.on('locationChange', this.locationCallback);
      let requestInfo: geoLocationManager.LocationRequest = {
        scenario: geoLocationManager.LocationRequestScenario.SCENE_DAILY_LIFE_SERVICE,
        maxAccuracy: maxAccuracy,
        distanceInterval: distanceInterval,
        intervalMs: intervalMs,
        maxPushSize: 1,
      };
      geoLocationManager.requestLocationUpdates(requestInfo, (err: BusinessError) => {
        if (err) {
          console.error(`requestLocationUpdates failed: ${JSON.stringify(err)}`);
        }
      });
    } catch (e) {
      console.error(`startLocationUpdates error: ${JSON.stringify(e)}`);
    }
  }

  stopLocationUpdates() {
    geoLocationManager.off('locationChange', this.locationCallback);
  }

  requestPermission() {
    const atManager = abilityAccessCtrl.createAtManager();
    const permissions: Permissions[] = [
      'ohos.permission.APPROXIMATELY_LOCATION',
      'ohos.permission.LOCATION',
    ];
    atManager.requestPermissionsFromUser(this.ctx, permissions)
      .then((result) => {
        const granted = result.authResults.every(code => code === 0);
        console.error(`location permission granted: ${granted}`);
      })
      .catch((err) => {
        console.error(`requestPermissionsFromUser error: ${JSON.stringify(err)}`);
      });
  }
}

这里有几个关键点：

• startLocationUpdates 的参数是从 JS 侧透传过来的，不要写死在原生里，方便 JS 按业务场景动态调整。
• locationCallback 需要保存为成员变量，否则 off 的时候引用对不上，监听移除不掉。
• requestPermission 单独暴露出一个方法，由 JS 在合适的时机（比如用户点"开启定位"按钮）触发，而不是在模块启动时自动弹，体验更可控。

模块写好之后，还要在 RNOH 的模块注册表里把它挂上。一般在 entry/src/main/ets/RNPackage.ts 或者 MainAbility 的 createRNInstance 相关逻辑里，把 GeolocationModule 加进 turboModuleProvider。

4.2 前台定位的启动与停止实现

上面代码里的 startLocationUpdates 已经实现了前台定位的启动。还有一个细节：在启动之前，最好先检查一下系统定位服务是否开启。鸿蒙提供了定位服务状态订阅：

typescript复制geoLocationManager.on('locationServiceState', (state: boolean) => {
  // state 为 true 表示定位服务已开启
});

我一般会在 startLocationUpdates 里先查一次当前状态：

typescript复制geoLocationManager.isLocationEnabled()
  .then((enabled: boolean) => {
    if (!enabled) {
      // 通知 JS 侧，让用户去设置里打开定位
      return;
    }
    // 继续启动
  });

不做这个检查会出现一种让人很懵的现象：权限给了、代码也调了，就是一直不回调位置。这时候先确认系统定位服务有没有开，是最快的排查路径。

停止定位时，除了 off('locationChange')，我还建议把 distanceInterval、intervalMs 这些参数置空并清掉对象引用，避免内存里残留大对象。

4.3 后台定位与长时任务配置

要真正做到"应用退到后台后定位依然持续更新"，光靠 LOCATION_IN_BACKGROUND 权限不够，还需要申请长时任务。我前文提到 backgroundModes: ["location"] 的配置，实际运行时还要调用后台任务管理的 API：

typescript复制import { backgroundTaskManager } from '@kit.BackgroundTasksKit';

backgroundTaskManager.startBackgroundRunning(
  this.ctx,
  backgroundTaskManager.BackgroundMode.LOCATION,
  (err: BusinessError) => {
    if (err) {
      console.error(`startBackgroundRunning failed: ${JSON.stringify(err)}`);
    }
  }
);

这个 API 在不同 API 版本里签名会有些变化，有的版本需要传 WantAgent 用于通知栏展示，有的版本只需要 context 和 mode。我建议以你 SDK 对应的类型提示为准，但整体思路一致：在定位启动时申请长时任务，停止定位时调用 stopBackgroundRunning 对应释放。

注意，长时任务会常驻通知栏，给用户一个"正在定位"的可见提示。这是系统规范，不要试图绕过，否则审核和真机行为都会出问题。

5. JS侧封装与业务接入：useContinuousLocation

5.1 封装EventEmitter与生命周期

鸿蒙侧的模块已经能发 onLocationChange 事件了，JS 侧需要封装一下，避免业务代码到处 addListener 导致内存泄漏。

我通常新建一个 geolocation.ts：

typescript复制import { NativeModules, NativeEventEmitter } from 'react-native';

const { GeolocationModule } = NativeModules;

let locationEmitter: NativeEventEmitter | null = null;

function getEmitter(): NativeEventEmitter {
  if (!locationEmitter) {
    locationEmitter = new NativeEventEmitter(GeolocationModule);
  }
  return locationEmitter;
}

export function requestLocationPermission() {
  GeolocationModule.requestPermission();
}

export function startLocationUpdates(options?: {
  intervalMs?: number;
  maxAccuracy?: number;
  distanceInterval?: number;
}) {
  GeolocationModule.startLocationUpdates({
    intervalMs: options?.intervalMs ?? 5000,
    maxAccuracy: options?.maxAccuracy ?? 200,
    distanceInterval: options?.distanceInterval ?? 0,
  });
}

export function stopLocationUpdates() {
  GeolocationModule.stopLocationUpdates();
}

export function subscribeLocationChange(callback: (location: LocationData) => void) {
  const subscription = getEmitter().addListener('onLocationChange', callback);
  return subscription;
}

5.2 对外暴露的接口设计

如果你用的是函数组件，建议再包一层 Hook，让业务侧只需要关心"我要不要监听位置"，不需要管事件订阅和原生模块调用的细节：

typescript复制import { useEffect, useRef, useState } from 'react';

export interface LocationData {
  latitude: number;
  longitude: number;
  accuracy: number;
  speed: number;
  timeStamp: number;
  direction: number;
}

export function useContinuousLocation(options?: {
  intervalMs?: number;
  maxAccuracy?: number;
  distanceInterval?: number;
}) {
  const [location, setLocation] = useState<LocationData | null>(null);
  const subscriptionRef = useRef<any>(null);

  useEffect(() => {
    startLocationUpdates(options);
    subscriptionRef.current = subscribeLocationChange((loc: LocationData) => {
      setLocation(loc);
    });

    return () => {
      subscriptionRef.current?.remove();
      stopLocationUpdates();
    };
  }, []);

  return location;
}

这里有个容易被忽视的坑：useEffect 的依赖数组如果是空 []，options 变化不会生效。如果你希望支持运行时动态调整更新频率，需要把 options 拆成基本类型放进依赖数组，或者用 ref 保存最新配置。考虑到原生模块启动后要改参数通常需要重启定位，我一般直接让 intervalMs 变化时先 stopLocationUpdates() 再重新 startLocationUpdates()。

5.3 定位数据缓存与节流策略

即使原生侧设了 intervalMs，回调频率也可能比业务预期高。尤其在一些定位信号好的环境，系统会在短时间内连续 push 多条位置。如果业务侧只需要"每 10 秒更新一次地图标记"，建议在 JS 侧再做一层节流，不要每次回调都去 setState。

我用的模式是：保留最近一次位置，用 setTimeout 或 requestAnimationFrame 控制 UI 更新频率。也可以在 subscribeLocationChange 里加一个 lastEmitTime 判断：

typescript复制let lastEmitTime = 0;

function throttledSubscribe(callback: (location: LocationData) => void, minIntervalMs: number) {
  return subscribeLocationChange((location) => {
    const now = Date.now();
    if (now - lastEmitTime < minIntervalMs) {
      return;
    }
    lastEmitTime = now;
    callback(location);
  });
}

注意节流和原生 intervalMs 是两个维度：原生控制定位请求频率，节流控制 UI 更新频率。两者叠加能有效减少页面卡顿。

6. 真机调试与坑位实录

6.1 权限弹窗不弹出的排查链路

这是我在新接手项目时最先踩的坑。权限声明写了、requestPermissionsFromUser 也调了，但真机上就是没有弹窗。排查思路是这样的：

第一步，确认权限在 module.json5 里真的声明了。别笑，我见过把权限写到 entry/src/main/resources/base/element/storage_element.json 里的情况，那是不生效的。

第二步，确认 requestPermissionsFromUser 传入的是 UIAbilityContext，不是 ApplicationContext。鸿蒙很多 API 需要带 UI 上下文才能弹窗，用应用上下文调用会直接失败或静默不弹。

第三步，看日志。用 hdc shell hilog | grep -i permission 过滤权限相关日志，通常能看到具体的错误码。如果是 201 表示权限校验失败，说明声明有问题；如果是 12100001 之类的参数错误，说明 context 传错了。

第四步，检查系统是否已经拒绝过该权限。有些设备的权限策略是：用户拒绝后，短时间内再次申请不会弹窗，而是直接返回拒绝结果。这种情况需要引导用户去系统设置里手动开启。

6.2 坐标一直回传0或定位失败

坐标一直是 0,0，这个现象在模拟器上很常见，但真机上如果出现，就要往这几个方向查：

• 系统定位服务是否开启。打开设置 -> 位置信息，确认开关是开的。
• 当前环境是否有 GPS 信号。室内靠 Wi-Fi 和基站定位，如果设备没开 Wi-Fi，定位精度会很差，甚至失败。
• on('locationChange') 是否在 requestLocationUpdates 之前注册。鸿蒙要求先订阅再启动，顺序反了可能导致回调丢失。
• 权限授权结果是否是"模糊位置"而不是"精确位置"。如果用户在弹窗里选择了模糊位置，回调的坐标精度会明显降低，但不会变成 0。如果精确位置权限没拿下来，也拿不到高精度定位。

我曾经遇到一个诡异的情况：requestLocationUpdates 的成功回调返回了 err 为 null，但位置事件一直不触发。最后发现是 scenario 设置成了 SCENE_NO_POWER，这个场景优先省电，系统会延迟定位请求，隔了很久才来第一条数据。所以优先检查场景和参数配置，别上来就怀疑系统 bug。

6.3 hdc日志抓取方式

真机调试定位问题，日志是最重要的依仗。RNOH 项目里日志入口比较多，最简单的组合是：

bash复制hdc shell hilog | grep -i geolocation

如果觉得日志太多，可以按进程过滤：

bash复制hdc shell hilog | grep -iE "RNOH|Geo|LocationManager"

还可以通过 hilog 的日志级别过滤，例如只看错误和警告：

bash复制hdc shell hilog -p 03

-p 后面的数字按 bit 组合，0x01 是 Debug，0x02 是 Info，0x04 是 Warn，0x08 是 Error，所以 -p 03 在部分版本里表示 Warn + Error。不同 SDK 版本支持度略有差异，记不住的话直接 hilog | grep 也一样能干。

6.4 工程启动白屏与native模块初始化的关系

热词里很多人搜"react native 启动白屏"，这个问题在 RNOH 工程里特别容易和原生模块初始化问题混淆。

我的经验是：如果白屏出现在"集成定位模块之后"才出现，优先怀疑原生模块在初始化阶段抛了异常。RNOH 的 TurboModule 如果构造函数里做了耗时操作或抛错，可能阻断整个 RNInstance 的创建，JS 压根跑不起来，表现就是白屏。

排查时先把 startLocationUpdates 相关的调用从 JS 里注释掉，确认是否恢复。如果恢复了，再把原生模块里的构造函数简化，只保留最基础的逻辑，逐步加代码二分定位。

另外，RNOH 还有一个常见的白屏原因：Metro bundle 没有加载成功。真机上 Metro 连接不上，或者 release 包里的 bundle 路径配置不对，都会白屏。和定位模块无关，但容易干扰排查。我的建议是：第一步永远先确认 Metro 在跑、bundle 有没有加载完，第二步再怀疑原生模块。

6.5 关于har封装so和napi的补充说明

如果你在集成定位能力时还引入了一些 C++ 底层库（比如地理位置编码、信号指纹分析之类），RNOH 工程里一般是以 .har 的形式封装原生 so 库，再通过 oh-package.json5 依赖引用。这里有一个实际容易踩的坑：so 库的 ABI 架构要和真机匹配。鸿蒙手机基本是 arm64-v8a，但你在模拟器上跑工程时，可能加载的是 x86_64 的 so。如果 so 目录里没有对应架构的文件，应用启动时会直接崩溃或者报 dlopen failed，让你误以为是定位模块的代码问题。

RNOH 里的 TurboModule 如果只是调用鸿蒙系统 SDK，不需要走 N-API，直接用 ArkTS 写就行。但如果你要复用已有的 C++ 定位算法库，那就要通过 N-API 封装一层接口给 ArkTS 调用，或者直接在 C++ 层用 napi_define_class 导出原生模块。这条链路会比纯 ArkTS 复杂不少，建议能不用就不用。

7. 持续定位的耗电与精度调优经验

7.1 scenario与intervalMs的选择

持续定位做得久了你会发现，真正难的不是"能不能定位"，而是"在耗电和精度之间找到平衡"。鸿蒙的 scenario 参数是个很好的工具，它告诉系统你的使用场景，系统会据此自动调整定位策略。

日常类应用，比如打卡、步数统计，用 SCENE_DAILY_LIFE_SERVICE 就够，定位频率会被系统控制在比较省电的档位。导航、骑行、跑步这类需要高频位置更新的场景，用 SCENE_NAVIGATION 或 SCENE_SPORT，系统会优先保证位置连续性，但耗电会明显上升。

intervalMs 方面，我没有选太激进的值。实测下来，日常场景 5000ms 已经能覆盖大多数需求；如果做外卖骑手轨迹这类高频实时应用，可以压到 2000ms，但要做好掉电变快的心理准备。不要设 100ms 这种值，系统大概率不会照做，反而会因为请求过于频繁导致定位服务异常。

7.2 距离触发与精度上限怎么配合

distanceInterval 和 intervalMs 是可以同时生效的，理解为"两个条件满足一个就回调"会更准确。如果设了 distanceInterval: 10，用户静止不动时，即使 intervalMs 到了 5 秒，也不会回调位置，因为距离没变化。如果用户快速移动，可能每隔几百毫秒就回调一次。

所以我推荐一个组合：需要做移动轨迹时，intervalMs 设一个保底值（比如 5000ms），distanceInterval 设一个业务上可接受的最小位移（比如 10m）。这样既能保证静止时减少无谓回调，又能在移动时及时刷新位置。

maxAccuracy 我一般设 100 到 200 之间。设太小会让系统频繁切换定位源去追求高精度，耗电大；设太大会让定位结果在地图上看有明显漂移。具体值可以根据业务场景试，地图打车类建议 100 以内，打卡签到类 200 以内就够。

7.3 冷启动后定位恢复的处理

应用冷启动后，GPS 模块可能需要几秒到几十秒的冷启动时间，这个阶段 locationChange 回调可能是空的或者不触发。我建议在启动定位后，先调用一次 getCurrentLocation 拉一个初始位置，尽快渲染地图中心点，然后等 locationChange 持续更新。这个"先拿一次快照、再订阅持续更新"的策略，体验上比干等着第一次回调要好很多。

具体代码可以这样：在 startLocationUpdates 之前先用 getCurrentLocation 拿初始坐标，成功后再启动持续更新：

typescript复制geoLocationManager.getCurrentLocation({
  'maxAccuracy': 200,
  'timeoutMs': 10000
}).then((location) => {
  this.emitLocation(location);
});

注意 getCurrentLocation 在室内或信号差的环境下可能超时，所以要设置 timeoutMs，并做好失败兜底，别让 Promise 一直 pending。

最后再分享一个小经验：在 RNOH 里做定位，一定要把权限申请、定位启动、定位停止这三个动作收敛到同一个原生模块里，不要分散在多个模块中。定位服务是系统级资源，多个模块同时操作，容易出现"一个模块停了、另一个模块还在监听"的错乱。我在实际项目里一开始把权限申请放在了一个公共服务模块、定位放在另一个模块，结果排查了整整两天，最后还是合并到 GeolocationModule 里统一管理才彻底稳定。持续定位这种东西，越收敛越省心。