引言：一个生活痛点引发的技术项目
作为一个喜欢 Citywalk 的独立开发者，我长期面临一个看似简单却始终没有好方案的问题：如何高效管理出行过程中产生的大量截图和照片？
手机相册里上千张街景照片、路线截图、店铺门头……按时间线堆叠，半年后想找某次出行的某张图，几乎不可能在合理时间内完成。系统相册的搜索能力有限，第三方工具又往往要求上传云端，隐私成本过高。
于是我决定自己动手，做一款以「地理轨迹」为核心索引维度的本地记录工具——「雁过留痕」。本文分享这个项目从 1.0 到 2.4 的架构选型、核心模块设计以及迭代过程中踩过的坑。
一、产品定位与技术约束
1.1 核心需求拆解
- 轨迹可视化：将用户走过的路径渲染为像素风格地图，每公里点亮一格，提供游戏化的正反馈
- 基于地理位置的照片归类：拍摄的照片、截图自动按地点聚合，支持地名检索
- 纯本地存储：所有数据不离开设备，零社交、零上传，彻底规避隐私风险
- 审美输出：地图截图本身具备分享价值，视觉设计需达到「发朋友圈不丢人」的水准
1.2 技术约束
| 约束维度 | 决策 |
|---|---|
| 数据存储 | 纯本地，SQLite + 文件系统 |
| 地图渲染 | 自绘像素网格，非第三方地图 SDK 叠加层 |
| 隐私策略 | 无网络权限依赖，无账号体系 |
| 目标用户 | 年轻女性为主，UI 需轻量、有设计感 |
二、核心架构设计
2.1 轨迹采集与网格化
轨迹记录模块基于系统定位服务，后台持续采集 GPS 坐标点。关键挑战在于：
- 功耗控制：采用分级精度策略，静止时降低采样频率，移动时提升至 5s/次
- 网格映射算法：将经纬度坐标映射到自定义的像素网格系统。基础思路是对地理坐标做 Geohash 编码后取前 N 位作为网格 ID，每格约对应现实中 1km × 1km 的区域
- 去噪处理：GPS 漂移在城市峡谷中很常见，采用卡尔曼滤波 + 速度阈值双重过滤
// 伪代码：坐标到像素格的映射
func coordinateToGrid(lat: Double, lng: Double) -> GridCell {let geohash = Geohash.encode(lat, lng, precision: 5)let gridX = Int((lng - originLng) / gridSize)let gridY = Int((lat - originLat) / gridSize)return GridCell(x: gridX, y: gridY, hash: geohash)
}
2.2 照片地理聚合
照片归类的逻辑并不复杂，但细节决定体验：
- 读取照片 EXIF 中的 GPS 信息，无 GPS 数据时回退到拍摄时间 ± 30s 内的轨迹点进行关联
- 截图类图片（无 EXIF GPS）通过截图时间戳与轨迹时间轴做最近邻匹配
- 聚合结果以地点为 key 存入 SQLite，建立地名 → 照片列表的倒排索引
这一设计让用户搜索「杭州 XX 巷」时，3 秒内即可定位到半年前的全部相关图片——这也是我作为用户最满意的功能点。
2.3 像素地图渲染引擎
视觉层是这个项目的差异化所在。技术选型上没有使用 MapKit/高德等传统地图 SDK 做底图，而是完全自绘：
- 底层用 Metal/Core Graphics 绘制像素网格
- 已点亮的格子有渐变色彩，冷色 → 暖色表示访问频次
- 城市轮廓通过行政区划边界数据预生成，作为背景参考层
- 支持缩放、平移手势，大范围浏览时做 LOD（Level of Detail）降级
像素风格的选择并非纯粹为了「好看」——它天然地对精度做了模糊处理，既保护了用户的精确位置隐私，又提供了游戏化的「点亮收集」体验。
三、本地存储方案
3.1 为什么坚持纯本地
市面上绝大多数轨迹类 App 要求云同步或社交分享，这对于注重隐私的用户是硬伤。「雁过留痕」的设计哲学是：
你的行踪数据属于你自己，任何第三方（包括我作为开发者）都不应该有能力获取。
技术实现上，App 不申请网络权限（或仅在用户主动导出时临时请求），数据库文件存储在 App 沙盒内，用户可通过系统文件管理器直接访问备份。
3.2 数据模型
-- 核心表结构简化示意
CREATE TABLE track_points (id INTEGER PRIMARY KEY,lat REAL, lng REAL,timestamp INTEGER,grid_id TEXT
);CREATE TABLE photos (id INTEGER PRIMARY KEY,local_path TEXT,lat REAL, lng REAL,timestamp INTEGER,grid_id TEXT,place_name TEXT
);CREATE TABLE grids (grid_id TEXT PRIMARY KEY,visit_count INTEGER,first_visit INTEGER,last_visit INTEGER
);
随着数据量增长（测试中单用户半年约 50 万条轨迹点），查询性能通过 grid_id 索引 + 时间分区保持在毫秒级。
四、迭代历程与踩坑记录
v1.0 → v1.5：最小可用
初版只有轨迹记录和基础网格渲染，照片关联靠手动标记。用了两周就发现手动标记根本不会用——人是懒的，自动化才是正道。
v1.5 → v2.0：自动化照片归类
引入 EXIF 解析和时间轴匹配后，照片管理的使用频率提升了一个量级。同时优化了功耗，从「一天掉 30% 电」降到几乎无感。
v2.0 → v2.4：审美与性能
- 重做了像素地图的配色系统，引入设计师协作
- Metal 渲染替代原来的 Core Graphics 方案，万格级网格滚动不掉帧
- 增加了「出片模式」——一键生成带城市轮廓的地图卡片，方便分享
五、一些架构反思
- 过早优化的代价：v1.0 时花了大量时间做 Geohash 精度自适应，实际上固定精度 + 后期聚合就够了
- 本地优先 ≠ 无备份方案：后来补充了 iCloud 文件级备份（非数据库同步），用户换机时不丢数据
- 像素风是一把双刃剑：喜欢的人非常喜欢，不喜欢的人觉得「看不清」——这就是定位取舍
结语
「雁过留痕」目前迭代到 2.4，作为独立开发项目，它解决的是一个很小的问题：让你能在 3 秒内找到任何一次出行的记录。技术上没有什么火箭科学，更多是对生活场景的观察和对细节体验的打磨。
如果你也是独立开发者，或者对本地优先（Local-first）架构、地理数据处理有兴趣，欢迎在评论区交流。