基于Android Studio的校园外卖App实战：订单状态机与定位轨迹全解析

简介：这是一套基于Android Studio开发的校园外卖App项目源码，面向Android学习者、毕业设计开发者等需要完整移动端+后台管理场景的人群。项目以校园场景为切入点，覆盖用户端从注册登录、商家模糊搜索、菜单查看、加购下单到订单评价的完整流程，同时附带基于JSP等技术的后台服务端，包含用户、商家、菜单、订单、评价信息管理等模块，可帮助读者理解前后端数据交互与Android客户端实现方式。资源包共1335个文件，主要有Java源码、XML布局文件、PNG图片、JAR依赖库以及少量JSP页面、SQL脚本等，其中Java与XML构成核心工程代码，图片资源用于界面展示，SQL可辅助初始化数据库，压缩包整体约18.38MB。该资源已有1160人学习下载，适合需要一套可直接运行、结构清晰的校园外卖App参考项目，用于课程设计、毕设或功能扩展练习。

1. 基于安卓Android Studio的校园外卖App，先解决状态和定位两个前提

基于安卓Android Studio的校园外卖App，看起来和普通外卖没什么两样，动手做才发现完全是两条技术路径。校园配送距离短、订单高峰集中在饭点、宿舍楼定位精度差，这些条件直接决定了架构和业务设计上的取舍。很多人拿到这个课题直接套通用外卖模板，结果在订单状态流转、地图定位和Android后台限制上反复返工。这篇文章把基于安卓Android Studio的校园外卖App从工程骨架、订单状态机、校园定位，到上架前的签名和崩溃处理串一遍，目标是让初学者能按步骤跑通，也让做过一两年的开发看到边界和取舍。适合准备毕设、跑校园创业项目，或者想系统过一遍业务型App工程化的人。

2. 用 Android Studio 搭出校园外卖的可扩展工程骨架

Android Studio安装教程网上到处都是，装完只是第一步。真正的问题在于，校园外卖App在课程设计或创业原型阶段看起来只有十几个页面，一旦涉及订单、地图、商家、用户中心，代码量增长会非常快。没有模块边界的工程，两个星期后改一个需求要动三四个文件。这里说的搭法，是基于安卓Android Studio的校园外卖App里比较稳的一版：壳工程加业务模块，核心能力下沉到公共层。

2.1 为什么选原生 Kotlin，而不是跨端方案

校园外卖客户端的硬需求是后台定位、前台服务保活、地图组件深度嵌入、低端机型流畅度。这些需求决定了客户端需要在系统层面拿到比较完整的控制权。原生Kotlin在这条路径上几乎没有额外封装损耗；Flutter和Uniapp做界面效率高，但后台定位、通知权限、地图SDK这些系统能力都需要通过插件或原生桥接补齐，每补一个能力就多一层适配。考虑到校园里还有相当比例的旧机型，原生方案在性能和兼容性上的优势更明显。

2.2 按业务拆模块，避免三个月后改一个功能要动三个文件

我一般会拆出 app、core、feature 三层，而不是把所有代码塞进一个 app 模块。壳工程只负责初始化；core 放网络、数据库、定位等基础能力；每个业务页面按 feature 模块独立开发。拿到这个课题，先别急着写界面，按这个结构把目录先建好：

app/ # 壳工程：启动、全局初始化 core/ network/ # Retrofit + OkHttp 封装 database/ # Room 数据库，订单本地缓存 location/ # 定位与轨迹上传 feature/ order/ # 订单状态、订单详情 shop/ # 商家与菜品 map/ # 地图与配送轨迹

这样拆之后，core 层不依赖业务，feature 模块只依赖 core，业务模块之间不互相引用。订单状态变更时，order 模块直接改本地数据库，map 模块只管轨迹，两个模块不会彼此拖累。实际开发里最常见的问题是订单模块想调用地图模块的类，一旦放行，模块边界就算破了，后面每个模块都会互相引用。

2.3 数据层用 Room + Retrofit，先把离线可看做到位

校园的弱网环境比写字楼差很多，宿舍楼道、电梯里经常断网。点进订单页的时候，如果网络请求不成功就白屏，用户的第一反应是卸载。所以数据层要先把“离线可看”做到位：Retrofit 负责网络数据，Room 负责本地缓存，页面数据全部从数据库读取。

// OrderEntity.kt @Entity(tableName = "order_table") data class OrderEntity( @PrimaryKey val orderId: String, val status: Int, // 对应订单状态机里的枚举值 val shopName: String, val totalPrice: Double, val updateTime: Long ) // OrderDao.kt @Dao interface OrderDao { @Query("SELECT * FROM order_table ORDER BY updateTime DESC") fun observeAll(): Flow<List<OrderEntity>> @Insert(onConflict = OnConflictStrategy.REPLACE) suspend fun upsert(order: OrderEntity) @Query("DELETE FROM order_table WHERE orderId = :id") suspend fun deleteById(id: String) }

DAO 把查询订单列表设计成 Flow，页面订阅之后，本地数据一变 UI 就跟着变。upsert 用 REPLACE 策略，服务端推过来同一个订单就直接整体覆盖，不需要先 delete 再 insert 两行代码。Retrofit 返回后先转成 OrderEntity 写入 Room，不要直接把网络数据丢给 UI。数据从数据库流向界面，这样断网时订单页仍然可以打开，等网络恢复再自动刷新。

2.4 Gradle 配置里值得固定的几个值

Gradle 配置是很容易被忽略的环节。Android Studio 默认新建工程的配置能跑，但未必适合校园外卖这种长时间后台运行、大量列表页面的项目。下面这组参数是这个场景下比较稳的起点：

android { compileSdk = 34 defaultConfig { applicationId = "com.example.campusmeal" minSdk = 23 // Android 6.0，覆盖绝大多数校园机型 targetSdk = 34 } compileOptions { sourceCompatibility = JavaVersion.VERSION_17 targetCompatibility = JavaVersion.VERSION_17 } buildFeatures { viewBinding = true } }

minSdk 选 23 而不是更低的 21，是因为 Android 6.0 之后的运行时权限模型和以前的隐式权限差别很大，校园里还在用 Android 5.1 的机型极少，降低 minSdk 等于要处理一套已经淘汰的权限逻辑。targetSdk 跟着 Android Studio 当前推荐走就行。AGP 和 Kotlin 版本建议直接用 Android Studio 自带下载的那一套，不要刻意追新，遇到插件兼容问题再去 SDK Manager 里换历史版本，这个坑很多人踩过。

提示：viewBinding 对校园外卖这种以列表和详情为主的界面足够用了，不需要再引入 DataBinding 的注解处理器，编译速度会更快。

3. 订单状态机与数据同步：把“已下单”到“已送达”串成闭环

校园外卖的订单状态看起来简单，无非是下单、接单、配送、送达。真实跑起来会遇到这些情况：商家二十秒没接单、骑手送错楼栋、用户在宿舍里接不到电话、订单被取消后又重新接单。状态一旦用散落的 Int 变量控制，改一处就会漏掉另一处。这个课题的业务核心不在界面，而在订单状态怎么流转、怎么保证不出现“已送达又变回配送中”这种低级错误。

3.1 用枚举状态机替代魔数，订单流转才不会越变越乱

订单状态在客户端和服务端之间传递时通常是一个整数，但如果代码里到处写 if (status == 1)，过一周自己都记不清 1 是什么。用枚举把状态和转移规则收拢到一个文件里，是所有后续逻辑的基础：

enum class OrderStatus(val value: Int, val desc: String) { CREATED(0, "已下单，等待商家接单"), ACCEPTED(1, "商家已接单，等待骑手"), PICKED_UP(2, "骑手已取餐，配送中"), DELIVERED(3, "已送达"), CANCELLED(4, "已取消"); fun canTransitTo(next: OrderStatus): Boolean { if (this == CANCELLED || this == DELIVERED) return false return when (this) { CREATED -> next == ACCEPTED || next == CANCELLED ACCEPTED -> next == PICKED_UP || next == CANCELLED PICKED_UP -> next == DELIVERED || next == CANCELLED else -> false } } companion object { fun fromValue(value: Int): OrderStatus? = entries.firstOrNull { it.value == value } } }

canTransitTo 是状态机的核心。所有状态变更的入口都调用这个方法，不合法就直接拒绝，而不是让业务代码自己判断。这样服务端重复推送同一个状态，或者网络延迟导致两条回调乱序，状态也不会从“已送达”退回到“配送中”。状态变更时客户端要做的事也相对固定：

3.2 长连接还是轮询：校园网络环境下的选择逻辑

订单状态实时性要求不高，但用户会盯着“骑手到哪了”，轮询如果用 10 秒一次，一个页面打开十分钟就是六十个请求，大量请求其实没有变化，校园网的弱网环境下失败率也不低。服务端支持的话，优先用 WebSocket；服务端不支持，就把轮询间隔控制在 15 秒以上，并且做退避策略。基于 OkHttp 的 WebSocket 客户端是常见做法：

class OrderSocketClient( private val onStatusChanged: (OrderStatus) -> Unit ) { private val client = OkHttpClient.Builder() .pingInterval(20, TimeUnit.SECONDS) // 心跳间隔，防止连接被网络设备掐断 .build() private val listener = object : WebSocketListener() { override fun onMessage(webSocket: WebSocket, text: String) { // 服务端推送格式：{"orderId":"1001","status":2} val json = JSONObject(text) val status = OrderStatus.fromValue(json.getInt("status")) ?: return onStatusChanged(status) } override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) { // 断线后做退避重连，最终退化成轮询兜底 scheduleReconnect() } } }

pingInterval 是必须配的，运营商或校园 Wi-Fi 的 NAT 空闲超时通常在一分钟到几分钟，不发心跳的长连接很容易被网络设备静默断开。onFailure 里重连要有退避策略，不能断线后立刻又连、连上又断。如果测试时发现 WebSocket 抓包抓不到，先检查代理设置和服务器证书，很多“抓包失败”问题其实卡在这里，而不是代码写错。

3.3 状态回调先落库再刷新UI，避免界面和状态对不上

很多 Android Studio 工程里，收到推送之后直接把状态 set 给 ViewModel，界面立刻刷新。这种做法在页面存续期间没问题，但 Activity 一旦因为内存不足被回收，用户再打开订单详情页，状态就没有了。正确顺序是：收到状态变更，先写 Room，再由数据库的 Flow 驱动界面刷新。

@Query("SELECT * FROM order_table WHERE orderId = :orderId") fun observeById(orderId: String): Flow<OrderEntity> class OrderViewModel( private val repo: OrderRepository, private val orderId: String ) : ViewModel() { val order: Flow<OrderEntity> = repo.observeOrder(orderId) fun handleStatusChanged(status: OrderStatus) { viewModelScope.launch { repo.updateStatus(orderId, status.value, System.currentTimeMillis()) } } }

这样做的另一个好处是，进程被杀之后重新打开订单详情页，看到的还是上次落库的状态，等网络恢复后才更新。如果你拿到别人的工程，发现订单页每次进来都闪一下 loading，基本就是数据没有先落库，直接依赖网络回调刷新界面导致的。

3.4 回调乱序、重复通知和后台限制的处理

即使有了状态机，合法乱序仍然存在。比如服务端先推 DELIVERED，再推 PICKED_UP，状态机允许从 PICKED_UP 到 DELIVERED，但反过来不行，这时候就需要在落库时对比本地已有记录的时间戳：

val existing = orderDao.getById(orderId) if (existing != null && existing.updateTime > incoming.updateTime) { return // 旧时间戳直接丢弃 }

时间戳对比放在状态机校验之前，可以过滤掉绝大多数乱序回放。通知栏的订单状态提醒要做去重，notify 时使用 orderId.hashCode() 作为通知 id，避免同一个订单重复弹通知。Android 8.0 以上，后台服务很容易被系统回收，尤其是国产机型，订单监听服务要用 startForegroundService 配合前台服务类型运行。很多 androidstudio 点击类报 cannot perform operation 的问题，本质上是网络回调线程里直接操作了数据库或者 UI，用 viewModelScope 切回主线程就不会出现。

4. 校园配送的定位与轨迹：不是简单调一个定位SDK

校园地图和城市地图是两种画风。城市道路规划清晰、楼栋间距大，GPS 误差十米内可以接受。校园里宿舍楼密集，很多楼栋之间的小路 GPS 是分不清的，定位点经常落在隔壁楼。骑手轨迹从这里开始歪，后面的送达判断全部跟着错。所以校园外卖App里的地图功能，重点不在地图样式，而在定位校准和轨迹过滤。

4.1 宿舍楼里收不到GPS，校园定位需要组合方案

GPS 在室内基本不可用，宿舍楼里要靠 Wi-Fi 和基站辅助定位，误差可能在几十米到几百米。标准做法是 GPS、基站、Wi-Fi 三者组合，Android 的 FusedLocationProvider 默认就是这种融合定位。校园里有大量宿舍楼只覆盖 2.4G 频段 Wi-Fi，定位结果会周期性漂移，所以要配业务逻辑做修正：骑手到了宿舍楼下，手动点“已送达”，不以 GPS 为准判断到达。

4.2 定位参数怎么配：高精度模式之外还需要省电策略

地图 SDK 一般默认开高精度，但如果不限制更新频率，骑手手机电量会肉眼可见地往下掉。基于 FusedLocationProvider 的推荐配置是用户在前台时用 2 秒更新一次，后台切换到 10 秒以上：

val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 2000) .setWaitForAccurateLocation(false) .setMinUpdateIntervalMillis(1000) // 允许最快1秒，不要低于这个值 .build() val client = LocationServices.getFusedLocationProviderClient(context) if (ContextCompat.checkSelfPermission(context, Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED) { client.requestLocationUpdates(request, callback, Looper.getMainLooper()) }

setWaitForAccurateLocation(false) 的作用是不要为了等一个精确的 GPS fix 而卡住回调，校园场景下先拿一个基站/Wi-Fi 的粗定位，比长期等待 GPS 有用。Android 12 之后，ACCESS_FINE_LOCATION 需要在运行时单独申请，同时要说明用途，否则用户很难理解为什么一个外卖软件要精确定位。

注意：不要用 0 作为最快更新间隔，部分机型会让 GPS 芯片持续满负荷工作，半小时内掉电百分之十以上。

4.3 轨迹点的漂移过滤与上传压缩

网约车App里的轨迹处理思路在校园外卖里可以直接借鉴，但不需要那么复杂的路径规划，只需要做好漂移点过滤和批量上传。骑手在宿舍楼之间骑行时，定位点会周期性跳到隔壁楼，直接上抛会让轨迹在地图上画出一条撕开的线。一个简单的过滤逻辑是距离加速度双重校验：

fun shouldUpload(newPoint: Location, lastPoint: Location): Boolean { val distance = newPoint.distanceTo(lastPoint) val timeDeltaSec = (newPoint.time - lastPoint.time) / 1000.0 // 两点距离超过500米但时间不足2秒，基本是漂移点 if (distance > 500 && timeDeltaSec < 2) return false // 校园骑行速度不超过60km/h，超过视为异常 val speedMps = distance / timeDeltaSec return speedMps < 16.7 }

过滤之外还要做上传压缩。我一般会攒够五个点，或者每隔五秒批量上传一次，而不是每个点单独发请求。校园网络环境不稳定，频繁的小请求反而更容易失败，批量上传可以把失败率降下来，也方便服务端做轨迹插值。

4.4 前后台定位与通知权限的适配

Android 10 之后，后台定位必须声明 foregroundServiceType="location"，否则服务一启动就崩。Android 14 对前台服务类型又加了一层限制，声明必须和实际调用匹配，这是一连串版本适配里最常见的崩溃来源：

<service android:name=".service.LocationService" android:foregroundServiceType="location" android:exported="false" />

启动这个服务时，必须传入一个通知，否则系统直接抛 ForegroundServiceDidNotStartInTimeException。通知渠道要在 Android 8.0 以上用 NotificationChannel 注册，配送轨迹通知属于常驻通知，优先级不能设成 PRIORITY_MIN，否则骑手切到其他应用就看不到轨迹了。Android 13 以上还要在运行时先申请 POST_NOTIFICATIONS 权限，没授予的情况下前台服务照样启动，但通知不会显示，用户看到的只是“没有通知栏的配送中”。

5. 上架与分发前的最后一步：签名、混淆和崩溃现场还原

Android Studio 编译 APK 只是上架的开始，真正决定一个校园外卖App能不能稳定分发的是签名、混淆和崩溃日志这三件事。签名错了装不上，混淆配错了启动就闪退，崩溃没有日志等于瞎修。

5.1 签名信息别写死在build.gradle里

签名文件应该从 gradle.properties 里读取，而不是明文写在 build.gradle 里提交到 Git。仓库里的 jks 文件一旦泄露，别人就能用你的签名发布带后门的版本：

// gradle.properties STORE_FILE=/Users/you/campusmeal/campusmeal.jks STORE_PASSWORD=****** KEY_ALIAS=campus KEY_PASSWORD=******

build.gradle 里通过 project.property 读取这些值，本地高版本 Android Studio 编译 APK 时，选择 Build > Generate Signed Bundle/APK 走一遍生成流程。调试签名和发布签名必须分开，调试签名只用于开发机，发布签名的 keystore 至少备份两份。

5.2 混淆规则要保住数据模型和反射入口

混淆能缩小 APK 体积，但也会把反射和序列化打断。Room 的实体类如果被混淆，字段名变了，生成的 Impl 类就找不到对应列。Gson 反射创建对象也会失败。这个课题里必须保留的至少是三块：数据模型、Room 实体、订单状态枚举：

-keep class com.example.campusmeal.data.entity.** { *; } -keep class com.example.campusmeal.core.database.** { *; } -keep enum com.example.campusmeal.order.OrderStatus { *; }

枚举不建议混淆，否则崩溃日志里看到的不是 DELIVERED 而是 A、B、C，排错时没法一眼看出状态。如果接口字段用了 @SerializedName 注解，还要把注解对应的字段也保留。不同序列化库的保留规则不一样，换库时记得同步改混淆配置。

5.3 崩溃日志落盘，把现场留给下次启动

接入第三方崩溃监控平台是最省事的方案，但如果只是校内分发，一个轻量的本地崩溃落盘就够了。在 Application 里设置默认的未捕获异常处理器，把堆栈写到本地文件，下一次启动时再补传：

class CrashHandler : Thread.UncaughtExceptionHandler { override fun uncaughtException(thread: Thread, throwable: Throwable) { val stack = Log.getStackTraceString(throwable) val dir = applicationContext.externalCacheDir ?: applicationContext.filesDir File(dir, "crash.log").appendText(stack) } } class App : Application() { override fun onCreate() { super.onCreate() Thread.setDefaultUncaughtExceptionHandler(CrashHandler()) } }

崩溃现场不要做网络请求，进程状态在崩溃时已经不可靠，所以要落盘再上传。验证方法是主动在代码里抛一个 RuntimeException，杀掉进程重新打开，去看 crash.log 里有没有记录。注意这个 crash.log 是追加写，跑久了会越来越大，正式发布前改成带时间戳的文件名，或者做日志滚动只保留最近二十条，不然最后占满外部存储的会是自己写的崩溃日志。

本文还有配套的精品资源，点击获取