简介本资源为基于Android平台的跑步App完整项目包采用Java语言开发适合Android初学者、课程设计及项目实战训练使用。App覆盖用户注册登录、计步传感、运动计时、任务目标设定与SQLite数据持久化等核心模块可帮助学习者理解传感器数据获取、Activity生命周期管理、异步任务处理及本地存储等关键开发要点。压缩包共330个文件包含145个xml布局与配置、60张png图片、48个java源码、11个so库、3个jar库、3个mp3音效及2个mp4演示视频附带gradle构建脚本和readme说明包体大小约33.01MB目录结构清晰便于按模块查阅。已有397人学习浏览适合需要通过完整案例快速积累Android实战经验、完成课程报告或毕业设计的开发者。演示视频可直观展示运行效果与操作流程源码注释与模块划分有助于对照学习、二次开发是一份兼具教学与参考价值的项目资源。1. 从源码开始的Android跑步App开发这条路该怎么走打开一个名为“基于Android的跑步App开发(源码演示视频).zip”的压缩包时多数人第一反应是解压、跑起来、改改界面就交差。但真正的价值不在于那几屏代码而在于理解跑步App背后的“运动数据链路”手机如何拿到经纬度与加速度数据如何用这些数据推导出配速、步频和卡路里消耗又如何在一个长时间运行的幻觉场景里保持电量与内存的稳定。这些能力恰恰是Android中Activity、Service、ContentProvider及传感器框架的综合运用而不是单纯的UI堆砌。这篇内容面向两类读者一是有Android基础、想独立完成一个完整App的开发者二是手上拿到源码但不知道怎么改造成自己项目的学生或初级工程师。我会从功能定义、权限模型、定位方案、数据存储和真机调试几个层面展开每步都给可复现的代码和参数说明。不绕弯子直接从你打开Android Studio到把跑步界面真实跑通的路径讲清楚。2. 跑步App的功能骨架先搞清楚后台定位、实时轨迹和数据回放三个硬需求2.1 跑步场景与普通地图App的本质区别地图App打开时才定位跑步App却必须从“开始运动”到“结束运动”持续记录期间用户锁屏、切换应用甚至来电记录都不能中断。这个差异决定了跑步App的架构起点不是Activity而是Service而且必须考虑系统对后台服务的限制。跑步App的核心需求可以拆成三项第一轨迹记录。每3秒或者每5米拿到一次经纬度按时间顺序存储并绘制在地图上。误差控制决定了App的好坏这里涉及Location的accuracy、timeInterval和distanceInterval三个关键参数的权衡。第二运动状态识别。手机放哪里、用户走还是跑可以通过系统加速度计和步频算法判断。源码中有没有做这一步直接决定了卡路里计算的准确度。第三运动回放和统计。结束跑步后用户要看到今天的路线、分段配速、总时长和平均速度。这些数据需要本地持久化用Room或者SQLite都行但必须有清晰的表结构。// 跑步会话的数据结构设计对应Room实体类 Entity(tableName run_session) public class RunSession { PrimaryKey(autoGenerate true) public long id; public long startTime; // 开始时间戳单位毫秒 public long endTime; // 结束时间戳 public float totalDistance; // 总距离单位米 public long totalDuration; // 总时长单位秒 public int averagePace; // 平均配速单位秒/公里 public int maxSpeed; // 最大瞬时速度单位km/h public String dateTag; // 存储当天的日期字符串用于按天查询 }这个实体大约是你解压源码后最先值得细看的地方。字段设计得好后面画图表、做历史记录都省力。如果源码里字段只有startTime、endTime没有分段配速的存储说明它的统计逻辑可能是在每次暂停时算一次用户恢复运动时再开新段。这种做法可接受但不适合做专业级跑者分析。2.2 Android 12以上后台定位权限被脱钩后权限请求必须三步走Android后台定位权限从API 29开始收紧到API 31Android 12时后台定位和前台定位必须拆成两个权限独立请求。很多源码项目跑到Android 13、14时会遇到“明明给了定位权限但服务里拿不到位置”的问题问题就出在只请求了前台权限没请求后台权限或者请求后台权限的方式不对。处理权限的正确顺序是!-- AndroidManifest.xml 中需要声明的权限 -- uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_BACKGROUND_LOCATION / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE /请求逻辑在代码里的顺序是先请求前台精确位置权限拿到前台权限后再请求后台定位权限不能一次性同时请求。同时Android 14要求前台服务必须指定类型跑步App需要声明为location类型service android:name.service.TrackingService android:foregroundServiceTypelocation android:exportedfalse /这一步很容易被忽略。同一个源码在Android 12上运行正常升到Android 14后Service一启动就崩或拿不到数据多半就是没加foregroundServiceType。真正在App开发项目里踩过这个坑的人都知道那个错误提示“RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()”。2.3 前台Service 通知栏是跑步App的保底方案跑步App不管怎么设计前台Service都是必须存在的组件。它有两个作用一是用通知栏让用户知道“运动正在记录中”二是告诉系统这个服务不能被轻易杀掉。这里给出一个通用的Service骨架public class TrackingService extends Service { private static final int NOTIFICATION_ID 1001; Override public void onCreate() { super.onCreate(); // 创建前台通知必须调用 startForeground 否则抛异常 Notification notification createNotification(); startForeground(NOTIFICATION_ID, notification); } private Notification createNotification() { Intent intent new Intent(this, MainActivity.class); PendingIntent pendingIntent PendingIntent.getActivity( this, 0, intent, PendingIntent.FLAG_IMMUTABLE); return new NotificationCompat.Builder(this, run_channel) .setContentTitle(正在记录跑步轨迹) .setContentText(距离: 0.00 公里 | 配速: --) .setSmallIcon(R.drawable.ic_run_notification) .setContentIntent(pendingIntent) .setOngoing(true) .setPriority(NotificationCompat.PRIORITY_LOW) .build(); } Override public void onDestroy() { super.onDestroy(); } }代码本身不复杂但startForeground和通知渠道CHANNEL的创建是必调的。Android 8.0以上如果没创建NotificationChannel通知会静默失败。还有一个细节有的入门项目用startService在前台Service里做耗时的定位回调这在现在的Android版本上已经不是好做法了正确做法是把定位放在一个单独的HandlerThread里避免阻塞主线程。3. 用Android Studio在本地跑通最小跑步记录流程3.1 定位服务选型Google Play服务还是原生LocationManager拿到源码时先看它用的是FusedLocationProviderClient还是LocationManager。这两个各有取舍FusedLocationProviderClient是Google Play服务提供的融合定位省电且精度好但依赖Google Play服务。国内厂商ROM上如果阉割了Play服务会直接闪退。LocationManager是原生API兼容性最好但需要自己写策略来处理GPS和网络定位的切换耗电控制要自己实现。对于“源码演示视频”类型的项目我一般建议先把LocationManager跑通因为逻辑直观、不依赖第三方服务。核心代码如下LocationManager locationManager (LocationManager) getSystemService(Context.LOCATION_SERVICE); // 检查GPS是否打开 boolean gpsEnabled locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER); LocationListener locationListener new LocationListener() { Override public void onLocationChanged(Location location) { // 每次位置更新回调写入数据并刷新通知栏 double latitude location.getLatitude(); double longitude location.getLongitude(); float speed location.getSpeed(); // 单位 m/s需转 km/h // 这里要判断精度避免跳点 if (location.getAccuracy() 50.0f) { return; // 精度超过50米直接丢弃防止轨迹漂移 } } Override public void onProviderEnabled(String provider) {} Override public void onProviderDisabled(String provider) { // 提示用户打开GPS } }; // 参数含义minTimeMs3000 表示最小时间间隔3秒更新一次 // minDistanceM5 表示移动超过5米才触发回调 // 注意minTime和minDistance必须同时满足才触发不要设置成0 locationManager.requestLocationUpdates( LocationManager.GPS_PROVIDER, 3000, 5.0f, locationListener, Looper.getMainLooper());这段代码的关键参数就两个3000毫秒和5米。3000毫秒太频繁会大幅耗电但间隔太长会丢弯道路段的数据5米距离阈值太小的话走路时原地抖一下也会触发回调。你们可以自己做个试验跑步时把手机放裤子口袋里抖动手机会生成大量低质量定位点跑完一看轨迹像心电图。所以要加精度过滤而且要在收到回调时用distanceTo()方法计算与上一点的实际距离防止跳点。3.2 轨迹绘制用Google Maps SDK把坐标点串成轨迹跑步App的界面核心是一张地图加上一条运动轨迹。假如源码用的地图SDK被替换成了百度地图或高德地图逻辑也是相通的拿到点集合画线刷新视野。// 用Google Maps的方式绘制轨迹 private void updateTrackPath(LatLng newPoint) { // trackPoints是一个ArrayListLatLng保存本次跑步的全部轨迹点 trackPoints.add(newPoint); // 每次新点进来都重新绘制整条线点少时没问题点多了要优化 if (polyline ! null) { polyline.remove(); } PolylineOptions options new PolylineOptions() .addAll(trackPoints) // 添加全量点集 .width(12) // 线宽12像素 .color(0xFFFF5722) // 橙色轨迹线 .startCap(new RoundCap()) .endCap(new RoundCap()); polyline googleMap.addPolyline(options); // 每次更新后移动镜头到最新位置但zoom保持不变 CameraUpdate update CameraUpdateFactory.newLatLng(newPoint); googleMap.animateCamera(update); }如果轨迹点超过200个还全量重绘性能会急剧下滑。源码项目里比较常见的优化方案有两个一是只绘制最近50个点历史轨迹作为底图一次性绘制二是使用GoogleMap.addPolyline()后静态保留更新时只更新最新一段。但要注意addPolyline每次都会创建一个新对象多次调用后内存中会积累大量Polyline实例需要remove()清理。3.3 暂停与恢复跑步事件的边界处理跑步App最容易出现逻辑漏洞的地方是暂停/恢复。按下暂停瞬间GPS还在回调恢复之后如果时机没对上会把暂停期间的距离和配速算进去。一套我见过的比较稳的源码处理方式是每次回调onLocationChanged时先判断当前状态变量isPause是否为true。暂停时只记录但不计算距离和时长都冻结。恢复时以当前的location为起点重新开始累计。暂停时通知栏内容改为“已暂停”恢复了再改回。private void onPausePressed() { isPause true; // 记录暂停时间恢复时用时间差修正时长 pauseStartTime System.currentTimeMillis(); // 保存一个暂停点后续轨迹连接到这个点上 pauseLatLng currentLatLng; } private void onResumePressed() { isPause false; // 计算出暂停时长从总运动时长中减掉 pauseDuration System.currentTimeMillis() - pauseStartTime; pauseStartTime 0; // 恢复时重置一个标志让下一次位置回调把起点置为当前位置 isNeedResetStartPoint true; }这里的核心是累计暂停时长的设计而不是简单地在恢复时重新计时。你的Activity暂停/退出时Service必须把运动状态存下来否则闹钟杀进程或手动滑掉任务卡片后一切归零。4. 跑步App的进阶改造数据统计、响铃提醒和耗电优化4.1 用Room把每次跑步拆成“会话 定位点”两张表定位点不能直接存到会话表里否则瞬时速度曲线画不出来。要拆表Entity(tableName location_point) public class LocationPoint { PrimaryKey(autoGenerate true) public long id; public long sessionId; // 关联 run_session.id public long timestamp; // 定位点时间 public double latitude; public double longitude; public float speed; // 瞬时速度 m/s public float accuracy; // 定位精度 米 } Dao public interface RunDao { Query(SELECT * FROM run_session ORDER BY startTime DESC LIMIT 1) LiveDataRunSession getLatestRun(); // 查询某次会话的所有轨迹点按时间升序排列 Query(SELECT * FROM location_point WHERE sessionId :sessionId ORDER BY timestamp ASC) ListLocationPoint getPointsBySession(long sessionId); }保存时用事务包裹插入会话拿到sessionId后再批量插入轨迹点。大量单条插入会卡UI线程用List批量插入或者使用Room的Transaction注解包住一个方法即可。4.2 公里播报用TextToSpeech实现配速语音提示跑步App一个常见需求是每跑一公里播报一次配速和总时间。TextToSpeech是原生方案不需要接入第三方语音服务public class TtsManager { private TextToSpeech tts; private boolean isReady false; public TtsManager(Context context) { tts new TextToSpeech(context, status - { // 初始化回调判断是否支持中文 if (status TextToSpeech.SUCCESS) { int result tts.setLanguage(Locale.CHINESE); isReady result ! TextToSpeech.LANG_MISSING_DATA result ! TextToSpeech.LANG_NOT_SUPPORTED; } }); } public void speakPace(float distanceKm, float pace) { if (!isReady) return; String content; // 把秒/公里转成分钟:秒的展示形式 int minutes (int) pace / 60; int seconds (int) pace % 60; content String.format(已跑%.2f公里当前配速%d分%d秒, distanceKm, minutes, seconds); tts.speak(content, TextToSpeech.QUEUE_FLUSH, null, pace_ System.currentTimeMillis()); } }注意QUEUE_FLUSH会打断当前正在播报的音频如果播报词条很短且间隔大没问题但如果用户同时开着音乐App你需要在真机上实际听一下audio focus的处理必要时调AudioAttributes设置USAGE_MEDIA或USAGE_ASSISTANT避免音乐被永久打断。4.3 定位频率自适应省电的进阶玩法源码项目大多是固定频率请求定位这个做法省事但耗电不容乐观。跑步时用户位置变化快频率降低会丢轨迹走路时频率太高纯属浪费一小时下来能多耗15%的电。可以考虑做动态频率调整当前速度大于2m/s奔跑状态时请求频率设为2秒距离阈值5米。速度小于1m/s步行状态时请求频率放宽到10秒距离阈值15米。速度在1-2m/s之间用中间值5秒/10米。private int getCurrentInterval(float speedMps) { if (speedMps 2.0f) { return 2000; // 跑步 } else if (speedMps 1.0f) { return 10000; // 步行或静止 } else { return 5000; // 慢速 } }动态调频涉及一个函数requestLocationUpdates()的重复调用。这个方法的参数调整有线生效是即时的你每次速度变化后重新调用一次即可不回收旧的provider对象问题不大。5. 演示视频里的3个实战技巧配速计算陷阱、真机断点调试和地图定位失败排查5.1 配速计算的边界值与不合理结果过滤配速是跑步App最核心的指标它的公式是“用时秒数 / 距离公里数”。看着简单但有两个隐藏问题问题一GPS信号弱的时候距离为0或极小。这时配速计算会出现无穷大值要做过滤。我常用的做法是当单次距离增量小于2米时不更新配速数据。问题二跑步停止时速度不为零。GPS模块在静止状态下会产生漂移速度忽大忽小。此时需要做一个简单滤波取最近5个速度点的中位数而不是平均值中位数能有效剔除极端跳点。private float calculatePace(long timeSeconds, float distanceMeters) { if (distanceMeters 20) { return 0; // 距离太短不计算防止GPS漂移干扰 } float pace timeSeconds / (distanceMeters / 1000f); // 秒/公里 // 有效性限制正常跑步配速在3min/km到12min/km之间 if (pace 180 || pace 720) { return lastValidPace; // 越界时返回上一次有效值 } lastValidPace pace; return pace; }这里设置的3分钟/公里和12分钟/公里的边界按人群来划定。如果你做的是专门的健走模式可以把上限放宽到20分钟/公里。不设边界的话突然一次GPS跳变就能让界面上显示一个荒谬的配速1分05秒演示视频里只要有一次就会被用户发现不够可靠。5.2 真机断点调试Android Studio后台Service的定位数据怎么看调试跑步App和调试普通页面App有个显著区别主界面按HOME键退到后台Service还在跑。Android Studio默认断点只能命中与调试器连接的进程Service是同一个进程里的组件所以能正常断住。关键技巧在于在Service的onLocationChanged回调里打上断点。保证手机没有勾选“不保留活动”否则Activity销毁但Service还在有时会有两个进程在跑。如果你对跟踪距离的字段不放心可以在Watch窗口输入location.getLatitude()之类的方法查看实时值。记得Android Studio底部Logcat面板里过滤关键字“location”然后在代码里加一行Log.d(run_track, lat latitude , lng longitude , speed speed);比断点更轻量。5.3 模拟器定位失效的问题用两条命令模拟移动轨迹在Android Studio自带模拟器上开发跑步App时最坑的是模拟器默认的定位只是一个固定点。怎么制造路跑环境不需要真机用模拟器控制台命令可以实现# 打开模拟器控制台端口处理 telnet localhost 5554进入控制台后通过如下命令发送经纬度坐标序列模拟移动geo fix 116.397128 39.916527 geo fix 116.398128 39.916927 geo fix 116.399128 39.917327但Android Studio模拟器有更直接的可视化方式Extended Controls(工具栏上三个点的按钮) → Location → 设置经纬度坐标然后点击“Send”。如果要模拟连续跑步可以准备一个GPX文件在Location面板的GPX/KML加载区域导入点播放就能模拟轨迹移动。这个方法对看轨迹绘制和配速计算逻辑的效果也不差。排查定位失败时先看这几处模拟器设置里没有开启GPS卫星信号在Extended Controls里切换到Fixes标签勾选GPS卫星。模拟器的Android版本可能不允许虚拟定位回调可以换成API 28以下的镜像跑通主干逻辑。真机上如果getLastKnownLocation()返回null大概率是没执行过任何一次定位请求所以不要在启动界面直接拿last known location做展示。必须先请求一次单次定位成功后再进入主界面。5.4 打包发布前检查通知权限、电池优化白名单和崩溃日志源码能跑是一回事能打包出去是另一回事。几个容易在真机上翻车的点你在演示视频里未必能看出来但上线或交作业时一旦被对方真机测试就会暴露通知权限Android 13开始运行App时在通知栏显示前台通知也需要POST_NOTIFICATIONS权限。不申请的话前台Service还能启动但通知栏不显示用户会以为服务没在跑。电池优化设置国内ROM上热门手机品牌会默认把后台进程挂起。跑步App如果被挂起GPS回调直接消失。正规做法是引导用户去设置页忽略电池优化// 检查当前是否在白名单内 PowerManager pm (PowerManager) getSystemService(POWER_SERVICE); if (!pm.isIgnoringBatteryOptimizations(getPackageName())) { Intent intent new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse(package: getPackageName())); startActivity(intent); }崩溃日志的留存跑步App使用频率不高但每次用都很久崩溃一次就严重打击信任。推荐在Application.onCreate里安装Thread.UncaughtExceptionHandler写入本地文件下次启动时自动读取并在设置页显示“上次崩溃日志”这样做比丢给用户一个弹窗“抱歉”要专业得多。源码和演示视频之外的真正功夫恰好是在这些不起眼的参数和权限细节里这也决定了你写出来的跑步App是毕业设计级别的作品还是能上架接受真实用户考验的App。本文还有配套的精品资源点击获取