简介这是一份面向Android初学者与餐饮应用开发练习者的移动点餐项目源码包含ph2移动客户端与ph2web服务端两部分可用于学习Android应用从界面到网络通信的完整开发流程。压缩包共149个文件约2.68MB以55个class编译文件、23个java源码、20个xml布局与配置、39个png图片资源为主另含jar依赖、apk安装包及ap_、dex等构建产物覆盖客户端与服务端的核心代码结构。客户端部分涉及菜单浏览、购物车与订单提交、HTTP数据交互及SQLite本地存储服务端则包含请求处理、数据库管理与RESTful接口设计等实践内容。目前已有164人学习下载适合希望通过真实项目理解模块化设计、网络编程与前后端协作的读者参考借鉴。1. 移动点餐源代码从扫码到出单一套能跑通的 Android 点餐系统前阵子帮一个做餐饮 SaaS 的朋友看项目他手里有一套移动点餐源代码想改成支持多门店的版本结果卡在订单状态同步上——顾客端显示已下单后厨端却迟迟不刷新。翻完代码发现问题出在本地数据库和远端接口的时序没对齐。这套源码本身功能是完整的顾客扫码进店、浏览菜单、加购物车、下单支付后厨接单出餐管理端改菜品改价格一条链路全通。技术栈是 Android 原生加 Java/Kotlin后端常见做法是 Spring Boot 配 MySQL接口走 RESTful。适合谁想快速搭一套点餐 Demo 的学生、要二次开发餐饮小程序的独立开发者、以及需要给客户演示点餐流程的产品团队。下面按「能干什么 → 怎么跑 → 怎么改」拆一遍。2. 项目架构与目录结构先看清模块边界再动手2.1 整体分层表现层、业务层、数据层怎么切这套移动点餐源代码的 Android 端采用经典的三层结构没有上 MVVM 的 DataBinding 那套重家伙而是用 Activity/Fragment 直接持有 Presenter 或 ViewModel对新手友好改起来也快。表现层负责扫码、菜单渲染、购物车弹窗、订单列表业务层处理加菜减菜、价格计算、订单状态机数据层分两块——本地 SQLite 存购物车和缓存菜单远端 Retrofit OkHttp 调后端接口。我一般会先看app/src/main/java/com/example/ordering/下的包结构通常长这样com.example.ordering ├── ui/ # Activity、Fragment、Adapter │ ├── menu/ # 菜单浏览 │ ├── cart/ # 购物车 │ ├── order/ # 订单确认与列表 │ └── admin/ # 管理端入口 ├── data/ # 数据层 │ ├── local/ # SQLite Helper、DAO │ ├── remote/ # Retrofit Service、ApiClient │ └── model/ # 实体类Dish、Order、CartItem ├── business/ # 业务逻辑OrderManager、CartManager └── util/ # 工具类PriceUtil、TimeUtil这个划分的好处是你要换后端接口只动data/remote要改价格规则只动business。常见做法是把ApiClient做成单例Retrofit 的 baseUrl 抽到BuildConfig或gradle.properties方便切测试环境和生产环境。2.2 关键依赖与版本Gradle 里哪些不能乱动打开app/build.gradle核心依赖一般这几条implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0 implementation com.squareup.okhttp3:logging-interceptor:4.9.3 implementation androidx.recyclerview:recyclerview:1.2.1 implementation com.google.android.material:material:1.6.0 implementation androidx.room:room-runtime:2.4.2 annotationProcessor androidx.room:room-compiler:2.4.2Retrofit 和 Gson 负责网络与 JSON 解析Room 是 SQLite 的封装比手写SQLiteOpenHelper省事。注意 Room 的 compiler 必须用annotationProcessor用implementation会编译不过。如果源码里用的是kotlin-kapt那就对应换成kapt。版本号别随意升Retrofit 2.9 和 OkHttp 4.9 是稳定搭配升到 OkHttp 5.x 会有 API 变动。2.3 后端接口约定订单和菜单的数据长什么样后端这块源码通常带一个简单的 Spring Boot 工程或者只给接口文档。核心接口就几个接口方法路径说明获取菜单GET/api/menu/list返回菜品列表含分类、价格、图片提交订单POST/api/order/create传桌号、菜品明细、总价查询订单GET/api/order/detail按订单号查状态更新菜品POST/api/admin/dish/update管理端改价改库存菜单返回的 JSON 里categoryId用来分组status字段控制是否上架。订单状态一般用数字枚举0 待支付、1 已支付、2 制作中、3 已完成、4 已取消。这个状态机是后面避坑的重点先记住。3. 跑起来从导入 Android Studio 到扫码点单成功3.1 环境准备与项目导入先把源码解压用 Android Studio 的「Open an existing project」选根目录不要选app子目录。等 Gradle sync 完成如果卡在下载依赖检查gradle-wrapper.properties里的 distributionUrl 是不是官方地址国内网络常见做法是换成镜像但注意别引入来路不明的仓库。SDK 版本看build.gradle里的compileSdk和targetSdk一般 30 或 31。如果本地没装对应版本Android Studio 会提示下载。minSdk通常是 21 或 23意味着 Android 5.0/6.0 以上都能跑。提示导入后先别急着 Run点一下 Build → Make Project把编译错误先暴露出来比直接跑模拟器省时间。3.2 配置后端地址与启动服务源码里后端地址通常写死在ApiClient或Constants类里类似public class ApiClient { // 模拟器访问本机用 10.0.2.2真机用局域网 IP private static final String BASE_URL http://10.0.2.2:8080/; private static Retrofit retrofit; public static Retrofit getInstance() { if (retrofit null) { OkHttpClient client new OkHttpClient.Builder() .addInterceptor(new HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY)) .connectTimeout(10, TimeUnit.SECONDS) .build(); retrofit new Retrofit.Builder() .baseUrl(BASE_URL) .client(client) .addConverterFactory(GsonConverterFactory.create()) .build(); } return retrofit; } }10.0.2.2是 Android 模拟器访问宿主机 localhost 的固定地址真机调试要改成电脑的局域网 IP比如192.168.1.100。后端如果是 Spring Boot 工程用mvn spring-boot:run或直接跑 main 方法启动默认端口 8080。启动后先用浏览器或 Postman 访问http://localhost:8080/api/menu/list确认返回 JSON 再跑 App。3.3 模拟器运行与扫码入口Run 到模拟器后App 启动页一般会请求菜单接口成功则进主页。扫码功能依赖zxing或ML Kit模拟器没摄像头常见做法是提供一个「模拟扫码」按钮直接填桌号进菜单。真机则调startActivityForResult拉起扫码页。// 模拟扫码直接传桌号方便调试 findViewById(R.id.btn_mock_scan).setOnClickListener(v - { Intent intent new Intent(this, MenuActivity.class); intent.putExtra(table_no, A01); // 桌号写死真机从扫码结果取 startActivity(intent); });桌号是订单的关键字段后端靠它区分送餐位置。调试阶段写死没问题上线前必须换成真实扫码结果。菜单页用 RecyclerView 按分类渲染点「」加购物车购物车数据先写本地 Room点「去结算」再调下单接口。3.4 下单到出单的完整验证下单成功后App 跳订单详情页轮询或长连接查状态。后端收到订单后厨端可能是另一个平板 App 或 Web 页面拉取待制作列表。验证链路是否通就看三件事订单号是否唯一、总价是否和购物车一致、状态是否从 1 变到 2。如果后厨端不刷新先查后端有没有推消息再看 App 轮询间隔是不是太长。4. 核心模块拆解购物车、订单状态机与网络层4.1 购物车逻辑本地 Room 怎么存怎么算购物车是点餐系统的核心这套源码用 Room 存CartItem字段包括dishId、name、price、count。加菜时先查本地有没有同dishId有就count1没有就插入。Dao public interface CartDao { Query(SELECT * FROM cart_item WHERE dishId :dishId LIMIT 1) CartItem findByDishId(int dishId); Insert(onConflict OnConflictStrategy.REPLACE) void insert(CartItem item); Update void update(CartItem item); Query(SELECT SUM(price * count) FROM cart_item) double getTotalPrice(); }getTotalPrice直接用 SQL 聚合算总价比在 Java 里循环累加更稳避免浮点误差累积。注意价格字段用double还是BigDecimal——源码里常见用double但涉及优惠券分摊时会有精度问题二次开发建议换BigDecimal或存「分」为单位的长整型。4.2 订单状态机0 到 4 的流转不能乱订单状态是踩坑重灾区。源码里通常定义一个OrderStatus枚举或常量类public class OrderStatus { public static final int PENDING_PAY 0; // 待支付 public static final int PAID 1; // 已支付 public static final int COOKING 2; // 制作中 public static final int DONE 3; // 已完成 public static final int CANCELED 4; // 已取消 }状态流转必须单向0→1→2→3取消只能从 0 或 1 进 4。后端更新状态时要加条件比如UPDATE orders SET status2 WHERE id? AND status1防止并发下状态跳变。App 端轮询到状态变化后用DiffUtil刷新列表别直接notifyDataSetChanged否则闪烁。4.3 网络层封装Retrofit 接口与错误处理Retrofit 的 Service 接口定义很直白public interface OrderService { GET(api/menu/list) CallMenuResponse getMenuList(); POST(api/order/create) CallOrderResponse createOrder(Body OrderRequest request); GET(api/order/detail) CallOrderDetail getOrderDetail(Query(orderNo) String orderNo); }调用时用enqueue异步回调里判response.isSuccessful()失败看errorBody。常见做法是包一层ApiCallback统一处理 token 过期和网络异常。注意OrderRequest里的菜品列表要用ListCartItemGson 序列化时字段名要和后端一致不一致用SerializedName标注。5. 避坑与排查订单不同步、价格错乱、扫码失败5.1 订单状态不同步顾客端已支付后厨端没反应现象是顾客付完钱订单详情显示「已支付」后厨列表还是空的。原因通常是后端更新状态后没有推送App 端轮询间隔设了 30 秒甚至更长。解决把轮询间隔降到 35 秒或者后端加 WebSocket 推。如果源码里用的是Handler.postDelayed轮询记得在onDestroy里removeCallbacks否则页面关了还在跑内存泄漏。5.2 总价对不上购物车算出来和订单金额差几分钱现象是购物车显示 58.60提交后订单变成 58.59。原因是double累加精度丢失或者后端重新算了一遍用了不同规则。解决统一在客户端算好总价传给后端后端只校验不重算或者两边都用「分」为单位的长整型。源码里如果price是double二次开发时优先改这个。5.3 扫码没反应模拟器无摄像头真机权限没给现象是点扫码按钮黑屏或直接返回。原因模拟器没摄像头硬件真机没申请CAMERA权限。解决调试用模拟扫码入口真机在AndroidManifest.xml加uses-permission android:nameandroid.permission.CAMERA/运行时用ActivityCompat.requestPermissions动态申请。Android 6.0 以上不动态申请会直接崩。5.4 菜单图片不显示Glide 没配或网络明文限制现象是菜单列表文字正常图片全是占位图。原因没加 Glide 依赖或者 Android 9 以上默认禁止明文 HTTP。解决加implementation com.github.bumptech.glide:glide:4.13.0并在AndroidManifest.xml的application加android:usesCleartextTraffictrue或者后端上 HTTPS。生产环境建议上 HTTPS明文只用于调试。5.5 后厨端重复出单接口没做幂等现象是同一订单在后厨列表出现两次。原因顾客端网络抖动重试后端createOrder没做幂等。解决下单时客户端生成唯一requestId后端用它去重或者订单号用「桌号时间戳随机数」保证唯一。这个坑在真实餐厅高峰期特别致命二次开发务必补上。6. 二次开发改造多门店、支付对接与性能优化拿到这套移动点餐源代码最常改的三个方向是多门店、接真实支付、以及性能优化。多门店的核心是给所有接口加storeId参数本地 Room 的菜单表加storeId字段切换门店时清空购物车重新拉菜单。支付对接一般是接微信或支付宝的 SDK把原来的「模拟支付」按钮换成调起支付支付回调里再更新订单状态——注意回调可能重复状态更新要幂等。性能上菜单图片多的时候 RecyclerView 会卡我一般会做三件事Glide 加override(200,200)限制解码尺寸、RecyclerView.setHasFixedSize(true)、以及分页加载。订单列表用DiffUtil替代notifyDataSetChanged滑动明显顺滑。验证改造是否成功我习惯写一个简单的检查清单切门店后菜单是否变、购物车是否清空、下单后订单号是否带门店前缀、支付回调后状态是否只变一次。每次改完都跑一遍这个清单比事后查日志快得多。从那以后我每次拿到一套点餐源码都强制先跑通「扫码→加菜→下单→后厨出单」这条最小闭环再动任何一行代码。希望帮到你。本文还有配套的精品资源点击获取