简介：一份基于Android的社区居家养老服务APP完整项目源码，面向移动开发学习者、毕业设计选题者及养老服务平台开发者。APP覆盖用户注册/登录、上门看病与康复护理预约、送药配送、营养餐推荐与定时配送、血压血糖等身体数据记录、按星级选择医护人员聊天以及个人信息与密码修改等核心业务模块，可直观理解社区养老O2O服务的功能闭环与界面交互设计。包体共2000个文件，压缩后89.43MB，以XML界面布局（535个）、Java业务代码（304个）、JSON配置与网络数据（268个）、图片资源（含PNG/JPG/JPEG共300余个）为主，另有Gradle工程配置、SQL数据库脚本及Android构建产物，目录结构完整，便于导入Android Studio后阅读和二次开发。已有151人学习下载，适合具备基础Android知识、希望参考完整项目结构或进行功能扩展的开发者使用。
1. 社区居家养老APP源码：为什么“能跑起来”比“功能多”更重要
社区居家养老服务的Android APP，在毕设仓库和源码站里常年是热门品类，但绝大多数人下载完工程后卡在同一个地方：编译报错、数据库表对不上、首页能进但下单流程一走就闪退。这个标题指向的交付物，通常不是一份纯代码，而是“设计方案文档 + Android Studio工程源码”的组合，覆盖开题报告、需求分析、数据库设计、界面原型到编码实现的完整链路。它的价值不在于功能罗列，而在于给你一条可以照着复现的业务闭环：老人或家属在APP里下单，助老员端接收工单，后台管理员审核归档。适合正在找毕设题目、或者想用现成框架快速验证业务逻辑的同学——你要做的不是读懂每一行代码，而是把这条链路跑通，再按自己的需求改。
2. 拆解系统的MVP架构：模块划分与技术选型
2.1 用MVP分层，让答辩老师3分钟看懂工程结构
社区居家养老APP的常见工程结构，我建议直接照搬MVP三层，而不是一上来就上MVVM。原因很实际：这类源码包面向的是课程设计和毕业设计，答辩时老师会翻开工程问“你这个项目怎么分层的”，MVP的Model、View、Presenter三个单词就能说清楚，而MVVM的DataBinding或ViewModel反而容易被追问源码细节。另一个考量是，大多数下载下来的源码是用Java写的，MVP对Java的适配最自然，不需要额外引入生命周期组件。
View层放Activity、Fragment和Adapter，只负责渲染和点击事件；Presenter层接收View的调用，请求数据后回调刷新界面；Model层封装数据库访问和网络请求。以“服务列表”为例：HomeActivity实现一个回调接口，HomePresenter持有一个ServiceModel实例，Model里用SQLite查数据，查完通过回调把结果抛回Presenter，Presenter再调用View接口刷新RecyclerView。这样的调用链用一张图就能画出来，答辩PPT里直接放这张图比放十页代码管用。
模块划分上，养老APP通常拆成四块：登录注册、首页服务、工单跟踪、个人中心。如果你想让系统看起来更完整，再加一个健康档案模块，记录老人的血压血糖数据。但注意，模块数量控制在五个以内，每个模块的业务不超过两张表，否则答辩时被问到“这个字段为什么冗余”会很难收场。模块之间通过Activity跳转和Bundle传参通信，不做复杂的路由框架，这也是下载源码最常见、最好改的写法。
2.2 依赖配置：用这组Gradle依赖，少走三年弯路
依赖选型直接影响你能不能一次编译通过。社区居家养老APP最稳妥的组合是：网络用Volley或OkHttp，JSON解析用Gson，图片加载用Glide，列表用RecyclerView和CardView。不要为了炫技引入RxJava或Retrofit全家桶，源码下载者最怕的就是依赖版本冲突。以下是一份可以直接抄进app/build.gradle的最小依赖集：
dependencies { implementation 'com.android.support:appcompat-v7:28.0.0' implementation 'com.android.support:recyclerview-v7:28.0.0' implementation 'com.android.support:cardview-v7:28.0.0' implementation 'com.google.code.gson:gson:2.8.5' implementation 'com.github.bumptech.glide:glide:4.9.0' implementation 'com.android.volley:volley:1.1.1' }这里有两个参数值得说明。第一，support库版本统一定为28.0.0，是因为很多老源码是在Android 9时代写的，用高版本的androidx包会导致ClassNotFoundException。如果你下载的工程里已经有androidx的依赖，那就要把import android.support.*全部替换成import androidx.*，这个迁移过程最容易翻车。第二，Glide版本用4.x系列，3.x的API在Glide.with()之后必须调用into()，而4.x支持apply()配置占位图，写法上差异不小。
还有一个容易被忽略的点：工程根目录的build.gradle里，google()仓库必须写在jcenter()之前。很多老工程只配了jcenter()，在新版Android Studio里同步时直接报Could not find com.android.tools.build:gradle。常见做法是改成下面这样：
buildscript { repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.4.0' } }版本号3.4.0对应Android Studio 3.4及以后，如果你本机装的是新版Android Studio，首次同步时会提示升级Gradle插件，选“不升级继续用本地版本”即可。参数这块的底线原则是：让依赖数量和版本都跟工程原始状态保持一致，能跑就坚决不升级。
3. 数据层设计：SQLite表结构、会话缓存与图片落地
3.1 四张核心表的建表SQL，以及字段为什么这样定
数据层是整个养老APP的命门。下载源码后，你首先应该打开数据库帮助类，确认表结构和业务代码里访问的字段是否一致——这一步能避免90%的“明明编译通过但一进页面就闪退”问题。社区居家养老服务APP的核心表有四张：用户表、服务项目表、工单表、健康档案表。用户表要区分三种角色：老人、助老员、管理员，用role字段区分，而不是建三张表，否则登录逻辑会复杂到你自己都讲不清。
CREATE TABLE user ( id INTEGER PRIMARY KEY AUTOINCREMENT, phone TEXT UNIQUE NOT NULL, password TEXT NOT NULL, nickname TEXT, role INTEGER DEFAULT 0, avatar TEXT, address TEXT, emergency_contact TEXT ); CREATE TABLE service ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, category TEXT, price REAL DEFAULT 0, cover_url TEXT, description TEXT ); CREATE TABLE work_order ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, service_id INTEGER NOT NULL, worker_id INTEGER, status INTEGER DEFAULT 0, order_time TEXT, service_time TEXT, address TEXT, remark TEXT ); CREATE TABLE health_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, blood_pressure TEXT, blood_sugar TEXT, heart_rate TEXT, record_time TEXT );字段设计上有三个参数你需要特别留意。第一，work_order表里的status用整型而不是字符串，0代表已下单待派单，1代表助老员已接单，2代表服务完成，3代表已取消。用整型的好处是状态流转可以用status + 1这样的简单逻辑，而且数据库排序更快。第二，service表里的cover_url直接存网络图片地址，不存本地路径——这会连带决定图片加载用Glide还是手动BitmapFactory，用Glide就是为了支持URL直接加载。第三，health_record的字段全部用TEXT类型而不是数值类型，因为血压值往往写成“120/80”这样的字符串，用INTEGER会直接崩。
如果源码里自带的是ContentProvider封装，那是加分项；但大多数下载包都是直接写一个DBHelper继承SQLiteOpenHelper，然后在onCreate里执行execSQL。两种写法都能跑，但在答辩时，SQLiteOpenHelper反而更好讲——它就是Android官方的SQLite入口，老师不会追问ContentProvider的Uri匹配规则。
3.2 登录状态与图片缓存：SharedPreferences和Glide的分工
数据层不只有SQLite，Session状态和图片缓存同样需要处理。登录状态用SharedPreferences存一份当前用户ID和角色，这是最轻量的做法，不需要引入Token机制。以下代码是我常用的封装方式：
public class SessionManager { private static final String PREF_NAME = "user_session"; private SharedPreferences pref; private SharedPreferences.Editor editor; public SessionManager(Context context) { pref = context.getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE); } public void saveUser(int id, String role) { editor = pref.edit(); editor.putInt("user_id", id); editor.putString("role", role); editor.apply(); } public boolean isLoggedIn() { return pref.getInt("user_id", -1) != -1; } }注意editor.apply()和editor.commit()的区别：apply()是异步落盘，commit()是同步落盘。在UI线程里调用commit()会卡界面，所以这里用apply()。还有一个细节：登出时要editor.clear().apply()，而不是只删user_id字段，否则下次另一位老人登录时会读到上一个人的角色信息。
图片缓存这块，Glide的默认配置已经够用，不需要额外写磁盘缓存代码。但有一个参数建议自定义——override。服务列表的头像和服务封面图如果不清除尺寸，在低端真机上很容易把内存撑爆，表现就是列表滑动越来越卡、最终OOM。推荐在加载时加上override(200, 200)：
Glide.with(context) .load(service.getCoverUrl()) .override(200, 200) .placeholder(R.drawable.ic_default) .into(holder.coverImage);placeholder占位图在弱网环境下很有用，否则图片加载期间RecyclerView对应位置会闪白块。这里的参数逻辑很简单：缩略图尺寸和服务列表的卡片宽度保持一致，不需要加载原图。
4. 跑通核心业务链路：从服务下单到工单完成的完整实现
4.1 订单状态机：用常量定义状态，别让魔数飘在代码里
社区居家养老服务APP的业务主链路是：老人浏览服务项目→选择服务并填写预约时间→提交生成工单→助老员端看到待接单任务→接单并上门→服务完成后标记状态。这条链路里最容易出bug的是状态管理。很多源码直接在Activity里写int status = 0去判断，后续改需求时根本分不清0和1分别代表什么。正确的做法是建一个常量类：
public class OrderStatus { public static final int PENDING = 0; public static final int ACCEPTED = 1; public static final int FINISHED = 2; public static final int CANCELED = 3; }状态机的核心规则只有三条：PENDING只能流向ACCEPTED或CANCELED；ACCEPTED只能流向FINISHED；FINISHED是终态，不允许任何修改。在WorkOrderDao里写一个通用更新方法，只允许UPDATE work_order SET status = ? WHERE id = ? AND status = ?，用旧状态当作更新条件，天然防止并发操作把状态改乱。这个AND status = ?就是最简单的乐观锁，虽然没有CAS那么严谨，但单机SQLite场景下足够了。
4.2 下单与接单的关键代码：DAO层怎么避免SQL注入
下单和接单本质上都是对work_order表的写操作。如果源码里用字符串拼接SQL，比如"SELECT * FROM work_order WHERE user_id=" + id，一旦用户输入被带到SQL里就会出问题。虽然本地数据库攻击面很小，但答辩时老师可能会问“这个写法安全吗”，所以第二版代码我建议统一改成参数绑定。下面是下单方法的完整写法：
public long insertOrder(WorkOrder order) { SQLiteDatabase db = dbHelper.getWritableDatabase(); ContentValues values = new ContentValues(); values.put("user_id", order.getUserId()); values.put("service_id", order.getServiceId()); values.put("order_time", order.getOrderTime()); values.put("service_time", order.getServiceTime()); values.put("address", order.getAddress()); values.put("remark", order.getRemark()); values.put("status", OrderStatus.PENDING); return db.insert("work_order", null, values); }insert方法的返回值是long类型——新增记录的行号（rowId），如果返回-1就说明插入失败。用ContentValues而不是拼接SQL的好处是，API内部会做转义处理，单引号、分号这类特殊字符不会破坏SQL结构。需要注意：insertOrder里没有worker_id字段，因为下单时还没派单，助老员ID是后续接单操作才写进去的。接单逻辑同理，但更新时要带上worker_id：
public boolean acceptOrder(int orderId, int workerId) { SQLiteDatabase db = dbHelper.getWritableDatabase(); ContentValues values = new ContentValues(); values.put("worker_id", workerId); values.put("status", OrderStatus.ACCEPTED); int rows = db.update("work_order", values, "id=? AND status=?", new String[]{String.valueOf(orderId), String.valueOf(OrderStatus.PENDING)}); return rows > 0; }这里rows > 0是唯一的成功判断标准。如果更新影响行数为0，说明工单可能已经被其他人接走，或者状态已经被改成CANCELED，UI层就要弹提示“工单状态已变更，请刷新列表”。这个细节就是答辩时的加分点：你不是单纯调了update，而是意识到并发更新可能覆盖状态。
列表展示方面，工单列表的Adapter里同样用Glide加载服务封面图，但要注意在onBindViewHolder里避免做耗时操作，比如db.query绝不能写在getItemViewType里。下拉刷新用手势监听或者SwipeRefreshLayout都行，我建议用后者，因为它是Android官方组件，配置只需要三行代码。
5. 避坑：从导入工程到真机验证最常见的5个问题
5.1 用Android Studio导入下载的工程，报错“Gradle sync failed”
现象：从源码站下载的压缩包，解压后用Android Studio的Open按钮选择文件夹，立刻出现红色报错，Gradle同步失败。
原因：打包者用的Gradle版本和插件版本跟你本机不一致。最常见的是他本机用Gradle 4.10，而你装的是Android Studio新版自带Gradle 6.x以上。
解决：不要升级工程里的Gradle版本。进入gradle/wrapper/gradle-wrapper.properties，把distributionUrl改成你能连接到的版本，或者干脆删掉wrapper配置，让Android Studio用自己的Gradle重新生成。另一个更稳妥的办法是用Android Studio的“File → New → Import Project”导入，它会自动帮你做版本适配。
5.2 真机调试显示“The application may be doing too much work on its main thread”
现象：APP装到真机上，点击“服务下单”按钮，界面卡住几秒后弹ANR（Application Not Responding），Logcat里刷出主线程超时的警告。
原因：下订单后立刻在主线程执行了数据库写入，加上图片压缩和状态刷新，主线程忙不过来。Android的UI线程不允许做超过5秒的耗时操作。
解决：把insertOrder挪到子线程执行，用new Thread(() -> dao.insertOrder(order)).start()，回调更新UI用runOnUiThread。如果嫌Thread写法难看，用AsyncTask也行，虽然它在新版本里标了废弃，但在答辩项目里反而更好解释——老师都知道AsyncTask的三个参数是什么意思。
5.3 Android 9以上真机访问服务器图片不显示
现象：服务列表的文字正常，但所有封面图都是灰块。Logcat里看到Cleartext HTTP traffic to xxx not permitted。
原因：Android 9（API 28）开始默认禁止明文HTTP流量。如果源码里接口地址是http://开头，图片URL也是http://，都会被系统拦截。
解决：最省事的方案是在AndroidManifest.xml的<application>标签里加上android:usesCleartextTraffic="true"。这个配置允许整个APP走HTTP协议，仅限开发和演示场景用。正经上线前应该换HTTPS，但答辩演示完全够用。如果加了仍没生效，检查一下networkSecurityConfig是否单独指定了配置文件，那个文件的优先级更高。
5.4 数据库改完表结构后，老用户打开APP闪退
现象：你给user表加了emergency_contact字段，卸载重装后一切正常，但老用户（上次安装过旧版本）打开APP就崩。
原因：SQLiteOpenHelper的onUpgrade没有触发。数据库版本号DB_VERSION没递增，系统认为数据库结构没变，不会执行升级逻辑。
解决：修改DBHelper里的版本号常量，private static final int DB_VERSION = 2;，然后覆写onUpgrade方法，在方法里执行DROP TABLE IF EXISTS再重新onCreate。毕设阶段不需要做数据迁移，直接重建表是可接受的方案。但要注意，如果用户表里有测试数据，一升级就全没了，所以演示前自己得清楚这个行为。
5.5 页面底部输入框被软键盘挡住
现象：填写预约地址或备注时，输入框被弹出键盘遮住一半，点击消失后再弹又活过来。
原因：主题里没有设置adjustResize，或者页面用的是全屏沉浸式布局。键盘弹出时系统没有重新布局，直接把输入框压在下面。
解决：在AndroidManifest.xml的对应Activity上增加android:windowSoftInputMode="adjustResize"。如果已经设置了还不行，检查根布局是不是ScrollView包着表单，键盘弹出时ScrollView会自动把焦点项滚出来。这是Android的玄学问题，adjustResize和ScrollView协同才最稳。
6. 答辩前夜：用一条“黄金演示路径”把源码变成能讲的系统
源码下载下来不是终点，能跑、能讲、能应对追问才是目的。我给你的建议是不要“从头到尾演示APP里的每个功能”——那只会让老师和同学在等待中失去耐心。你需要准备一条固定的操作路径：登录老人账号→首页选服务→下单填地址→提交工单→退出登录→切换助老员账号→接单→标记完成。整条路径控制在三分钟内，每步截图存到手机相册，万一现场Wi-Fi断了，图片加载不出来，直接切相册讲流程。
验证用数据要提前造好。在service表里插入6-8条服务数据，价格梯度拉开，从50到150元都有；user表里准备两个测试账号，一个老人、一个助老员，密码简单到演示现场能30秒内输完。工单状态最好造三种——一条待派单、一条进行中、一条已完成——这样你可以在演示时展示状态列表的不同颜色标识。真机测试时先插着USB跑一遍adb shell monkey命令随机点300次，把崩溃问题提前暴露掉，别把“现场翻车”的机会留给答辩教室。
这个项目的技术深度到MVP分层加SQLite足够毕业设计了。想再往上拔一点，可以把数据库访问层换成Room，讲“Jetpack组件在传统Java项目中的渐进式落地”，这个选题方向老师很吃。如果你想走产品方向，就突出适老化设计：字体放大、图标间距、语音播报按钮，每一点都能对应到需求文档里的一句话。我最想提醒你的是：答辩前一定要在自己电脑上完整跑一遍“黄金路径”，因为教室里用的往往是你笔记本的HDMI外接屏，分辨率一变，布局可能就乱了，提前在1080P外接屏上测一遍，才不会在众目睽睽之下调整布局参数。
“基于Android的社区居家养老服务APP”这个题目，每年都有无数人做，每年也都有人因为跑不通源码而换题。把它当成一个能改、能扩展的骨架，比当成一份标准答案要值钱得多。希望这篇拆解能帮你把下载的压缩包变成真正跑在自己的设备上、讲得出逻辑的系统。
本文还有配套的精品资源，点击获取
