H4.06.3background location justification设计研究
后台位置需要独立且更强的理由
别名: 后台定位 · 始终允许 · always allow location · background location
概念解释
后台位置指应用不在前台、人并未盯着地图时仍在取坐标：始终允许、访问过的位置回访、地理围栏在锁屏后仍触发。它必须与「使用期间」分开申请，理由必须强过前台附近搜索——例如正在进行的导航、共享行程、防丢。这条谈的是位置在离开前台之后的范围，不是坐标该精确还是模糊，也不是所有权限的「仅一次 / 持续」时间模型。
机制
前台位置的风险被「我看着它」约束；后台把约束拿掉，坐标流可以在人以为已经退出后继续。始终允许因此是范围升级，不是同一授权的默认延续。人很难从桌面图标看出后台是否在采点，所以请求必须单独发生，并且说明不在应用里时仍会做什么。把后台绑在前台允许上，等于用一次可见的地图使用，换走不可见的持续追踪。理由要更强，是因为伤害从「这次被定位」变成「生活轨迹可被拼接」。
怎么研究
比较「仅使用期间」与「始终允许」在同类任务上的完成度与事后察觉。
自变量：后台请求是否单独弹窗、理由是否写明离开应用后的行为、是否提供「仅在导航期间」的会话式后台。 因变量：后台授予率、实际后台取点次数、人对「退出后还在定位吗」的判断、主动撤回后台的时间。
实验室会话几乎总在前台，测不到后台的不可见性。需要多日日记或系统访问日志。不要把后台授予率当产品成功——对多数附近类功能，低后台授予才说明前台已经够用。
边界
进行中的导航、通话中的位置共享、车辆防盗，离开前台后仍要更新，后台是任务本身。即使如此，也应在任务结束时把范围收回「使用期间」，而不是把始终允许留作默认。地理围栏若只在进入店门时亮一次，应申请围栏能力而不是持续点流。网页几乎没有可靠的后台位置，不应模仿应用要「始终」。
怎么落地
- 前台位置与后台位置做成两次请求；第一次成功不得自动跟第二次。
- 后台说明必须出现「当你不在使用本应用时」以及停止条件（行程结束、共享关闭）。
- 能用「使用期间」或任务会话完成后台的，不要申请始终允许。
- 验证：授予「使用期间」、拒绝「始终」，把应用切到后台五分钟。不应再有位置上报。再跑一条正在导航的任务，确认只有该任务期间存在后台点，任务结束点流停止。对照系统的位置访问记录与产品声称是否一致。