移动端声音追踪应用架构咨询及技术实现指导请求

一、Android端架构优化 #

• 分层解耦，用MVVM+Room替代原生SQLite
  • 拆分UI层（Activity/Fragment）、业务逻辑层（ViewModel+Repository）、数据层（Room Dao），避免把录制、存储、上传逻辑全部堆在页面类里，降低维护难度。
  • 用Room作为本地SQLite的封装，自带实体类映射、LiveData监听，能快速实现样本数据的CRUD，还能自动处理数据库升级，比原生SQLite更适合新手。
• 音频录制与位置获取的健壮性处理
  • 严格处理权限：动态申请麦克风、位置权限，拒绝权限时给出友好提示，避免崩溃。
  • 录制时增加异常捕获：处理麦克风被占用、存储空间不足等情况，录制完成后校验音频文件的完整性，无效样本不存入数据库。
  • 位置获取用FusedLocationProviderClient：仅在录制音频时获取一次位置，减少电量消耗，同时保证位置精度。
• 本地样本管理与上传可靠性
  • 给样本表新增is_uploaded状态字段，标记样本是否已上传，防止重复提交。
  • 用WorkManager执行后台上传任务：即使App退到后台或重启，也能保证攒够10个样本后完成上传，比手动开线程更稳定。
  • OkHttp请求配置：添加超时时间、重试机制，批量上传10个样本（用JSON数组或Multipart形式），减少HTTP请求次数。上传成功后批量更新本地样本的is_uploaded状态，或直接删除已上传数据。

二、后端（SpringBoot+Apache）架构优化 #

• 简化部署链路
  • 无需单独用Apache作为数据中转：直接让SpringBoot提供HTTP接口，Android端用OkHttp直接请求SpringBoot服务。如果必须保留Apache，可配置反向代理，将外部请求转发到SpringBoot的运行端口（如8080），降低部署复杂度。
• SpringBoot分层设计
  • Controller层：接收Android上传的批量样本，做参数校验（如样本数量是否为10、必填字段是否完整），返回清晰的响应状态码。
  • Service层：处理业务逻辑，用数据库事务保证10个样本要么全部存储成功，要么全部回滚，避免数据不一致。
  • Dao层：用MyBatis或Spring Data JPA操作后端数据库（推荐用MySQL，比SQLite更适合后端持久化），简化数据操作。
• Google Maps展示优化
  • 后端提供接口返回样本的位置、音频信息、文件路径等数据，前端（SpringBoot Web页面）调用Google Maps JavaScript API加载地图，用标记点展示每个样本的位置，点击标记可查看详情或播放音频。
  • 音频文件存储在后端本地文件夹或对象存储，数据库仅保存文件路径，避免数据库体积过大。

三、整体数据流转优化 #

• 批量上传的一致性保障：Android端打包10个样本为一个请求，后端用事务处理存储操作，确保数据一致性。
• 日志调试支持：Android端和后端分别添加关键流程的日志（如录制完成、存储成功、上传结果），方便新手排查问题。
• 版本兼容性：Android端适配不同系统版本的权限规则，SpringBoot选用稳定版本（如2.7.x或3.x），保证与Google Maps API的兼容性。

内容的提问来源于stack exchange，提问作者Chewie