简介这是一份面向安卓开发者的城市生鲜配送系统完整源码可用于课程设计、毕业设计或实际项目二次开发。资源为RAR压缩包共包含两千个文件体积约为七十七兆字节文件类型覆盖开发各环节近六百个资源编译文件、四百多个界面与配置标记文件、两百多个Java逻辑代码文件、两百多个数据配置文件、两百余张图片素材同时附带原生动态库、服务端页面、数据库脚本和工程构建配置。依托这些文件可以完整还原项目的目录结构与运行环境。目前已有一百二十五人学习使用具有一定的参考价值。读者可从源码中学习订单管理、商品展示、配送流程等核心模块的实现思路理解安卓工程如何组织资源、调用本地库以及对接服务端数据并在此基础上灵活扩展快速形成自己的生鲜配送应用。1. 拿到这套生鲜配送源码先看清它的技术分层再动手这套基于 Android 的城市生鲜配送系统源码不是那种十个页面拼起来的演示工程。解压后能看到一堆.ap_、fileSnapshots.bin、classAnalysis.bin、jarAnalysis.bin这类 Gradle 构建中间产物说明项目经过了完整的编译流程源码结构基本是「用户端 App 商家/骑手端业务模块」的体量。对想拿来二次开发或者做毕业设计的人来说第一件事不是急着改 UI而是先摸清它底层是怎么组织的。生鲜配送和普通电商 App 最大的差异在于三件事生鲜商品有重量和温区属性库存会随订单实时波动配送环节强依赖 LBS 定位和路线轨迹订单状态在整个链路里流转频繁从下单到签收可能要经历六到八个状态。这套源码里如果没有把这三块做扎实后续改起来会非常痛苦。适合的人群也比较明确已经掌握 Android 四大组件基础、想直接看一个完整商业项目怎么落地的人或者准备在商城类项目上做二次开发、需要一套可运行骨架的开发者。接下来我会按源码的实际模块拆开讲包括定位怎么接、订单状态机怎么设计、购物车库存并发怎么处理最后落到构建产物和性能优化上。2. 基础架构层多 Module 拆分与关键依赖选型2.1 从源码目录反推工程的模块划分开发过中大型项目的朋友应该知道一个能上线级别的项目不会把所有代码堆在一个 app module 里生鲜配送这套源码走的也是多 Module 路线。打开工程根目录的settings.gradle一般能看到:app、:lib_base、:lib_network、:lib_widget、:module_home、:module_cart、:module_order、:module_user这类拆分。:app是外壳只做初始化、路由注册和页面容器业务代码全部下沉到各个 feature module。这样做的直接好处是你在改购物车模块时不需要重新编译首页模块编译时间能缩短一半以上。lib_base通常承载 BaseActivity、BaseFragment、MVP 或 MVVM 的基类封装以及权限申请、屏幕适配这些公共能力这套源码里屏幕适配用的是AutoSize这是目前适配成本最低的方案原理是修改系统 dp 与 px 的换算比例Android 6.0 以下的机器也能保持一致。lib_network则封装了 Retrofit OkHttp RxJava 这套组合网络层单独抽出来之后接口地址切换、加签名、统一处理错误码都只改一个库。2.2 从 Gradle 配置看依赖版本踩坑点源码里build.gradle的 dependencies 区域一般长这样网络层核心代码看起来类似下面这段implementation com.squareup.okhttp3:okhttp:4.9.3 implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0 implementation com.squareup.retrofit2:adapter-rxjava2:2.9.0 implementation io.reactivex.rxjava2:rxandroid:2.1.1 implementation com.alibaba:arouter-api:1.5.2 annotationProcessor com.alibaba:arouter-compiler:1.5.2这里有一个很典型的坑要提醒你rxandroid版本和rxjava版本必须配套rxjava用 2.2.x 时rxandroid用 2.1.x 没问题但如果把rxjava升到 3.xadapter-rxjava2就会直接编译失败因为 Retrofit 的 RxJava2CallAdapterFactory 不兼容 RxJava 3。我看到不少朋友拿到源码后第一件事就是升级依赖版本结果升级完根本跑不起来反过来骂源码是坏的实际上大多数问题都出在版本配套上。建议前期保持源码原版本跑通后再逐个升级。2.3 路由表的实际价值生鲜配送这种有用户端、骑手端多个身份角色的项目页面跳转如果全部用显式 IntentModule 之间就会产生严重耦合。这套源码里用 ARouter 做跨模块跳转路由地址通常写在常量类里。Route(path /order/detail) public class OrderDetailActivity extends BaseActivity { public static void start(Context context, String orderId) { ARouter.getInstance() .build(/order/detail) .withString(orderId, orderId) .navigation(); } }这种写法的好处是跳转时参数类型在编译期不检查但换来的是 Module 之间完全解耦。你只需要确保每个被跳转的页面都加了Route注解并且使用页面的 Module 在build.gradle里引入了arouter-api。如果跳转后页面白屏先在Application里检查有没有调用ARouter.init再检查annotationProcessor是否配置正确超过 80% 的路由失效都是这两个原因。3. 订单状态机生鲜配送链路中的状态流转与并发安全3.1 状态枚举如何映射业务节点生鲜配送的订单链路比普通电商长得多普通电商是「下单-支付-发货-签收」四步生鲜配送中间还夹着「拣货-称重-打包-骑手接单-到店取货-送达」多个环节。这套源码的订单模块用了一个状态机来管理订单状态枚举一般是这样的public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 已支付/待拣货), PICKING(2, 拣货中), PACKAGED(3, 已打包待接单), DELIVERING(4, 配送中), COMPLETED(5, 已完成), CANCELLED(6, 已取消); public final int value; public final String desc; OrderStatus(int value, String desc) { this.value value; this.desc desc; } }状态机不只是一个枚举列表关键在于「谁允许从哪个状态转移到哪个状态」。比如「已支付」状态下用户不能直接取消必须经过商家确认「配送中」状态下只有骑手端可以触发「已完成」或「异常上报」用户端不能操作。源码里通常有一个OrderStateMachine类负责校验核心逻辑是维护一张允许转移的映射表。3.2 状态扭转时如何解决并发问题这里要特别说一下并发问题。生鲜配送场景下一个订单可能同时被用户端、商家端、骑手端三个角色操作比如用户正在点「取消订单」骑手同时点了「开始配送」如果状态更新没有加锁数据库里的订单记录会变成脏数据。项目里用的方案是在 SQL 层面做条件更新而不是先在 Java 层判断再更新。具体做法是执行更新时带着预期状态作为条件Dao public interface OrderDao { Query(UPDATE orders SET status :newStatus WHERE order_id :orderId AND status :expectStatus) int updateStatus(String orderId, int expectStatus, int newStatus); }这段代码的巧妙之处在于updateStatus方法的返回值是受影响行数。如果返回 0说明更新时订单状态已经不是我们期望的状态了说明有其他端抢先改了状态此时再根据当前状态做补偿处理。这样就把判断和更新合并成了一个原子操作避免了「检查-再更新」中间的时间窗口。我在实际项目里见过不少团队用「先查询当前状态if 判断合法再更新」的方式在高并发下一定会出问题这套源码的做法值得学习。3.3 消息推送与状态刷新的配合状态机只是数据层用户端要实时感知状态变化还得靠推送或者轮询。这套项目里用的是「推送 本地广播刷新」的组合服务端在订单状态变化时推送PUSH_ORDER_STATUS消息App 收到后先更新本地数据库再发一个LocalBroadcastManager通知页面刷新。Intent intent new Intent(ACTION_ORDER_STATUS_CHANGED); intent.putExtra(orderId, orderId); intent.putExtra(status, newStatus); LocalBroadcastManager.getInstance(context).sendBroadcast(intent);Activity 侧在onResume中注册BroadcastReceiveronPause中反注册避免内存泄漏。不要用EventBus全项目乱发事件生鲜配送这种高频状态变化场景用 LocalBroadcastManager 的线程切换成本更低也不会因为事件没有订阅者而产生空指针。轮询逻辑放在JobScheduler或者WorkManager里间隔不要低于 15 秒否则服务器压力大而且骑手端频繁请求也费电。4. 购物车与库存生鲜商品的时效性如何影响数据设计4.1 购物车表的结构设计与本地缓存购物车在生鲜配送里比普通电商复杂因为生鲜商品可能按份卖、按斤称而且不同门店的库存不一样。源码里购物车数据库表一般是这样设计的CREATE TABLE cart_items ( id INTEGER PRIMARY KEY AUTOINCREMENT, goods_id TEXT NOT NULL, goods_name TEXT, price REAL, weight REAL DEFAULT 0, quantity INTEGER DEFAULT 1, sku_id TEXT, shop_id TEXT, selected INTEGER DEFAULT 1, expired_time LONG );这个表结构里比较关键的两个字段是sku_id和expired_time。sku_id用来区分规格比如「500g 装」和「1kg 装」是不同的 skuexpired_time是购物车内商品的「保鲜期」生鲜商品如果超过某个时间没支付库存会被释放购物车里的这条记录也应该同步失效。源码里在进入购物车页面时会先执行一次清理cartDao.deleteExpired(System.currentTimeMillis());4.2 库存扣减的原子性处理生鲜库存是强实时数据一个榴莲被加进购物车不代表锁住了库存真正扣库存发生在提交订单那一刻。源码里用的扣减 SQL 是这样的UPDATE goods_stock SET stock stock - 1 WHERE goods_id ? AND stock 1注意这个 SQL 的AND stock 1条件它保证了库存不会扣成负数。同样地如果 update 返回 0 行说明库存不足需要提示用户「该商品已售罄」。商户端在处理超卖问题时也用的同一个方案只是在应用层加了 Redis 的DECR操作做分布式限流App 端不直接操作 Redis而是通过后端接口中转。4.3 下单时的 Activity 任务栈与返回逻辑购物车下单流程如果不在任务栈上做处理用户会陷入「下单页-支付页-订单详情页-返回购物车」的混乱循环中。源码里在订单提交成功后使用了 Intent.FLAG_ACTIVITY_CLEAR_TOP 和 SINGLE_TOP 组合让购物车页面成为任务栈栈底的唯一入口。Intent intent new Intent(this, OrderListActivity.class); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK); startActivity(intent);CLEAR_TASK会把整个栈清空再创建新任务用户从订单列表返回时不会回到已经无意义的购物车结算页。要注意的是这个 flag 在 Android 12 及以上行为有变化如果发现返回后页面错乱优先检查是否适配了android:enableOnBackInvokedCallback属性部分国产 ROM 对这个属性支持不佳。5. 定位与地图模块商超配送的骑手轨迹与门店距离计算5.1 定位服务如何做到前后台稳定输出生鲜配送用户端需要展示周边门店、选择收货地址骑手端需要持续上报位置轨迹。这套源码里定位模块用的是系统 LocationManager 和高德定位 SDK 结合的方式权限配置在AndroidManifest.xml里uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_BACKGROUND_LOCATION /Android 10 以上如果不在 Manifest 里声明ACCESS_BACKGROUND_LOCATION退到后台后定位频率会被系统限制到几分钟一次骑手轨迹基本就是一条直线连过去的没有实际价值。源码里前台服务会创建一个常驻通知栏的 notification让用户知道「配送定位正在运行」这也是 Android 8.0 以上必须做的否则服务在后台存活不了几秒钟。5.2 轨迹点去重与距离计算的高效实现高频上报会产生大量冗余点骑手站在原地不动时每秒上报一个经纬度没有任何意义。源码里对轨迹做了一层抽稀处理public boolean shouldUpload(Location lastLocation, Location newLocation) { if (lastLocation null) return true; float distance lastLocation.distanceTo(newLocation); long timeDelta newLocation.getTime() - lastLocation.getTime(); return distance 30 || timeDelta 20 * 1000; }这个判断逻辑是移动距离超过 30 米或者距离上次上报超过 20 秒才上传坐标。两个条件用或连接保证骑手匀速骑行时大约每 20 秒一个点停车时则完全不上传大大节省电量开销和服务器存储压力。如果想让轨迹更平滑可以在服务端做Douglas-Peucker抽稀但这套源码的业务量级用阈值法完全足够。5.3 门店定位与配送范围的半径判断计算门店是否在配送范围内源码里用的是半正矢公式封装在高德地图的DistanceUtil中double distance AMapUtils.calculateLineDistance( new LatLng(userLat, userLng), new LatLng(shopLat, shopLng) ); boolean inScope distance shop.deliveryRadius;calculateLineDistance返回的是米deliveryRadius字段在门店表里存的是「配送半径米」的值。这里要注意一个边界问题生鲜配送和外卖不一样生鲜门店的配送半径通常在 3 公里以内超过这个范围生鲜品质无法保证。源码里店列表接口一次性返回了半径内的门店但如果你拿来做二次开发建议改成「先获取用户定位再按半径倒查门店 SQL」否则门店数量一多App 端过滤会变得越来越卡。6. 构建缓存清理、编译加速与 Kotlin 化的渐进迁移resources-debugAndroidTest.ap_、fileSnapshots.bin、classAnalysis.bin、jarAnalysis.bin这些文件都是 Gradle 在编译过程中产生的缓存快照它们存放在app/build、build目录下体积通常能占到整个工程的一半以上。拿到源码后第一件事先把这些缓存清掉否则 IDE 索引会非常慢Windows 上甚至会出现文件占用导致编译失败./gradlew clean rm -rf .gradle rm -rf build app/build注意./gradlew clean只能清理输出目录.gradle目录里保存的是任务历史和文件哈希记录如果源码是从别处拷贝过来的这些缓存里的文件路径和你本机不一致就会导致 Gradle 误判「无需编译」。编译加速方面的建议是打开构建缓存和并行编译在gradle.properties里加三行配置org.gradle.jvmargs-Xmx4096m -XX:MaxMetaspaceSize1024m org.gradle.paralleltrue org.gradle.cachingtrue但这里有个前提如果工程里的 Module 数量在三个以下org.gradle.paralleltrue反而会因为任务调度开销变慢。你可以先用./gradlew assembleDebug --profile生成一份构建报告看哪些任务耗时最长再决定是否开启。对于这套生鲜配送工程一般至少有四个业务 Module打开并行编译能节省 20% 以上的构建时间。关于 Kotlin 迁移我建议按「工具类 → 数据模型 → 页面」的顺序渐进式替换不要一把梭。先把lib_base里的 DateUtils、FileUtils 这类纯工具类用 Kotlin 重写因为它们是静态调用、依赖最少改完立刻能跑通。接着把商品、订单等数据实体类转成 Kotlin data class这些类没有复杂继承关系转换成本最低。最后再动 Activity 和 Fragment因为涉及 findViewById、点击事件、Adapter 等 Java 语法糖和 Kotlin 之间差异较大的代码一次改太多容易出编译错误。转换完数据模型后记得加JvmField注解否则 Java 代码里访问 Bean 字段的方式会变导致一堆编译报错。最后说一个比较隐蔽的坑这套源码如果是从 Windows 机器打包的build目录里可能存在大小写不敏感的文件引用拷到 Mac 或 Linux 上编译会报FileNotFoundException。出现这种情况时不要慌把~/.gradle缓存也清一遍然后重新同步绝大多数报错都能消失。本文还有配套的精品资源点击获取 Android生鲜配送系统源码全解析：架构、状态机与性能优化
简介这是一份面向安卓开发者的城市生鲜配送系统完整源码可用于课程设计、毕业设计或实际项目二次开发。资源为RAR压缩包共包含两千个文件体积约为七十七兆字节文件类型覆盖开发各环节近六百个资源编译文件、四百多个界面与配置标记文件、两百多个Java逻辑代码文件、两百多个数据配置文件、两百余张图片素材同时附带原生动态库、服务端页面、数据库脚本和工程构建配置。依托这些文件可以完整还原项目的目录结构与运行环境。目前已有一百二十五人学习使用具有一定的参考价值。读者可从源码中学习订单管理、商品展示、配送流程等核心模块的实现思路理解安卓工程如何组织资源、调用本地库以及对接服务端数据并在此基础上灵活扩展快速形成自己的生鲜配送应用。1. 拿到这套生鲜配送源码先看清它的技术分层再动手这套基于 Android 的城市生鲜配送系统源码不是那种十个页面拼起来的演示工程。解压后能看到一堆.ap_、fileSnapshots.bin、classAnalysis.bin、jarAnalysis.bin这类 Gradle 构建中间产物说明项目经过了完整的编译流程源码结构基本是「用户端 App 商家/骑手端业务模块」的体量。对想拿来二次开发或者做毕业设计的人来说第一件事不是急着改 UI而是先摸清它底层是怎么组织的。生鲜配送和普通电商 App 最大的差异在于三件事生鲜商品有重量和温区属性库存会随订单实时波动配送环节强依赖 LBS 定位和路线轨迹订单状态在整个链路里流转频繁从下单到签收可能要经历六到八个状态。这套源码里如果没有把这三块做扎实后续改起来会非常痛苦。适合的人群也比较明确已经掌握 Android 四大组件基础、想直接看一个完整商业项目怎么落地的人或者准备在商城类项目上做二次开发、需要一套可运行骨架的开发者。接下来我会按源码的实际模块拆开讲包括定位怎么接、订单状态机怎么设计、购物车库存并发怎么处理最后落到构建产物和性能优化上。2. 基础架构层多 Module 拆分与关键依赖选型2.1 从源码目录反推工程的模块划分开发过中大型项目的朋友应该知道一个能上线级别的项目不会把所有代码堆在一个 app module 里生鲜配送这套源码走的也是多 Module 路线。打开工程根目录的settings.gradle一般能看到:app、:lib_base、:lib_network、:lib_widget、:module_home、:module_cart、:module_order、:module_user这类拆分。:app是外壳只做初始化、路由注册和页面容器业务代码全部下沉到各个 feature module。这样做的直接好处是你在改购物车模块时不需要重新编译首页模块编译时间能缩短一半以上。lib_base通常承载 BaseActivity、BaseFragment、MVP 或 MVVM 的基类封装以及权限申请、屏幕适配这些公共能力这套源码里屏幕适配用的是AutoSize这是目前适配成本最低的方案原理是修改系统 dp 与 px 的换算比例Android 6.0 以下的机器也能保持一致。lib_network则封装了 Retrofit OkHttp RxJava 这套组合网络层单独抽出来之后接口地址切换、加签名、统一处理错误码都只改一个库。2.2 从 Gradle 配置看依赖版本踩坑点源码里build.gradle的 dependencies 区域一般长这样网络层核心代码看起来类似下面这段implementation com.squareup.okhttp3:okhttp:4.9.3 implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0 implementation com.squareup.retrofit2:adapter-rxjava2:2.9.0 implementation io.reactivex.rxjava2:rxandroid:2.1.1 implementation com.alibaba:arouter-api:1.5.2 annotationProcessor com.alibaba:arouter-compiler:1.5.2这里有一个很典型的坑要提醒你rxandroid版本和rxjava版本必须配套rxjava用 2.2.x 时rxandroid用 2.1.x 没问题但如果把rxjava升到 3.xadapter-rxjava2就会直接编译失败因为 Retrofit 的 RxJava2CallAdapterFactory 不兼容 RxJava 3。我看到不少朋友拿到源码后第一件事就是升级依赖版本结果升级完根本跑不起来反过来骂源码是坏的实际上大多数问题都出在版本配套上。建议前期保持源码原版本跑通后再逐个升级。2.3 路由表的实际价值生鲜配送这种有用户端、骑手端多个身份角色的项目页面跳转如果全部用显式 IntentModule 之间就会产生严重耦合。这套源码里用 ARouter 做跨模块跳转路由地址通常写在常量类里。Route(path /order/detail) public class OrderDetailActivity extends BaseActivity { public static void start(Context context, String orderId) { ARouter.getInstance() .build(/order/detail) .withString(orderId, orderId) .navigation(); } }这种写法的好处是跳转时参数类型在编译期不检查但换来的是 Module 之间完全解耦。你只需要确保每个被跳转的页面都加了Route注解并且使用页面的 Module 在build.gradle里引入了arouter-api。如果跳转后页面白屏先在Application里检查有没有调用ARouter.init再检查annotationProcessor是否配置正确超过 80% 的路由失效都是这两个原因。3. 订单状态机生鲜配送链路中的状态流转与并发安全3.1 状态枚举如何映射业务节点生鲜配送的订单链路比普通电商长得多普通电商是「下单-支付-发货-签收」四步生鲜配送中间还夹着「拣货-称重-打包-骑手接单-到店取货-送达」多个环节。这套源码的订单模块用了一个状态机来管理订单状态枚举一般是这样的public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 已支付/待拣货), PICKING(2, 拣货中), PACKAGED(3, 已打包待接单), DELIVERING(4, 配送中), COMPLETED(5, 已完成), CANCELLED(6, 已取消); public final int value; public final String desc; OrderStatus(int value, String desc) { this.value value; this.desc desc; } }状态机不只是一个枚举列表关键在于「谁允许从哪个状态转移到哪个状态」。比如「已支付」状态下用户不能直接取消必须经过商家确认「配送中」状态下只有骑手端可以触发「已完成」或「异常上报」用户端不能操作。源码里通常有一个OrderStateMachine类负责校验核心逻辑是维护一张允许转移的映射表。3.2 状态扭转时如何解决并发问题这里要特别说一下并发问题。生鲜配送场景下一个订单可能同时被用户端、商家端、骑手端三个角色操作比如用户正在点「取消订单」骑手同时点了「开始配送」如果状态更新没有加锁数据库里的订单记录会变成脏数据。项目里用的方案是在 SQL 层面做条件更新而不是先在 Java 层判断再更新。具体做法是执行更新时带着预期状态作为条件Dao public interface OrderDao { Query(UPDATE orders SET status :newStatus WHERE order_id :orderId AND status :expectStatus) int updateStatus(String orderId, int expectStatus, int newStatus); }这段代码的巧妙之处在于updateStatus方法的返回值是受影响行数。如果返回 0说明更新时订单状态已经不是我们期望的状态了说明有其他端抢先改了状态此时再根据当前状态做补偿处理。这样就把判断和更新合并成了一个原子操作避免了「检查-再更新」中间的时间窗口。我在实际项目里见过不少团队用「先查询当前状态if 判断合法再更新」的方式在高并发下一定会出问题这套源码的做法值得学习。3.3 消息推送与状态刷新的配合状态机只是数据层用户端要实时感知状态变化还得靠推送或者轮询。这套项目里用的是「推送 本地广播刷新」的组合服务端在订单状态变化时推送PUSH_ORDER_STATUS消息App 收到后先更新本地数据库再发一个LocalBroadcastManager通知页面刷新。Intent intent new Intent(ACTION_ORDER_STATUS_CHANGED); intent.putExtra(orderId, orderId); intent.putExtra(status, newStatus); LocalBroadcastManager.getInstance(context).sendBroadcast(intent);Activity 侧在onResume中注册BroadcastReceiveronPause中反注册避免内存泄漏。不要用EventBus全项目乱发事件生鲜配送这种高频状态变化场景用 LocalBroadcastManager 的线程切换成本更低也不会因为事件没有订阅者而产生空指针。轮询逻辑放在JobScheduler或者WorkManager里间隔不要低于 15 秒否则服务器压力大而且骑手端频繁请求也费电。4. 购物车与库存生鲜商品的时效性如何影响数据设计4.1 购物车表的结构设计与本地缓存购物车在生鲜配送里比普通电商复杂因为生鲜商品可能按份卖、按斤称而且不同门店的库存不一样。源码里购物车数据库表一般是这样设计的CREATE TABLE cart_items ( id INTEGER PRIMARY KEY AUTOINCREMENT, goods_id TEXT NOT NULL, goods_name TEXT, price REAL, weight REAL DEFAULT 0, quantity INTEGER DEFAULT 1, sku_id TEXT, shop_id TEXT, selected INTEGER DEFAULT 1, expired_time LONG );这个表结构里比较关键的两个字段是sku_id和expired_time。sku_id用来区分规格比如「500g 装」和「1kg 装」是不同的 skuexpired_time是购物车内商品的「保鲜期」生鲜商品如果超过某个时间没支付库存会被释放购物车里的这条记录也应该同步失效。源码里在进入购物车页面时会先执行一次清理cartDao.deleteExpired(System.currentTimeMillis());4.2 库存扣减的原子性处理生鲜库存是强实时数据一个榴莲被加进购物车不代表锁住了库存真正扣库存发生在提交订单那一刻。源码里用的扣减 SQL 是这样的UPDATE goods_stock SET stock stock - 1 WHERE goods_id ? AND stock 1注意这个 SQL 的AND stock 1条件它保证了库存不会扣成负数。同样地如果 update 返回 0 行说明库存不足需要提示用户「该商品已售罄」。商户端在处理超卖问题时也用的同一个方案只是在应用层加了 Redis 的DECR操作做分布式限流App 端不直接操作 Redis而是通过后端接口中转。4.3 下单时的 Activity 任务栈与返回逻辑购物车下单流程如果不在任务栈上做处理用户会陷入「下单页-支付页-订单详情页-返回购物车」的混乱循环中。源码里在订单提交成功后使用了 Intent.FLAG_ACTIVITY_CLEAR_TOP 和 SINGLE_TOP 组合让购物车页面成为任务栈栈底的唯一入口。Intent intent new Intent(this, OrderListActivity.class); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK); startActivity(intent);CLEAR_TASK会把整个栈清空再创建新任务用户从订单列表返回时不会回到已经无意义的购物车结算页。要注意的是这个 flag 在 Android 12 及以上行为有变化如果发现返回后页面错乱优先检查是否适配了android:enableOnBackInvokedCallback属性部分国产 ROM 对这个属性支持不佳。5. 定位与地图模块商超配送的骑手轨迹与门店距离计算5.1 定位服务如何做到前后台稳定输出生鲜配送用户端需要展示周边门店、选择收货地址骑手端需要持续上报位置轨迹。这套源码里定位模块用的是系统 LocationManager 和高德定位 SDK 结合的方式权限配置在AndroidManifest.xml里uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_BACKGROUND_LOCATION /Android 10 以上如果不在 Manifest 里声明ACCESS_BACKGROUND_LOCATION退到后台后定位频率会被系统限制到几分钟一次骑手轨迹基本就是一条直线连过去的没有实际价值。源码里前台服务会创建一个常驻通知栏的 notification让用户知道「配送定位正在运行」这也是 Android 8.0 以上必须做的否则服务在后台存活不了几秒钟。5.2 轨迹点去重与距离计算的高效实现高频上报会产生大量冗余点骑手站在原地不动时每秒上报一个经纬度没有任何意义。源码里对轨迹做了一层抽稀处理public boolean shouldUpload(Location lastLocation, Location newLocation) { if (lastLocation null) return true; float distance lastLocation.distanceTo(newLocation); long timeDelta newLocation.getTime() - lastLocation.getTime(); return distance 30 || timeDelta 20 * 1000; }这个判断逻辑是移动距离超过 30 米或者距离上次上报超过 20 秒才上传坐标。两个条件用或连接保证骑手匀速骑行时大约每 20 秒一个点停车时则完全不上传大大节省电量开销和服务器存储压力。如果想让轨迹更平滑可以在服务端做Douglas-Peucker抽稀但这套源码的业务量级用阈值法完全足够。5.3 门店定位与配送范围的半径判断计算门店是否在配送范围内源码里用的是半正矢公式封装在高德地图的DistanceUtil中double distance AMapUtils.calculateLineDistance( new LatLng(userLat, userLng), new LatLng(shopLat, shopLng) ); boolean inScope distance shop.deliveryRadius;calculateLineDistance返回的是米deliveryRadius字段在门店表里存的是「配送半径米」的值。这里要注意一个边界问题生鲜配送和外卖不一样生鲜门店的配送半径通常在 3 公里以内超过这个范围生鲜品质无法保证。源码里店列表接口一次性返回了半径内的门店但如果你拿来做二次开发建议改成「先获取用户定位再按半径倒查门店 SQL」否则门店数量一多App 端过滤会变得越来越卡。6. 构建缓存清理、编译加速与 Kotlin 化的渐进迁移resources-debugAndroidTest.ap_、fileSnapshots.bin、classAnalysis.bin、jarAnalysis.bin这些文件都是 Gradle 在编译过程中产生的缓存快照它们存放在app/build、build目录下体积通常能占到整个工程的一半以上。拿到源码后第一件事先把这些缓存清掉否则 IDE 索引会非常慢Windows 上甚至会出现文件占用导致编译失败./gradlew clean rm -rf .gradle rm -rf build app/build注意./gradlew clean只能清理输出目录.gradle目录里保存的是任务历史和文件哈希记录如果源码是从别处拷贝过来的这些缓存里的文件路径和你本机不一致就会导致 Gradle 误判「无需编译」。编译加速方面的建议是打开构建缓存和并行编译在gradle.properties里加三行配置org.gradle.jvmargs-Xmx4096m -XX:MaxMetaspaceSize1024m org.gradle.paralleltrue org.gradle.cachingtrue但这里有个前提如果工程里的 Module 数量在三个以下org.gradle.paralleltrue反而会因为任务调度开销变慢。你可以先用./gradlew assembleDebug --profile生成一份构建报告看哪些任务耗时最长再决定是否开启。对于这套生鲜配送工程一般至少有四个业务 Module打开并行编译能节省 20% 以上的构建时间。关于 Kotlin 迁移我建议按「工具类 → 数据模型 → 页面」的顺序渐进式替换不要一把梭。先把lib_base里的 DateUtils、FileUtils 这类纯工具类用 Kotlin 重写因为它们是静态调用、依赖最少改完立刻能跑通。接着把商品、订单等数据实体类转成 Kotlin data class这些类没有复杂继承关系转换成本最低。最后再动 Activity 和 Fragment因为涉及 findViewById、点击事件、Adapter 等 Java 语法糖和 Kotlin 之间差异较大的代码一次改太多容易出编译错误。转换完数据模型后记得加JvmField注解否则 Java 代码里访问 Bean 字段的方式会变导致一堆编译报错。最后说一个比较隐蔽的坑这套源码如果是从 Windows 机器打包的build目录里可能存在大小写不敏感的文件引用拷到 Mac 或 Linux 上编译会报FileNotFoundException。出现这种情况时不要慌把~/.gradle缓存也清一遍然后重新同步绝大多数报错都能消失。本文还有配套的精品资源点击获取