根本原因是安卓系统对定位请求的多层拦截和降级处理，需设timeout:15000和highaccuracyexpiretime:5000、type选gcj02、避免onload调用并确保权限/sdk/系统设置协同。
安卓手机调用 uni.getLocation 响应慢、卡顿几秒才返回
根本原因不是代码写错了，而是安卓系统对定位请求做了多层拦截和降级处理。尤其在中低端机型或省电模式下，uni.getLocation 默认行为会先尝试 IP 定位（快但不准），失败后再切 GPS（准但慢），这个切换过程无提示、无超时控制，用户就卡在“白屏等结果”状态。
必须设 timeout 和 highAccuracyExpireTime
这两个参数不设，安卓端几乎必慢。默认 timeout 是 5 秒，但很多国产 ROM（如 MIUI、EMUI）会在后台限制定位服务响应，实际等待可能长达 10–20 秒才 fail，而不是及时 fallback。
-
timeout: 15000—— 明确设为 15 秒，避免无限等待 -
highAccuracyExpireTime: 5000—— 表示“5 秒内尽量返回高精度结果，超时就给个低精度兜底”，比单纯设highAccuracy: true更可控 - 不要只依赖
highAccuracy: true：它只是“尽力而为”，不承诺时效，且部分安卓版本会直接忽略
type 选 gcj02 而不是 wgs84
在未配置高德 SDK 的云打包环境下，wgs84 会强制走纯 GPS 或网络定位，信号弱时极易卡住；而 gcj02 在 App 端默认启用高德 SDK（DCloud 基座已内置），即使没填 key，也能走更快的混合定位通道。
- 真机调试时
gcj02普遍比wgs84快 2–5 秒 - 若已配置高德 AppKey，
gcj02还能触发基站+WIFI+GPS 三模协同，进一步缩短首次定位时间 - 注意：返回的经纬度是国测局坐标，别直接丢给 Google 地图用
避免在页面 onLoad 里直接调用定位
安卓系统对“冷启动即定位”非常敏感，尤其在后台进程被杀后重新拉起，onLoad 阶段调用 uni.getLocation 极易触发系统延迟策略，表现为长时间无响应或直接 fail。
- 改在用户显式交互后触发，比如按钮点击、下拉刷新、tab 切换事件中调用
- 如果必须自动定位，加一层防抖 + 延迟：用
setTimeout(() => { uni.getLocation(...) }, 300) - 首次定位失败后，不要立刻重试，等 1–2 秒再调一次，避开系统定位服务初始化窗口期
最常被忽略的一点：安卓定位慢往往不是单个 API 的问题，而是权限申请、系统定位模式、SDK 配置三者没对齐。比如你开了 highAccuracyExpireTime 却没在 manifest.json 里配高德 key，或者用户手机开着“省电模式”却指望 GPS 秒出结果——这些组合问题不会报错，只会默默拖慢整个流程。
