简介这是一套面向Android开发初学者与课程设计者的社区居家养老服务APP完整源码围绕居家养老场景整合了注册登录、上门服务预约、送药配送、营养餐订购、健康数据记录、医护聊天及个人信息管理等核心模块适合作为毕业设计、课程大作业或Android综合练习的参考项目。压缩包共2000个文件约89.43MB以xml布局、flat与java业务代码、json配置、png与jpg图片资源为主另含少量jsp、so、jar及sql脚本基本覆盖一个可运行Android工程的完整结构。目前已有151人学习下载。读者可从中获取模块划分思路、界面布局写法、数据存储与网络请求组织方式以及健康数据记录、预约配送等业务逻辑的实现参考便于对照自身项目查漏补缺、快速搭建类似养老服务应用框架。1. 从一份社区居家养老服务 APP 源码说起它到底解决什么问题社区居家养老这件事真正落到代码层面核心矛盾只有一个老人不上门、子女不在场、服务人员流动大三方信息全靠电话和纸质台账在传。我接触过的几个街道级项目最初都是拿 Excel 排班护工上门签到靠微信群发定位月底对账能对到崩溃。基于 Android 的社区居家养老服务 APP 要解决的就是把「老人档案—服务工单—上门签到—健康记录—家属查看」这条链路收进一个移动端系统里让护工用手机接单、签到、拍照留痕让家属在另一端看到服务过程。这类系统的源码在网上的检索量一直不低关键词基本围绕 Android、APP、源码下载打转。但我要先把话说在前面能直接跑起来的完整商用源码极少多数是教学级 Demo 或者半成品真正值钱的是它把业务模型跑通了——老人、服务项目、工单状态机、签到地理围栏这几块的数据结构设计。你拿到源码后第一件事不是编译而是读它的表结构和状态流转判断这套模型能不能套到你自己的社区场景里。这篇笔记就按「这套系统由什么组成 → 怎么在本地跑通 → 参数怎么配 → 哪里会翻车」的顺序讲适合想自己搭一套社区养老平台的开发者、街道信息化负责人以及需要做课程设计或毕设的学生。2. 社区居家养老服务 APP 的功能拆解与数据模型2.1 四类角色与核心功能边界一套能用的社区居家养老 APP角色划分比功能堆砌重要得多。我一般会把它拆成四类角色每类角色只暴露它必须看到的界面权限收得越紧后期越省事。角色核心功能关键数据老人/家属查看服务记录、预约服务、健康数据老人档案、服务历史服务人员护工接单、上门签到、上传服务照片工单、签到记录社区管理员派单、审核、服务项目维护工单调度、服务目录系统管理员账号、权限、数据统计用户、角色、日志这里最容易做错的是把「家属」和「老人」合成一个账号。实际场景里老人往往不会用智能机操作方是子女但服务对象是老人所以档案要挂在老人身上账号要能绑定多个老人。这个一对多关系如果一开始没设计好后面加绑定功能会牵动整个用户表。服务工单是整个系统的核心实体它的状态机决定了所有页面的跳转逻辑。常见做法是设计成「待接单 → 已接单 → 服务中 → 已完成 → 已评价」五态中间允许「已取消」分支。状态流转必须由后端校验不能只靠前端按钮控制否则护工端被改包就能跳过签到直接完成工单。2.2 数据库表结构设计要点源码能不能复用八成看表设计。下面是我从多个项目里归纳出的最小可用表结构字段名做了通用化处理你可以直接对照手里的源码看它缺了哪块。-- 老人档案表一个老人一条记录家属通过 user_elder 关联 CREATE TABLE elder ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(32) NOT NULL COMMENT 老人姓名, id_card VARCHAR(18) UNIQUE COMMENT 身份证用于去重, address VARCHAR(255) COMMENT 居家地址签到围栏中心点, latitude DECIMAL(10,7) COMMENT 纬度, longitude DECIMAL(10,7) COMMENT 经度, care_level TINYINT DEFAULT 1 COMMENT 护理等级 1-3, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 服务工单表状态机字段是核心 CREATE TABLE service_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, worker_id BIGINT COMMENT 接单护工未接单为空, service_item_id BIGINT NOT NULL COMMENT 服务项目, status TINYINT DEFAULT 0 COMMENT 0待接单 1已接单 2服务中 3已完成 4已取消, appoint_time DATETIME COMMENT 预约上门时间, checkin_time DATETIME COMMENT 实际签到时间, checkin_lat DECIMAL(10,7) COMMENT 签到纬度, checkin_lng DECIMAL(10,7) COMMENT 签到经度, finish_time DATETIME, INDEX idx_worker_status (worker_id, status) );elder表里的经纬度字段是给签到围栏用的护工签到时后端要算它和老人地址的距离超过阈值就标记异常。service_order的status字段一定要建索引护工端查「我的进行中工单」是高频操作没索引在数据量上来后列表会明显卡顿。checkin_lat/lng单独存一份而不是只存工单关联是为了防止老人地址后续被修改导致历史签到记录失真这是血泪经验。2.3 服务项目与派单逻辑服务项目表看起来简单但它是计费和统计的基础。常见做法是给每个项目配一个duration标准时长和price单价工单完成时按实际时长和标准时长的比例结算。派单逻辑分两种手动派单由社区管理员指定护工自动派单按护工当前工单数和服务项目技能标签匹配。教学级源码通常只做手动派单自动派单需要额外维护护工技能表工作量不小建议一期先不做。3. 用 Android Studio 把源码在本地跑起来的最小步骤3.1 环境准备与工程导入拿到一份 Android 源码第一步不是急着点运行而是先看它的build.gradle和gradle-wrapper.properties确认 Gradle 版本和 AGP 版本。版本不匹配是导入失败的头号原因报错信息往往只给一句「Gradle sync failed」新手容易卡在这里。# 查看工程要求的 Gradle 版本 cat gradle/wrapper/gradle-wrapper.properties # 输出示例distributionUrl...gradle-7.5-bin.zip # 查看 AGP 版本在项目级 build.gradle 里 grep -r com.android.tools.build:gradle build.gradle如果本地 Android Studio 自带的 Gradle 和工程要求差一个大版本最稳的做法是让 IDE 按工程配置自动下载而不是手动改成本地版本。手动改版本经常引发插件不兼容反而更难排查。JDK 版本也要对AGP 7.x 以上要求 JDK 11AGP 8.x 要求 JDK 17用错 JDK 会在编译期报Unsupported class file major version。导入后先做一次Build Clean Project再Rebuild Project把缓存清掉。很多「找不到符号」的报错其实是增量编译缓存脏了Clean 一次就好。3.2 后端服务与数据库配置纯 Android 端源码通常带一个本地 Mock 或者需要你自建后端。如果源码里带了 Spring Boot 后端配置集中在application.yml重点改三处数据库连接、文件上传路径、签到围栏阈值。spring: datasource: url: jdbc:mysql://127.0.0.1:3306/elder_care?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 10MB # 护工上传服务照片太小会传失败 max-request-size: 20MB app: checkin: radius: 300 # 签到围栏半径单位米 allow-mock-location: false # 是否允许模拟定位生产必须 falseserverTimezone必须显式指定否则 MySQL 8 连接会报时区错误这个坑几乎每个新手都会踩一次。max-file-size默认只有 1MB护工用手机拍的服务照片动辄三四 MB不改的话上传直接抛MaxUploadSizeExceededException。签到半径 300 米是个经验值社区楼栋密集可以调到 200郊区可以放到 500设太小护工在楼下都签不上设太大围栏就失去意义了。数据库建好后用源码里的schema.sql或init.sql初始化注意字符集要选utf8mb4老人姓名里可能有生僻字utf8存不下会变成问号。3.3 真机调试与权限配置养老 APP 必须真机调试模拟器的定位和相机行为和真机差别太大。Android 6.0 以后定位、相机、存储都是运行时权限源码里如果只在AndroidManifest.xml声明了权限但没做运行时申请真机上会直接闪退。!-- AndroidManifest.xml 中必须声明的权限 -- uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.CAMERA / uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE / uses-permission android:nameandroid.permission.INTERNET /声明只是第一步代码里还要在进入签到页面前动态申请ACCESS_FINE_LOCATION用户拒绝后要有引导去设置页的兜底逻辑。我见过不少源码只声明不申请在 Android 10 以上直接拿不到定位签到功能形同虚设。另外 Android 10 起后台定位需要额外申请ACCESS_BACKGROUND_LOCATION如果护工需要后台持续上报位置这个权限绕不开但申请时要在界面上说明用途否则用户大概率拒绝。4. 签到围栏、工单状态与接口联调的参数怎么设4.1 地理围栏距离计算与阈值调优签到围栏的本质是算两个经纬度点之间的球面距离别用平面几何那套勾股定理纬度越高误差越大。标准做法是用 Haversine 公式Android 端可以直接用Location.distanceBetween后端用下面这段。// Haversine 公式计算两点球面距离返回米 public static double distance(double lat1, double lng1, double lat2, double lng2) { double R 6371000; // 地球半径米 double dLat Math.toRadians(lat2 - lat1); double dLng Math.toRadians(lng2 - lng1); double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); double c 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); return R * c; }R取 6371000 米是通用值精度足够社区场景。阈值不要写死在代码里放配置中心或数据库不同社区楼栋密度不一样能动态调才实用。签到结果建议分三档小于阈值正常签到阈值到两倍之间标记「疑似偏差」但仍允许签到并记录超过两倍直接拒绝并提示联系管理员。一刀切拒绝会让护工在信号漂移时反复签不上体验极差。4.2 工单状态流转的接口设计状态流转必须由后端做唯一裁决前端传的status只能作为「请求目标状态」后端校验当前状态是否允许跳到目标状态。下面是一个典型的状态校验逻辑。// 工单状态流转校验返回是否允许 private static final MapInteger, ListInteger TRANSITIONS Map.of( 0, List.of(1, 4), // 待接单 - 已接单 / 已取消 1, List.of(2, 4), // 已接单 - 服务中 / 已取消 2, List.of(3), // 服务中 - 已完成 3, List.of(), // 已完成终态 4, List.of() // 已取消终态 ); public boolean canTransfer(int from, int to) { return TRANSITIONS.getOrDefault(from, List.of()).contains(to); }把状态机抽成一张 Map比写一长串 if-else 好维护得多加状态只改配置。接口层面接单、签到、完成各是一个独立接口不要做成一个万能updateOrder接口否则权限校验和日志记录会乱成一团。每个接口进来先查工单当前状态再校验操作人是不是该工单的护工最后才执行流转。4.3 接口联调与数据一致性前后端联调阶段最常见的问题是时间格式和空值处理。后端返回LocalDateTime默认序列化成数组或时间戳Android 端解析容易出错统一在配置里指定格式。spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai default-property-inclusion: non_null # 空字段不返回减小包体default-property-inclusion: non_null能省不少流量但前端要能处理字段缺失的情况别默认每个字段都存在。工单列表接口建议做分页护工端一次拉 20 条足够社区管理员端可以放到 50。分页参数用pageNum/pageSize还是offset/limit要和源码保持一致中途改约定会让联调反复返工。5. 源码落地时的避坑与排查清单5.1 编译期报错Gradle 与依赖冲突现象导入工程后 Gradle sync 一直失败或者报Duplicate class冲突。原因通常是源码里同时引了多个版本的 support 库或 AndroidX 混用。解决在项目级build.gradle里强制统一版本用resolutionStrategy锁定或者把android.useAndroidXtrue和android.enableJetifiertrue写进gradle.properties让 Jetifier 自动迁移旧库。5.2 定位拿不到权限与厂商限制现象真机上签到页一直转圈日志里没有定位回调。原因有两个一是运行时权限没申请二是国产 ROM 对后台定位做了额外限制。解决先确认ACCESS_FINE_LOCATION已动态申请并授权再检查手机设置里该应用的定位权限是不是「仅前台」需要改成「始终允许」。部分厂商还需要在自启动管理里放行否则应用退到后台定位就断。5.3 图片上传失败路径与大小限制现象护工上传服务照片报 500 或超时。原因多是后端max-file-size太小或者上传目录没有写权限。解决把max-file-size调到 10MB 以上上传目录用绝对路径并确保运行用户有写权限。Android 端注意 Android 10 以后不能直接用文件路径访问相册要用MediaStore或content://URI源码里如果还在用file://会直接抛FileUriExposedException。5.4 工单状态错乱并发接单现象两个护工同时点接单都提示成功但工单只应该属于一个人。原因接单接口没有做并发控制两个请求都通过了状态校验。解决在更新工单时加乐观锁用UPDATE ... WHERE status 0判断影响行数返回 0 就说明被别人抢先了提示护工刷新。这是分布式场景下的经典问题单机部署也躲不掉。5.5 数据统计对不上时区与软删除现象月底统计服务单量和实际对不上。原因通常是时区没统一或者删除工单用了物理删除导致历史数据丢失。解决全链路统一用Asia/Shanghai数据库连接、Jackson、服务器系统时间三处都要设。删除一律用软删除加is_deleted字段统计时过滤掉这样出问题还能追溯。6. 从能跑到能用把源码改造成可交付系统的几个技巧源码跑通只是起点真正交付给社区用还得过几关。第一关是离线能力社区里老人家里信号差是常态护工签到和拍照不能强依赖网络。我的做法是本地用 Room 建一张待同步表签到先写本地网络恢复后按时间顺序补传后端接口做成幂等同一条签到记录重复提交只认第一条。这个改造工作量不大但能救回大量「签不上」的投诉。第二关是数据脱敏。老人身份证、家庭住址、健康记录都是敏感信息源码里往往是明文存储和明文传输。至少要做到传输层 HTTPS身份证在列表页只显示前六后四完整信息只有管理员能看。别嫌麻烦这类数据泄露的后果不是技术问题。第三关是护工端的操作简化。我见过太多源码把护工端做得和后台管理一样复杂护工年龄普遍偏大字要够大、按钮要够少。签到页最好只有一个大按钮点一下自动定位加拍照其他信息后端补全。字体设置上sp单位别小于 16重要按钮高度不低于 48dp。验证一套改造是否到位我一般会做三个测试断网状态下走完一次完整签到流程看数据能不能补传用两台手机同时抢同一工单看会不会重复接单把系统时间调到月底最后一天看统计报表数字对不对。这三个测试过了基本就能交付试运行了。最后说个我自己的习惯拿到任何一份源码先别改代码花半天把它的数据库 ER 图和接口清单画出来标清楚哪些是核心链路、哪些是边角功能。核心链路的代码质量决定这套系统能不能用边角功能大不了重写。我早期吃过亏上来就改 UI改到一半发现底层状态机是错的前面全白干。先读模型再动手这个顺序省下来的时间远超你想象。希望帮到你。本文还有配套的精品资源点击获取