1. 项目背景与核心价值
垃圾分类已成为现代城市治理的重要环节，而移动端应用因其便捷性成为推广垃圾分类的理想载体。这个基于SpringBoot和Android的垃圾分类系统，恰好解决了传统纸质指南更新慢、查询不便的痛点。我在实际开发中发现，将后端API与移动端结合，能够实现实时数据同步和个性化推荐，这是纯Web应用难以比拟的优势。
系统采用MVC分层架构，后端使用SpringBoot 2.7.x版本提供RESTful API，Android端通过Retrofit进行网络通信。数据库选用MySQL 8.0，主要考虑到事务支持和JSON字段处理能力，这对存储用户历史记录和分类规则非常关键。特别要说明的是，我们放弃了JPA而采用MyBatis-Plus，因为在处理复杂分类规则关联查询时，手写SQL更易优化性能。
2. 技术栈选型解析
2.1 后端技术组合
SpringBoot作为基础框架，其自动配置特性大幅减少了环境搭建时间。实测对比发现，2.7.x版本在吞吐量上比2.5.x提升约15%，特别是在垃圾图片识别API的并发处理上。关键依赖包括：
xml复制<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.3.1</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
Redis缓存的应用是个亮点。我们将变更频率低的分类规则数据缓存起来，使API响应时间从平均200ms降至80ms。缓存键设计采用分层结构：
code复制gc:rules:{cityCode}:{categoryId}
2.2 移动端技术要点
Android端采用Jetpack组件构建，值得关注的是CameraX库的使用。在垃圾拍照识别功能中，我们通过以下流程优化用户体验：
- ImageAnalysis配置YUV_420_888格式
- 使用ML Kit进行物体边缘检测
- 压缩图像至640x480分辨率
- 通过OkHttp的RequestBody上传
kotlin复制val camera = cameraProvider.bindToLifecycle(
lifecycleOwner,
cameraSelector,
previewUseCase,
imageAnalysisUseCase
)
3. 核心功能实现细节
3.1 分类规则引擎
系统最复杂的部分是动态规则引擎。我们设计了三层判断逻辑：
- 基础关键词匹配（如"电池"→有害垃圾）
- 图像特征匹配（通过ResNet18模型）
- 用户历史行为修正
数据库表设计采用纵表结构，便于规则扩展：
sql复制CREATE TABLE garbage_rules (
id BIGINT PRIMARY KEY,
keyword VARCHAR(50) COMMENT '触发关键词',
pattern VARCHAR(200) COMMENT '正则表达式',
category TINYINT COMMENT '1可回收 2有害 3厨余 4其他',
weight DECIMAL(3,2) COMMENT '匹配权重'
);
3.2 实时数据同步机制
采用WebSocket+MQTT混合方案解决网络切换问题。当检测到网络不稳定时，自动降级为MQTT协议，消息格式设计为：
json复制{
"msgId": "UUID",
"timestamp": 1630000000,
"content": {
"type": "rule_update|user_data",
"payload": {...}
}
}
4. 性能优化实战
4.1 图片识别服务优化
初始版本直接传输原图导致API超时，通过三阶段优化：
- 客户端预压缩（质量降至70%）
- 服务端启用GPU加速（CUDA 11.2）
- 引入CDN缓存识别结果
优化前后对比：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 平均耗时 | 2.3s | 680ms |
| 成功率 | 82% | 95% |
| 内存占用 | 1.2GB | 450MB |
4.2 数据库查询优化
针对高频查询的规则匹配接口，我们重构了索引策略：
sql复制ALTER TABLE garbage_rules
ADD INDEX idx_keyword_category (keyword, category)
USING BTREE;
配合EXPLAIN分析，使复杂查询从全表扫描变为索引覆盖，QPS从120提升到350。
5. 典型问题解决方案
5.1 混合垃圾识别难题
当用户拍摄包含多种垃圾的照片时，系统通过以下流程处理：
- 图像分割（使用OpenCV的GrabCut算法）
- 区域特征提取
- 多标签分类
- 结果聚合排序
关键代码片段：
java复制public List<RecognitionResult> processMixedImage(Mat src) {
List<Mat> segments = imageSegmenter.segment(src);
return segments.stream()
.map(segment -> {
FeatureVector vector = featureExtractor.extract(segment);
return classifier.predict(vector);
})
.sorted(Comparator.comparingDouble(RecognitionResult::getConfidence).reversed())
.collect(Collectors.toList());
}
5.2 离线模式支持
考虑到垃圾投放点可能网络不佳，我们实现了SQLite本地缓存方案：
- 首次启动下载基础规则库
- 增量更新通过DiffMatchPatch算法
- 采用LRU策略管理缓存
数据同步状态机设计：
mermaid复制stateDiagram
[*] --> Idle
Idle --> Syncing : 网络恢复
Syncing --> Merging : 收到数据
Merging --> Idle : 完成
Syncing --> Error : 超时
Error --> Idle : 重试成功
6. 部署与监控方案
6.1 容器化部署
使用Docker Compose编排服务，关键配置：
yaml复制services:
app:
image: openjdk:17-jdk
volumes:
- ./logs:/var/log/app
environment:
- SPRING_PROFILES_ACTIVE=prod
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
interval: 30s
redis:
image: redis:6-alpine
command: redis-server --save 60 1 --loglevel warning
6.2 监控指标设计
通过Micrometer暴露以下关键指标：
garbage.classify.duration：分类耗时百分位api.error.count：按错误类型统计cache.hit.ratio：Redis缓存命中率
Grafana面板配置示例：
code复制sum(rate(api_error_count{exception!~"None"}[5m])) by (exception)
7. 扩展开发建议
基于现有系统，可以进一步扩展：
- 语音查询功能：集成ASR服务
- 投放指引：结合ARCore实现3D导航
- 积分系统：区块链记录环保行为
在实现AR导航时，需要注意：
安卓不同机型对ARCore的支持差异较大，建议先进行设备能力检测：
kotlin复制fun checkARAvailability(context: Context): Boolean {
return when (ArCoreApk.getInstance().checkAvailability(context)) {
ArCoreApk.Availability.SUPPORTED_INSTALLED -> true
ArCoreApk.Availability.SUPPORTED_APK_TOO_OLD,
ArCoreApk.Availability.SUPPORTED_NOT_INSTALLED -> {
try {
ArCoreApk.getInstance().requestInstall(context, true)
true
} catch (e: Exception) {
false
}
}
else -> false
}
}
这个项目最让我意外的是用户对拍照识别的依赖程度——超过60%的查询通过图像完成而非文本输入。因此在第二期开发中，我们重点优化了图像处理流水线，将识别准确率从78%提升到93%。建议后续开发者可以尝试集成更大的视觉模型，虽然会牺牲一些启动速度，但能显著提升复杂场景下的识别效果。