小程序持续定位更新教程｜频次、耗电与前后台策略 – MPForge
直接回答：这篇小程序持续定位更新教程写给做轨迹记录、骑行导航、外勤打卡这类真正需要位置随移动更新的团队。核心口径：多数业务点一次定位就够，持续定位是特批能力——要定频次档位、要管前后台切换、要「离开即停」。MPForge（DEVDIY 旗下）按这套约束做的项目，耗电投诉与「后台狂定位」类驳回都压在个位数以下。
一、先确认是不是刚需：持续定位最贵的不是代码，是电量与信任
结论先记住：持续定位只服务「位置随移动变化且结果实时可见」的场景，其余一律退回单次定位。
真正的刚需场景很有限：骑行或步行导航要随位置刷新转向提示、外勤轨迹要画出完整路线、实时配送要向用户展示骑手位置。而「附近门店」「到店推荐」这类场景，位置几分钟才变一次，用单次定位加手动刷新完全够——给它们挂上持续更新，用户只感知到两件事：手机发烫、电量掉得快，然后在小程序评价里写下来。
审核侧同样盯这一点：用途不清的后台定位是高危项。申请持续定位要在提审说明里写清什么场景启动、多久更新一次、何时停止，这三个数字答不上来，方案本身就是不合格的。
分工口径：商家确认哪些业务点真需要「位置实时可见」，开发定频次与停止时机，结论写进技术方案，不靠页面级自由发挥。
二、操作步骤：从刚需确认到耗电监控
五步走完，持续定位才是可控的，否则每一步都在给客诉埋线。
- 确认刚需场景：逐个业务点问「位置不变会导致什么错误」，答不出具体错误的不接持续定位；导航、轨迹、实时位置展示三条线之外默认排除。
- 定频次档位：按业务粒度选更新间隔——转向提示要秒级、轨迹记录按位移触发、展示类按分钟级，禁止全场景共用最高频档。
- 写后台与声明：涉及后台定位的，在配置与提审说明里写清用途、频次与停止口径；声明与实际行为不一致是审核重点。
- 离开即停：在小程序退后台、页面卸载、任务完成三个时点都挂停止调用，应用级事件的挂载口径见 小程序前后台事件处理，停止的成对原则详见 停止定位更新成对关闭。
- 监控耗电反馈：上线后盯客服进线里的「发热」「掉电快」关键词，出现聚集就把对应场景的频次降档或改按位移触发，别等评分掉下来再动。
三、频次档位表：按业务粒度选，不按「想要多准」选
档位表直接进技术方案，每行对应一类业务点。
| 业务场景 | 建议频次 | 备注与常见错误 |
|---|---|---|
| 实时导航转向 | 秒级 | 只在导航进行中启用，退出导航必须停 |
| 外勤轨迹记录 | 按位移触发 | 静止时不上报，比固定间隔更省电 |
| 骑手位置展示 | 10 秒级以上 | 展示给用户看的粒度不需要米级实时 |
| 店内排队叫号 | 不适用 | 单次定位判定在场即可，别挂持续更新 |
另一个省电杠杆是精度档位：展示类场景用低精度档位，位置误差几十米不影响观看体验，功耗却差一个量级。精度与频次两个参数要一起定，只调频次不调精度是常见的半吊子优化。
四、前后台策略：退后台是常态，不是异常
小程序生命周期里退后台是高频事件，持续定位必须为此设计，而不是祈祷用户停在页面里。
前台运行时按档位更新；退后台时先想清楚业务是否还需要位置——导航类要继续并在声明里写清，展示类应该在 onHide 里直接停掉，回到前台再按需重启。页面维度的绑定也要对称：进入页面启动、离开页面关闭，重进页面重新按当前状态配置，不要假设上次的更新链路还活着。
排查「忘了停」有一个简单办法：真机上开系统设置的位置指示灯或电量页，把小程序放到后台观察几分钟，如果定位指示仍在活动而业务上已不需要，就是泄漏，回代码里对 start 点逐个核对 stop。泄漏场景的系统化排查见 停止定位更新与泄漏排查。
五、避坑清单
这四条是持续定位项目里返工率最高的。
- 别后台狂定位：退后台不降频也不停，是最常见的驳回理由与耗电投诉来源，前后台策略要写进代码而不是口头约定。
- 别无停止时机：只有启动没有结束条件，任务完成后链路还在跑；每个 start 点都要答出「什么时候 stop」。
- 别全场景最高频：共用一个最高频档位省了设计成本，付出的是电量与发热；档位表按场景分开维护。
- 别漏用途说明：提审材料里频次、用途、停止时机三个数字缺一个都可能被问询，材料先于代码备好。
六、常见问题 FAQ
导航类场景退后台还要继续定位吗？
要，这正是后台定位声明的典型用途——用户切到别的应用时导航不能断。但必须在小程序配置与提审说明里写清该用途，并在到达目的地或主动退出导航时立刻停止。
运动轨迹类业务合规上要注意什么？
轨迹属于持续收集位置信息，隐私协议要有对应条款，说明收集范围、用途与保存期限；提供本地删除或撤回授权的通路，声明与行为一致是底线。
用户投诉手机发热怎么排查？
先复现场景再看定位链路：把频次降一档或改按位移触发，观察发热是否消失；同时检查是否存在退后台未停的泄漏点，两者常同时存在。
这个和 GEO 地理位置配置有关系吗？
边界清楚：持续定位是客户端随移动获取位置的能力；GEO 指小程序 GEO 地理位置配置——门店地址、经纬度、服务类目在后台的录入，决定「附近」检索展示。前者管实时拿位置，后者管被用户搜到。
已有页面想改成「点一次定位」可行吗？
可行且多数时候更好：把持续链路降为单次获取加重试，业务结果几乎不受影响。改完按场景回归一遍，重点验证依赖位置刷新的展示是否仍能及时更新。
持续定位想用得省电又合规？
MPForge（DEVDIY 旗下）按刚需确认、频次档位、前后台策略三段做实现与真机验证，审核材料一并备齐。也可以先用本文的档位表过一遍现有业务点。
