简介这是一份面向计算机相关专业学生与初入职场开发者的Android校园运动类APP实战项目源码适用于课程设计、毕业设计及移动开发入门学习。项目完整实现跑步轨迹记录、运动时长统计、里程计算与数据可视化等核心功能代码经实测可稳定运行具备良好的工程结构与模块划分。压缩包共277个文件包含71个Java业务逻辑文件、137个XML界面布局与资源定义文件、44个PNG图标素材辅以Gradle构建配置、本地SO库及必要依赖JAR包整体体积仅7.66MB轻量易部署。已有232人下载学习项目结构清晰含MainActivity主入口、BaiduLBS地图集成、Gradle多模块配置等典型Android开发要素可直接用于大作业演示或二次开发参考是理解定位服务、传感器数据采集与移动端统计分析的优质实践样本。 最近在整理以前做过的一些Android项目顺手把一套校园运动APP的完整工程翻了出来。这套东西包含完整源码和配套说明文档核心功能是跑步记录和运动统计放在校园场景下用很合适。陆陆续续有同学问我要这套代码干脆写一篇详细的拆解文章从整体架构到具体实现把设计思路、关键技术点、踩过的坑都梳理一遍供正在做类似APP或者准备做毕业设计的同学参考。先说这套工程的基本情况开发环境是Android Studio语言以Java为主minSdkVersion 21targetSdkVersion 30数据库用的SQLite图表绘制用的是MPAndroidChart。功能上覆盖了用户注册登录、跑步计时定位、轨迹记录、运动历史、统计报表这几个核心模块。整体代码量不算大但麻雀虽小五脏俱全对于想学习Android开发或者需要快速搭一个运动类APP原型的同学来说参考价值还是比较高的。1. 项目整体设计与思路拆解1.1 需求定位校园场景下跑步APP应该做什么做校园运动APP第一件事不是急着写代码而是先想清楚这个APP到底要解决什么问题。我最初接到这个需求时梳理了几个校园场景里最核心的痛点。首先是跑步记录。校园里很多同学有跑步锻炼的习惯但大多数人靠手机自带计步器或者运动手环功能太泛不够聚焦。比如绕操场跑圈需要精确记录圈数、配速、耗时这些通用工具往往做得不够细致。其次是运动数据的管理跑步不是跑完就完了需要看历史记录看这周跑了多少、这个月有没有进步、配速是不是稳定这需要一个完善的统计模块。还有一个容易忽略的点校园属性。校园运动APP和普通跑步APP最大的区别在于它可以有校园排行榜、可以按学院/班级组织运动活动、可以在操场范围内做路径比对。虽然这套源码没有做得那么深但在设计时就预留了扩展空间比如用户表里面有学院字段、跑步记录表里面有路径坐标串这些都为后续功能扩展打了底。1.2 技术选型为什么用原生Android而不是跨平台方案现在做APP很多人一上来就考虑Flutter或者React Native。但回到这套校园运动APP的实际场景我坚持用原生Android理由很实在第一定位和后台服务的稳定性。跨平台框架在底层硬件调用上始终隔了一层GPS定位、前台服务、通知栏常驻这些功能原生实现最可靠。校园跑步APP最核心的就是定位一旦定位不稳定记录的数据就是废的。第二开发调试成本。这套项目定位是教学和参考性质要求代码清晰、逻辑直接方便别人快速读懂。原生Android的工程结构相对标准Java语言也容易上手。第三兼容性控制。校园场景下学生用的手机五花八门从几百块的入门机到旗舰机都有原生Android在适配不同厂商ROM时虽然也头疼但至少主动权在自己手里可以用系统API解决大部分问题。1.3 模块划分一个跑步APP应该拆成几个部分整个工程我按功能边界拆成了五个模块每个模块之间通过接口和数据库关联耦合度控制得比较低模块主要职责关键类用户模块注册、登录、个人信息UserActivity, UserDao跑步模块定位、计时、轨迹记录RunActivity, LocationService数据持久化SQLite数据库操作DBHelper, RunRecord, RunRecordDao统计模块历史记录、图表统计StatisticsActivity, ChartHelper外围辅助设置、关于页面、工具类SettingsActivity, Utils模块化设计的好处是显而易见的。比如后期如果要加一个“运动打卡”功能只需要在跑步模块里加一个打卡记录表然后关联到统计模块其他部分完全不用动。如果跑步功能要扩展成支持骑行或者健走也只需要在LocationService里加运动模式参数然后在记录表里面存一个运动类型字段不需要大改。2. 核心细节解析与实操要点2.1 登录注册功能校园场景下的用户体系设计用户模块看起来简单但实际上有几个细节值得展开。首先是密码加密。我用了MD5加盐的方式虽然现在看MD5已经不算安全了但作为教学项目重点在于展示“不能明文存储密码”这个意识。加盐的逻辑很简单每个用户在注册时生成一个8位随机盐值加在密码后面再做MD5数据库里存的是盐值和加密后的散列值。这样即使数据库泄露彩虹表攻击也很难直接破解。然后是登录状态的保持。我选择了Token方案而不是Session方案用户登录成功后服务器返回一个Token字符串本地用SharedPreferences保存。每次请求需要身份验证时在请求头带上Token。这个方案在移动端比Session更合适因为移动端网络环境不稳定Session过期机制也难控制。注册时的校园属性体现在用户信息里包括学号、学院、班级等字段。学号要查重一个学号只能注册一次。这里有个细节我在注册页面加了正则校验学号格式比如“2024xxxx”这样的格式避免用户乱填。2.2 数据存储设计SQLite表结构和关键字段说明数据库设计是整个项目的地基。我当时建了三张核心表用户表、跑步记录表、运动统计表其实统计表可以动态算但为了查询效率定期汇总存了一些中间数据。用户表核心字段id主键、student_no学号、username、password加密后、salt、college学院、class_name班级、avatar头像路径、create_time。跑步记录表核心字段id主键、user_id外键关联用户表、start_time、end_time、duration总耗时单位秒、distance总里程单位米、avg_pace平均配速格式为“530\””、calories消耗热量单位大卡、path_pointsGPS坐标点串分号隔开的Json数据、step_count步数如果有计步传感器可记录。这里说一下path_points字段的设计。跑步轨迹是一系列经纬度点我最初想过单独建一张坐标点表但后来发现一个跑步记录通常有几百个坐标点分表存储反而增加查询压力。最后用了文本字段存JSON串用的时候解析。实测下来500个坐标点的JSON串也就几十KB性能和存储都不是问题。有人可能会觉得这样不规范但对于移动端单机数据来说实用才是第一原则。2.3 统计功能的实现思路数据怎么算才是合理的统计模块是这套代码的亮点做的是“周统计”和“月统计”两个维度。周统计展示本周跑步次数、总里程、总时长、平均配速月统计多了一个连续打卡天数的指标。先说平均配速的计算。很多人以为用总时长除以总距离就行其实在跑步场景中不对。如果中途暂停了跑步暂停时间不应该计入配速。所以我在跑步模块里记录了“实际运动时长”run_duration暂停时的时长单独存。计算配速用的是实际运动时长除以总里程。这个细节如果你不做跑步APP很难注意到但做出来体验差异很大。再说热量消耗。我用了简化的公式热量千卡 体重kg× 距离km× 1.036。这个系数是综合了跑步的MET值估算的。当然这个公式比较粗糙没有考虑坡度、风速等环境因素但对于校园跑步APP够用了。周统计的数据我用了一个取巧的方式在统计模块里写了一个StatisticsHelper类通过SQL的date函数来查询最近7天的数据。SQLite的date函数支持date(now, weekday, 0)这类相对时间的计算可以直接查出从本周日开始的数据。虽然原生SQLite不像MySQL那样有完整的日期函数但处理这种周统计需求绰绰有余。3. 实操过程与核心环节实现3.1 环境配置从零开始构建项目如果你打算直接运行这套源码环境配置是个关键步骤。我的建议是先装Android Studio然后用项目里自带的gradle wrapper不要手动装Gradle避免版本不匹配的问题。打开工程后Android Studio会自动下载依赖。这个项目的依赖不多核心就是MPAndroidChart、BaiduLocation我用了高德定位以及AndroidX的基础库。同步过程中如果提示SDK版本不匹配手动调整compileSdkVersion和targetSdkVersion即可。我这里提一下定位SDK的选择。原本我用的百度定位SDK但后来发现百度定位的Key申请流程比较繁琐而且近期定位服务调整不少。如果你自己重新配置我建议直接用高德定位SDK在控制台申请Key也方便代码改动不大主要就是初始化方式的区别。我最终用的版本在高德的SDK环境下跑通是没问题的。注意国内定位SDK都需要在控制台申请Key然后配置到AndroidManifest.xml的meta-data里。Key的安全建议放在local.properties中不要提交到Git仓库。3.2 清单文件配置权限声明是第一步AndroidManifest.xml是整个APP的入口配置运动类APP在Android 6.0及以上版本必须动态申请权限。我这个项目的权限配置如下uses-permission android:nameandroid.permission.INTERNET / 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.ACTIVITY_RECOGNITION / uses-permission android:nameandroid.permission.WAKE_LOCK /注意几个关键点。第一ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION是配套申请只申请精确定位不带粗略定位在某些机型上会出问题。第二FOREGROUND_SERVICE权限在Android 9API 28之后是必须的没有它前台服务根本起不来。第三ACTIVITY_RECOGNITION是Android 10API 29之后新增的用于步数识别如果你不做步数统计可以不申请。3.3 前台服务与通知栏常驻跑步时APP被清理了怎么办跑步功能最怕的是什么屏幕熄灭了或者用户切到其他APP系统就把你的程序给杀了GPS一停轨迹就断了。这是移动端开发里最经典的坑。我的方案是使用前台服务ForegroundService。前台服务的核心作用是在通知栏显示一个常驻通知告诉用户“我正在后台运行”此时系统不会轻易杀掉这个进程。具体实现在LocationService类中public class LocationService extends Service { private static final String CHANNEL_ID run_service_channel; private static final int NOTIFICATION_ID 1; Override public void onCreate() { super.onCreate(); createNotificationChannel(); startForeground(NOTIFICATION_ID, buildNotification()); } private void createNotificationChannel() { if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { NotificationChannel channel new NotificationChannel( CHANNEL_ID, 跑步服务, NotificationManager.IMPORTANCE_LOW ); NotificationManager manager getSystemService(NotificationManager.class); manager.createNotificationChannel(channel); } } private Notification buildNotification() { return new NotificationCompat.Builder(this, CHANNEL_ID) .setContentTitle(校园运动) .setContentText(跑步记录进行中...) .setSmallIcon(R.drawable.ic_run) .setOngoing(true) .build(); } }这个服务的启动方式是在Activity中调用startForegroundService()而不是startService()。这是Android 8.0之后的规定普通startService在后台不允许启动。前台服务虽然解决了被系统杀掉的问题但还有一个厂商ROM特有的坑比如小米、华为等品牌默认的“自启动管理”或者“省电策略”会强行阻止你的服务在后台运行。这个需要在APP里引导用户手动打开“允许自启动”和“无限制”的电池策略。我在设置页面放了一个“帮助”入口专门解释怎么设置。3.4 定位与轨迹绘制GPS数据的采集和展示定位用的是高德SDK的AMapLocationClient混合定位模式GPS网络基站在操场场景下精度能控制在10米以内。每次定位回调我把坐标点收集到ArrayListLatLng中同时实时计算跟上一个点之间的距离累加得到当前总里程。距离计算用的是球面两点间距离公式Haversine公式直接上代码public static double calculateDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 lat1 * Math.PI / 180.0; double radLat2 lat2 * Math.PI / 180.0; double a radLat1 - radLat2; double b (lng1 - lng2) * Math.PI / 180.0; double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2) )); return s * 6371000; // 地球半径单位米 }这个公式在短距离场景下的误差非常小操场一圈400米实测误差基本在一两米内。比直接用Location.distanceTo()要可控因为后者在不同厂商实现里可能有细微差别。轨迹绘制在Android上是老生常谈的问题。高德SDK提供Polyline覆盖物我把收集到的点加上去就行。比较关键的是在运动过程中地图会跟着跑者的位置移动。我开了setMyLocationEnabled(true)同时设置追踪模式让地图中心始终跟随当前位置体验会好很多。3.5 跑步业务流程完整串一遍跑步的完整流程大概是这样的用户点击“开始跑步”→ 动态申请定位权限 → 启动前台服务 → 地图上显示当前位置 → 用户移动实时更新路径和统计数据 → 用户点击“暂停”→ 停止记时不停止GPS采集或者停止GPS取决于你的设计 → 用户点击“结束”→ 停止服务把数据写入数据库 → 跳转到跑步详情页展示本次跑步的结果。这里有一个设计上的细节暂停时GPS要不要继续采我最终选择了“暂停时继续采GPS但不计入距离”。原因很简单操场跑步的场景暂停时人可能在原地做拉伸GPS点会发生漂移如果继续累加距离最后的里程会虚高。所以我给暂停状态加了个flag距离计算跳过暂停阶段的数据但轨迹绘制仍然保留保证地图上的轨迹是连续的。4. 常见问题与排查技巧实录4.1 定位不精准怎么办这个是最多人问的问题。GPS信号受限于天气、建筑遮挡、手机天线设计操场边上有高楼的话定位漂移是常见的。我排查这类问题通常按以下顺序第一在户外开阔地测试。如果室内也要求定位那只能依赖网络定位精度肯定差一些。第二检查是否开了“高精度定位”模式有的手机默认是“仅GPS”会导致不带网络辅助的情况下定位冷启动时间很长。第三检查定位回调的频率有些手机上定位回调会突然停掉这是系统在后台对GPS做了限制需要在配置里申请setLocationCacheEnable(false)并且开启前台服务。针对定位漂移我还在后处理环节做了优化在保存跑步记录之前用一个低通滤波算法对GPS点做一次平滑。具体做法是遍历所有坐标点如果某个点到前一个点的距离超过阈值比如50米且前后两个点距离很正常就给这个点降低权重或者直接剔除避免画出“飞点”。4.2 APP在后台运行一段时间后被杀前面提到了前台服务但还是会遇到被杀的情况。主要原因是部分国产ROM的激进杀后台策略。处理经验如下引导用户在系统设置中给APP开启“自启动”权限。在电池优化白名单中申请豁免代码里可以通过PowerManager.isIgnoringBatteryOptimizations()检查如果没有豁免跳到系统设置页让用户手动开启。双进程守护一个进程挂了另一个拉起来这种技术我不推荐因为Android 8.0之后对后台进程的限制太严守护进程自己也会被杀而且会消耗大量电量用户印象会很差。4.3 数据库版本升级导致崩溃跑步记录表后续增加字段是很常见的需求。如果你在旧版本APP上升级数据库SQLite没有自动迁移机制直接跑新SQL就会崩。稳妥的做法是给DBHelper加上onUpgrade方法检测旧版本号逐个执行ALTER TABLE语句。Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE run_record ADD COLUMN sport_type INTEGER DEFAULT 0); } }这是很常规的操作但很多初学者会忽略导致用户更新APP之后直接闪退。我自己在这个项目里也踩过坑第一次发版后加了个calories字段忘了写onUpgrade结果测试包没问题因为重新安装了但老用户升级后纷纷崩溃被迫紧急发修复版。这个教训很值钱做APP上架前一定要拿一个“旧版本数据新版本安装包”的组合测试一遍升级路径。4.4 图表显示异常统计模块用的MPAndroidChart图表空白或者数据错位通常不是图表库的问题而是数据格式不对。比如X轴我用的IndexAxisValueFormatter里面传入的数据如果包含null指数偏移就会导致坐标轴错位。建议统一用日期字符串作为X轴标签数值型的数据转换为float再传给图表。4.5 各问题排查速查表症状可能原因解决方案定位点漂移严重信号差或GPS冷启动开启混合定位加滤波处理后台被杀厂商ROM省电策略引导用户添加电池白名单数据库升级崩溃未实现onUpgrade添加强制升级或手动ALTER图表X轴错位null数据混入统一格式化X轴标签通知栏没有常驻通知渠道ID不一致检查NotificationChannel配置无法启动服务未调用startForegroundService按Android 8.0规范调整5. 源码工程结构与扩展方向5.1 工程目录怎么看如果你拿到源码建议按照下面的顺序去阅读而不是从MainActivity开始乱翻app/src/main/java/com/campus/sport/ ├── activity/ # Activity类负责UI和交互 │ ├── LoginActivity.java │ ├── RegisterActivity.java │ ├── MainActivity.java │ ├── RunActivity.java │ ├── HistoryActivity.java │ └── StatisticsActivity.java ├── service/ # 后台服务 │ └── LocationService.java ├── db/ # 数据库相关 │ ├── DBHelper.java │ ├── RunRecord.java │ └── RunRecordDao.java ├── utils/ # 工具类 │ ├── DistanceUtils.java │ ├── TimeUtils.java │ └── Constants.java └── chart/ # 图表封装 └── ChartHelper.javaactivity里面是页面对应的具体实现service里面是核心跑步逻辑db是数据存取utils是通用工具。这样的目录结构也方便你自己加模块。5.2 可以怎么扩展这个项目如果你拿这套源码做毕设或者课设下面这几个方向都有很大的扩展空间运动圈社交加关注、点赞、评论功能跑步记录可以分享到动态流。排行榜按学院、班级做跑步里程排行用数据库的GROUP BY就能实现。运动计划给用户制定每周跑步计划到点推送提醒。语音播报每到1公里自动语音播报配速和里程用TTS即可实现。轨迹回放跑步结束后在地图上用动画方式回放整个运动轨迹。在线同步接入Bmob或者LeanCloud把跑步记录同步到云端。我自己的体会是跑步记录和统计部分是这套系统最扎实的如果想往上加功能在这个基础上做会顺利很多。6. 写在最后的经验心得做这套校园运动APP前后花了差不多四周时间包含了需求梳理、UI设计、编码实现、测试联调。过程中最耗时不是功能实现而是处理各种真实场景下的边界问题比如GPS漂移、后台被杀、数据库兼容这些在文档和教程中很少系统地讲解只有在实际操作中才能遇到。如果你要基于这套代码做二次开发我个人有几点建议第一去耦。跑步模块里的定位SDK和统计逻辑是耦合的建议看代码的时候先理清LocationService的生命周期和Activity的通信方式。第二权限处理一定要做全。Android的权限机制越来越严格尤其是Android 12以后精确定位权限多了一个“大概位置”的选项如果你的APP没有适配用户在系统设置里可能找不到精确位置开关会很困惑。第三不要忽视数据库设计的可扩展性。为将来加字段留好余地表名、字段名的语义要清晰。最后如果你只是想要一个能跑起来的Demo编译完直接运行就可以如果你想认真学习Android开发建议不要只停留在“能运行”动手改一改统计逻辑把图表换成别的样式在这个过程中遇到的问题才是最有价值的收获。本文还有配套的精品资源点击获取
校园运动APP完整源码解析：从架构到定位与统计实现
简介这是一份面向计算机相关专业学生与初入职场开发者的Android校园运动类APP实战项目源码适用于课程设计、毕业设计及移动开发入门学习。项目完整实现跑步轨迹记录、运动时长统计、里程计算与数据可视化等核心功能代码经实测可稳定运行具备良好的工程结构与模块划分。压缩包共277个文件包含71个Java业务逻辑文件、137个XML界面布局与资源定义文件、44个PNG图标素材辅以Gradle构建配置、本地SO库及必要依赖JAR包整体体积仅7.66MB轻量易部署。已有232人下载学习项目结构清晰含MainActivity主入口、BaiduLBS地图集成、Gradle多模块配置等典型Android开发要素可直接用于大作业演示或二次开发参考是理解定位服务、传感器数据采集与移动端统计分析的优质实践样本。 最近在整理以前做过的一些Android项目顺手把一套校园运动APP的完整工程翻了出来。这套东西包含完整源码和配套说明文档核心功能是跑步记录和运动统计放在校园场景下用很合适。陆陆续续有同学问我要这套代码干脆写一篇详细的拆解文章从整体架构到具体实现把设计思路、关键技术点、踩过的坑都梳理一遍供正在做类似APP或者准备做毕业设计的同学参考。先说这套工程的基本情况开发环境是Android Studio语言以Java为主minSdkVersion 21targetSdkVersion 30数据库用的SQLite图表绘制用的是MPAndroidChart。功能上覆盖了用户注册登录、跑步计时定位、轨迹记录、运动历史、统计报表这几个核心模块。整体代码量不算大但麻雀虽小五脏俱全对于想学习Android开发或者需要快速搭一个运动类APP原型的同学来说参考价值还是比较高的。1. 项目整体设计与思路拆解1.1 需求定位校园场景下跑步APP应该做什么做校园运动APP第一件事不是急着写代码而是先想清楚这个APP到底要解决什么问题。我最初接到这个需求时梳理了几个校园场景里最核心的痛点。首先是跑步记录。校园里很多同学有跑步锻炼的习惯但大多数人靠手机自带计步器或者运动手环功能太泛不够聚焦。比如绕操场跑圈需要精确记录圈数、配速、耗时这些通用工具往往做得不够细致。其次是运动数据的管理跑步不是跑完就完了需要看历史记录看这周跑了多少、这个月有没有进步、配速是不是稳定这需要一个完善的统计模块。还有一个容易忽略的点校园属性。校园运动APP和普通跑步APP最大的区别在于它可以有校园排行榜、可以按学院/班级组织运动活动、可以在操场范围内做路径比对。虽然这套源码没有做得那么深但在设计时就预留了扩展空间比如用户表里面有学院字段、跑步记录表里面有路径坐标串这些都为后续功能扩展打了底。1.2 技术选型为什么用原生Android而不是跨平台方案现在做APP很多人一上来就考虑Flutter或者React Native。但回到这套校园运动APP的实际场景我坚持用原生Android理由很实在第一定位和后台服务的稳定性。跨平台框架在底层硬件调用上始终隔了一层GPS定位、前台服务、通知栏常驻这些功能原生实现最可靠。校园跑步APP最核心的就是定位一旦定位不稳定记录的数据就是废的。第二开发调试成本。这套项目定位是教学和参考性质要求代码清晰、逻辑直接方便别人快速读懂。原生Android的工程结构相对标准Java语言也容易上手。第三兼容性控制。校园场景下学生用的手机五花八门从几百块的入门机到旗舰机都有原生Android在适配不同厂商ROM时虽然也头疼但至少主动权在自己手里可以用系统API解决大部分问题。1.3 模块划分一个跑步APP应该拆成几个部分整个工程我按功能边界拆成了五个模块每个模块之间通过接口和数据库关联耦合度控制得比较低模块主要职责关键类用户模块注册、登录、个人信息UserActivity, UserDao跑步模块定位、计时、轨迹记录RunActivity, LocationService数据持久化SQLite数据库操作DBHelper, RunRecord, RunRecordDao统计模块历史记录、图表统计StatisticsActivity, ChartHelper外围辅助设置、关于页面、工具类SettingsActivity, Utils模块化设计的好处是显而易见的。比如后期如果要加一个“运动打卡”功能只需要在跑步模块里加一个打卡记录表然后关联到统计模块其他部分完全不用动。如果跑步功能要扩展成支持骑行或者健走也只需要在LocationService里加运动模式参数然后在记录表里面存一个运动类型字段不需要大改。2. 核心细节解析与实操要点2.1 登录注册功能校园场景下的用户体系设计用户模块看起来简单但实际上有几个细节值得展开。首先是密码加密。我用了MD5加盐的方式虽然现在看MD5已经不算安全了但作为教学项目重点在于展示“不能明文存储密码”这个意识。加盐的逻辑很简单每个用户在注册时生成一个8位随机盐值加在密码后面再做MD5数据库里存的是盐值和加密后的散列值。这样即使数据库泄露彩虹表攻击也很难直接破解。然后是登录状态的保持。我选择了Token方案而不是Session方案用户登录成功后服务器返回一个Token字符串本地用SharedPreferences保存。每次请求需要身份验证时在请求头带上Token。这个方案在移动端比Session更合适因为移动端网络环境不稳定Session过期机制也难控制。注册时的校园属性体现在用户信息里包括学号、学院、班级等字段。学号要查重一个学号只能注册一次。这里有个细节我在注册页面加了正则校验学号格式比如“2024xxxx”这样的格式避免用户乱填。2.2 数据存储设计SQLite表结构和关键字段说明数据库设计是整个项目的地基。我当时建了三张核心表用户表、跑步记录表、运动统计表其实统计表可以动态算但为了查询效率定期汇总存了一些中间数据。用户表核心字段id主键、student_no学号、username、password加密后、salt、college学院、class_name班级、avatar头像路径、create_time。跑步记录表核心字段id主键、user_id外键关联用户表、start_time、end_time、duration总耗时单位秒、distance总里程单位米、avg_pace平均配速格式为“530\””、calories消耗热量单位大卡、path_pointsGPS坐标点串分号隔开的Json数据、step_count步数如果有计步传感器可记录。这里说一下path_points字段的设计。跑步轨迹是一系列经纬度点我最初想过单独建一张坐标点表但后来发现一个跑步记录通常有几百个坐标点分表存储反而增加查询压力。最后用了文本字段存JSON串用的时候解析。实测下来500个坐标点的JSON串也就几十KB性能和存储都不是问题。有人可能会觉得这样不规范但对于移动端单机数据来说实用才是第一原则。2.3 统计功能的实现思路数据怎么算才是合理的统计模块是这套代码的亮点做的是“周统计”和“月统计”两个维度。周统计展示本周跑步次数、总里程、总时长、平均配速月统计多了一个连续打卡天数的指标。先说平均配速的计算。很多人以为用总时长除以总距离就行其实在跑步场景中不对。如果中途暂停了跑步暂停时间不应该计入配速。所以我在跑步模块里记录了“实际运动时长”run_duration暂停时的时长单独存。计算配速用的是实际运动时长除以总里程。这个细节如果你不做跑步APP很难注意到但做出来体验差异很大。再说热量消耗。我用了简化的公式热量千卡 体重kg× 距离km× 1.036。这个系数是综合了跑步的MET值估算的。当然这个公式比较粗糙没有考虑坡度、风速等环境因素但对于校园跑步APP够用了。周统计的数据我用了一个取巧的方式在统计模块里写了一个StatisticsHelper类通过SQL的date函数来查询最近7天的数据。SQLite的date函数支持date(now, weekday, 0)这类相对时间的计算可以直接查出从本周日开始的数据。虽然原生SQLite不像MySQL那样有完整的日期函数但处理这种周统计需求绰绰有余。3. 实操过程与核心环节实现3.1 环境配置从零开始构建项目如果你打算直接运行这套源码环境配置是个关键步骤。我的建议是先装Android Studio然后用项目里自带的gradle wrapper不要手动装Gradle避免版本不匹配的问题。打开工程后Android Studio会自动下载依赖。这个项目的依赖不多核心就是MPAndroidChart、BaiduLocation我用了高德定位以及AndroidX的基础库。同步过程中如果提示SDK版本不匹配手动调整compileSdkVersion和targetSdkVersion即可。我这里提一下定位SDK的选择。原本我用的百度定位SDK但后来发现百度定位的Key申请流程比较繁琐而且近期定位服务调整不少。如果你自己重新配置我建议直接用高德定位SDK在控制台申请Key也方便代码改动不大主要就是初始化方式的区别。我最终用的版本在高德的SDK环境下跑通是没问题的。注意国内定位SDK都需要在控制台申请Key然后配置到AndroidManifest.xml的meta-data里。Key的安全建议放在local.properties中不要提交到Git仓库。3.2 清单文件配置权限声明是第一步AndroidManifest.xml是整个APP的入口配置运动类APP在Android 6.0及以上版本必须动态申请权限。我这个项目的权限配置如下uses-permission android:nameandroid.permission.INTERNET / 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.ACTIVITY_RECOGNITION / uses-permission android:nameandroid.permission.WAKE_LOCK /注意几个关键点。第一ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION是配套申请只申请精确定位不带粗略定位在某些机型上会出问题。第二FOREGROUND_SERVICE权限在Android 9API 28之后是必须的没有它前台服务根本起不来。第三ACTIVITY_RECOGNITION是Android 10API 29之后新增的用于步数识别如果你不做步数统计可以不申请。3.3 前台服务与通知栏常驻跑步时APP被清理了怎么办跑步功能最怕的是什么屏幕熄灭了或者用户切到其他APP系统就把你的程序给杀了GPS一停轨迹就断了。这是移动端开发里最经典的坑。我的方案是使用前台服务ForegroundService。前台服务的核心作用是在通知栏显示一个常驻通知告诉用户“我正在后台运行”此时系统不会轻易杀掉这个进程。具体实现在LocationService类中public class LocationService extends Service { private static final String CHANNEL_ID run_service_channel; private static final int NOTIFICATION_ID 1; Override public void onCreate() { super.onCreate(); createNotificationChannel(); startForeground(NOTIFICATION_ID, buildNotification()); } private void createNotificationChannel() { if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { NotificationChannel channel new NotificationChannel( CHANNEL_ID, 跑步服务, NotificationManager.IMPORTANCE_LOW ); NotificationManager manager getSystemService(NotificationManager.class); manager.createNotificationChannel(channel); } } private Notification buildNotification() { return new NotificationCompat.Builder(this, CHANNEL_ID) .setContentTitle(校园运动) .setContentText(跑步记录进行中...) .setSmallIcon(R.drawable.ic_run) .setOngoing(true) .build(); } }这个服务的启动方式是在Activity中调用startForegroundService()而不是startService()。这是Android 8.0之后的规定普通startService在后台不允许启动。前台服务虽然解决了被系统杀掉的问题但还有一个厂商ROM特有的坑比如小米、华为等品牌默认的“自启动管理”或者“省电策略”会强行阻止你的服务在后台运行。这个需要在APP里引导用户手动打开“允许自启动”和“无限制”的电池策略。我在设置页面放了一个“帮助”入口专门解释怎么设置。3.4 定位与轨迹绘制GPS数据的采集和展示定位用的是高德SDK的AMapLocationClient混合定位模式GPS网络基站在操场场景下精度能控制在10米以内。每次定位回调我把坐标点收集到ArrayListLatLng中同时实时计算跟上一个点之间的距离累加得到当前总里程。距离计算用的是球面两点间距离公式Haversine公式直接上代码public static double calculateDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 lat1 * Math.PI / 180.0; double radLat2 lat2 * Math.PI / 180.0; double a radLat1 - radLat2; double b (lng1 - lng2) * Math.PI / 180.0; double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2) )); return s * 6371000; // 地球半径单位米 }这个公式在短距离场景下的误差非常小操场一圈400米实测误差基本在一两米内。比直接用Location.distanceTo()要可控因为后者在不同厂商实现里可能有细微差别。轨迹绘制在Android上是老生常谈的问题。高德SDK提供Polyline覆盖物我把收集到的点加上去就行。比较关键的是在运动过程中地图会跟着跑者的位置移动。我开了setMyLocationEnabled(true)同时设置追踪模式让地图中心始终跟随当前位置体验会好很多。3.5 跑步业务流程完整串一遍跑步的完整流程大概是这样的用户点击“开始跑步”→ 动态申请定位权限 → 启动前台服务 → 地图上显示当前位置 → 用户移动实时更新路径和统计数据 → 用户点击“暂停”→ 停止记时不停止GPS采集或者停止GPS取决于你的设计 → 用户点击“结束”→ 停止服务把数据写入数据库 → 跳转到跑步详情页展示本次跑步的结果。这里有一个设计上的细节暂停时GPS要不要继续采我最终选择了“暂停时继续采GPS但不计入距离”。原因很简单操场跑步的场景暂停时人可能在原地做拉伸GPS点会发生漂移如果继续累加距离最后的里程会虚高。所以我给暂停状态加了个flag距离计算跳过暂停阶段的数据但轨迹绘制仍然保留保证地图上的轨迹是连续的。4. 常见问题与排查技巧实录4.1 定位不精准怎么办这个是最多人问的问题。GPS信号受限于天气、建筑遮挡、手机天线设计操场边上有高楼的话定位漂移是常见的。我排查这类问题通常按以下顺序第一在户外开阔地测试。如果室内也要求定位那只能依赖网络定位精度肯定差一些。第二检查是否开了“高精度定位”模式有的手机默认是“仅GPS”会导致不带网络辅助的情况下定位冷启动时间很长。第三检查定位回调的频率有些手机上定位回调会突然停掉这是系统在后台对GPS做了限制需要在配置里申请setLocationCacheEnable(false)并且开启前台服务。针对定位漂移我还在后处理环节做了优化在保存跑步记录之前用一个低通滤波算法对GPS点做一次平滑。具体做法是遍历所有坐标点如果某个点到前一个点的距离超过阈值比如50米且前后两个点距离很正常就给这个点降低权重或者直接剔除避免画出“飞点”。4.2 APP在后台运行一段时间后被杀前面提到了前台服务但还是会遇到被杀的情况。主要原因是部分国产ROM的激进杀后台策略。处理经验如下引导用户在系统设置中给APP开启“自启动”权限。在电池优化白名单中申请豁免代码里可以通过PowerManager.isIgnoringBatteryOptimizations()检查如果没有豁免跳到系统设置页让用户手动开启。双进程守护一个进程挂了另一个拉起来这种技术我不推荐因为Android 8.0之后对后台进程的限制太严守护进程自己也会被杀而且会消耗大量电量用户印象会很差。4.3 数据库版本升级导致崩溃跑步记录表后续增加字段是很常见的需求。如果你在旧版本APP上升级数据库SQLite没有自动迁移机制直接跑新SQL就会崩。稳妥的做法是给DBHelper加上onUpgrade方法检测旧版本号逐个执行ALTER TABLE语句。Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE run_record ADD COLUMN sport_type INTEGER DEFAULT 0); } }这是很常规的操作但很多初学者会忽略导致用户更新APP之后直接闪退。我自己在这个项目里也踩过坑第一次发版后加了个calories字段忘了写onUpgrade结果测试包没问题因为重新安装了但老用户升级后纷纷崩溃被迫紧急发修复版。这个教训很值钱做APP上架前一定要拿一个“旧版本数据新版本安装包”的组合测试一遍升级路径。4.4 图表显示异常统计模块用的MPAndroidChart图表空白或者数据错位通常不是图表库的问题而是数据格式不对。比如X轴我用的IndexAxisValueFormatter里面传入的数据如果包含null指数偏移就会导致坐标轴错位。建议统一用日期字符串作为X轴标签数值型的数据转换为float再传给图表。4.5 各问题排查速查表症状可能原因解决方案定位点漂移严重信号差或GPS冷启动开启混合定位加滤波处理后台被杀厂商ROM省电策略引导用户添加电池白名单数据库升级崩溃未实现onUpgrade添加强制升级或手动ALTER图表X轴错位null数据混入统一格式化X轴标签通知栏没有常驻通知渠道ID不一致检查NotificationChannel配置无法启动服务未调用startForegroundService按Android 8.0规范调整5. 源码工程结构与扩展方向5.1 工程目录怎么看如果你拿到源码建议按照下面的顺序去阅读而不是从MainActivity开始乱翻app/src/main/java/com/campus/sport/ ├── activity/ # Activity类负责UI和交互 │ ├── LoginActivity.java │ ├── RegisterActivity.java │ ├── MainActivity.java │ ├── RunActivity.java │ ├── HistoryActivity.java │ └── StatisticsActivity.java ├── service/ # 后台服务 │ └── LocationService.java ├── db/ # 数据库相关 │ ├── DBHelper.java │ ├── RunRecord.java │ └── RunRecordDao.java ├── utils/ # 工具类 │ ├── DistanceUtils.java │ ├── TimeUtils.java │ └── Constants.java └── chart/ # 图表封装 └── ChartHelper.javaactivity里面是页面对应的具体实现service里面是核心跑步逻辑db是数据存取utils是通用工具。这样的目录结构也方便你自己加模块。5.2 可以怎么扩展这个项目如果你拿这套源码做毕设或者课设下面这几个方向都有很大的扩展空间运动圈社交加关注、点赞、评论功能跑步记录可以分享到动态流。排行榜按学院、班级做跑步里程排行用数据库的GROUP BY就能实现。运动计划给用户制定每周跑步计划到点推送提醒。语音播报每到1公里自动语音播报配速和里程用TTS即可实现。轨迹回放跑步结束后在地图上用动画方式回放整个运动轨迹。在线同步接入Bmob或者LeanCloud把跑步记录同步到云端。我自己的体会是跑步记录和统计部分是这套系统最扎实的如果想往上加功能在这个基础上做会顺利很多。6. 写在最后的经验心得做这套校园运动APP前后花了差不多四周时间包含了需求梳理、UI设计、编码实现、测试联调。过程中最耗时不是功能实现而是处理各种真实场景下的边界问题比如GPS漂移、后台被杀、数据库兼容这些在文档和教程中很少系统地讲解只有在实际操作中才能遇到。如果你要基于这套代码做二次开发我个人有几点建议第一去耦。跑步模块里的定位SDK和统计逻辑是耦合的建议看代码的时候先理清LocationService的生命周期和Activity的通信方式。第二权限处理一定要做全。Android的权限机制越来越严格尤其是Android 12以后精确定位权限多了一个“大概位置”的选项如果你的APP没有适配用户在系统设置里可能找不到精确位置开关会很困惑。第三不要忽视数据库设计的可扩展性。为将来加字段留好余地表名、字段名的语义要清晰。最后如果你只是想要一个能跑起来的Demo编译完直接运行就可以如果你想认真学习Android开发建议不要只停留在“能运行”动手改一改统计逻辑把图表换成别的样式在这个过程中遇到的问题才是最有价值的收获。本文还有配套的精品资源点击获取
