简介智能点餐系统毕业设计与课程作业源码包面向计算机相关专业学生用于学习餐饮信息化与人工智能在点餐场景中的应用覆盖用户界面、菜单管理、订单处理、支付集成、库存管理、数据分析、后台管理等核心模块。压缩包共259个文件以102个Java源码、81个XML配置、60个PNG界面图为主辅以Gradle构建脚本、属性配置及依赖库文件如universal-image-loader整体约1.73MB目录结构清晰便于按模块阅读和二次开发。目前已有109人学习下载。通过该源码可掌握Spring Boot或Android等技术的工程落地理解需求分析、数据库设计、API接口与前后端交互流程还包含构建配置和资源文件适合作为毕业设计参考或课程项目实战练手。其中的人工智能元素可帮助探索个性化推荐、智能预测或语音点餐等扩展方向对系统安全性与支付对接也有参考价值。1. 一份智能点餐系统工程里最容易被忽略的构建入口拿到这份智能点餐系统.zip解压后第一眼看到的往往不是 MainActivity而是一堆 build.gradle、settings.gradle、gradlew.bat 和 library-releasev1.0.aar 这类工程文件。很多同学会下意识地去找源码目录结果发现点餐界面和订单逻辑其实藏在了 aar 模块和 jar 依赖背后。这个 zip 实际上是一个完整的 Android 客户端工程既适合做毕业设计二次开发也适合用来理解“主工程 本地库”的协作方式。解压之后能跑通构建才算真正拿到了这套系统跑不通代码再多也只是摆设。下文就从这个 zip 的工程结构开始把点餐客户端的分层、数据流转、图片加载和构建排错一起拆开。2. 先从 zip 工程结构认识点餐客户端的分层2.1 解压后先分清 aar、jar 和 gradle 文件的作用用 7-Zip 打开这个 zip 包可以看到三类典型的工程单元。library-releasev1.0.aar是 Android Library 的发布包里面同时包含编译后的 class 文件和 res 资源universal-image-loader-1.9.5.jar是纯 Java 编写的图片加载库不包含 Android 资源而gradlew.bat、config.gradle、build.gradle则构成了 Gradle 构建入口和参数配置。在点餐客户端里aar 通常是业务模块的封装比如把订单数据模型、网络请求封装在一起主工程只需要引用它并负责 UI。常见的做法是把 aar 和 jar 都放到主模块的libs目录再在build.gradle里声明本地依赖// app/build.gradle android { compileSdkVersion 30 defaultConfig { applicationId com.example.smartorder minSdkVersion 21 targetSdkVersion 30 } } dependencies { implementation files(libs/library-releasev1.0.aar) implementation files(libs/universal-image-loader-1.9.5.jar) }这段配置里implementation files()声明的是相对模块目录的本地文件依赖。aar 和 jar 的区别很关键aar 会参与资源合并并且自带AndroidManifest.xml所以它里面的 Activity 可以直接在工程里引用jar 只是 class 文件如果它内部引用了 Android API就必须由主工程提供运行环境。如果直接把 aar 改名为 zip 解压再放进 libs反而会破坏依赖关系编译时容易出现 “Failed to resolve” 报错。另一种更稳妥的做法是在项目级build.gradle里用flatDir声明 aar 仓库然后按名称引用allprojects { repositories { google() mavenCentral() flatDir { dirs libs } } }对应的依赖声明变成implementation(name: library-releasev1.0, ext: aar)我一般倾向于用flatDir方式因为不需要写冗长的文件路径而且多个模块可以同时引用同一个 aar。需要注意flatDir会扫描所有模块的libs目录如果出现同名 aarGradle 会选择第一个找到的所以命名时要避免多个版本混放。2.2 点餐系统的状态核心菜单、购物车与订单状态机从一个客户端工程师的角度看智能点餐系统在本地需要维护三类核心状态菜品菜单、购物车聚合数据和订单状态。菜单是只读数据一般由后端接口下发购物车是本地临时聚合用户增减菜品时直接改内存订单状态则必须和后端保持同步否则会出现“已付款但界面还停在待支付”的问题。先看菜品类和购物车条目的数据定义public class Dish { int id; String name; String imageUrl; double price; int stock; int categoryId; } public class CartItem { Dish dish; int count; double getSubtotal() { return dish.price * count; } }订单状态建议用枚举而不是散落在代码里的 int 常量。这样写的好处是每次状态流转都只能传枚举对象不会传错数字public enum OrderStatus { CREATED(0), PAID(1), PROCESSING(2), COMPLETED(3), CANCELLED(4); private final int code; OrderStatus(int code) { this.code code; } public int getValue() { return code; } public static OrderStatus fromCode(int code) { for (OrderStatus status : values()) { if (status.code code) { return status; } } return CREATED; } }这里要注意枚举里的code必须与后端接口文档里的数字完全一致。如果后端返回的是字符串比如processing就应该在fromCode中增加字符串分支而不是让 API 层直接返回枚举。很多毕设项目在这一步用了魔法数字导致前后端联调时反复横跳。2.3 服务接口用 Retrofit 把数据模型和后端协议对上这个 zip 里面没有后端源码但点餐客户端必须通过 HTTP 接口与服务器交互。常见做法是使用 Retrofit 定义接口再配合 Gson 完成 JSON 序列化。假设后端提供三个接口获取菜单列表、提交订单、查询订单状态对应的 Service 可以这样定义public interface OrderApi { GET(menu) CallMenuResponse getMenu(); POST(order) CallOrderResponse createOrder(Body CreateOrderRequest request); GET(order/{id}) CallOrderStatusResponse getOrderStatus(Path(id) long orderId); }这段代码中GET和POST声明 HTTP 方法Body会把CreateOrderRequest对象序列化成 JSON 放进请求体Path(id)则替换 URL 中的{id}占位符。为了让 Retrofit 能把返回的 JSON 变成对象还需要在 Gradle 里加上转换器implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0如果是毕设演示直接用Call.enqueue异步请求就够了不需要引入 RxJava 或协程。需要注意图片字段后端返回的imageUrl可能是相对路径比如/upload/dish_001.jpg。Universal Image Loader 拿到这个地址后拼接了错误的 baseUrl会直接导致图片加载不出。正确的做法是在数据解析层补全if (!dish.imageUrl.startsWith(http)) { dish.imageUrl BASE_URL dish.imageUrl; }这一步漏掉是图片列表白屏最常见的根源比 Glide 和 Universal Image Loader 的选型问题更值得先排查。3. 用 Universal Image Loader 和 RecyclerView 把点餐主流程跑起来3.1 图片加载Universal Image Loader 的配置与边界Universal Image Loader 1.9.5 是一个很稳的图片加载库虽然维护不再活跃但在教学和毕设工程里仍然够用。它需要你在Application或第一个页面里初始化一次全局配置ImageLoaderConfiguration config new ImageLoaderConfiguration.Builder(this) .threadPriority(Thread.NORM_PRIORITY - 2) .denyCacheImageMultipleSizesInMemory() .memoryCacheSize(2 * 1024 * 1024) .diskCacheSize(50 * 1024 * 1024) .diskCacheFileNameGenerator(new Md5FileNameGenerator()) .tasksProcessingOrder(QueueProcessingType.LIFO) .writeDebugLogs(false) .build(); ImageLoader.getInstance().init(config);这里需要解释几个参数threadPriority设置加载线程优先级避免图片加载抢占主线程memoryCacheSize是内存缓存上限太小会频繁回收太大容易 OOMdiskCacheFileNameGenerator用 MD5 重命名磁盘缓存文件否则远端图片 URL 长度超限时会报文件系统路径过长错误。writeDebugLogs(false)建议在正式演示时关闭不然 logcat 会被图片加载日志刷屏。在RecyclerView.Adapter里绑定菜品图片的常见写法是Override public void onBindViewHolder(NonNull ViewHolder holder, int position) { Dish dish list.get(position); holder.nameView.setText(dish.name); holder.priceView.setText(¥ dish.price); ImageLoader.getInstance().displayImage(dish.imageUrl, holder.imageView, new DisplayImageOptions.Builder() .showImageOnLoading(R.drawable.ic_placeholder) .showImageForEmptyUri(R.drawable.ic_empty) .showImageOnFail(R.drawable.ic_error) .cacheInMemory(true) .cacheOnDisk(true) .build()); }displayImage的第三个参数是DisplayImageOptions这里设置了三种占位图避免网络慢时列表出现空白。cacheInMemory(true)和cacheOnDisk(true)分别开启内存和磁盘缓存滚动时不会再重新发起网络请求。注意showImageOnFail很有必要因为厨房图片经常因为权限或路径问题加载失败。3.2 购物车库存校验与价格计算购物车模块最容易翻车的是库存边界。用户点击“加购”时不能只把数量加一还要判断当前数量是否超过Dish.stock。一般会在点击事件里做同步校验public boolean addToCart(Dish dish, MapInteger, CartItem cart) { CartItem item cart.get(dish.id); int currentCount (item null) ? 0 : item.count; if (currentCount dish.stock) { return false; } if (item null) { item new CartItem(dish, 0); cart.put(dish.id, item); } item.count; return true; }这段代码用MapInteger, CartItem以菜品 id 作为键保证同一个菜品在购物车里只有一条记录。返回值为false时UI 层弹 Toast 提示“库存不足”同时把加号按钮置灰。价格计算不要在 UI 循环里累加应该单独写一个方法public double calcTotal(MapInteger, CartItem cart) { double totalPrice 0; for (CartItem item : cart.values()) { totalPrice item.getSubtotal(); } return totalPrice; }需要注意的是如果后端接口要求金额以分为单位这个totalPrice还要乘以 100 后转成整数否则会出现小数点精度丢失。很多订单金额对不上的问题不是计算逻辑错而是单位转换不一致。3.3 下单订单状态迁移的代码实现用户点击“提交订单”后客户端要做的事不是直接杀到支付页而是先同步创建一个本地订单把状态设为CREATED然后调用后端接口。这样即使网络失败也能保留用户的操作意图。代码结构大致如下private void submitOrder(CreateOrderRequest request) { orderIdLocal System.currentTimeMillis(); currentStatus OrderStatus.CREATED; orderApi.createOrder(request).enqueue(new CallbackOrderResponse() { Override public void onResponse(CallOrderResponse call, ResponseOrderResponse response) { if (response.isSuccessful()) { currentStatus OrderStatus.PAID; refreshOrderStatusView(); } else { showError(下单失败 response.code()); } } Override public void onFailure(CallOrderResponse call, Throwable t) { showError(网络异常 t.getMessage()); } }); }这里把PAID状态直接放在onResponse中属于简化写法。真实场景中支付回调会从服务端推送或轮询得到客户端不应自行将CREATED改成PAID否则服务端还没确认支付界面却已经显示已支付。毕设演示可以选择轮询private void pollOrderStatus(long orderId) { orderApi.getOrderStatus(orderId).enqueue(new CallbackOrderStatusResponse() { Override public void onResponse(CallOrderStatusResponse call, ResponseOrderStatusResponse response) { OrderStatus newStatus OrderStatus.fromCode(response.body().status); if (newStatus ! currentStatus) { currentStatus newStatus; updateStatusBadge(); } } }); }然后配合一个Handler每 5 秒调用一次。这样做的好处是后端处理时间不可控时客户端能稳定收敛到真实状态。4. gradlew.bat 构建与联调排错从 zip 解压到真机运行4.1 config.gradle 里的构建参数config.gradle通常用来抽离统一版本号避免每个模块各写一份。打开这个文件后你可能会看到类似这样的内容ext { compileSdkVersion 30 buildToolsVersion 30.0.3 minSdkVersion 21 targetSdkVersion 30 appVersionCode 1 appVersionName 1.0.0 }然后在项目根build.gradle里通过apply from: config.gradle加载各模块再引用rootProject.ext.compileSdkVersion。这种做法的好处是当你切换 targetSdk 或 minSdk 时只需要改一个文件。对点餐客户端来说minSdkVersion尤其重要如果设为 23那在 Android 6.0 以下旧机型上安装应用会直接失败。4.2 常见构建错误与解决办法解压 zip 后直接跑gradlew.bat assembleDebug常见的报错和解决路径可以先用一张表列出来错误现象可能原因处理方式error read zip archive或invalid zip archive: could not find eocdaar 或 jar 文件下载不完整被杀毒软件拦截重新解压原始 zip确认 libs 下的 aar 大小与压缩包内一致不要在解压过程中强制中断Could not find library-releasev1.0.aar依赖声明路径不对或flatDir没有覆盖该模块改用implementation files(libs/...)的绝对相对路径检查settings.gradle里的includeFailed to resolve: com.android.support:appcompat-v7Gradle 仓库版本和 SDK 版本不匹配在allprojects.repositories里补全google()和mavenCentral()不要只留jcenter()AAPT2 error: file failed to compileaar 内部资源引用冲突检查主工程是否也引用了同名的 res 文件Task assembleDebug not found当前目录不是 Gradle 根工程确认settings.gradle在解压后的最外层目录而不是子模块目录这里特别提一下error read zip archive。这个报错经常出现在从浏览器下载 zip 后直接解压的场景Windows 下如果用了系统自带解压后再复制到另一台机器很容易出现 EOCD 头丢失。我一般会用 7-Zip 打开原始压缩包先测试压缩包是否完整再解压到纯英文路径下。中文路径叠加 Gradle 时有些版本会读取异常。4.3 真机联调的验证流程构建通过后用数据线连接 Android 手机开启开发者模式下的 USB 调试然后执行gradlew.bat installDebug adb shell am start -n com.example.smartorder/.MainActivity如果应用启动后白屏第一件事不是看代码而是看 logcatadb logcat -s AndroidRuntime:E ImageLoader:EAndroidRuntime:E过滤崩溃异常ImageLoader:E只看图片加载错误。截图记录下日志里第一个非空错误通常指向资源找不到或空指针。联调时还要记住一点Android 模拟器里访问宿主机后端localhost要改成10.0.2.2否则网络请求全部超时。真机则必须使用电脑在同一局域网下的 IP 地址并在security_config.xml里允许 HTTP 明文流量否则 Android 9 以上直接拒绝明文请求。5. 把毕设改成能演示的 MVP离线菜单缓存与订单模拟模式毕设答辩最怕现场网络不稳定后端服务一挂点餐界面全空白。这里分享一个低成本方案把菜单缓存到本地后端不可用时自动切换模拟模式。先在Application启动时读取本地缓存用 Gson 把MenuResponse序列化成字符串写入SharedPreferencespublic void cacheMenu(MenuResponse menu) { String json gson.toJson(menu); prefs.edit().putString(cached_menu, json).apply(); } public MenuResponse readCachedMenu() { String json prefs.getString(cached_menu, null); if (json null) return null; return gson.fromJson(json, MenuResponse.class); }网络请求失败时直接降级到缓存菜单orderApi.getMenu().enqueue(new CallbackMenuResponse() { Override public void onResponse(...) { if (response.isSuccessful()) { MenuResponse menu response.body(); cacheMenu(menu); showDishList(menu); } else { showOfflineMenu(); } } Override public void onFailure(...) { showOfflineMenu(); } });showOfflineMenu()里再套一层判断如果缓存为空就从 assets 目录读一份预置的menu_demo.json。这个 JSON 可以提前从后端接口导出这样评审现场即使断网也能完整演示菜单浏览和加购流程。订单模拟模式同理做一个MockOrderApi在无网络时直接让订单状态在CREATED → PAID → PROCESSING → COMPLETED之间每 3 秒自动跳转一遍。校验的方法是在“订单详情”页面加一个 Debug 开关双击页面标题切换真实/模拟模式切换后看日志输出switch to mock order mode。答辩前连续 20 次模拟下单不崩溃再把writeDebugLogs关掉这个项目就有足够说服力了。本文还有配套的精品资源点击获取 智能点餐系统Android客户端构建与开发实战
简介智能点餐系统毕业设计与课程作业源码包面向计算机相关专业学生用于学习餐饮信息化与人工智能在点餐场景中的应用覆盖用户界面、菜单管理、订单处理、支付集成、库存管理、数据分析、后台管理等核心模块。压缩包共259个文件以102个Java源码、81个XML配置、60个PNG界面图为主辅以Gradle构建脚本、属性配置及依赖库文件如universal-image-loader整体约1.73MB目录结构清晰便于按模块阅读和二次开发。目前已有109人学习下载。通过该源码可掌握Spring Boot或Android等技术的工程落地理解需求分析、数据库设计、API接口与前后端交互流程还包含构建配置和资源文件适合作为毕业设计参考或课程项目实战练手。其中的人工智能元素可帮助探索个性化推荐、智能预测或语音点餐等扩展方向对系统安全性与支付对接也有参考价值。1. 一份智能点餐系统工程里最容易被忽略的构建入口拿到这份智能点餐系统.zip解压后第一眼看到的往往不是 MainActivity而是一堆 build.gradle、settings.gradle、gradlew.bat 和 library-releasev1.0.aar 这类工程文件。很多同学会下意识地去找源码目录结果发现点餐界面和订单逻辑其实藏在了 aar 模块和 jar 依赖背后。这个 zip 实际上是一个完整的 Android 客户端工程既适合做毕业设计二次开发也适合用来理解“主工程 本地库”的协作方式。解压之后能跑通构建才算真正拿到了这套系统跑不通代码再多也只是摆设。下文就从这个 zip 的工程结构开始把点餐客户端的分层、数据流转、图片加载和构建排错一起拆开。2. 先从 zip 工程结构认识点餐客户端的分层2.1 解压后先分清 aar、jar 和 gradle 文件的作用用 7-Zip 打开这个 zip 包可以看到三类典型的工程单元。library-releasev1.0.aar是 Android Library 的发布包里面同时包含编译后的 class 文件和 res 资源universal-image-loader-1.9.5.jar是纯 Java 编写的图片加载库不包含 Android 资源而gradlew.bat、config.gradle、build.gradle则构成了 Gradle 构建入口和参数配置。在点餐客户端里aar 通常是业务模块的封装比如把订单数据模型、网络请求封装在一起主工程只需要引用它并负责 UI。常见的做法是把 aar 和 jar 都放到主模块的libs目录再在build.gradle里声明本地依赖// app/build.gradle android { compileSdkVersion 30 defaultConfig { applicationId com.example.smartorder minSdkVersion 21 targetSdkVersion 30 } } dependencies { implementation files(libs/library-releasev1.0.aar) implementation files(libs/universal-image-loader-1.9.5.jar) }这段配置里implementation files()声明的是相对模块目录的本地文件依赖。aar 和 jar 的区别很关键aar 会参与资源合并并且自带AndroidManifest.xml所以它里面的 Activity 可以直接在工程里引用jar 只是 class 文件如果它内部引用了 Android API就必须由主工程提供运行环境。如果直接把 aar 改名为 zip 解压再放进 libs反而会破坏依赖关系编译时容易出现 “Failed to resolve” 报错。另一种更稳妥的做法是在项目级build.gradle里用flatDir声明 aar 仓库然后按名称引用allprojects { repositories { google() mavenCentral() flatDir { dirs libs } } }对应的依赖声明变成implementation(name: library-releasev1.0, ext: aar)我一般倾向于用flatDir方式因为不需要写冗长的文件路径而且多个模块可以同时引用同一个 aar。需要注意flatDir会扫描所有模块的libs目录如果出现同名 aarGradle 会选择第一个找到的所以命名时要避免多个版本混放。2.2 点餐系统的状态核心菜单、购物车与订单状态机从一个客户端工程师的角度看智能点餐系统在本地需要维护三类核心状态菜品菜单、购物车聚合数据和订单状态。菜单是只读数据一般由后端接口下发购物车是本地临时聚合用户增减菜品时直接改内存订单状态则必须和后端保持同步否则会出现“已付款但界面还停在待支付”的问题。先看菜品类和购物车条目的数据定义public class Dish { int id; String name; String imageUrl; double price; int stock; int categoryId; } public class CartItem { Dish dish; int count; double getSubtotal() { return dish.price * count; } }订单状态建议用枚举而不是散落在代码里的 int 常量。这样写的好处是每次状态流转都只能传枚举对象不会传错数字public enum OrderStatus { CREATED(0), PAID(1), PROCESSING(2), COMPLETED(3), CANCELLED(4); private final int code; OrderStatus(int code) { this.code code; } public int getValue() { return code; } public static OrderStatus fromCode(int code) { for (OrderStatus status : values()) { if (status.code code) { return status; } } return CREATED; } }这里要注意枚举里的code必须与后端接口文档里的数字完全一致。如果后端返回的是字符串比如processing就应该在fromCode中增加字符串分支而不是让 API 层直接返回枚举。很多毕设项目在这一步用了魔法数字导致前后端联调时反复横跳。2.3 服务接口用 Retrofit 把数据模型和后端协议对上这个 zip 里面没有后端源码但点餐客户端必须通过 HTTP 接口与服务器交互。常见做法是使用 Retrofit 定义接口再配合 Gson 完成 JSON 序列化。假设后端提供三个接口获取菜单列表、提交订单、查询订单状态对应的 Service 可以这样定义public interface OrderApi { GET(menu) CallMenuResponse getMenu(); POST(order) CallOrderResponse createOrder(Body CreateOrderRequest request); GET(order/{id}) CallOrderStatusResponse getOrderStatus(Path(id) long orderId); }这段代码中GET和POST声明 HTTP 方法Body会把CreateOrderRequest对象序列化成 JSON 放进请求体Path(id)则替换 URL 中的{id}占位符。为了让 Retrofit 能把返回的 JSON 变成对象还需要在 Gradle 里加上转换器implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0如果是毕设演示直接用Call.enqueue异步请求就够了不需要引入 RxJava 或协程。需要注意图片字段后端返回的imageUrl可能是相对路径比如/upload/dish_001.jpg。Universal Image Loader 拿到这个地址后拼接了错误的 baseUrl会直接导致图片加载不出。正确的做法是在数据解析层补全if (!dish.imageUrl.startsWith(http)) { dish.imageUrl BASE_URL dish.imageUrl; }这一步漏掉是图片列表白屏最常见的根源比 Glide 和 Universal Image Loader 的选型问题更值得先排查。3. 用 Universal Image Loader 和 RecyclerView 把点餐主流程跑起来3.1 图片加载Universal Image Loader 的配置与边界Universal Image Loader 1.9.5 是一个很稳的图片加载库虽然维护不再活跃但在教学和毕设工程里仍然够用。它需要你在Application或第一个页面里初始化一次全局配置ImageLoaderConfiguration config new ImageLoaderConfiguration.Builder(this) .threadPriority(Thread.NORM_PRIORITY - 2) .denyCacheImageMultipleSizesInMemory() .memoryCacheSize(2 * 1024 * 1024) .diskCacheSize(50 * 1024 * 1024) .diskCacheFileNameGenerator(new Md5FileNameGenerator()) .tasksProcessingOrder(QueueProcessingType.LIFO) .writeDebugLogs(false) .build(); ImageLoader.getInstance().init(config);这里需要解释几个参数threadPriority设置加载线程优先级避免图片加载抢占主线程memoryCacheSize是内存缓存上限太小会频繁回收太大容易 OOMdiskCacheFileNameGenerator用 MD5 重命名磁盘缓存文件否则远端图片 URL 长度超限时会报文件系统路径过长错误。writeDebugLogs(false)建议在正式演示时关闭不然 logcat 会被图片加载日志刷屏。在RecyclerView.Adapter里绑定菜品图片的常见写法是Override public void onBindViewHolder(NonNull ViewHolder holder, int position) { Dish dish list.get(position); holder.nameView.setText(dish.name); holder.priceView.setText(¥ dish.price); ImageLoader.getInstance().displayImage(dish.imageUrl, holder.imageView, new DisplayImageOptions.Builder() .showImageOnLoading(R.drawable.ic_placeholder) .showImageForEmptyUri(R.drawable.ic_empty) .showImageOnFail(R.drawable.ic_error) .cacheInMemory(true) .cacheOnDisk(true) .build()); }displayImage的第三个参数是DisplayImageOptions这里设置了三种占位图避免网络慢时列表出现空白。cacheInMemory(true)和cacheOnDisk(true)分别开启内存和磁盘缓存滚动时不会再重新发起网络请求。注意showImageOnFail很有必要因为厨房图片经常因为权限或路径问题加载失败。3.2 购物车库存校验与价格计算购物车模块最容易翻车的是库存边界。用户点击“加购”时不能只把数量加一还要判断当前数量是否超过Dish.stock。一般会在点击事件里做同步校验public boolean addToCart(Dish dish, MapInteger, CartItem cart) { CartItem item cart.get(dish.id); int currentCount (item null) ? 0 : item.count; if (currentCount dish.stock) { return false; } if (item null) { item new CartItem(dish, 0); cart.put(dish.id, item); } item.count; return true; }这段代码用MapInteger, CartItem以菜品 id 作为键保证同一个菜品在购物车里只有一条记录。返回值为false时UI 层弹 Toast 提示“库存不足”同时把加号按钮置灰。价格计算不要在 UI 循环里累加应该单独写一个方法public double calcTotal(MapInteger, CartItem cart) { double totalPrice 0; for (CartItem item : cart.values()) { totalPrice item.getSubtotal(); } return totalPrice; }需要注意的是如果后端接口要求金额以分为单位这个totalPrice还要乘以 100 后转成整数否则会出现小数点精度丢失。很多订单金额对不上的问题不是计算逻辑错而是单位转换不一致。3.3 下单订单状态迁移的代码实现用户点击“提交订单”后客户端要做的事不是直接杀到支付页而是先同步创建一个本地订单把状态设为CREATED然后调用后端接口。这样即使网络失败也能保留用户的操作意图。代码结构大致如下private void submitOrder(CreateOrderRequest request) { orderIdLocal System.currentTimeMillis(); currentStatus OrderStatus.CREATED; orderApi.createOrder(request).enqueue(new CallbackOrderResponse() { Override public void onResponse(CallOrderResponse call, ResponseOrderResponse response) { if (response.isSuccessful()) { currentStatus OrderStatus.PAID; refreshOrderStatusView(); } else { showError(下单失败 response.code()); } } Override public void onFailure(CallOrderResponse call, Throwable t) { showError(网络异常 t.getMessage()); } }); }这里把PAID状态直接放在onResponse中属于简化写法。真实场景中支付回调会从服务端推送或轮询得到客户端不应自行将CREATED改成PAID否则服务端还没确认支付界面却已经显示已支付。毕设演示可以选择轮询private void pollOrderStatus(long orderId) { orderApi.getOrderStatus(orderId).enqueue(new CallbackOrderStatusResponse() { Override public void onResponse(CallOrderStatusResponse call, ResponseOrderStatusResponse response) { OrderStatus newStatus OrderStatus.fromCode(response.body().status); if (newStatus ! currentStatus) { currentStatus newStatus; updateStatusBadge(); } } }); }然后配合一个Handler每 5 秒调用一次。这样做的好处是后端处理时间不可控时客户端能稳定收敛到真实状态。4. gradlew.bat 构建与联调排错从 zip 解压到真机运行4.1 config.gradle 里的构建参数config.gradle通常用来抽离统一版本号避免每个模块各写一份。打开这个文件后你可能会看到类似这样的内容ext { compileSdkVersion 30 buildToolsVersion 30.0.3 minSdkVersion 21 targetSdkVersion 30 appVersionCode 1 appVersionName 1.0.0 }然后在项目根build.gradle里通过apply from: config.gradle加载各模块再引用rootProject.ext.compileSdkVersion。这种做法的好处是当你切换 targetSdk 或 minSdk 时只需要改一个文件。对点餐客户端来说minSdkVersion尤其重要如果设为 23那在 Android 6.0 以下旧机型上安装应用会直接失败。4.2 常见构建错误与解决办法解压 zip 后直接跑gradlew.bat assembleDebug常见的报错和解决路径可以先用一张表列出来错误现象可能原因处理方式error read zip archive或invalid zip archive: could not find eocdaar 或 jar 文件下载不完整被杀毒软件拦截重新解压原始 zip确认 libs 下的 aar 大小与压缩包内一致不要在解压过程中强制中断Could not find library-releasev1.0.aar依赖声明路径不对或flatDir没有覆盖该模块改用implementation files(libs/...)的绝对相对路径检查settings.gradle里的includeFailed to resolve: com.android.support:appcompat-v7Gradle 仓库版本和 SDK 版本不匹配在allprojects.repositories里补全google()和mavenCentral()不要只留jcenter()AAPT2 error: file failed to compileaar 内部资源引用冲突检查主工程是否也引用了同名的 res 文件Task assembleDebug not found当前目录不是 Gradle 根工程确认settings.gradle在解压后的最外层目录而不是子模块目录这里特别提一下error read zip archive。这个报错经常出现在从浏览器下载 zip 后直接解压的场景Windows 下如果用了系统自带解压后再复制到另一台机器很容易出现 EOCD 头丢失。我一般会用 7-Zip 打开原始压缩包先测试压缩包是否完整再解压到纯英文路径下。中文路径叠加 Gradle 时有些版本会读取异常。4.3 真机联调的验证流程构建通过后用数据线连接 Android 手机开启开发者模式下的 USB 调试然后执行gradlew.bat installDebug adb shell am start -n com.example.smartorder/.MainActivity如果应用启动后白屏第一件事不是看代码而是看 logcatadb logcat -s AndroidRuntime:E ImageLoader:EAndroidRuntime:E过滤崩溃异常ImageLoader:E只看图片加载错误。截图记录下日志里第一个非空错误通常指向资源找不到或空指针。联调时还要记住一点Android 模拟器里访问宿主机后端localhost要改成10.0.2.2否则网络请求全部超时。真机则必须使用电脑在同一局域网下的 IP 地址并在security_config.xml里允许 HTTP 明文流量否则 Android 9 以上直接拒绝明文请求。5. 把毕设改成能演示的 MVP离线菜单缓存与订单模拟模式毕设答辩最怕现场网络不稳定后端服务一挂点餐界面全空白。这里分享一个低成本方案把菜单缓存到本地后端不可用时自动切换模拟模式。先在Application启动时读取本地缓存用 Gson 把MenuResponse序列化成字符串写入SharedPreferencespublic void cacheMenu(MenuResponse menu) { String json gson.toJson(menu); prefs.edit().putString(cached_menu, json).apply(); } public MenuResponse readCachedMenu() { String json prefs.getString(cached_menu, null); if (json null) return null; return gson.fromJson(json, MenuResponse.class); }网络请求失败时直接降级到缓存菜单orderApi.getMenu().enqueue(new CallbackMenuResponse() { Override public void onResponse(...) { if (response.isSuccessful()) { MenuResponse menu response.body(); cacheMenu(menu); showDishList(menu); } else { showOfflineMenu(); } } Override public void onFailure(...) { showOfflineMenu(); } });showOfflineMenu()里再套一层判断如果缓存为空就从 assets 目录读一份预置的menu_demo.json。这个 JSON 可以提前从后端接口导出这样评审现场即使断网也能完整演示菜单浏览和加购流程。订单模拟模式同理做一个MockOrderApi在无网络时直接让订单状态在CREATED → PAID → PROCESSING → COMPLETED之间每 3 秒自动跳转一遍。校验的方法是在“订单详情”页面加一个 Debug 开关双击页面标题切换真实/模拟模式切换后看日志输出switch to mock order mode。答辩前连续 20 次模拟下单不崩溃再把writeDebugLogs关掉这个项目就有足够说服力了。本文还有配套的精品资源点击获取