简介基于Android平台、采用Java开发的跑步App完整项目源码面向Android初学者和需要完成课程设计的学生可用于快速掌握移动端应用开发流程。资源内置用户注册登录、计步传感器监测、运动计时、任务目标设定、跑步记录持久化存储等功能模块并附带演示视频和工程代码。整个压缩包共330个文件大小33.01MB主要包含48个java源文件、145个xml布局与配置、60个png素材、11个so动态库以及2个mp4演示视频另有gradle构建脚本、jar依赖库和readme说明文档项目结构清晰适合导入Android Studio直接运行调试。目前已有397人学习下载通过对照视频和源码可以深入理解Android生命周期管理、SensorManager传感器数据处理、SQLite数据库操作以及异步任务等核心知识点同时从布局设计、事件响应到本地存储的完整链路也为后续独立开发其他类型App提供了可复用的思路与经验。1. 基于Android的跑步App源码包拿到手先看这三处在GitHub、CSDN和各类源码分享站上基于Android的跑步App源码包是下载量靠前的品类zip里通常是一份Android Studio工程、一段演示视频和一份或详或略的README。跑步App是Android开发里典型的综合练习定位、地图、前台服务、传感器、数据库和图表几乎全沾边所以很多人拿它当期末大作业、毕设甚至面试作品。这篇不去评价某个具体包的好坏而是把这类源码该有的模块、几个关键数字的算法、让工程在新版Android Studio里跑起来的步骤以及真机验证时最容易踩的GPS漂移和进程被杀这两个坑一次讲清。手里正好有这个zip、或者打算从零搭一个的人都能按这条线走完。2. 跑步App的核心架构定位、前台服务与地图三块怎么搭跑步App的骨架可以抽象成一条链路定位模块持续产出坐标前台服务保证采集进程不被系统回收数据落库后算出距离和配速最后地图SDK把坐标点连成轨迹。绝大多数源码包的工程结构都围绕这条链路展开先把这条链看懂再改代码就不容易迷路。2.1 定位方案的选型LocationManager与FusedLocationProvider的取舍安卓定位有两条主流路线。老工程常用原生LocationManager直接在onLocationChanged回调里收坐标代码直观、无额外依赖Google系工程则用FusedLocationProviderClientGMS做融合定位同时用GPS、Wi-Fi和基站信号冷启动出位置快、相对省电但设备上没装GMS就跑不起来。对比项LocationManagerFusedLocationProviderClient额外依赖无需引入play-services-location首次定位速度纯GPS冷启动慢融合定位几秒内出粗略位置真机兼容性所有Android设备依赖GMS部分国行机型不可用典型场景教学演示、离线源码面向海外市场的产品级App我拿到源码包第一件事是看build.gradle里有没有com.google.android.gms.location这个依赖。如果是LocationManager版本改一下定位频率和最小位移阈值就能跑通如果是GMS版本先确认测试机带不带GMS否则定位回调永远不会触发界面就停在正在定位上。提示如果包用的是老式LocationManager建议保留原实现先把流程跑通不要一上来就迁到FusedLocationProvider。依赖、GMS检测、回调时机三处要一起改调试成本直接翻倍。2.2 前台服务是跑步App存活的前提定位本身不难难在持续定位。Android 8.0之后后台执行被严格限制普通Service里长时间盯GPS几分钟内就会被系统回收。跑步App的标准做法是启动前台服务配合一条常驻通知让系统知道用户正在计时跑步。class RunService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val channelId run_channel val manager getSystemService(NOTIFICATION_SERVICE) as NotificationManager manager.createNotificationChannel( NotificationChannel(channelId, 跑步记录, NotificationManager.IMPORTANCE_LOW) ) val notification Notification.Builder(this, channelId) .setContentTitle(正在跑步) .setContentText(累计时间 00:00:00) .setSmallIcon(R.drawable.ic_run) .setOngoing(true) .build() startForeground(1, notification) // 在这里注册定位监听把坐标写入Repository长期持有 return START_STICKY } }这段代码的关键是startForeground(1, notification)。从Android 8.0开始前台服务必须在启动后5秒内调用它否则抛出ForegroundServiceStartNotAllowedExceptionAndroid 13又把通知权限改成了运行时申请老源码包里经常漏掉POST_NOTIFICATIONS这一条结果通知不显示、服务被视为非法。START_STICKY表示进程被系统杀掉后会尝试重建服务但重建时定位监听和已记录的坐标都要自己恢复严谨的做法是把上一段轨迹缓存到SharedPreferences里启动时重新读取。2.3 轨迹地图Polyline把坐标点串成路线地图展示一般用高德或百度国内源码包里高德占多数因为它不需要GMS、在国行设备上兼容性更好。跑步轨迹的本质是Polyline拿到一串LatLng点按顺序连成折线再在起点和终点各画一个Marker。这里有个容易被忽略的点定位点不是均匀分布的等红绿灯时坐标会堆在一起画出来的轨迹边缘发毛这个留到轨迹平滑部分处理。地图SDK接入有三步加依赖、在AndroidManifest里填API Key、在Application里做初始化。初始化代码通常是这样的class RunApplication : Application() { override fun onCreate() { super.onCreate() AMapLocationClient.updatePrivacyShow(this, true, true) AMapLocationClient.updatePrivacyAgree(this, true) MapsInitializer.initialize(this) } }updatePrivacyShow和updatePrivacyAgree是高德SDK近几个版本的硬性合规要求必须在定位前调用否则SDK直接抛异常拒绝工作。很多源码包是两三年前写的SDK版本落后这段初始化代码往往是导入后第一个要补的地方如果包里的高德SDK版本正好是旧的加上这两行也不会冲突。3. 距离、配速和卡路里跑步数据是用这几个公式算出来的演示视频里跑一圈界面上的距离、配速、卡路里同步在跳。这些数字不是地图SDK白给的是源码自己算的。算得对不对直接决定这个App能不能真用来记录跑步。3.1 用Haversine计算相邻定位点距离球面上两点间距离不能直接套勾股定理。常见做法是Haversine公式把经纬度转成弧度后按大圆距离计算公里级距离上误差约0.5%记录跑步完全够用。fun haversineMeters(lat1: Double, lon1: Double, lat2: Double, lon2: Double): Double { val radius 6371000.0 val dLat Math.toRadians(lat2 - lat1) val dLon Math.toRadians(lon2 - lon1) val a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLon / 2) * Math.sin(dLon / 2) return 2 * radius * Math.asin(Math.sqrt(a)) }总距离是相邻两点逐段累加。这个函数有三处值得注意一是radius取6371000米是平均半径对跑步场景够用二是返回单位是米累加时别和公里混用三是不要在循环里频繁创建Location对象调distanceTo()虽然它内部也是球面算法但每次都要new对象在1秒一次的高频采集中会产生明显GC压力。另一个大坑是静止漂移手机放桌上GPS也会跳几米到十几米跑步前站着系个鞋带如果不做过滤能凭空累积出三五十米假距离。3.2 配速的平滑处理配速是跑步App的核心指标常规口径是移动时间除以移动距离单位min/km。难点在移动的定义停下来等红灯的那几十秒算不算业界常见做法是设定一个速度阈值低于阈值判定为静止静止时长不计入移动时间这样算出来的才是moving time配速。data class TrackPoint( val lat: Double, val lon: Double, val time: Long, val speed: Float ) fun calcPace(points: ListTrackPoint): String { var moveSec 0.0 var totalMeters 0.0 for (i in 1 until points.size) { val prev points[i - 1] val cur points[i] val dist haversineMeters(prev.lat, prev.lon, cur.lat, cur.lon) val dt (cur.time - prev.time) / 1000.0 val spd if (dt 0) dist / dt else 0.0 if (spd 0.5) { moveSec dt totalMeters dist } } val paceMin (moveSec / 60.0) / (totalMeters / 1000.0) val mm paceMin.toInt() val ss ((paceMin - mm) * 60).toInt() return %d%02d.format(mm, ss) }这段里的speed取自Location.getSpeed()也有源码用distance/dt自己算两者在GPS信号差的时候差异很大。0.5 m/s这个阈值不是铁律常规做法是抽成常量按场景可调慢走模式要降到0.3跑完拉伸时如果阈值太低拉伸的时间会被算进移动时间配速虚低。另一个常见误用是直接用总时长除总距离这叫elapsed pace和显示在表盘上的实时配速混为一谈产品定位完全不同。3.3 卡路里估算口径与身高体重参数卡路里没有精确公式所有App都是估算。常见口径是MET代谢当量法热量(kcal)MET值×体重(kg)×时长(h)。跑步的MET按速度分档源码里通常维护一张速度区间到MET值的映射表体重从用户设置里读。速度区间MET值对应场景小于6 km/h6.0快走、慢跑热身6~10 km/h8.3常规慢跑10~14 km/h11.0中高速跑MET表和分档方式各家差异很大同一个包换一张表结果能差20%。如果是期末大作业或面试作品卡路里没必要追求绝对准确但一定要在设置页或接口注释里写清基于MET法估算否则被追问怎么验证你的卡路里准不准时很难收场。年龄、性别、心率对卡路里的影响在这个口径下被忽略了这是可接受的简化但要在文档里声明。4. 把源码跑起来Android Studio、权限和API Key三个必调参数源码包解压后第一件事不是点Run。老工程在新版Android Studio里直接跑十有八九挂在Gradle同步或SDK版本上。按下面的顺序排查基本能在十分钟内见到首屏。4.1 导入工程后的Gradle与SDK版本适配先看gradle/wrapper/gradle-wrapper.properties里的distributionUrl再看根build.gradle里的AGP版本和compileSdk。很多分享的源码compileSdk还停在30或31新装的Android Studio默认JDK 17、Gradle 8AGP低于7.0直接不兼容。常见做法不是改工程去迁新版而是装一个与工程匹配的JDK版本。# 在工程根目录确认当前Gradle版本 cat gradle/wrapper/gradle-wrapper.properties # 常见匹配关系按这个组合试最快 # Gradle 7.4 AGP 7.x: 适合 compileSdk 32/33JDK 11 # Gradle 8.2 AGP 8.x: 适合 compileSdk 33/34JDK 17典型报错原因处理方式Could not find com.android.tools.build:gradle工程指定的AGP版本号有问题或已被仓库清理手改AGP版本并确认google()仓库在repositories里Unsupported class file major version 61JDK太新AGP太老File→Project Structure里把JDK切到11INSTALL_FAILED_INSUFFICIENT_STORAGE模拟器数据分区太小AVD Manager里编辑模拟器扩大data分区工具链匹配这事演示视频基本不会讲因为它录制的环境和你现在差了好几个版本。我的做法是先看包内有没有local.properties或jdk配置记录没有就按上表从JDK版本开始逐个试比在build.gradle里盲改Gradle版本快得多。4.2 权限声明与运行时申请跑步App的权限比普通App多而且Android大版本不同声明位置和政策都不同。AndroidManifest里至少要包含这些uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_LOCATION / uses-permission android:nameandroid.permission.ACTIVITY_RECOGNITION / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS /FOREGROUND_SERVICE_LOCATION是Android 14新增的老源码包里没有targetSdk升到34后不加这一条前台服务里申请定位权限会直接崩溃。ACTIVITY_RECOGNITION是Android 10引入的用于识别用户处于跑步还是静止状态如果包里还接了蓝牙心率带通常还要补BLUETOOTH_SCAN。运行时申请用Activity Result API写最省事val launcher registerForActivityResult( ActivityResultContracts.RequestMultiplePermissions() ) { result - val fine result[android.Manifest.permission.ACCESS_FINE_LOCATION] ?: false if (!fine) { // 跳转设置页让用户手动打开光弹Toast没用 } } launcher.launch(arrayOf( android.Manifest.permission.ACCESS_FINE_LOCATION, android.Manifest.permission.ACTIVITY_RECOGNITION ))权限这关最常见的故障是只弹了定位申请、没弹通知权限Android 13上通知直接不显示前台服务失去常驻通道锁屏后进程很容易被杀。面试或答辩时能把Android 10、13、14三个版本的权限变化说清楚比背概念得分高。4.3 地图SDK的API Key配置与签名匹配高德和百度地图的Key是按包名签名SHA1绑定的。源码包里通常带着作者自己的Key你直接打包运行地图区域会显示鉴权失败水印或者干脆白屏。自己的Key要去开放平台申请配置在AndroidManifest的application节点里meta-data android:namecom.amap.api.v2.apikey android:value你的Key /SHA1这个坑尤其隐蔽。Android Studio跑调试包用的是系统生成的debug签名打release包用的是你自己的签名文件两套SHA1不一样同一个Key只绑了一个SHA1的话就会调试能显示、发布不能显示。我一般把debug和release配置两个不同Key或者统一用同一个签名文件签名调试包。注意直接改包名SDK也会失效。如果源码里的applicationId和你自己的包名不一致要去开放平台重新申请绑定新包名的Key只改SHA1不够。5. 真机验证排掉GPS漂移和后台被杀这两个坑5.1 用模拟器定位模拟做初步验证Android Studio模拟器的Extended Controls里有Location面板可以设置多个经纬度坐标点作为线路循环发送也可以直接输入坐标做单点跳转。注意模拟器默认位置是固定的要勾选循环发送坐标否则距离永远是0。模拟器适合验证UI流程和数据计算但GPS精度值、速度值这类硬件相关的逻辑必须在真机上验模拟的定位点精度值一般都返回一个固定大值会把精度过滤逻辑带偏。5.2 GPS漂移过滤的三个阈值漂移过滤是跑步App源码里最值得改的业务逻辑。我一般维护三个阈值精度阈值坐标的Accuracy大于20米的点不入库速度阈值瞬时速度超过25 m/s90 km/h判定为异常可能是坐车或GPS跳变单点位移阈值相邻两点距离超过500米且时间间隔小于10秒判定为跳变直接回退到上一个有效点。三个阈值配合轨迹基本不会出现穿楼或瞬间闪现到隔壁街区的现象。阈值要写成可在设置页调试的配置不要硬编码在算法类里。5.3 后台定位保活与电池优化白名单Android 6.0之后的Doze模式会限制后台定位频率Android 12之后系统还会自动重置未使用应用的电池优化白名单。跑步App一旦锁屏定位频率可能被系统拉低到几乎不更新。正规做法是引导用户把App加入电池优化白名单通过Intent跳转val intent Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) intent.data Uri.parse(package:$packageName) startActivity(intent)这个Intent需要在运行时申请且先判断isIgnoringBatteryOptimizations返回是否为falseAndroidManifest里不能直接声明这个权限。真机上验证保活是否生效最直接的办法是锁屏跑10分钟再解锁打开轨迹页看相邻定位点的时间间隔如果中间出现一大段空白但进程没被杀说明只是定位被降频如果前台服务被系统重建要看START_STICKY之后的恢复逻辑有没有把之前的轨迹接上接不上就会在轨迹中间出现一条直线。最后补一条验收技巧跑完在轨迹页截图和演示视频里的路线形态对比。如果视频里轨迹平滑、你的却方方正正多半是定位更新间隔被系统或代码拉长到十几秒以上把LocationRequest的setInterval从10秒调到3秒再看同时盯住电池曲线找到精度和耗电的平衡点这一步做完跑步App才算真正能拿出门记录一次完整的跑步。本文还有配套的精品资源点击获取
简介基于Android平台、采用Java开发的跑步App完整项目源码面向Android初学者和需要完成课程设计的学生可用于快速掌握移动端应用开发流程。资源内置用户注册登录、计步传感器监测、运动计时、任务目标设定、跑步记录持久化存储等功能模块并附带演示视频和工程代码。整个压缩包共330个文件大小33.01MB主要包含48个java源文件、145个xml布局与配置、60个png素材、11个so动态库以及2个mp4演示视频另有gradle构建脚本、jar依赖库和readme说明文档项目结构清晰适合导入Android Studio直接运行调试。目前已有397人学习下载通过对照视频和源码可以深入理解Android生命周期管理、SensorManager传感器数据处理、SQLite数据库操作以及异步任务等核心知识点同时从布局设计、事件响应到本地存储的完整链路也为后续独立开发其他类型App提供了可复用的思路与经验。1. 基于Android的跑步App源码包拿到手先看这三处在GitHub、CSDN和各类源码分享站上基于Android的跑步App源码包是下载量靠前的品类zip里通常是一份Android Studio工程、一段演示视频和一份或详或略的README。跑步App是Android开发里典型的综合练习定位、地图、前台服务、传感器、数据库和图表几乎全沾边所以很多人拿它当期末大作业、毕设甚至面试作品。这篇不去评价某个具体包的好坏而是把这类源码该有的模块、几个关键数字的算法、让工程在新版Android Studio里跑起来的步骤以及真机验证时最容易踩的GPS漂移和进程被杀这两个坑一次讲清。手里正好有这个zip、或者打算从零搭一个的人都能按这条线走完。2. 跑步App的核心架构定位、前台服务与地图三块怎么搭跑步App的骨架可以抽象成一条链路定位模块持续产出坐标前台服务保证采集进程不被系统回收数据落库后算出距离和配速最后地图SDK把坐标点连成轨迹。绝大多数源码包的工程结构都围绕这条链路展开先把这条链看懂再改代码就不容易迷路。2.1 定位方案的选型LocationManager与FusedLocationProvider的取舍安卓定位有两条主流路线。老工程常用原生LocationManager直接在onLocationChanged回调里收坐标代码直观、无额外依赖Google系工程则用FusedLocationProviderClientGMS做融合定位同时用GPS、Wi-Fi和基站信号冷启动出位置快、相对省电但设备上没装GMS就跑不起来。对比项LocationManagerFusedLocationProviderClient额外依赖无需引入play-services-location首次定位速度纯GPS冷启动慢融合定位几秒内出粗略位置真机兼容性所有Android设备依赖GMS部分国行机型不可用典型场景教学演示、离线源码面向海外市场的产品级App我拿到源码包第一件事是看build.gradle里有没有com.google.android.gms.location这个依赖。如果是LocationManager版本改一下定位频率和最小位移阈值就能跑通如果是GMS版本先确认测试机带不带GMS否则定位回调永远不会触发界面就停在正在定位上。提示如果包用的是老式LocationManager建议保留原实现先把流程跑通不要一上来就迁到FusedLocationProvider。依赖、GMS检测、回调时机三处要一起改调试成本直接翻倍。2.2 前台服务是跑步App存活的前提定位本身不难难在持续定位。Android 8.0之后后台执行被严格限制普通Service里长时间盯GPS几分钟内就会被系统回收。跑步App的标准做法是启动前台服务配合一条常驻通知让系统知道用户正在计时跑步。class RunService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val channelId run_channel val manager getSystemService(NOTIFICATION_SERVICE) as NotificationManager manager.createNotificationChannel( NotificationChannel(channelId, 跑步记录, NotificationManager.IMPORTANCE_LOW) ) val notification Notification.Builder(this, channelId) .setContentTitle(正在跑步) .setContentText(累计时间 00:00:00) .setSmallIcon(R.drawable.ic_run) .setOngoing(true) .build() startForeground(1, notification) // 在这里注册定位监听把坐标写入Repository长期持有 return START_STICKY } }这段代码的关键是startForeground(1, notification)。从Android 8.0开始前台服务必须在启动后5秒内调用它否则抛出ForegroundServiceStartNotAllowedExceptionAndroid 13又把通知权限改成了运行时申请老源码包里经常漏掉POST_NOTIFICATIONS这一条结果通知不显示、服务被视为非法。START_STICKY表示进程被系统杀掉后会尝试重建服务但重建时定位监听和已记录的坐标都要自己恢复严谨的做法是把上一段轨迹缓存到SharedPreferences里启动时重新读取。2.3 轨迹地图Polyline把坐标点串成路线地图展示一般用高德或百度国内源码包里高德占多数因为它不需要GMS、在国行设备上兼容性更好。跑步轨迹的本质是Polyline拿到一串LatLng点按顺序连成折线再在起点和终点各画一个Marker。这里有个容易被忽略的点定位点不是均匀分布的等红绿灯时坐标会堆在一起画出来的轨迹边缘发毛这个留到轨迹平滑部分处理。地图SDK接入有三步加依赖、在AndroidManifest里填API Key、在Application里做初始化。初始化代码通常是这样的class RunApplication : Application() { override fun onCreate() { super.onCreate() AMapLocationClient.updatePrivacyShow(this, true, true) AMapLocationClient.updatePrivacyAgree(this, true) MapsInitializer.initialize(this) } }updatePrivacyShow和updatePrivacyAgree是高德SDK近几个版本的硬性合规要求必须在定位前调用否则SDK直接抛异常拒绝工作。很多源码包是两三年前写的SDK版本落后这段初始化代码往往是导入后第一个要补的地方如果包里的高德SDK版本正好是旧的加上这两行也不会冲突。3. 距离、配速和卡路里跑步数据是用这几个公式算出来的演示视频里跑一圈界面上的距离、配速、卡路里同步在跳。这些数字不是地图SDK白给的是源码自己算的。算得对不对直接决定这个App能不能真用来记录跑步。3.1 用Haversine计算相邻定位点距离球面上两点间距离不能直接套勾股定理。常见做法是Haversine公式把经纬度转成弧度后按大圆距离计算公里级距离上误差约0.5%记录跑步完全够用。fun haversineMeters(lat1: Double, lon1: Double, lat2: Double, lon2: Double): Double { val radius 6371000.0 val dLat Math.toRadians(lat2 - lat1) val dLon Math.toRadians(lon2 - lon1) val a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLon / 2) * Math.sin(dLon / 2) return 2 * radius * Math.asin(Math.sqrt(a)) }总距离是相邻两点逐段累加。这个函数有三处值得注意一是radius取6371000米是平均半径对跑步场景够用二是返回单位是米累加时别和公里混用三是不要在循环里频繁创建Location对象调distanceTo()虽然它内部也是球面算法但每次都要new对象在1秒一次的高频采集中会产生明显GC压力。另一个大坑是静止漂移手机放桌上GPS也会跳几米到十几米跑步前站着系个鞋带如果不做过滤能凭空累积出三五十米假距离。3.2 配速的平滑处理配速是跑步App的核心指标常规口径是移动时间除以移动距离单位min/km。难点在移动的定义停下来等红灯的那几十秒算不算业界常见做法是设定一个速度阈值低于阈值判定为静止静止时长不计入移动时间这样算出来的才是moving time配速。data class TrackPoint( val lat: Double, val lon: Double, val time: Long, val speed: Float ) fun calcPace(points: ListTrackPoint): String { var moveSec 0.0 var totalMeters 0.0 for (i in 1 until points.size) { val prev points[i - 1] val cur points[i] val dist haversineMeters(prev.lat, prev.lon, cur.lat, cur.lon) val dt (cur.time - prev.time) / 1000.0 val spd if (dt 0) dist / dt else 0.0 if (spd 0.5) { moveSec dt totalMeters dist } } val paceMin (moveSec / 60.0) / (totalMeters / 1000.0) val mm paceMin.toInt() val ss ((paceMin - mm) * 60).toInt() return %d%02d.format(mm, ss) }这段里的speed取自Location.getSpeed()也有源码用distance/dt自己算两者在GPS信号差的时候差异很大。0.5 m/s这个阈值不是铁律常规做法是抽成常量按场景可调慢走模式要降到0.3跑完拉伸时如果阈值太低拉伸的时间会被算进移动时间配速虚低。另一个常见误用是直接用总时长除总距离这叫elapsed pace和显示在表盘上的实时配速混为一谈产品定位完全不同。3.3 卡路里估算口径与身高体重参数卡路里没有精确公式所有App都是估算。常见口径是MET代谢当量法热量(kcal)MET值×体重(kg)×时长(h)。跑步的MET按速度分档源码里通常维护一张速度区间到MET值的映射表体重从用户设置里读。速度区间MET值对应场景小于6 km/h6.0快走、慢跑热身6~10 km/h8.3常规慢跑10~14 km/h11.0中高速跑MET表和分档方式各家差异很大同一个包换一张表结果能差20%。如果是期末大作业或面试作品卡路里没必要追求绝对准确但一定要在设置页或接口注释里写清基于MET法估算否则被追问怎么验证你的卡路里准不准时很难收场。年龄、性别、心率对卡路里的影响在这个口径下被忽略了这是可接受的简化但要在文档里声明。4. 把源码跑起来Android Studio、权限和API Key三个必调参数源码包解压后第一件事不是点Run。老工程在新版Android Studio里直接跑十有八九挂在Gradle同步或SDK版本上。按下面的顺序排查基本能在十分钟内见到首屏。4.1 导入工程后的Gradle与SDK版本适配先看gradle/wrapper/gradle-wrapper.properties里的distributionUrl再看根build.gradle里的AGP版本和compileSdk。很多分享的源码compileSdk还停在30或31新装的Android Studio默认JDK 17、Gradle 8AGP低于7.0直接不兼容。常见做法不是改工程去迁新版而是装一个与工程匹配的JDK版本。# 在工程根目录确认当前Gradle版本 cat gradle/wrapper/gradle-wrapper.properties # 常见匹配关系按这个组合试最快 # Gradle 7.4 AGP 7.x: 适合 compileSdk 32/33JDK 11 # Gradle 8.2 AGP 8.x: 适合 compileSdk 33/34JDK 17典型报错原因处理方式Could not find com.android.tools.build:gradle工程指定的AGP版本号有问题或已被仓库清理手改AGP版本并确认google()仓库在repositories里Unsupported class file major version 61JDK太新AGP太老File→Project Structure里把JDK切到11INSTALL_FAILED_INSUFFICIENT_STORAGE模拟器数据分区太小AVD Manager里编辑模拟器扩大data分区工具链匹配这事演示视频基本不会讲因为它录制的环境和你现在差了好几个版本。我的做法是先看包内有没有local.properties或jdk配置记录没有就按上表从JDK版本开始逐个试比在build.gradle里盲改Gradle版本快得多。4.2 权限声明与运行时申请跑步App的权限比普通App多而且Android大版本不同声明位置和政策都不同。AndroidManifest里至少要包含这些uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_LOCATION / uses-permission android:nameandroid.permission.ACTIVITY_RECOGNITION / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS /FOREGROUND_SERVICE_LOCATION是Android 14新增的老源码包里没有targetSdk升到34后不加这一条前台服务里申请定位权限会直接崩溃。ACTIVITY_RECOGNITION是Android 10引入的用于识别用户处于跑步还是静止状态如果包里还接了蓝牙心率带通常还要补BLUETOOTH_SCAN。运行时申请用Activity Result API写最省事val launcher registerForActivityResult( ActivityResultContracts.RequestMultiplePermissions() ) { result - val fine result[android.Manifest.permission.ACCESS_FINE_LOCATION] ?: false if (!fine) { // 跳转设置页让用户手动打开光弹Toast没用 } } launcher.launch(arrayOf( android.Manifest.permission.ACCESS_FINE_LOCATION, android.Manifest.permission.ACTIVITY_RECOGNITION ))权限这关最常见的故障是只弹了定位申请、没弹通知权限Android 13上通知直接不显示前台服务失去常驻通道锁屏后进程很容易被杀。面试或答辩时能把Android 10、13、14三个版本的权限变化说清楚比背概念得分高。4.3 地图SDK的API Key配置与签名匹配高德和百度地图的Key是按包名签名SHA1绑定的。源码包里通常带着作者自己的Key你直接打包运行地图区域会显示鉴权失败水印或者干脆白屏。自己的Key要去开放平台申请配置在AndroidManifest的application节点里meta-data android:namecom.amap.api.v2.apikey android:value你的Key /SHA1这个坑尤其隐蔽。Android Studio跑调试包用的是系统生成的debug签名打release包用的是你自己的签名文件两套SHA1不一样同一个Key只绑了一个SHA1的话就会调试能显示、发布不能显示。我一般把debug和release配置两个不同Key或者统一用同一个签名文件签名调试包。注意直接改包名SDK也会失效。如果源码里的applicationId和你自己的包名不一致要去开放平台重新申请绑定新包名的Key只改SHA1不够。5. 真机验证排掉GPS漂移和后台被杀这两个坑5.1 用模拟器定位模拟做初步验证Android Studio模拟器的Extended Controls里有Location面板可以设置多个经纬度坐标点作为线路循环发送也可以直接输入坐标做单点跳转。注意模拟器默认位置是固定的要勾选循环发送坐标否则距离永远是0。模拟器适合验证UI流程和数据计算但GPS精度值、速度值这类硬件相关的逻辑必须在真机上验模拟的定位点精度值一般都返回一个固定大值会把精度过滤逻辑带偏。5.2 GPS漂移过滤的三个阈值漂移过滤是跑步App源码里最值得改的业务逻辑。我一般维护三个阈值精度阈值坐标的Accuracy大于20米的点不入库速度阈值瞬时速度超过25 m/s90 km/h判定为异常可能是坐车或GPS跳变单点位移阈值相邻两点距离超过500米且时间间隔小于10秒判定为跳变直接回退到上一个有效点。三个阈值配合轨迹基本不会出现穿楼或瞬间闪现到隔壁街区的现象。阈值要写成可在设置页调试的配置不要硬编码在算法类里。5.3 后台定位保活与电池优化白名单Android 6.0之后的Doze模式会限制后台定位频率Android 12之后系统还会自动重置未使用应用的电池优化白名单。跑步App一旦锁屏定位频率可能被系统拉低到几乎不更新。正规做法是引导用户把App加入电池优化白名单通过Intent跳转val intent Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) intent.data Uri.parse(package:$packageName) startActivity(intent)这个Intent需要在运行时申请且先判断isIgnoringBatteryOptimizations返回是否为falseAndroidManifest里不能直接声明这个权限。真机上验证保活是否生效最直接的办法是锁屏跑10分钟再解锁打开轨迹页看相邻定位点的时间间隔如果中间出现一大段空白但进程没被杀说明只是定位被降频如果前台服务被系统重建要看START_STICKY之后的恢复逻辑有没有把之前的轨迹接上接不上就会在轨迹中间出现一条直线。最后补一条验收技巧跑完在轨迹页截图和演示视频里的路线形态对比。如果视频里轨迹平滑、你的却方方正正多半是定位更新间隔被系统或代码拉长到十几秒以上把LocationRequest的setInterval从10秒调到3秒再看同时盯住电池曲线找到精度和耗电的平衡点这一步做完跑步App才算真正能拿出门记录一次完整的跑步。本文还有配套的精品资源点击获取
)
)
