起因：一个听起来简单的几何题
去年我开始做一个叫「雁过留痕」的 iOS App，核心功能是把你日常走过的路转化成一个数字——探索面积（km²）。不是打卡签到，不是画轨迹线，而是你实实在在用脚覆盖过的土地面积。
听起来就是个几何问题对吧？把 GPS 轨迹点围起来算面积。我最初的方案是凸包算法——所有轨迹点取最小凸多边形，求面积。代码写了半小时，跑出来的结果直接劝退：从家到公司的通勤路线，凸包把沿途两侧几百米的空地全算进去了，一趟通勤「探索」了 2km²。这显然不对。
凸包的问题在于它只关心外轮廓，你走了一条窄长的路线，它给你框一个巨大的多边形。这不是我要的「覆盖面积」。
换思路：25m 网格方案
放弃凸包后，我改用网格离散化的方案：把地图按固定尺寸切成格子，GPS 点落在哪个格子，那个格子就算被「点亮」。最终面积 = 亮格子数 × 单格面积。
粒度选 25m 是反复试出来的。10m 太细，城市里 GPS 漂移严重，一条路能飘出三排格子，面积虚高；50m 太粗，绕小区一圈和直接穿过去几乎没区别。25m 的体感最合理：一条马路亮一排，拐个弯多亮几个格子。
投影方面用的等距圆柱投影，经度方向乘上 cos(latitude) 做纬度修正。没用 UTM 是因为跨带处理麻烦，而网格本身就是 25m 粒度，中低纬度地区的投影误差远小于一个格子，够用了。
核心代码很简洁：
struct GridCell: Hashable {let x: Intlet y: Int
}func exploredCells(from points: [CLLocationCoordinate2D], gridSize: Double = 25.0) -> Set<GridCell> {var cells = Set<GridCell>()let metersPerDegLat = 111_320.0for point in points {let metersPerDegLon = 111_320.0 * cos(point.latitude * .pi / 180)let mx = point.longitude * metersPerDegLonlet my = point.latitude * metersPerDegLatcells.insert(GridCell(x: Int(floor(mx / gridSize)), y: Int(floor(my / gridSize))))}return cells
}
// 面积 = cells.count * 625 m²
用 Set<GridCell> 天然去重，同一个格子走多少次都只算一次，正好符合「探索」的语义。
Game Center 成就对接：静默丢弃的大坑
App 里做了一套成就徽章系统，分了 exploration、consistency、china、world、pro 五个 Track，对接 Game Center 上报。我原以为就是写几个 if 判断的事，结果在 Game Center 上折腾了两周。
最恶心的坑：Game Center 的成就百分比必须单调递增，你上报一个比之前小的值，它不报错、不回调失败，直接静默丢弃。 我的代码在某些边界情况下会重算指标（比如用户删除了一条无效轨迹），导致百分比回退，上报就像石沉大海。
排查这个花了三天，原因是沙盒环境下成就可以手动重置，重置后上报小值是正常的，表现和生产环境完全不同。最终方案是本地维护一个已上报最大值的缓存，上报前做 max(local, new) 比较，保证单调递增。
另外沙盒环境的成就列表加载偶尔返回空数组，不是网络问题，就是苹果沙盒服务不稳定。加了重试队列和指数退避才算解决。
后台 GPS 续航优化：从 30% 降到 18%
后台持续 GPS 记录是经典难题。我用 CLLocationManager 的 allowsBackgroundLocationUpdates，activityType 设成 .fitness，让系统根据运动状态调整采样频率。
在 iPhone 14 上用 Instruments 的 Energy Log 实测了一整天（累计约 6 小时移动，包括通勤步行和周末散步），GPS 模块单项能耗占比约 30%。后来加了一个策略：如果连续 N 个点位移小于 25m，就把 desiredAccuracy 降到 kCLLocationAccuracyHundredMeters，让系统有机会关掉 GPS 芯片硬件；一旦检测到位移恢复就切回高精度。同样条件再测，降到了约 18%。
有点烦的是 iOS 每次大版本更新后台定位策略都会微调，每年秋天得重新测一轮。
行政区判定的坐标系陷阱
App 里有省份/城市解锁功能，内置了中国行政区边界数据，用射线法判定 GPS 点落在哪个省市。
坑在坐标系：CoreLocation 返回 WGS-84，国内地图普遍用 GCJ-02，偏移在某些区域能到几百米。不做转换的话，人站在北京能被判到河北。市级边界数据精度也有问题，锯齿严重的地方 GPS 一飘就落到边界外。我的处理比较粗暴——边界做一次简化，判定时加小缓冲区。对于「你去没去过这个城市」这个粒度来说够用了。
一个还没想明白的问题
我一直在纠结网格粒度要不要做成动态的——城区 25m、郊区 50m、野外 100m。好处是郊区徒步时不会因为 GPS 精度差导致面积虚高。
我试过按 CLLocation.horizontalAccuracy 动态调整格子大小：精度优于 20m 用 25m 格子，20-50m 用 50m 格子，50m 以上用 100m。但边界处会出现面积跳变——从城区走到郊区，同一段路前半段 25m 格子后半段变 50m 格子，用户看到面积增速突然变化，体感很奇怪。而且跨粒度的面积没法直接加，得做归一化，复杂度一下子上去了。
目前我倾向于固定 25m 粒度 + 后处理过滤（丢弃 horizontalAccuracy 大于 50m 的点），简单粗暴但结果一致性好。如果有做过类似自适应网格的朋友，欢迎在评论区交流一下你们的方案。
「雁过留痕」目前已上架 App Store，感兴趣的可以搜索下载体验：App Store 链接