Android设备获取实时位置应优先使用FusedLocationProviderClient，需动态申请定位权限并检查定位开关；传感器与位置数据需通过SystemClock.elapsedRealtimeNanos()统一时间戳对齐；离线数据暂存推荐内存队列+NDJSON文件追加写；后台持续跟踪须用前台服务并声明FOREGROUND_SERVICE_TYPE_LOCATION。
Android设备如何获取实时位置数据
Java在Android中不直接提供定位能力，实际调用的是Android SDK的LocationManager或FusedLocationProviderClient（推荐）。需要声明ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION权限，Android 10+还需ACCESS_BACKGROUND_LOCATION（后台跟踪场景必需）。
常见错误：只申请运行时权限但没检查isProviderEnabled()，导致getLastKnownLocation()返回null；或使用LocationManager.GPS_PROVIDER却未开启GPS硬件。
- 优先用
FusedLocationProviderClient，省电且精度自适应 - 设置
LocationRequest时避免setInterval(1000)这种高频请求——后台服务下系统会降频甚至拒绝 - 真机测试务必打开“位置信息”总开关，模拟器需手动发送经纬度（Android Studio Emulator控制台输入
geo fix 116.397428 39.90923）
传感器数据怎么和位置对齐时间戳
加速度计、陀螺仪等传感器回调（SensorEventListener.onSensorChanged()）与定位回调（LocationCallback.onLocationResult()）完全异步，各自使用不同时间源：event.timestamp是纳秒级芯片时间，location.getTime()是毫秒级UTC时间，二者不可直接比较。
正确做法是统一转为SystemClock.elapsedRealtimeNanos()作为本地单调时钟基准：
立即学习“Java免费学习笔记（深入）”；
// 在Application或Service初始化时记录偏移 long bootOffset = SystemClock.elapsedRealtimeNanos() - System.nanoTime(); <p>// 后续所有数据打上统一时间戳 long alignedTime = SystemClock.elapsedRealtimeNanos() + bootOffset;
- 不要用
System.currentTimeMillis()对齐——它可能被用户/网络校准跳变 - 传感器
timestamp需除以1_000_000转换为毫秒再参与业务逻辑，否则数值过大溢出 - 若需长期存储，最终落库时仍应保留原始
location.getTime()（用于时区还原）和alignedTime（用于内部事件排序）
离线环境下数据如何可靠暂存
移动网络不稳定时，不能依赖实时HTTP上传。SQLite虽可用，但高频率写入（如每秒多条传感器+定位）易触发WAL checkpoint阻塞主线程；Room抽象层默认也不支持事务批量插入。
更稳妥的选择是「内存队列 + 文件追加写」组合：
- 用
ConcurrentLinkedQueue缓存待发数据对象（避免锁竞争） - 后台线程定期将队列内容以JSON行格式（NDJSON）追加到
getFilesDir()下的track_buffer.log，每行一个{ "ts": 171..., "lat": 39.9..., "acc": [0.1, -0.2, 9.8] } - 上传成功后，用
RandomAccessFile标记已发送行（如在行首加[S]），而非删除文件——避免I/O中断导致数据丢失
注意：不要用SharedPreferences存轨迹数据——它本质是XML文件，频繁edit().putString().apply()会引发ANR。
后台持续跟踪的系统限制怎么绕过
Android 8.0+强制限制后台服务，startService()在后台会被系统静默拒绝；Android 12+进一步收紧foregroundServiceType类型，普通定位必须声明FOREGROUND_SERVICE_TYPE_LOCATION。
可行路径只有两条：
- 前台服务 + 持续通知：调用
startForeground(id, notification)，并在通知里明确提示“正在记录位置”，否则应用商店审核可能拒审 - JobIntentService（AndroidX）替代传统Service：系统允许其在后台执行有限任务，但需接受调度延迟（最长15分钟才触发）
关键细节：WorkManager不适合实时跟踪——它的最小间隔是15分钟，且无法保证精确触发时间；而AlarmManager.setExactAndAllowWhileIdle()在Android 10+已被大幅限制，仅允许每天最多一次唤醒。
