Android+Java毕业设计实战指南：一套骨架搞定4S店与公交查询系统

每年到了毕业设计选题的时候，总有学弟学妹拿着类似的题目来问我：汽车4S店管理系统、公交实时通、车来了动态速查……乍一看是三个完全不相干的题目，但把需求拆开就会发现，它们的内核高度一致：Android端做交互界面，Java后端做数据支撑，中间用HTTP接口串起来，再配合一个小型关系型数据库。我自己带过的毕业设计里，这类“信息管理系统+移动端展示”的组合占了快一半，每年都会有人踩同样的坑，问同样的问题。

这篇文章就把这套题目的完整解题思路拆开讲透。从题目怎么分析、技术选型怎么定、数据库表怎么设计，到开发环境怎么配、前后端怎么联调、答辩现场怎么避坑，一条线走完。打算选这几个题目的同学可以直接参考，想自己扩展题目的，也能从里面拿走一套可以复用的骨架。

1. 三个题目放一起看：不是三个项目，是一套骨架的三种皮肤

很多人拿到课题列表时习惯一个题目一个题目单独想，其实效率很低。这三个题目的标题虽然长得不一样，但都属于同一个套路：“Android端+Java服务端+关系型数据库”的三层结构。

1.1 4S店管理系统的本质：审批流加表格堆叠

4S店管理系统听起来很硬，实际上核心业务就那几块：客户管理、车辆库存、预约试驾、整车销售、维修保养工单。说白了，就是各种身份的人在一个门店里登记信息、流转单据、查询状态。

所以它的功能模块基本是固定的：

这里面真正考验人的点不是界面多炫，而是“状态流转”。一个订单从待付款到已付款再到已完成，数据库里的status字段要跟着变，界面上要能对应显示不同的操作按钮。想清楚这一层，代码写起来才有条理，也才能在答辩时回答“如果客户退款了，你的程序怎么处理”这类问题。

有个很容易被忽略的细节是角色区分。4S店里店长、销售顾问、维修技师看到的内容差别很大，虽然毕业设计不一定做完整的权限系统，但登录后按角色显示不同菜单这一步一定要有，否则评委一眼就能看出来是纯界面堆叠。

1.2 公交实时通与“车来了”速查系统：地图加状态刷新

这两个公交类题目表面区别在应用名，实际侧重点不一样。

“公交实时通”的关键词是“运行监测”，它的核心功能是一张地图或列表上显示多条线路上的车跑到了哪，偏向轨迹和状态的可视化，甚至要做简单的偏离调度提醒。

“车来了动态速查”的关键词是“速查”，它强调查询效率，用户打开App输入线路名，马上能知道最近一班车还有几站、大约几分钟到，所以界面要轻、刷新要快，信息层级要少。

但两者的底层模块高度重合：线路搜索、站点列表、实时车辆位置、到站时间估算。到站时间可以简化成“最近车辆距离站点还有多少米，按平均车速推算分钟数”，这是答辩时可以说清的合理简化。

这里还要面对一个实际难题：真实公交GPS数据学生是拿不到的。稳妥方案是自建模拟数据源——服务端每3到5秒更新一次车辆经纬度，App端轮询拉取并刷新界面。把模拟数据的设计讲清楚，反而比假装接入真实数据更诚实，也更能拿到分。

1.3 为什么“Android客户端+Java服务端”是稳妥的毕业设计路线

这套路线稳，首先是技术难度中等偏下，但覆盖面非常广。一个项目里同时包含了Java基础语法、面向对象设计、Android界面开发、网络请求、多线程、数据库表设计、接口联调，基本上大学四年学的核心内容都能用上，讲题目价值时也有的说。

其次是演示效果直观。管理系统跑在手机上，评委看着比看控制台输出强太多了。尤其公交类项目，地图上一辆辆小车在动，天然适合现场演示。

也见过不少同学纠结用Python行不行。Python做数据分析很舒服，但做移动端App绕不开Android原生环境，本质还是Java或Kotlin。与其前后端语言不一致，不如Java一把梭。

还有一点要提醒：很多同学一上来就想学Kotlin，其实毕业设计稳妥起见用Java就够。Kotlin的协程和空安全确实好，但Java资料多、遇到的问题网上都能搜到答案，工期紧的时候“能查到的方案”就是最好的方案。

2. Android端绕不开的技术点：从界面到数据链路

这一部分会把Android开发里真正影响毕业设计成败的技术点逐个过一遍。不是让你全学，而是告诉你哪些必须掌握、哪些可以糊弄过去。

2.1 Activity与Fragment：页面的地基

不管做4S店还是公交查询，App都是“启动页→首页→详情页”的结构，有时首页底部再用Tab切分几个功能区。这套结构里Activity是容器，Fragment是内容页，它们之间的跳转和数据传递是每天都会写的代码。

要学会的几个点：Activity生命周期中onCreate做初始化、onSaveInstanceState保存临时状态、旋转屏幕时数据不丢。Fragment切换到后台或页面销毁以后，不要再去操作其中的控件，否则容易出现空指针。

一个非常典型的崩溃现场是：网络请求回调回来时，页面已经关闭了，代码还试图去刷新列表。解决办法不算高级，但必须养成习惯——请求发起时记录页面状态，回调里判断当前页面是否可见再刷新。

2.2 列表页的“老三样”：RecyclerView、刷新、进度条

这两类项目里，列表页是绝对主角：客户列表、订单列表、线路列表、站点列表。Android端做列表绕不开RecyclerView。刚上手的同学喜欢用ScrollView硬拼，短数据能跑，数据一多就掉帧，答辩时滑动卡顿非常露怯。

RecyclerView的核心套路是固定三步：定义ViewHolder持有控件，写Adapter绑定数据，在Activity里设置LayoutManager。配合的还有两样东西：SwipeRefreshLayout做下拉刷新，ProgressBar做加载进度条。热词里“android进度条”搜得多，说明很多人卡在这。其实进度条分两种：整页加载时用居中圆圈，分页加载时用列表底部的小条，别混了。

比较标准的加载逻辑是：首次进入显示居中进度条，请求成功后填充数据并隐藏进度条；下拉刷新时显示刷新转圈；上拉到底后加载下一页，底部显示“正在加载”。这块代码建议自己完整写一遍，别看一个Demo抄一个，因为后面三个项目都要用它。

2.3 网络请求不要再用老掉牙的HttpClient

这部分必须多说两句。每年都有人因为网络请求库选错，浪费两三天时间。网上很多老代码还在用HttpClient，这个类在Android API 23之后已经被官方移除了，你用高版本SDK编译，一运行就崩，这正是热词“android 运行httpclient崩溃”的来源。

现在做毕业设计，直接上Retrofit加OkHttp，配合Gson解析JSON。Retrofit负责把接口定义转发成HTTP请求，Gson负责把返回的JSON变成Java对象，OkHttp在底层处理连接和超时。三者是这个领域最稳的组合，资料也最多。

接口定义大概长这样：

public interface ApiService { @GET("line/search") Call<Result<List<LineInfo>>> searchLine(@Query("kw") String keyword); @POST("order/create") Call<Result<OrderInfo>> createOrder(@Body OrderCreateRequest request); }

回调里注意线程问题：网络请求不能放主线程，不然会抛NetworkOnMainThreadException；请求结果也不能直接改界面，要用runOnUiThread切回主线程。这里经常翻车，写之前先把这个逻辑想明白。

2.4 定位与地图：公交类项目的地基

公交类题目如果不用地图，会显得很单薄。主流选择是接入高德或百度地图SDK，申请一个Key，然后调用它们的定位和Marker展示能力。

做之前先把权限理清楚。Android 6.0以后是动态权限申请，不能在Manifest里写完就算完事，要在代码里判断、申请、处理回调。定位权限涉及ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION，漏一个都会导致定位结果一直为空。

公交项目的实时位置，不需要手机端真实GPS参与，而是从服务端拉取车辆坐标，再画到地图上。熟悉一下“地图上添加Marker”“移动Marker位置”“让地图视角跟随车辆”这三个动作就够了。

要不要让车辆动态平滑移动？加分项，但不做也不扣分。简单方案是每轮刷新时直接把Marker挪到新坐标；进阶方案是动画插值，让Marker在两帧坐标之间线性移动。实际效果差别很大，答辩演示时小车在地图上平滑地跑，观感很不一样。

2.5 视觉细节：背景、图标、协调布局与轮播

界面观感直接决定答辩第一印象。很多管理系统默认主题白底黑字，功能都对，但看起来就是“课程设计”水平。

可以花一点时间调整三件事：背景和按钮样式用shape和selector定义，别用图片硬铺，这样能保持风格统一，也能做出按压反馈效果；应用图标要准备多套mipmap尺寸，别只放一张大图，否则在部分手机上会显示模糊；首页如果是信息流，可以用CoordinatorLayout加AppBarLayout做联动，顶部Banner轮播用ViewPager2配合定时切换，这也是热词“android中协调布局+banner”里大家主要搜的东西。

不过要提醒一句：千万别过度设计。毕业设计界面干净、风格统一、重点信息突出就够了。往上堆动画、堆特效，调试成本翻倍，还容易把App拖卡。

3. 服务端的取舍：Spring Boot、MyBatis Plus和一张能答辩的表

App只是皮，整台戏能不能唱下去，全看Java服务端正不正经。这一章讲两件事：框架怎么选，库表怎么写。

3.1 为什么用Spring Boot而不是老SSH

十年前做这类项目流行SSH，Spring加Struts加Hibernate，配置文件又长又绕，经常为了一个Bean的定义折腾半天。现在做毕业设计，优先级最高的就是Spring Boot。

Spring Boot最大的优势是“配置少、能跑”。内嵌Tomcat，不用单独装服务器；起步依赖把常用的包给你配好；一个注解就能启动Web服务。快速创建一个工程，用Spring Initializr选上Spring Web、MySQL驱动，再把MyBatis Plus的依赖加进去，十分钟就能出一个能连数据库的Hello World。

版本上有个重要提醒：Spring Boot 3.x要求JDK17，如果你还停留在JDK8或者只会在Windows上装JDK8，那就老老实实用Spring Boot 2.7.x。技术选型的原则永远是“团队能驾驭”，而不是“最新最酷”。

3.2 表设计：先想清楚业务对象，再动手建表

4S店系统的表和公交类系统的表完全不一样，但设计方法一样：先找业务里的核心名词，再找名词之间的关系。

4S店这里，核心对象是：用户（登录员工）、客户、车辆、销售订单、维修工单、预约试驾。关系是：一个客户可能买多台车，一个销售订单对一个客户，一个维修工单对一个客户和一台车。按这个关系画一张简单的ER图，转成表就是：

CREATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20), level INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sale_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT, vehicle_id BIGINT, total_amount DECIMAL(10,2), status INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

公交类的核心对象是：线路、站点、车辆。难点在“线路和站点是多对多关系”，必须用中间表line_station来记录，字段包括线路ID、站点ID、站点顺序号。实时位置表bus_position则可以简化成车辆ID、经度、纬度、上报时间。几次上车体验后我觉得，把一张中间表设计明白，比多写十个接口更能体现数据库功底。

3.3 MyBatis Plus：从实体类反推建表SQL

很多人搜“MyBatis Plus根据Java实体类生成创建表的SQL语句”，说明这类需求确实普遍。严格说MyBatis Plus本身不做建表，它的自动化能力体现在：用@TableName注解指定表名，用@TableId注解指定主键，然后在运行或测试阶段自动执行建表脚本。

更省事的做法是借助IDEA的数据库插件，直接根据实体类生成SQL。比如你写好这个实体类：

@Data @TableName("line") public class Line { @TableId(type = IdType.AUTO) private Long id; private String lineName; private String startStation; private String endStation; private Integer status; }

IDEA里对着实体类右键，选Generate，再选MyBatis X相关入口，就能生成对应的建表语句。生成后重点检查两件事：一是decimal字段的精度有没有自动带出来，金额和时间字段最容易出问题；二是delete标志、create_time这类通用字段有没有补上。

一点经验：不要依赖自动化生成就完全不看表结构。生成完必须自己过一遍字段类型、默认值、是否允许为空，尤其是status、create_time这些字段，答辩时经常被问到。

3.4 接口设计：统一返回、分页与登录状态

App调接口时最怕什么？不同接口返回格式不一样，今天这个返回data里是数组，明天那个返回data里是对象，解析代码写到想哭。

所以服务端接口一定要统一返回结构：

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } }

列表接口设计分页参数pageNum和pageSize，返回值里带上total和records，Android端才能做“上拉加载更多”。登录态这一块，毕业设计没必要上Spring Security这类重型框架，用一个简单的token方案就够：登录成功后生成一个UUID存到内存或数据库，App后续请求在Header里带上token，服务端校验一下。把“为什么要用token而不是session”想清楚，在答辩时就是一道送分题。

4. 把项目跑起来的完整实操记录

理论说完了，进入实操。这一章是一台“公交实时通”从零到能演示的完整过程，4S店项目照着这套流程做，基本不会跑偏。

4.1 环境配置：Android Studio中文界面与多JDK共存

开发环境是第一个门槛，每年都有同学卡在这一步。

Android Studio设置中文界面，老版本在Settings里的Plugins搜索Chinese，新版本直接在Settings里把界面语言切到中文，改完重启就生效。这个不算难，但很多人不知道入口在哪个菜单，浪费不少时间。

更常见的问题是JDK环境变量。如果机器上同时装了多个JDK，就需要在环境变量里灵活切换。Java在寻找JDK时优先看JAVA_HOME，其次才是Path里配置的路径。所以正确做法是把JAVA_HOME指向你想用的版本目录，比如JDK8，然后把Path里的第一条改成%JAVA_HOME%\bin。切换时只改JAVA_HOME一个变量就可以，顺手在控制台输入java -version验证一下。

Android Studio对JDK的要求也要留意。老版本AS配老版本JDK一般没问题，新版本AS如果提示Gradle版本不兼容，优先检查AGP和Gradle版本的对应关系。网上有官方版本对照表，别随便升级，升级一时爽，缓存火葬场。

4.2 创建服务端工程并配置数据库连接

服务端工程用Spring Initializr创建，选Java 8、Spring Web、MySQL Driver，然后手动加MyBatis Plus的最新版本坐标。这里有一个很容易踩的坑：MyBatis Plus版本和Spring Boot版本不匹配，最常见的现象是启动报错提示找不到某个类。解决办法也简单，按官方文档推荐的版本组合来，或者直接用MyBatis Plus包的spring-boot-starter。

数据库连接配置写在application.yml里：

spring: datasource: url: jdbc:mysql://localhost:3306/bus_db?useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这段配置里的serverTimezone是高频坑。MySQL 8以上不指定时区会报错，还有SSL连接如果不关，启动时会有大段警告。按上面这段配基本一次能过。

数据库建好后，先把公交线路表、站点表、车辆位置表建出来，写一个数据初始化类，启动时自动插入几条线路和模拟车辆位置数据。这样演示时永远有数据，不需要手动造。

4.3 Android端连接本地服务：模拟器与真机的差异

App写完总得连服务器，这一步很多同学卡到怀疑人生。

模拟器里访问电脑本地的服务端，不能用localhost，要用10.0.2.2，这是Android模拟器访问宿主机的固定地址。真机则不一样，手机和电脑连同一个WiFi，然后填电脑的局域网IP，比如192.168.1.5:8080。

连接的前提是服务端允许明文HTTP。Android 9以后默认禁用了明文流量，如果不配置，所有HTTP请求都会报错。解决办法是在AndroidManifest.xml的application节点上设置：

<application android:usesCleartextTraffic="true" ... >

定位到问题不难，但排查思路值得养成：先确认服务端启动成功，再用本机浏览器访问接口看能否返回JSON，最后才查App端的地址配置。按这个顺序排查，一分钟就能定位是后端没起来、端口不对，还是防火墙挡了。

4.4 联调页面：从接口数据到列表展示

前后端串起来的核心套路是固定的：

第一步，界面初始化时显示进度条。第二步，用Retrofit发起请求。第三步，请求回调里判断code是否等于200，成功就解析data填充列表并隐藏进度条，失败就提示错误信息。第四步，下拉刷新时重新请求第一页，上拉加载时页码加一。

这段流程我会建议你手写一遍，而不是直接复制Demo。因为联调真正遇到的坑，几乎全在细节里：忘记切回主线程导致崩溃、没有处理空列表导致界面空白、没有做下拉刷新时loading状态的去重导致重复请求。

公交实时通项目联调时还有一个关键体验点：车辆位置数据是轮询来的。设定一个定时任务，每5秒请求一次最新位置接口，刷新地图上的Marker。轮询间隔别太短，模拟器上的线程和网络开销会把演示过程拖卡，5秒正好。

5. 高频报错排查：这些坑我帮你踩完了

这一章是给赶时间的同学看的，遇到问题直接来查，对症下药。

5.1 Android环境下的目录与权限问题

搜索记录里出现大量/storage/emulated/0/android/data/...的路径，说明很多人卡在文件访问上。Android很早就导入了分区存储机制，从Android 10开始，App不能随便读写其他应用在外部存储创建的数据目录，即便你有存储权限也不行。

如果你确实要读写自己的私有目录，正确姿势是用FileProvider和getExternalFilesDir获取专属路径，而不是硬编码绝对路径。放在Android/data/下面的文件，卸载App时会一并被清除，别拿它当长期存储。

这块再提醒一次：代码里绝对不要写死“/storage/emulated/0/”这种路径。不同品牌、不同系统版本的路径可能有差异，轻则文件读不到，重则崩溃。真想用图片上传功能，就规规矩矩走相册选择加ContentResolver获取Uri，再配合FileProvider做临时访问权限。

5.2 Java服务端的常见启动与连接问题

搜“java启动失败怎么解决”的，一半以上是这三类情况：端口被占用、数据库没启动、配置文件写错。

端口占用最好查，控制台会直接提示Port 8080 was already in use，找到占用进程关掉就好。数据库启动失败，连接池的报错信息里通常有Access denied或Communications link failure，前者是账号密码不对，后者八成是服务没启动或URL写错。

热词里还有“java如何连接SQL Server 2008”，这也是经典老坑。SQL Server 2008用官方JDBC驱动时注意三点：驱动版本不能太新，太新对老版本数据库支持并不好；要确认SQL Server开启了TCP/IP协议，默认可能只开了Named Pipes；连接URL里实例名端口要写对，默认1433，但命名实例的口径不一样。话说回来，毕业设计尽量统一用MySQL，省去一堆兼容性烦恼。

5.3 答辩演示最容易翻车的三个瞬间

现场演示是毕设的临门一脚，多数翻车点其实可以提前预防。

第一个雷是模拟器断网。答辩教室的WiFi不一定稳定，模拟器一旦脱离宿主机网络，所有接口数据全拉不出来。稳妥做法是提前把服务端跑在本地，用模拟器走10.0.2.2，千万别依赖公共网络里的远程服务器。

第二个雷是数据库忘记启动。关掉电脑再开，MySQL服务默认没启动，一运行就报数据库连接失败。建议把MySQL注册成Windows服务并设为自动启动，演示前再确认一下右下角图标是绿色。

第三个雷是权限弹窗没处理。App第一次启动时定位权限弹窗没有点击允许，直接进到地图页会是空白的。演示脚本里要写清楚“点允许”这个动作，甚至可以在演示前用真机提前授权好。

6. 一个题目做完后，往哪扩展

做完其中一个题目，千万别交完就完事。三个题目其实可以共用一套服务端架构，想想怎么扩展，能帮你把项目档次再提一截。

6.1 三个题目共享一个服务端的思路

这三个题的共性大于差异：都有用户登录、都有列表查询、都有数据状态刷新、都有移动端展示。如果一开始就把服务端按模块分包设计，比如用户模块、业务模块、公共模块，那么做完一个题目的框架，另外两个项目只需要往业务模块里加新表和新接口，App端复用网络层、列表组件、登录逻辑，工作量能下降一半。

从答辩叙事的角度看，这也可以作为“系统设计”亮点来谈：你设计了一套可复用的接口架构，不是每个功能都从头造轮子。

6.2 公共模块抽取与加分项

如果你学有余力，可以把网络层、图片加载、定位管理这些App端公共模块抽成一个独立工具类库，三个项目直接引用。面试时也可以把这个作为“组件化意识”的例证。

加分项建议排个优先级：第一优先是数据统计可视化，比如4S店项目做个销售统计折线图，公交项目做个站点客流柱状图，用MPAndroidChart这类开源库就能实现，观感提升巨大。第二优先是Excel导出，在服务端把订单或线路数据导出成Excel，答辩时展示一下“报表导出”功能，很加分。第三优先是本地缓存，公交查询这类高频操作，把常用线路的站点缓存到SQLite或SharedPreferences里，弱网环境下也能秒开。

延伸方向还有Android TV和汽车车载系统，但这些方向设备成本高、调试难度大，不是毕业设计该碰的场景。真有兴趣，把TV端的焦点处理、车载端的横屏适配当作扩展延伸提一嘴，已经足够让评委觉得你有视野。

这套项目做完，我自己最大的体会是：技术框架是次要的，能不能把一条完整的数据链路串通才是关键。从一个界面、一次点击，到后端接口、数据库记录，再回到界面刷新，中间每一步都理解透彻，这个毕业设计才算真正“到手”。

最后再分享一个压箱底的技巧：演示前把所有模拟数据和静态图片准备到位，哪怕现场断网，你也能靠缓存和本地数据撑住场子。先把链路做通，再谈优化和扩展，这条经验不仅适用于这几个题目，以后做任何工程都吃香。