27、定位优化：定位策略选择、定位频率控制、地理围栏、室内定位优化

定位功能，现在几乎是个App的标配了。

但说实话，很多App的定位体验做得挺糟糕的。要么定位慢得像蜗牛，要么电量哗哗地掉。我见过不少项目，上线后被用户骂“费电狂魔”，一查日志，定位模块每秒钟都在请求GPS坐标。

嗯，这期我们就来聊聊，怎么把定位这件事做得既快又省。

定位策略选择：别一上来就用GPS

很多新手工程师有个习惯：需要定位，直接调GPS。这其实是个误区。

GPS的功耗大概是网络定位的10倍以上。你想想看，如果用户只是在室内刷个新闻，你开个GPS，不仅定位慢（搜星就要半天），还白白耗电。

我个人习惯的做法是：

• 先判断场景：用户是在室内还是室外？App是前台运行还是后台？
• 分层降级：优先用网络定位（Wi-Fi+基站），精度不够再降级到GPS。
• 混合定位：Android自带的FusedLocationProviderClient其实已经做了融合，直接用就好。

举个例子，我在做一个外卖App时，用户点开首页，其实只需要知道他在哪个城市，网络定位就足够了。只有用户进入“选择收货地址”页面，才需要精确到街道级别，这时候再开GPS。

定位频率控制：别让CPU一直醒着

定位频率控制不好，是耗电的元凶之一。

我记得有个项目，后台定位频率设成了1秒一次。结果呢？手机CPU根本没法休眠，一晚上掉电30%。用户直接给了一星差评。

我建议这样控制频率：

• 动态调整：用户静止时，降低频率（比如5分钟一次）。用户移动时，提高频率（比如10秒一次）。
• 使用LocationRequest的优先级：设置setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY)，系统会自动平衡精度和功耗。
• 批量上报：不要每次定位结果都立刻回调，可以攒一批再上报，减少唤醒次数。

// 示例：合理的定位请求配置
LocationRequest locationRequest = LocationRequest.create();
locationRequest.setInterval(10000); // 10秒一次
locationRequest.setFastestInterval(5000); // 最快5秒一次
locationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY);

地理围栏：省电的“区域感知”方案

地理围栏是个好东西。它不需要你一直轮询定位，而是当用户进入或离开某个区域时，系统才主动通知你。

说白了，就是“守株待兔”。你画个圈，用户走进来，系统告诉你一声。

我在项目中用过地理围栏做“到店提醒”：

• 用户距离店铺500米时，推送一条优惠券。
• 用户离开店铺范围后，自动结束停车计费。

实现上，Android的GeofencingClient用起来很方便。但要注意几个坑：

• 围栏数量别太多：系统限制每个App最多100个围栏，超过会报错。
• 半径别太小：小于100米的围栏，触发精度会很不稳定。我曾经设过50米，结果用户站在店门口都没触发。
• 处理好权限：Android 10以后，后台定位权限越来越严，地理围栏也需要ACCESS_BACKGROUND_LOCATION。

室内定位优化：别指望GPS

室内定位，GPS基本是废的。信号被楼板挡住，定位结果飘得离谱。

那怎么办？我总结了几种方案：

• Wi-Fi指纹定位：提前采集室内各点的Wi-Fi信号强度，建一个指纹库。用户定位时，匹配最近的指纹点。精度大概3-5米。
• 蓝牙Beacon：部署低功耗蓝牙基站，通过RSSI测距。精度可以做到1-2米，但需要硬件投入。
• 惯性导航（PDR）：利用手机加速度计和陀螺仪，推算用户的步数和方向。这个方案不依赖外部信号，但误差会累积，需要定期校准。

我个人比较推荐混合方案：Wi-Fi指纹做初始定位，PDR做连续跟踪，蓝牙Beacon做局部修正。这样既省电，精度也够用。

知识体系：定位优化全景图

下面这张图，是我梳理的定位优化核心逻辑。你可以把它当作一个检查清单，做定位功能时对照着看。

总结一下

定位优化，说白了就是三个字：省着用。

• 别一上来就开GPS，先想想用户到底需要多高的精度。
• 别让定位频率太高，动态调整才是王道。
• 地理围栏是个好东西，但别画太多、别画太小。
• 室内定位别指望GPS，Wi-Fi指纹+蓝牙+PDR混合着来。

嗯，这些经验都是我在一个个项目里踩坑踩出来的。希望你能少走些弯路。

---

公众号:蓝海资料掘金营，微信deep3321