简介这是一套基于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这些系统能力都需要通过插件或原生桥接补齐每补一个能力就多一层适配。考虑到校园里还有相当比例的旧机型原生方案在性能和兼容性上的优势更明显。方案后台定位系统弹窗权限地图SDK深度定制低端机流畅度结论原生 Kotlin完整支持完整支持官方SDK全套好校园外卖主选Flutter需插件拼装部分受限插桩较多一般备选Uniapp依赖原生打包受限按模块支持一般慎用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(): FlowListOrderEntity 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 是状态机的核心。所有状态变更的入口都调用这个方法不合法就直接拒绝而不是让业务代码自己判断。这样服务端重复推送同一个状态或者网络延迟导致两条回调乱序状态也不会从“已送达”退回到“配送中”。状态变更时客户端要做的事也相对固定状态触发动作客户端行为CREATED用户支付成功展示等待商家接单倒计时ACCEPTED商家接单展示骑手预计到达时间PICKED_UP骑手取餐展示骑手实时位置DELIVERED点击送达引导用户评价CANCELLED用户或商家取消展示退款状态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): FlowOrderEntity class OrderViewModel( private val repo: OrderRepository, private val orderId: String ) : ViewModel() { val order: FlowOrderEntity 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 为准判断到达。定位来源典型精度校园场景问题GPS5-15 米宿舍楼内无法收到卫星信号基站50-200 米楼宇密集时误差过大Wi-Fi10-50 米2.4G 覆盖单一位置更新延迟高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 之后后台定位必须声明 foregroundServiceTypelocation否则服务一启动就崩。Android 14 对前台服务类型又加了一层限制声明必须和实际调用匹配这是一连串版本适配里最常见的崩溃来源service android:name.service.LocationService android:foregroundServiceTypelocation android:exportedfalse /启动这个服务时必须传入一个通知否则系统直接抛 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_ALIAScampus 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 是追加写跑久了会越来越大正式发布前改成带时间戳的文件名或者做日志滚动只保留最近二十条不然最后占满外部存储的会是自己写的崩溃日志。本文还有配套的精品资源点击获取
