Android智慧健康养老系统毕设：从架构设计到关键模块实现-育师

最近在辅导学弟学妹做毕设时，发现一个挺普遍的现象：很多同学在做“智慧健康养老”这类Android应用时，容易陷入“功能大杂烩”的困境。想法很多，健康监测、紧急呼叫、用药提醒、社区活动……恨不得全塞进去，结果代码结构混乱，各个功能模块的数据互不相通，成了一个个“数据孤岛”。更关键的是，很多设计脱离了真实场景，比如健康数据全靠手动输入，没有考虑如何与真实的传感器（如手环、血压计）集成，导致项目看起来“很丰满”，评审时却经不起推敲。

所以，我想结合一个具体的“Android智慧健康养老系统”毕设案例，和大家系统地聊聊，如何从零开始，构建一个结构清晰、可扩展、且能体现一定技术深度的项目。我们的目标不是堆砌功能，而是打造一个“轻量级但完整”的应用，重点覆盖健康监测、紧急呼叫和用药提醒三大核心场景。

1. 先想清楚：你的系统到底要解决什么问题？

在动手写代码之前，我们先得把思路理清。一个典型的毕设痛点就是需求模糊。为了避免这个，我们可以先明确系统的核心用户（老人）和核心关怀者（子女或护工）分别需要什么：

对老人：操作必须极其简单，信息展示直观，在紧急情况下能一键求助。
对关怀者：能远程、清晰地了解老人的健康状况（如心率、血压趋势），及时收到异常提醒和用药提醒。

基于此，我们可以将系统核心功能收敛为：

健康数据看板：展示最近的心率、血压、步数数据。数据来源可以是手动录入，也可以是（作为技术亮点）模拟蓝牙设备上传。
紧急呼叫：界面有巨大、醒目的“一键呼叫”按钮，触发后能自动发送包含位置信息的短信或通知给预设联系人。
智能用药提醒：允许关怀者为老人设置服药计划，到点后在手机上弹出无法忽略的提醒。

明确了功能，接下来就要为这些功能选择合适的技术“砖瓦”。

2. 技术选型：用对工具，事半功倍

这里列举几个毕设中常见的技术抉择点，选对了能让你的代码质量提升一个档次。

本地数据库：Room vs SQLiteOpenHelper强烈推荐使用Room。它虽然是SQLite的封装，但提供了编译时SQL检查、方便的ORM（对象关系映射）支持和直接与LiveData/Flow配合的能力。对于存储老人健康记录、用药计划这种结构化数据，Room能让你避免大量模板代码和运行时SQL错误。

// 使用Room定义一个健康数据实体和数据访问对象（DAO） @Entity(tableName = “health_records”) data class HealthRecord( @PrimaryKey(autoGenerate = true) val id: Long = 0, val type: String, // 如 “heart_rate”, “blood_pressure” val value: String, // 如 “72”, “120/80” val timestamp: Long // 记录时间戳 ) @Dao interface HealthRecordDao { @Query(“SELECT * FROM health_records WHERE type = :type ORDER BY timestamp DESC LIMIT 10”) fun getRecentRecordsByType(type: String): Flow<List<HealthRecord>> @Insert suspend fun insert(record: HealthRecord) }

上面这段代码就定义了数据表和基本操作，清晰且安全。

后台定时任务：WorkManager vs AlarmManager对于“定时用药提醒”这种需求，应该使用WorkManager。它是Android推荐的用于处理可延迟的、保证会执行的后台任务API。相比古老的AlarmManager，WorkManager更省电，能兼容不同的Android版本，并且会在设备重启后重新调度任务。AlarmManager更适合需要精确到秒的闹钟类应用，但对于提醒任务，WorkManager的灵活性更合适。

3. 核心模块实现拆解

现在，我们进入具体的实现环节。

模块一：健康数据采集与本地存储数据采集可以设计为两种方式：

手动录入：提供简单的表单界面，输入数值后保存。
模拟设备上传：这是体现技术亮点的部分。可以模拟一个蓝牙低功耗（BLE）设备，在Android应用中扮演“中央设备”角色，扫描并“连接”到一个虚拟的健康设备服务，接收模拟的数据流。即使没有真设备，这个过程也能展示你对BLE API的理解。

数据存储就用上面提到的Room。当数据插入数据库后，通过Flow自动通知UI层更新图表或列表。

模块二：坚不可摧的用药提醒机制这是系统的核心体验之一，务必可靠。

设置计划：让用户选择药品、服药时间、重复周期（每天、每周特定几天）。

调度任务：当用户保存一个计划时，立即使用WorkManager调度一个一次性的或周期性的工作请求。

// 创建提醒任务 val reminderWorkRequest = OneTimeWorkRequestBuilder<ReminderWorker>() .setInitialDelay(calculateDelayToNextReminder(), TimeUnit.MILLISECONDS) .setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build()) .addTag(“medication_reminder_${planId}”) // 方便后续取消 .build() WorkManager.getInstance(context).enqueue(reminderWorkRequest)

执行提醒：在ReminderWorker的doWork()方法中，创建一条高优先级的通知（使用NotificationChannel），并可能伴随振动和声音。
处理跳过/完成：通知中应包含“标记为已服用”和“跳过”的按钮（通过PendingIntent实现），点击后更新计划状态，并可能取消后续提醒。

模块三：一键紧急呼叫这个功能的关键是“快”和“准”。

界面：在主屏幕放置一个颜色鲜艳、面积大的按钮。
逻辑：点击按钮后，立即获取设备最后一次已知位置（使用FusedLocationProviderClient，注意权限处理）。
发送：将位置信息（经纬度或转换后的粗略地址）和求助信息，通过SmsManager发送给预设的联系人电话号码列表。务必在非UI线程执行发送操作。同时，也可以在应用内弹出一个确认对话框，防止误触。

4. 别忘了性能与隐私安全

毕设答辩时，如果能提到这些点，会很加分。

敏感数据加密：老人的健康数据、联系人电话是敏感信息。数据库密码、存储在SharedPreferences中的令牌等，不应明文存储。可以考虑使用Android Keystore系统来生成和存储加密密钥，对敏感数据进行加密后再存入数据库或本地文件。
后台任务合规性：Android对后台执行限制越来越严。我们使用的WorkManager是符合规范的最佳实践。避免使用Service进行长期后台轮询，尤其是对于非核心功能。
权限最小化：只在需要时申请权限（如发送短信、访问位置），并清晰地向用户解释用途。对于Android 6.0+，做好运行时权限请求的处理。

5. 生产环境避坑指南

这些是开发中容易踩坑的地方，提前了解能省很多调试时间。

Android 10+分区存储适配：如果你的应用需要保存用户服药的图片，或者导出健康报告，就不能再随意访问外部存储了。必须使用MediaStoreAPI来保存公共媒体文件，或者将文件保存在应用专属目录（Context.getExternalFilesDir()）内。
低功耗蓝牙连接稳定性：如果实现了模拟BLE设备连接，要注意蓝牙连接是易失的。代码中必须包含完善的连接状态监听、错误处理和重连机制。例如，在onConnectionStateChange回调中处理连接断开的情况，并尝试重新连接或通知用户。
通知渠道：Android 8.0以上，所有通知都必须分配到一个渠道。你需要为“用药提醒”和“系统提醒”创建不同的渠道，让用户可以分别管理它们的优先级和是否响铃。
应用后台限制：在手机厂商定制系统上，你的应用可能被“电池优化”或“后台清理”干掉。对于关键的后台提醒服务，需要引导用户手动在系统设置中豁免你的应用，并在代码中检查电池优化状态（PowerManager.isIgnoringBatteryOptimizations）。