HarmonyOS 鸿蒙Next中长时定位出现中断

HarmonyOS 鸿蒙Next中长时定位出现中断 【问题描述】：长时定位出现中断

【问题现象】：

在鸿蒙代码没有改变的情况下，尝试多个场景，有如下：

  1. 夜间多次重启程序，测试手机静止状态，观察结果：每次重启大约静止10分钟后，定位停止
  2. 今天早上再次检查代码，确定代码未做变化，与定位相关的代码最晚修改时间在12.10日，而12.17日下午5点前定位一直正常。
  3. 检查代码后，重新打包鸿蒙项目，重启手机，卸载原app，重新启动一个测试，重新下载安装app，观察结果，静止状态下，与之前观察一样，大约10分钟后，定位停止。
  4. 决定外出观察运动情况，同一部手机，还是那个app，甚至也未重启手机，没有重新安装app，观察结果：运动状态下，一切正常。

cke_1123.png cke_1908.png

如图一，是本次故障判断的测试的情况，这可能就是鸿蒙设计的目标，但这个目标和用户需求不符，这会导致鸿蒙的app与苹果安卓功能不一致，在用户看来，那是不如苹果和安卓的。

为了省电，让很多业务无法实现，如果实现这样的规则，即使是导航业务，势必面临很大难题，导航中，常见情景是人开车跑，运动时一切正常，但随时能停车喝口水、撒个尿、抽个烟，再上车，发现导航不能及时提醒该左拐、右拐，还是继续行，和安卓苹果版导航有明显差距，那不是好事吧。我们认为这不值得，如图二需求，不是我们想象的，而是用户真正提出的，他们提出这个，取决于现实情况。如果一个员工上班期间外出，即使停止了，也有每几分钟一次定位，公司就能确定人在哪里，但如果到那里，定位就停了，那公司就会怀疑，手机坏了？app不可靠？人关机跑了？……，如此，考勤还怎么做啊。更有甚者，有些员工发现这种情况，他可能有意关闭app，为脱岗创造条件，公司要问，就以一直停这里，而企业知道停下来就不能定位了，那企业该怎么做啊，没法做了。

这种情况，影响的肯定不止这个业务，运输业，水电检查、燃气、所有外勤检查维护工作，外勤员工的调度等等，很多业务，将无法用手机的功能改善管理调度。

建议：若鸿蒙认为这里的省电很关键，可以这样做：增加一个情景，让用户去选择这里要省电，还是要确保静止时持续定位。将选择权交给用户，比我们逼着他选择手机，那风险要小的多。

【版本信息】：不涉及

【复现代码】：不涉及

【尝试解决方案】：无


更多关于HarmonyOS 鸿蒙Next中长时定位出现中断的实战教程也可以访问 https://www.itying.com/category-93-b0.html

2 回复

鸿蒙Next长时定位中断可能由系统省电策略、后台任务管理或定位服务异常导致。检查应用是否已申请ohos.permission.LOCATION_IN_BACKGROUND权限，并在module.json5中配置backgroundModes为location。确保应用未进入休眠列表，可通过continuationManager注册设备连接状态监听。定位中断时系统会触发onLocationChange回调，可通过location.getCurrentLocation重新请求位置。

更多关于HarmonyOS 鸿蒙Next中长时定位出现中断的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


根据你的描述，这确实是HarmonyOS Next在后台长时定位策略上的一个设计特性，旨在静止状态下为节省电量而限制定位更新。这并非代码缺陷，而是系统级的行为。

对于需要持续获取静止位置的应用（如考勤、外勤管理），关键在于正确申请并维持后台定位所需的权限和能力。请按以下步骤检查和配置你的应用：

  1. 权限声明：确保在module.json5文件中声明了ohos.permission.LOCATION和ohos.permission.LOCATION_IN_BACKGROUND（持续后台定位）权限。

    {
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.LOCATION",
        "reason": "$string:location_reason",
        "usedScene": {
          "abilities": ["YourAbilityName"],
          "when": "always"
        }
      },
      {
        "name": "ohos.permission.LOCATION_IN_BACKGROUND",
        "reason": "$string:location_bg_reason"
      }
    ]
  }
}

  2. 后台模式配置：在同一个文件中，为需要后台定位的Ability配置backgroundModes为location。

    {
  "module": {
    "abilities": [
      {
        "name": "YourAbilityName",
        "backgroundModes": ["location"]
      }
    ]
  }
}

  3. 使用正确的定位API：在代码中，使用@ohos.geolocation模块的on('locationChange')方法订阅位置变化。确保在应用切换到后台时，订阅仍然有效。系统会根据你声明的权限和能力，在设备静止时决定是否暂停更新。重点在于，你的应用必须通过上述配置向系统明确声明其后台持续定位的“业务必要性”。

  4. 前台服务通知（重要）：如果上述配置后，在长时间后台运行时定位仍可能中断，你需要考虑使用长时任务（LongTermTask） 或连续任务（ContinuousTask） 机制来向系统申明你的任务关键性，并配合一个持续的前台服务通知。这能显著降低进程被挂起或资源被限制的概率。

关于你提到的用户选择权建议：当前HarmonyOS的设计逻辑是，应用通过声明权限和能力来表明其用途，系统据此管理资源。用户则在安装或运行时授予这些权限。因此，确保你的应用清晰地向用户申请LOCATION_IN_BACKGROUND权限，用户授权即意味着同意该后台行为。对于更细粒度的“静止时是否定位”控制，目前需由应用自身根据业务逻辑在代码层面实现（例如，在检测到静止时，通过其他传感器或网络状态判断是否真正需要唤醒定位），或等待系统未来提供更精细的API。

总结：请首先严格检查并确保你的应用已正确声明后台定位权限和后台模式能力。这是HarmonyOS Next系统识别并允许你应用在后台（包括设备静止时）持续进行定位操作的基础。如果问题依旧，则需要评估使用长时/连续任务机制来维持任务优先级。

回到顶部