企业官网建设流程全解析

简介：面向计算机专业毕业设计及Android开发学习者，这份基于Android Studio的校园快递代拿跑腿App源码案例，完整呈现了从需求分析到前后端联调的实现过程，适合用来参考选题、搭建项目框架或进行二次开发。压缩包共52个文件，以Vue页面组件和JavaScript逻辑代码为主，辅以MySQL建表SQL脚本、CSS样式、JSON配置及项目说明文档，整体仅540KB，结构轻量紧凑。目前已有116人浏览学习，具备一定参考热度。案例覆盖MVP/MVVM架构、Activity与Fragment界面组织、Retrofit/OkHttp网络请求、MySQL数据库设计、权限配置与消息推送等关键知识点，并附带清晰的目录层级和数据库脚本，可帮助使用者快速理解校园代取场景下的订单流转、用户认证与数据表关联，是一份实践性强、易于上手的毕业设计参考资料。

1. 校园快递代拿跑腿App：一个能直接跑起来的Android Studio毕业设计源码

校园快递代拿跑腿App是Android Studio毕业设计里的常青树选题——论技术难度不高不低，但胜在模块多、链路长，答辩现场演示起来非常直观。这份zip源码解决的是很实际的问题：快递到驿站了但你人在教学楼，发布一个代取订单，跑腿员接单、取件、送到楼下，双方在App内完成整个闭环，不用你去写后端接口，用户端、跑腿端、管理端三套界面加一份能用的SQLite数据库都给你备齐了。适合三类人：选了类似题目的计算机、软件工程专业毕业生，急需一份能演示、能答辩的完整工程；想把框架改造成代拿外卖、代排队等其他跑腿场景的同学；以及第一次接触Android Studio项目、需要一个可运行参考对象的初学者。不必担心后端基础薄弱，核心链路都在App内部闭环，这份源码的边界和坑我都帮你趟过了。

2. 功能拆解与角色设计：先看懂模块再动手改代码

拿到源码先别急着导入，花十分钟把角色和表结构搞清楚，后面改起代码会顺很多。这个项目的本质是一个三端合一的单App应用，登录后按角色走不同的主界面，而不是拆成三个独立安装包。

2.1 三个角色一张订单表：用户端、跑腿端与管理端的边界

用户端承担的动作是发布代取订单、查看自己发过的订单列表、确认跑腿员送达并完成支付动作。跑腿端承担的动作是浏览待接单列表、抢单、更新订单状态到已送达。管理端则是查看全部用户和全部订单，偶尔做一下状态修正。三者的关系不是靠三个表，而是靠用户表里的role字段和订单表里的publisher_id、taker_id来维系的。

用户表的结构通常长这样：

CREATE TABLE tb_user ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE, password TEXT NOT NULL, role INTEGER DEFAULT 0, -- 0普通用户 1跑腿员 2管理员 phone TEXT, create_time TEXT DEFAULT (datetime('now','localtime')) );

这里role字段是整套权限判断的源头。登录时查出这个值，跳转到不同的Activity；后续每个界面的按钮是否可见、能否操作，也都要跟它比对。常见做法是把当前登录用户的role值存在SharedPreferences里，每次进入Activity时读出来判断，而不是重新查数据库。

订单表是另一个核心，我一般建议拿到源码先看这张表的建表语句，因为订单状态字段直接决定整个App的交互逻辑：

CREATE TABLE tb_order ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, pickup_location TEXT NOT NULL, -- 取件地址，比如菜鸟驿站 deliver_location TEXT NOT NULL, -- 送件地址，比如12号楼 reward REAL DEFAULT 0, -- 跑腿赏金 status INTEGER DEFAULT 0, -- 0待接单 1已接单 2已送达 3已完成 4已取消 publisher_id INTEGER NOT NULL, -- 发单人id taker_id INTEGER DEFAULT 0, -- 接单人id，0表示还没人接 create_time TEXT DEFAULT (datetime('now','localtime')) );

如果你发现源码里的字段比这多——比如加了order_no编号、备注remark、商品类型type——那是原作者根据自己答辩报告扩展的，不影响阅读。核心记住publisher_id、taker_id、status三个字段就够了，改功能时九成都在动它们。

2.2 订单状态机：从“待接单”到“已完成”的流转

跑腿App的交互本质就是一条状态链在驱动。状态机的完整流转路径是：发布者创建订单后status=0；跑腿员抢单成功status=1并写入自己的id到taker_id；跑腿员把快递送到楼下后status=2；发布者确认收货并点击完成status=3；中途发布者反悔则status=4。

状态机里最容易翻车的就是“任何人都有可能改状态”，所以源码里每个更新操作必须同时校验操作者身份和当前状态。我之前看到有些版本会犯一个经典错误——跑腿员接单后，发单人还能取消订单，甚至会直接删掉订单记录，导致跑腿员端列表空指针崩溃。正确做法是取消操作只在status=0时放行，接单之后要取消必须走管理端介入。

另一个要注意的细节是status=2到status=3之间，要不要做“赏金转账”动作。很多毕设偷懒，直接把确认完成等同于支付完成，没有钱包表。如果你想让答辩多一点亮点，可以考虑加一张tb_wallet表，让发布者确认时扣款、跑腿员收到入账记录，这个我在第六章会说怎么加。

2.3 源码目录结构：从java包到res资源的映射

理解了数据模型再来看工程结构，就会清晰很多。打开app/src/main/java，包结构一般是按职责分层：

app/src/main/java/com/example/express/ ├── activity/ // 所有界面类：LoginActivity、MainActivity、PublishActivity、OrderDetailActivity ├── adapter/ // RecyclerView适配器：OrderAdapter、UserAdapter ├── db/ // DBHelper数据库帮助类、UserDao、OrderDao ├── model/ // 实体类：User、Order ├── utils/ // MD5Utils加密工具、ToastUtils提示工具 └── base/ // BaseActivity，封装了SharedPreferences读取和角色判断

对应的资源目录app/src/main/res/layout/里，activity_login.xml是登录页、activity_main.xml是主页容器、item_order.xml是订单列表的单行卡片。改界面样式认准layout目录，改文案和配色认准values目录下的strings.xml和colors.xml。

我现在拿到一份源码的习惯是：先打开AndroidManifest.xml看注册了哪些Activity，再看base包里的角色判断逻辑，最后用SQLite可视化工具打开数据库文件过一遍表结构。这套流程走完，整个项目等于已经跑了一遍脑内模拟，后面改代码就不会迷路。

3. 把zip变成能跑的工程：Android Studio导入与Gradle配置

源码到手第一件事就是让它跑起来。这个阶段新手最容易在环境配置上消耗大量时间，而这本来是最不需要动脑的环节。

3.1 版本匹配：Gradle、JDK与SDK的三方关系

Android Studio项目能编译过，本质是Gradle版本、JDK版本、SDK版本三者匹配的结果。拿到源码先看三个文件：

gradle/wrapper/gradle-wrapper.properties里的distributionUrl决定了Gradle版本；根目录build.gradle里的com.android.tools.build:gradle版本是AGP插件版本；app/build.gradle里的compileSdk、minSdk、targetSdk是SDK版本。

常见组合我列在下面：

这份源码如果是前两年做的，大概率停在AGP 7.x和Gradle 7.x。如果你的Android Studio是2023年之后的版本，打开旧工程时IDE会提示升级AGP，我建议不要急着点升级——升级到AGP 8.x之后，很多旧代码的依赖写法要跟着改，不熟悉的同学会陷入连环编译错误。宁可让它停留在原版本，只要能sync通过就行。

3.2 导入步骤：从Open到Build Success

第一次导入建议完整走一遍下面几步：

1. 先把zip解压到纯英文路径，比如D:\Projects\ExpressApp。路径里有中文的话，Gradle有些任务会报诡异错误。
2. 打开Android Studio，点File → Open，选中刚才解压目录下含settings.gradle的那一层。
3. 等待Gradle Sync跑完，期间Android Studio会去下载distributionUrl里指定的Gradle发行版。如果你的网络访问不了services.gradle.org，这一步会卡很久，解决办法见避坑章节。
4. Sync完成后，点菜单Build → Make Project，观察底部Build窗口有没有报错。
5. 连点两次Shift弹出Search Everywhere，输入AVD Manager，创建一个API 30左右的模拟器。
6. 点Run按钮，选模拟器安装App。

导入过程里最需要注意的是：如果Sync阶段报SDK组件缺失，比如“SDK Build Tools xx.x.x is missing”，说明你本地的SDK Manager里没装那个版本。点开SDK Tools，勾选对应版本装一下就行。如果报的是Gradle本身下载失败，就不是SDK的问题了。

3.3 数据库初始化：SDK本地数据从哪里来

这个App用的是本地SQLite，所有数据都存在手机内部存储里。数据库的创建和初始化在DBHelper的onCreate回调中执行——第一次安装打开App时，系统会自动调用onCreate方法建表和插入种子数据。

// DBHelper.java 数据库创建与预置数据 public class DBHelper extends SQLiteOpenHelper { private static final String DB_NAME = "express.db"; private static final int DB_VERSION = 1; public DBHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL("CREATE TABLE tb_user (...)"); // 建用户表 db.execSQL("CREATE TABLE tb_order (...)"); // 建订单表 // 插入预置管理员账号和测试订单 db.execSQL("INSERT INTO tb_user (username, password, role) VALUES ('admin', 'e10adc3949ba59abbe56e057f20f883e', 2)"); db.execSQL("INSERT INTO tb_order (title, pickup_location, deliver_location, reward, status) VALUES ('帮拿快递', '菜鸟驿站', '12号楼', 3.0, 0)"); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { db.execSQL("DROP TABLE IF EXISTS tb_order"); db.execSQL("DROP TABLE IF EXISTS tb_user"); onCreate(db); } }

参数说明：管理员账号的密码是e10adc3949ba59abbe56e057f20f883e，这是“123456”的MD5值，说明源码里做了MD5加密存储。测试订单插入了一条status=0的待接单数据，保证你第一次打开App时界面上是有内容可看的。

这里有一个重要的调试技巧：当你改了数据库表结构，比如加了字段或者改了状态定义，模拟器里的旧数据库不会自动重建。最省事的做法是打开App管理界面，长按App图标 → 应用信息 → 存储与缓存 → 清除数据，然后再重新打开App，让onCreate重新建表。不然你只会遇到“android.database.sqlite.SQLiteException: no such column”这类报错。

4. 核心链路实战：登录鉴权、订单发布与抢单操作

环境跑通之后，就可以开始改代码了。这一章挑三条核心链路来讲：登录后Session怎么保持、订单列表怎么刷新、抢单怎么保证并发安全。这三条改明白，App的主流程你就拿捏了。

4.1 登录模块：Session保存与角色判断

登录页的逻辑在LoginActivity里，通常是这样一段代码：

// LoginActivity.java 登录校验 public void login(View view) { String username = etUsername.getText().toString().trim(); String password = etPassword.getText().toString().trim(); if (TextUtils.isEmpty(username) || TextUtils.isEmpty(password)) { Toast.makeText(this, "账号和密码不能为空", Toast.LENGTH_SHORT).show(); return; } UserDao dao = new UserDao(this); User user = dao.queryByUsername(username); if (user != null && user.getPassword().equals(MD5Utils.md5(password))) { SharedPreferences sp = getSharedPreferences("session", MODE_PRIVATE); sp.edit() .putInt("userId", user.getId()) .putInt("role", user.getRole()) .putString("username", user.getUsername()) .apply(); redirectByRole(user.getRole()); finish(); } else { Toast.makeText(this, "用户名或密码错误", Toast.LENGTH_SHORT).show(); } }

逻辑说明：先从输入框拿到账号密码，非空校验之后调UserDao去数据库里查用户记录。查到了比对密码的MD5值，比对成功就把用户信息写入SharedPreferences，然后根据角色跳转到对应主页。

这里有两个细节值得注意。一是密码比对用MD5Utils.md5(password)对输入做哈希后再与库中值比对，这是毕设源码里最标准的做法，避免明文密码直接存储和传输。二是SharedPreferences的写入用了apply()而不是commit()，apply是异步写入不阻塞UI线程，commit是同步等待磁盘落盘。单条数据场景两者差别不大，但我见过有的同学在循环里连续commit导致页面卡顿。

登录成功后的跳转方法一般是这样：

// LoginActivity.java 按角色跳转 private void redirectByRole(int role) { if (role == 1) { startActivity(new Intent(this, RunnerMainActivity.class)); } else if (role == 2) { startActivity(new Intent(this, AdminMainActivity.class)); } else { startActivity(new Intent(this, UserMainActivity.class)); } }

也就是说，同一个App按角色拆了三个主页。如果你想在用户端也看到全部待接单订单，只需要在UserMainActivity里多加一个Fragment或者一个入口按钮，跳转到待接单列表即可，底层数据是同一张表。

4.2 发布订单与列表刷新：RecyclerView绑定数据

发布订单是用户的第一个核心动作。界面上输入标题、取件地、送件地、赏金，点提交后插入数据库并回到列表页。难点不在插入，而在列表怎么感知数据变化并刷新。

// PublishActivity.java 发布订单 public void publish(View view) { String title = etTitle.getText().toString().trim(); String pickup = etPickup.getText().toString().trim(); String deliver = etDeliver.getText().toString().trim(); float reward = Float.parseFloat(etReward.getText().toString().trim()); int userId = getSharedPreferences("session", MODE_PRIVATE).getInt("userId", 0); if (TextUtils.isEmpty(title) || TextUtils.isEmpty(pickup) || TextUtils.isEmpty(deliver)) { Toast.makeText(this, "请完整填写订单信息", Toast.LENGTH_SHORT).show(); return; } Order order = new Order(); order.setTitle(title); order.setPickupLocation(pickup); order.setDeliverLocation(deliver); order.setReward(reward); order.setPublisherId(userId); order.setStatus(0); OrderDao dao = new OrderDao(this); long newId = dao.insert(order); if (newId > 0) { Toast.makeText(this, "发布成功", Toast.LENGTH_SHORT).show(); setResult(RESULT_OK); finish(); } else { Toast.makeText(this, "发布失败，请稍后重试", Toast.LENGTH_SHORT).show(); } }

参数说明：getSharedPreferences里的session文件名需要和登录时写入的完全一致，否则读不到userId，发布出来的订单publisher_id会是0，查不到关联用户。setResult配合startActivityForResult或者registerForActivityResult使用，让列表页在返回时知道数据变化了。

列表页的RecyclerView适配器是另一个重点。订单列表的Adapter通常长这样：

// OrderAdapter.java 订单列表适配器 public class OrderAdapter extends RecyclerView.Adapter<OrderAdapter.ViewHolder> { private List<Order> orderList; private OnOrderClickListener listener; public OrderAdapter(List<Order> orderList, OnOrderClickListener listener) { this.orderList = orderList; this.listener = listener; } @Override public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View view = LayoutInflater.from(parent.getContext()) .inflate(R.layout.item_order, parent, false); return new ViewHolder(view); } @Override public void onBindViewHolder(ViewHolder holder, int position) { Order order = orderList.get(position); holder.tvTitle.setText(order.getTitle()); holder.tvPickup.setText("取件：" + order.getPickupLocation()); holder.tvDeliver.setText("送件：" + order.getDeliverLocation()); holder.tvReward.setText("¥" + order.getReward()); holder.itemView.setOnClickListener(v -> listener.onClick(order)); } @Override public int getItemCount() { return orderList == null ? 0 : orderList.size(); } class ViewHolder extends RecyclerView.ViewHolder { TextView tvTitle, tvPickup, tvDeliver, tvReward; ViewHolder(View itemView) { super(itemView); tvTitle = itemView.findViewById(R.id.tv_title); tvPickup = itemView.findViewById(R.id.tv_pickup); tvDeliver = itemView.findViewById(R.id.tv_deliver); tvReward = itemView.findViewById(R.id.tv_reward); } } }

这个适配器的核心就是onBindViewHolder里把Order对象的各个字段写到View控件上，同时给整张卡片设置点击回调。列表刷新时，你先从数据库查出List ，然后调用adapter.notifyDataSetChanged()，界面就会重新渲染。我在改这类代码时的习惯是，查询数据库和刷新UI分两层写，数据层单独封装一个方法：

// OrderDao.java 查询待接单订单 public List<Order> queryOrdersByStatus(int status) { List<Order> list = new ArrayList<>(); SQLiteDatabase db = getReadableDatabase(); Cursor cursor = db.query("tb_order", null, "status=?", new String[]{String.valueOf(status)}, null, null, "create_time DESC"); while (cursor.moveToNext()) { Order order = new Order(); order.setId(cursor.getInt(cursor.getColumnIndexOrThrow("id"))); order.setTitle(cursor.getString(cursor.getColumnIndexOrThrow("title"))); order.setPickupLocation(cursor.getString(cursor.getColumnIndexOrThrow("pickup_location"))); order.setDeliverLocation(cursor.getString(cursor.getColumnIndexOrThrow("deliver_location"))); order.setReward(cursor.getFloat(cursor.getColumnIndexOrThrow("reward"))); order.setStatus(cursor.getInt(cursor.getColumnIndexOrThrow("status"))); list.add(order); } cursor.close(); return list; }

这样你在Activity里只需要一行代码搞定刷新：orderList = dao.queryOrdersByStatus(0); adapter.notifyDataSetChanged(); 保持数据层与UI层分离，后面加筛选条件也方便。

4.3 接单操作与状态回写：并发安全的下沉写法

跑腿端最关键的动作就是抢单。场景是多个跑腿员同时盯着一个待接单订单，谁先点谁成功。如果代码写得不够严谨，会出现两个人同时看到这个订单、同时点击、同时提示接单成功的情况，最后数据库里taker_id只保存了后写入的那个人，但先写入的那个人也以为自己抢到了。

这个问题的根源在于“先查询状态再更新”的操作不是原子的。查的时候status=0，两个线程都查到了，然后各自执行更新，都把status改成1，各自的taker_id不同，后执行的覆盖前者。解决的办法是把状态判断下沉到UPDATE语句的WHERE条件里：

// OrderDao.java 并发安全的接单操作 public boolean takeOrder(int orderId, int takerId) { SQLiteDatabase db = getWritableDatabase(); ContentValues values = new ContentValues(); values.put("status", 1); values.put("taker_id", takerId); int rows = db.update("tb_order", values, "id=? AND status=0", new String[]{String.valueOf(orderId)}); return rows > 0; }

参数说明：db.update方法返回的是受影响的行数。因为WHERE里带了AND status=0，当且仅当该订单此刻仍然是待接单状态时，更新才会真正生效。如果订单已经被抢走，rowCount是0，takeOrder返回false，第二个点击的跑腿员就会看到“订单已被抢走”。把并发判断交给数据库的单条UPDATE语句，天然保证了原子性，这比在Java层加synchronized锁可靠得多。

对应Activity里的调用代码：

// RunnerOrderDetailActivity.java 跑腿员点击接单 public void onTakeOrderClick(View view) { int orderId = getIntent().getIntExtra("orderId", 0); int currentUserId = getSharedPreferences("session", MODE_PRIVATE).getInt("userId", 0); if (currentUserId == 0) { Toast.makeText(this, "登录状态失效，请重新登录", Toast.LENGTH_SHORT).show(); return; } boolean ok = new OrderDao(this).takeOrder(orderId, currentUserId); if (ok) { Toast.makeText(this, "接单成功", Toast.LENGTH_SHORT).show(); // 通知列表页刷新并返回 setResult(RESULT_OK); finish(); } else { new AlertDialog.Builder(this) .setTitle("提示") .setMessage("手慢了，该订单已被其他跑腿员抢走") .setPositiveButton("知道了", null) .show(); } }

判断currentUserId为0是为了防止直接打开详情页时未登录导致的数据异常。因为接单成功后要return掉Activity，所以返回值通过startActivityForResult或新的Activity Result API传递给列表页。如果列表页是用startActivityForResult打开的详情页，那么详情页finish()之前setResult(RESULT_OK)，列表页的onActivityResult里收到这个结果就去重新查库刷新。

这里还有一个值得注意的性能设计：每次接单都查一次数据库并更新，对于毕设规模完全没有问题。但如果做商用，这种读多写多的场景一定要走Redis或服务端锁，App直连数据库的架构撑不住并发。答辩时被问到这点，可以主动说“当前实现利用了SQLite更新的原子性，在单机演示场景下能保证正确；大规模并发需要引入服务端和事务锁”——这就是一个很好的加分回答。

5. 避坑合集：导入崩溃、黑屏、订单不同步的五个典型现场

这部分是血泪经验。下面五条坑我几乎在每份同类毕业设计源码里都能遇到，提前知道可以省掉好几个晚上的调试时间。

5.1 现象：Gradle Sync卡住不动，或报Could not resolve com.android.tools.build:gradle:7.4.1

原因：Android Studio的Gradle插件需要从Google Maven仓库下载，国内网络直连经常失败或极慢。这不是源码的问题，是网络环境的问题。

解决：在根目录build.gradle的repositories里加阿里云镜像，修改后的样子是：

buildscript { repositories { maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/public' } maven { url 'https://maven.aliyun.com/repository/gradle-plugin' } google() mavenCentral() } }

改完后重新Sync。如果还是卡在下载Gradle本体，直接打开gradle-wrapper.properties看distributionUrl指定的是哪个版本，比如gradle-7.4.2-all.zip，然后从浏览器或用其他下载工具手动下载这个zip，放到用户目录.gradle/wrapper/dists/gradle-7.4.2-all/下的对应哈希目录里重新打开工程。不要解压，直接让Gradle自己解压。

5.2 现象：App安装成功但一启动就闪退，Logcat报SQLiteException: no such table: tb_order

原因：代码里查询的表和实际数据库里存在的表不一致。最常见的情况是你改过DBHelper里的建表语句，但模拟器里已经有一个旧版本数据库文件，onCreate不会重新执行。

解决：模拟器上卸载App重装，或者在代码里临时把DB_VERSION加1，触发onUpgrade。如果是在开发阶段频繁改表结构，最快的办法是卸载重装，不要想着做数据迁移。用adb命令一行搞定：

adb uninstall com.example.express adb install app/build/outputs/apk/debug/app-debug.apk

另外，卸载重装后之前登录写入的SharedPreferences数据也没了，需要重新登录一次。如果嫌麻烦，开发阶段可以把创建表的语句放到Application的onCreate里每次都检查，但我个人建议还是用正规的DB_VERSION管理，别给答辩埋雷。

5.3 现象：跑腿员点击接单提示成功，但列表刷新后状态还是“待接单”

原因：takeOrder的UPDATE语句没有生效，但界面没有感知到失败。场景往往是代码用了db.execSQL("UPDATE tb_order SET status=1...")，execSQL不返回受影响行数，所以即使WHERE条件没匹配到任何行，也不会报错，代码直接往下走，Toast提示成功。

解决：把execSQL换成db.update方法并获得返回的rowCount，只有rowCount大于0才提示接单成功。这正好对应到4.3节里写的takeOrder方法。我判断一份源码质量高低，就看它跟数据库交互时有没有使用update/insert/delete的返回值。用execSQL的版本，十有八九存在这种“假成功”逻辑。

5.4 现象：真机调试点击Run后，手机提示安装失败或“应用未安装”

原因：多数情况是签名不一致，调试版签名和之前安装的发布版签名不一样。尤其是手机之前装过同一个包名的其他签名版本时，Android系统会拒绝安装。另一种可能是targetSdkVersion设置高于手机操作系统版本，不过这个一般不会单独导致安装失败。

解决：最简单粗暴的办法是卸载手机上的旧App再安装。如果是长期调试，保持debug签名统一即可。真机调试还需要注意：手机上开启开发者选项和USB调试后，确认电脑上的驱动没毛病。Linux用户在插线后如果报insufficient permissions for device，需要配置udev规则，或者在Android Studio的SDK Manager里把Platform Tools更新到最新。

5.5 现象：订单列表刷新后，界面显示的位置不对或者出现重复卡片

原因：RecyclerView复用机制被错误处理。常见写法是在onBindViewHolder里直接new出来的控件赋值，但如果你在Activity里把List给改了，忘记清除旧的List元素，而是用addAll追加，那列表就会出现重复卡片。还有一种情况是没有调用adapter.notifyDataSetChanged()而只调用了notifyItemInserted，但插入位置和实际数据不一致，导致错位。

解决：刷新数据时统一走如下模式：

// MainActivity.java 安全的列表刷新方式 private void refreshOrderList(int status) { List<Order> newList = dao.queryOrdersByStatus(status); orderList.clear(); orderList.addAll(newList); adapter.notifyDataSetChanged(); }

千万不要直接给orderList赋值一个新对象，因为Adapter持有的引用还是旧的List对象，只有clear后addAll才是在原对象上修改。这条细节点答辩时经常会问到，值得记住底层原因。

6. 答辩前的最后一步：数据预置、录屏脚本与亮点打磨

环境跑通、核心链路也没问题，剩下的工作就是让答辩演示环节行云流水。这一步是最容易被忽视的，但也是让老师觉得“这学生真的把系统做出来了”的关键。

先做数据预置。在DBHelper的onCreate里多插几条状态不同的订单数据，模拟真实使用场景：

// DBHelper.java 预置演示数据 db.execSQL("INSERT INTO tb_order (title, pickup_location, deliver_location, reward, status, publisher_id) VALUES ('帮拿快递', '菜鸟驿站', '12号楼', 3.0, 0, 2)"); db.execSQL("INSERT INTO tb_order (title, pickup_location, deliver_location, reward, status, publisher_id) VALUES ('取顺丰件', '东区快递柜', '3号楼', 2.0, 0, 2)"); db.execSQL("INSERT INTO tb_order (title, pickup_location, deliver_location, reward, status, publisher_id) VALUES ('带杯奶茶', '西区甜品店', '图书馆', 5.0, 1, 3)");

参数说明：最后一条状态是1，表示已经被某跑腿员接单了，用于演示“进行中”的界面效果。建议至少备两条待接单、一条已接单、一条已送达的数据，这样演示每个角色切换时都有内容展示，不至于现场临时发布等待刷新。

录屏脚本建议固定下来，整个演示控制在5分钟以内。第一段用普通用户账号登录，演示发布一个订单，附上快递到货的模拟通知；第二段切到跑腿员账号，演示看到新订单、抢单、改状态为已送达；第三段切回用户端，确认完成订单。这个顺序符合业务时序，老师说到底是能听懂的。

答辩时值得强调的三个技术亮点：一是4.3节实现的并发安全抢单，直接说“我用UPDATE带status条件的原子操作避免了超卖问题”；二是MD5密码加密存储，安全角度稳了一个提问；三是三端合一的角色路由设计，说明你对软件架构有分层意识。提前练好对这三点的话术，老师追问的概率会小很多。

最后的验证步骤建议强制走一遍：卸载App重装，确认数据库重新初始化没有报错；连续快速点击两次接单按钮，看第二次是否被拦截；清掉后台进程重新打开App，确认登录状态保持逻辑正确。这三条过一个，这个demo基本就稳了。从那以后我每次拿到一份毕业设计源码，不管是自己用还是帮人看，都会先花十分钟把“卸载重装、连续点击、杀进程重开”这三板斧走一遍，再谈改其他的。这段经验帮我避开了至少三次现场答辩翻车，希望帮到你。

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