简介面向安卓开发学习者的订餐系统完整Android Studio项目源码基于Material Design设计语言还原真实外卖点餐App的核心流程。从欢迎页、注册登录到底部三栏导航覆盖美食列表、详情页可折叠标题栏、购物车数量累加与长按删除、提交订单后下拉刷新以及个人中心侧滑菜单、订单管理和第三方分享等功能模块适合课程设计、毕业设计或入门实战练习。资源包共690个文件约30.69MB以flat编译资源、json配置、dex字节码、class文件、xml布局、java源码、png/jpg图片素材等为主附apk安装包结构基本完整可直接导入Android Studio查看运行。目前已有13187人学习下载。通过源码可重点理解Material Design控件运用、底部导航与Fragment架构、购物车数据交互和订单状态刷新等实现思路是快速上手安卓App开发的实用参考。 去年帮一个做餐饮管理的朋友搭了个内部点餐Demo顺手把整套实现思路整理了下来。这阵子总有人问“用Android Studio做订餐系统到底怎么做、要学哪些东西”干脆把当时的设计文档、代码结构和踩坑记录都翻出来写一篇能直接照着做的实操复盘。先说清楚这篇内容适合谁刚学完Android基础、想做完整项目练手的同学或者打算把校园外卖、食堂点餐、餐厅预约这类场景做成App的开发者。文中不会堆叠华丽架构全程围绕“一个人也能完成”的开发思路来讲核心技术点集中在Activity/Fragment、RecyclerView、SQLite、SharedPreferences以及几个常用的Material控件上。看完之后你应该能独立画出订餐系统的整体模块图并动手实现出一个包含用户登录、菜品分类、购物车、订单确认和本地存储的可用App。1. 项目整体设计与技术选型1.1 订餐系统的需求拆解做任何项目之前先把“用户到底要干嘛”这件事想透。订餐系统的使用场景很简单用户打开App浏览菜品选好后加入购物车最后生成订单。但这个简单链条背后隐藏着几个实际开发必须处理的问题。第一是用户身份。堂食点餐和外卖点餐都需要一个身份标识最简单的方式就是手机号加密码注册登录。做本地Demo阶段不用接短信验证码但登录态需要保持不然每次打开App都要重新登录体验很差。第二是菜品数据怎么来。绝大多数学生项目或个人Demo不会真的搭建后台服务器那么菜品信息、图片、价格就要提前预置在本地或者用一个极简JSON文件作为数据源。App启动时读入数据显示在列表里。第三是订单状态。用户加入购物车、确认下单后订单信息要能保存下来至少下次启动App时还能看到历史订单。这意味着必须引入本地数据库SQLite就是这个场景最直接的选择。按这个拆解路径核心模块就非常清晰了登录注册模块、菜品展示模块、购物车模块、订单确认模块、历史订单查询模块。再加上一个底部导航栏把主界面串联起来整个App骨架就出来了。1.2 技术栈选型与理由技术选型不必追新稳定、资料多、容易调试才是关键参考因素。界面层我采用经典的Activity Fragment组合。底部三个Tab分别对应菜单、购物车、我的通过BottomNavigationView切换Fragment。Fragment的好处是避免Activity跳转过程中重复重建列表数据购物车和菜单可以保留页面状态。列表展示用RecyclerView它是目前Android列表开发的事实标准配合ListAdapter或简单Adapter都行。订餐系统里菜品列表、购物车列表、订单列表全是列表形态RecyclerView一套代码可以复用三种场景。数据存储分两层结构化数据用SQLite用SQLiteOpenHelper管理轻量的登录状态、用户ID这类键值对用SharedPreferences。这样分工明确操作起来也简单。再强调一个关键点开发环境统一使用Android Studio版本不需要最新稳定版就行。很多人纠结API Level项目里我会把minSdk设为21覆盖Android 5.0以上绝大多数真机targetSdk设为33左右即可避免新版本权限模型引入不必要的复杂度。1.3 数据源设计要点既然没有后端那就把数据源做在前端。菜品数据我一开始试过直接写死在Java代码里但很快就发现维护困难——想调价、加菜、换图片都得改代码重新编译非常低效。更好的处理方式是把菜品数据放到assets目录下一个JSON文件。App启动时用JSONObject解析文件内容构建菜品对象列表。这样菜品信息与代码逻辑分离甚至可以做个本地管理页面通过文件写入方式维护菜品内容。图片资源方面Demo项目建议使用本地drawable资源配合一个imageRes字段挂在菜品对象上。如果想要更真实的体验也可以把图片文件放进assets/images目录通过BitmapFactory.decodeStream动态加载但要注意大图的内存压缩处理不然容易OOM内存溢出。提示订餐系统的数据层设计直接决定了后续功能扩展的难度。哪怕只是Demo也尽量把数据源和UI解耦这样加需求时不用动界面代码。2. 开发环境搭建与项目初始化2.1 Android Studio安装与中文配置很多初学者卡在第一步——Android Studio下载安装。这里梳理一遍完整路径。打开Android Studio官方网站下载对应系统安装包Windows建议选择exe安装包macOS选择dmg。安装过程中勾选Android SDK和Android Virtual Device组件其余保持默认即可。首次启动会提示下载组件网络状况较好的情况下几分钟就能完成。SDK Manager里建议安装API 33或API 34同时装一个系统镜像用于创建模拟器。模拟器性能不够或者启动卡顿的话直接使用真机调试连接USB并开启开发者选项即可。关于设置中文的问题。老版本的Android Studio没有官方中文界面新版本可以这样操作安装官方中文语言包插件进入Settings - Plugins搜索Chinese找到Chinese (Simplified) Language Pack后安装重启界面就变成中文了。不过我个人建议项目初期保持英文界面因为大多数技术博客、解决方案、报错信息都是英文上下文遇到问题时搜索资料会更顺手。2.2 项目创建与依赖配置打开Android Studio后选择New Project模板选Empty Views Activity或Empty Activity建议选择Views Activity便于手动控制布局不需要引入Compose。项目创建成功后第一件事是配置Gradle依赖。订餐系统用到的依赖清单如下dependencies { implementation androidx.constraintlayout:constraintlayout:2.1.4 implementation com.google.android.material:material:1.9.0 implementation androidx.recyclerview:recyclerview:1.3.0 implementation androidx.cardview:cardview:1.0.0 }这几个库分别是约束布局写复杂界面用、Material组件库底部导航、按钮、浮动操作按钮都靠它、RecyclerView列表控件和CardView卡片式布局装饰。同步Gradle时如果出现下载缓慢在build.gradleProject级别配置阿里云镜像仓库。这是国内开发者必须掌握的常规操作allprojects { repositories { maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } google() mavenCentral() } }2.3 manifest权限与主题设置Android 6.0以上动态权限机制需要特别留意。订餐系统如果只使用本地数据理论上不需要额外权限。但如果你计划让用户上传头像、或者做个简单的扫码点餐功能就需要在AndroidManifest.xml里声明相机或存储权限。uses-permission android:nameandroid.permission.CAMERA / uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE /同时检查主题设置。新的Material组件要求Activity继承Theme.MaterialComponents或Theme.Material3系列的父主题否则Material控件比如BottomNavigationView会渲染异常。建议直接在themes.xml里改成style nameTheme.OrderingApp parentTheme.Material3.DayNight.NoActionBar没有ActionBar是为了给沉浸式界面和自定义标题栏留空间。3. 核心功能模块的实现3.1 用户登录与注册模块用户模块的核心流程是未登录时App启动会先跳转登录页输入手机号和密码后校验本地SQLite中的user表注册时向user表插入新记录。数据表结构设计如下CREATE TABLE user ( id INTEGER PRIMARY KEY AUTOINCREMENT, phone TEXT UNIQUE NOT NULL, password TEXT NOT NULL, username TEXT, created_time TEXT DEFAULT (datetime(now, localtime)) );密码不能明文存储Demo阶段也不建议用过于复杂的加密方案。使用MD5加盐即可加个固定盐值如“order_app_2024”拼接密码后做哈希。虽然MD5强度不算顶级但用于本地Demo足以规避明文存储风险。登录成功后把用户id和手机号存入SharedPreferencesprefs getSharedPreferences(user_info, Context.MODE_PRIVATE); prefs.edit() .putInt(user_id, user.getId()) .putString(user_phone, user.getPhone()) .apply();MainActivity的onCreate里做登录态判断如果SharedPreferences里没有用户信息直接跳转LoginActivity并把MainActivity finish掉。这个思路简单但有效确保每次冷启动走一遍自动登录逻辑。注意在校验输入合法性时手机号用正则拦截密码最少6位。这些判断一定要在前端做一次避免非法数据污染数据库。3.2 菜品展示与分类浏览菜品展示是整个App出现频率最高的界面。我采用的布局结构是顶部一个横向滚动的分类Tab使用Material的ChipGroup下面一个RecyclerView网格样式。分类的数据结构非常关键。我定义了一个Dish类public class Dish { private int id; private String name; private double price; private String category; private String description; private int imageRes; // getters and setters }解析JSON时按category字段做筛选。分类Tab点击时只显示当前分类下的菜品。这里推荐在内存中维护一份全量List 每次切换分类时用一个新的List去创建Adapter避免频繁读文件。菜品卡片使用CardView包裹里面包含图片、菜名、价格和一个加号按钮。加号按钮会触发添加到购物车的逻辑。RecyclerView的Adapter里关键代码是addDishToCart的回调Override public void onBindViewHolder(ViewHolder holder, int position) { Dish dish dishList.get(position); holder.tvName.setText(dish.getName()); holder.tvPrice.setText(String.format(¥%.2f, dish.getPrice())); holder.ivImage.setImageResource(dish.getImageRes()); holder.btnAdd.setOnClickListener(v - { if (cartListener ! null) { cartListener.onAddToCart(dish); } }); }3.3 购物车与订单确认购物车的数据结构推荐用MapDish, Integer来保存key是菜品对象value是数量。如果直接创建CartItem类也行但Map在合并相同菜品时非常方便。public class CartManager { private MapDish, Integer cart new HashMap(); public void add(Dish dish) { cart.put(dish, cart.containsKey(dish) ? cart.get(dish) 1 : 1); } public void remove(Dish dish) { if (cart.containsKey(dish)) { int count cart.get(dish); if (count 1) cart.put(dish, count - 1); else cart.remove(dish); } } public double getTotalPrice() { double total 0; for (Map.EntryDish, Integer entry : cart.entrySet()) { total entry.getKey().getPrice() * entry.getValue(); } return total; } }购物车界面前面加了一个小功能长按条目弹出删除确认对话框。这个交互实际使用下来很顺手能够弥补“减号按钮只能一次减少一份”的操作痛点。确认订单页面展示购物车内容和总价再让用户填写用餐人数、备注信息。点击下单按钮后将订单数据写入SQLite的orders表并清空购物车。orders表结构CREATE TABLE orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, total_price REAL NOT NULL, remark TEXT, status INTEGER DEFAULT 0, create_time TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE order_item ( id INTEGER PRIMARY KEY AUTOINCREMENT, order_id INTEGER NOT NULL, dish_name TEXT NOT NULL, dish_price REAL NOT NULL, dish_count INTEGER NOT NULL );订单和订单详情拆成两表目的是未来如果要扩展“再来一单”功能直接拿订单详情去重放购物车即可不需要改表结构。提示下单事务要保证一致性——先插入orders表拿到自增id再批量插入order_item表。建议放在一个事务里执行避免数据中途写入失败造成脏数据。4. 本地持久化、状态管理与性能细节4.1 SQLite的合理使用与升级策略项目使用SQLiteOpenHelper管理数据库数据库版本设为1。如果后续要增加字段不能直接改创建语句而是要修改数据库版本号并实现onUpgrade方法Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE orders ADD COLUMN table_no TEXT); } }很多初学者在这里会踩坑——修改数据库结构后直接卸载重装测试数据全没了。正确的做法是保留旧表数据通过ALTER TABLE增加新列。另外建议用ContentValues而不是拼接SQL字符串插入数据一方面避免SQL注入另一方面减少字符串拼接的出错概率。4.2 SharedPreferences与登录态管理SharedPreferences在实际项目中不仅是保存登录态还可以缓存用户偏好比如“桌面显示大字体”“下单前默认勾选无需餐具”这类设置项。读取账号信息时要注意UserManager.getInstance().setCurrentUser( prefs.getInt(user_id, -1), prefs.getString(user_phone, ) );当用户注销时把SharedPreferences里的数据清掉并跳转登录页。还有一个容易被忽略的细节应用退到后台再回来时用户信息可能因内存回收而被清空。此时SharedPreferences里的数据仍在可以在MainActivity的onResume里重新读取一次保证页面状态稳定。4.3 图片加载与内存优化本地Demo如果菜品图片全部塞在drawable不同密度目录里可能会导致App体积膨胀。我的处理方式是只放一套图片资源在drawable-nodpi目录避免因屏幕密度不同多次打包。如果菜品图片数量超过30张建议使用Glide或Coil加载implementation com.github.bumptech.glide:glide:4.15.0Glide的优势不止是异步加载更重要的是它自带内存缓存、磁盘缓存、图片压缩有效避免RecyclerView快速滑动时OOM。只需替换一行代码Glide.with(holder.itemView.getContext()) .load(dish.getImageRes()) .centerCrop() .into(holder.ivImage);4.4 RecyclerView列表优化三件套订餐系统虽然数据量不大但列表卡顿会直接影响使用体验。我总结了三件套第一setHasFixedSize(true)在RecyclerView上设置。这样列表宽高固定时不会因为item变化触发重新测量布局。第二onCreateViewHolder里用标准ViewHolder模式不要每次绑定数据时findViewById。第三Adapter里使用List notifyDataSetChanged时要谨慎。如果只是修改了数量位置用notifyItemChanged(position)代替全量刷新避免整个列表重绘闪烁。5. 实操过程中的坑与处理方案5.1 调试时的常见问题速查我在开发过程中遇到了一批高频问题这里整理成速查表按出现频率排序问题现象常见原因解决思路模拟器启动后黑屏模拟器图形渲染模式与显卡不兼容切换到Software GLES渲染或改用真机BottomNavigationView不显示文字主题不是Material系列切换主题为Theme.Material3.DayNightRecyclerView白屏不显示数据忘记设置LayoutManager添加setLayoutManager(new GridLayoutManager(this, 2))图片资源过大导致卡顿原图直接加载使用Glide或压缩图片到合适分辨率SQLite打开报错no such table未执行onCreate或数据库未关闭确认SQLiteOpenHelper调用路径、版本号SharedPreferences读不到值使用了不同文件名实例统一getSharedPreferences的name参数5.2 踩过的几个设计坑第一个坑是Fragment之间传递数据。一开始我用EventBus处理“添加购物车后底部Badge更新”事件用起来确实方便但项目里事件多了之后很难追踪。后来改成在Activity中定义接口由Fragment调用Activity实现类更新UI代码定位更直观。建议你的Demo也走接口回调路线后续接MVVM时再考虑LiveData。第二个坑是下单后购物车清空逻辑。最开始我在CartFragment的“去结算”按钮里清空Map导致用户从确认订单页返回时购物车已经空了再点返回菜单发现选过的菜全没。正确做法是点击下单成功后才通知购物车清空确认订单页只负责读取数据不做修改。第三个坑是订单列表时间显示。SQLite的datetime函数返回的是UTC时间直接显示会差8小时。解决方式是保存时间戳数值或者用localtime修饰符也可以在显示层用SimpleDateFormat转换SimpleDateFormat input new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); SimpleDateFormat output new SimpleDateFormat(MM月dd日 HH:mm); Date date input.parse(order.getCreateTime()); order.setDisplayTime(output.format(date));5.3 性能优化与体验细节订餐系统想要从“能跑”升级到“好用”有四个细节值得下功夫。一是列表滚动流畅度。RecyclerView里的item布局层级越简单越好避免过度嵌套。比如菜品卡片我用ConstraintLayout实现一个根结点容纳图片、文本、按钮减少measure/layout耗时。二是购物车角标更新。BottomNavigationView的Badge可以实时显示购物车商品总件数核心代码如下BadgeDrawable badge bottomNav.getOrCreateBadge(R.id.navigation_cart); badge.setNumber(cartManager.getTotalCount()); badge.setVisible(cartManager.getTotalCount() 0);这个细节一加上整个App的交互感立刻不一样。三是输入法遮挡问题。确认订单页有备注输入框需要在AndroidManifest里给Activity设置windowSoftInputModeadjustResize否则输入法弹出时会遮挡底部按钮。四是空数据提示。购物车为空、订单列表为空时页面不能白茫茫一片。我习惯放一个ImageView加TextView的占位布局文案用“购物车还是空的去挑点好吃的吧”比直接空白友好得多。6. 项目扩展方向与后续提升思路订餐系统这个项目做完能跑通不代表就结束了。以现在的代码为基础扩展空间其实很大。第一个扩展方向是把数据源切换成真实后端。用Retrofit替换本地JSON解析把SQLite换成后端MySQL或PostgreSQL登录注册改用Token鉴权。这个升级对理解前后端协作非常有帮助。第二个方向是引入Jetpack组件。把ViewModel LiveData Room组合进来替换当前手动管理Fragment数据和SQLite的逻辑。Room比原生SQLiteHelper写起来更安全编译期就能检查SQL语句语法配合Flow做响应式更新整个架构会干净不少。第三个方向是添加更丰富业务功能比如菜品搜索通过SearchView过滤、下单后二维码取餐、订单状态推送本地模拟成“备餐中-已出餐”。这些都是真实场景中高频出现的能力每做一项都会对应一个新的技术点。第四个方向是改用Kotlin Jetpack Compose重写UI。Google现在对Kotlin和Compose的支持力度很大新项目基本都基于Compose构建。如果你已经熟悉了传统View体系用这个项目练手Compose重构是个绝佳机会两个UI体系的差异会在实际写代码过程中体会得非常深刻。提示扩展时不要在现有代码上打补丁式堆功能。先画模块图规划清楚接口边界再动手不然代码腐化速度会很快。最后再分享一点我的个人体会做完这个订餐系统我最大的感受是Android开发中真正花时间的不是某个单一技术点而是把零散功能串成完整产品的过程。登录、列表、购物车、订单、数据库每一个模块单独拿出来都不复杂但它们要在同一个App里协同工作事件通知、数据一致性、页面状态管理这些细节才是最磨人的地方。如果你正在做类似的项目希望这篇内容能帮你少走一些弯路。遇到具体问题卡壳的时候记住一条排查原则先把报错日志读完再谷歌最后才是问别人。绝大多数“奇怪问题”根源都是某个引用没配对、某个状态没更新、某个生命周期回调没考虑周到。多写几个项目这种直觉自然就来了。本文还有配套的精品资源点击获取