简介面向Android开发学习者的智慧医疗App完整项目基于Android Studio与Java/XML构建涵盖患者信息管理、预约挂号、健康数据跟踪等常见功能模块适合课程设计、毕业设计或项目实战练手。压缩包共854个文件、69.59MB包含275个Java源码、211个XML布局与配置、262张PNG图片以及SO库、Gradle构建脚本和说明文档等目录结构清晰便于按模块查阅。已有1617人学习下载具备一定参考价值。通过这份项目可以系统理解Android工程搭建、Activity/Fragment/Service组件协作、数据持久化与UI适配等关键开发环节资源自带完整Gradle配置可直接导入Android Studio编译运行也可作为二次开发的基础框架帮助初学者缩短从零到一的上手周期。 做智慧医疗App这个项目我在技术栈上没有纠结太久直接选了Android Studio Kotlin这套原生方案。原因很简单医疗场景里的硬件对接、权限管控、数据安全要求比普通工具类App要严格得多原生开发可控性最强。整个项目从需求梳理到上架前后迭代了三个多月覆盖了预约挂号、在线问诊、检查报告查询、个人健康档案这几个核心模块下面我把从技术选型到落地的全过程拆开聊聊也给正准备做类似项目的朋友一些参考。这篇内容适合两类人一类是刚接触Android开发想找一个完整项目练手的学生或转行新人另一类是在公司或接私活时遇到医疗健康类项目需要快速了解技术方案、模块拆解和坑点的人。我会按项目推进的真实顺序来写尽量还原开发过程中的思考和取舍。1. 项目整体设计与技术选型1.1 为什么选择Android原生Kotlin在项目启动之前我也认真评估过Flutter、React Native这些跨平台方案。如果只看开发效率跨平台确实能省掉一套iOS团队的人力。但医疗App这个场景有它特殊的地方第一蓝牙设备的兼容性。智慧医疗少不了对接血压计、血糖仪、心电贴这些硬件这类外设厂商的SDK基本都是Java/Kotlin的Android原生库用跨平台框架做二次封装会多一层桥接出问题很难排查。第二系统级权限的精细控制。医疗应用涉及相机扫码、定位、通知、后台运行等敏感权限Android原生的权限模型更新很快用原生开发才能在第一时间适配新版行为变化。第三后台稳定性和保活能力。问诊过程中常常需要保持网络长连接、接收服务端推送原生Service机制配合前台服务通知保活能力和系统兼容性都是最优的。实际开发中我全程使用Kotlin而不是Java。Kotlin的空安全机制在数据解析时救了不少次协程处理异步任务比回调嵌套清爽太多代码量和可读性都有明显优势。Android Studio作为开发IDE是当前Android开发的唯一主流选择内置模拟器、布局编辑器、APK分析器、性能分析工具都很齐全整个项目从创建到调试都没有离开它。1.2 架构分层与核心依赖项目一开始我就定了MVVM架构配合Repository仓库模式。没有选更重的组件化方案因为团队规模不大业务模块之间的复用需求没有强到要拆独立Module的程度过度设计在这个阶段只会拖慢进度。依赖库这块我选了这几样核心的Retrofit2 OkHttp网络请求Retrofit的注解式API定义简洁OkHttp的拦截器机制用来做Token刷新和日志打印很方便。Kotlin协程 Flow异步任务和响应式数据流配合ViewModel处理生命周期安全。Room本地数据库用来缓存用户基本资料、挂号记录和报道消息。DataStore替代SharedPreferences存储Token、用户偏好支持协程且是异步的不会阻塞主线程。Hilt依赖注入省去大量手动管理单例和工厂类的样板代码。Coil图片加载比Glide更轻量Kotlin原生写的协程支持好。整体分层上View层只用ViewModel暴露的State状态来驱动UIViewModel通过Repository获取数据Repository内部决定数据是从网络拿还是走本地缓存。这样各层各司其职后面替换数据源或者改UI逻辑影响范围都能控制住。2. 核心功能模块拆解与数据链路设计2.1 挂号、问诊、报告这几个关键模块的逻辑先看挂号模块。用户进入科室列表选择医生和排班时间确认后创建订单并支付。这背后不只是简单的列表展示还需要处理排班状态的实时同步。比如某个时段的号已经挂满服务端要等用户重新选择。我这边用下拉刷新加分页加载的方式拉取排班列表本地同时用Room缓存最近一次成功拉取的数据这样用户在弱网环境下也能看到上一次的排班记录不至于页面白屏。在线问诊模块相对复杂因为涉及IM消息和音视频通话。IM这块服务端用WebSocket长连接推送文字消息客户端要处理消息的到达通知、离线消息补拉和消息状态同步。音视频通话我们当时接了第三方的RTC SDK这里踩了不少坑后面在问题排查部分细说。检查报告查询模块的逻辑比较直接输入报告编号或者选择日期范围从服务端拉取PDF或者图片报告。关键点是报告文件体积通常不小加载时要处理好下载进度、缓存复用、断点续传。我用OkHttp的下载拦截器配合本地文件缓存同一个报告ID只下载一次后续直接读缓存。健康档案模块则是把用户过往的体检数据、就诊记录、过敏史等信息汇总成结构化页面。这些数据源比较杂有手动录入的有第三方机构同步的也有系统从问诊记录里自动抽取的所以在数据一致性上要多做校验。UI上用一个时间轴来展示历史记录直观清楚。2.2 数据模型设计示例与缓存策略以挂号订单为例定义数据实体时要注意后端返回的时间戳服务端一般是unix时间戳客户端存储用Long类型展示时再格式化避免在不同时区机型上出现时间偏差。Entity(tableName appointment_order) data class AppointmentOrder( PrimaryKey val orderId: String, val doctorId: String, val doctorName: String, val departmentId: String, val departmentName: String, val visitDate: Long, val visitTimeSlot: String, val status: Int, // 0待支付 1已支付 2已完成 3已取消 val createTime: Long )缓存策略上我遵循一个原则列表数据优先读缓存、后台静默刷新详情数据强制走网络保证最新。这样挂号和报告列表在弱网下打开很快用户点击详情时又能看到最新状态。3. 实操过程中的关键环节实现3.1 权限适配从Android 6.0到Android 14医疗App对权限的依赖特别密集相机扫码、录音问诊、蓝牙连接设备、通知推送全都需要动态申请。Android的权限模型一年比一年严格稍微没跟上就要出事。从Android 6.0引入运行时权限开始每次系统大版本更新都有权限相关的调整。Android 11开始包的可见性受限App要声明查询包名才能拉起外部应用。Android 13把通知权限和附近的WLAN设备、蓝牙权限拆开必须在代码里单独申请。Android 14又收紧了精确闹钟和部分后台行为的权限。现在新项目我建议直接用ActivityResult API来申请权限不要再写requestPermissions加回调的老写法。示例代码private val requestPermissionLauncher registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { result - val allGranted result.values.all { it } if (allGranted) { // 权限都拿到了开始干活 } else { // 提示用户去设置页开启 } } fun checkAndRequestPermissions() { val permissions mutableListOf( Manifest.permission.CAMERA, Manifest.permission.RECORD_AUDIO ) if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { permissions.add(Manifest.permission.POST_NOTIFICATIONS) } requestPermissionLauncher.launch(permissions.toTypedArray()) }权限申请有个容易被忽略的细节Android 11及以上如果用户两次拒绝某个权限系统会把它置为“不再询问”后面再次申请时会直接弹失败。这种情况下要给用户提供一个跳转系统设置页的入口否则用户永远无法在应用内重新开启权限只能去卸载重装这个体验会非常糟。3.2 网络层封装与Token自动续期网络层我统一封装了一整套请求基类所有接口请求都通过它走。核心要处理的是Token过期后自动续期以及多个请求同时返回401时怎么避免重复刷新Token。用OkHttp拦截器的思路请求发出前检查Token是否接近过期如果即将过期就先刷新Token再带上新Token发起请求。但更稳妥的做法是响应拦截器——收到401时再主动刷新Token并把同时期被拦截的其他请求排队等Token刷新完成后再重发。我后来采用的是响应拦截加请求队列的方案class AuthInterceptor : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val request chain.request() val response chain.proceed(request) if (response.code 401) { synchronized(lock) { val newToken refreshToken() if (newToken ! null) { val newRequest request.newBuilder() .removeHeader(Authorization) .addHeader(Authorization, Bearer $newToken) .build() return chain.proceed(newRequest) } } } return response } }这里有个并发问题要重点处理如果多个接口同时返回401第一个请求刷新Token时其他请求不能也跟着去刷新否则会把前一个刷新后的Token再次覆盖。所以我在刷新Token时加了同步锁并且用一个标志位标记当前是否正在刷新其他请求在锁外面等锁释放后直接复用新的Token重发。3.3 医疗数据的本地安全存储医疗数据比普通业务数据敏感得多用户病历、体检报告、处方信息不管服务端怎么加密客户端本地存储也要有防护意识。我做了三层处理。第一层数据库加密用SQLCipher替代默认的Room数据库引擎这样本地数据库文件即使被人从手机里拷贝出来也只是一堆密文。第二层关键字段单独加密像身份证号、手机号这类敏感信息在入库之前用AES-GCM算法加密存储访问时再解密。第三层日志脱敏。开发过程中打日志很容易把用户信息打出来上线前要全项目排查一遍把所有输出敏感字段的Log统一替换成脱敏工具类。提示AES-GCM的加密密钥不要硬编码在代码里建议用Android Keystore系统生成和管理密钥密钥一旦生成就无法从设备中导出安全性有硬件级别保障。4. 常见问题与排查技巧实录4.1 构建与编译阶段的坑项目开发中后期我遇到过一个很典型的AGP版本兼容问题。Android Studio从Giraffe版本开始对AGP版本要求变了如果直接把老项目的AGP升级到8.x而Gradle插件和Kotlin版本没有同步升级编译时会报一堆莫名其妙的错误比如Failed to apply plugin或者Unsupported class file major version。我的建议是新项目尽量在官方最新稳定版Android Studio里新建让IDE自动生成兼容的Gradle、AGP、Kotlin版本组合。如果是老项目迁移先查Android Studio版本和AGP的对应关系表再统一升级不要单独升其中一个。编译慢的问题也困扰过我们。后来发现主因是依赖库太多且没有做好版本统一每次编译都要解析大量依赖。优化方式是统一用BOM管理库版本同时开启Gradle构建缓存让没有改动的模块在增量编译时直接走缓存编译时间从三分钟压到了四十秒左右。4.2 运行期问题与解决方案问诊模块的音视频通话在真机上出现过多次后台自动掉线的问题。一开始怀疑是网络问题后来发现根因是服务进程被系统回收了。Android系统在内存不足时会优先杀掉后台进程尤其是国产ROM后台管理策略非常激进。解决思路是双管齐下一方面把通话核心进程做成前台服务同时创建一个低优先级通知来维持进程存活这符合系统的前台服务规范另一方面跟ROM厂商的白名单机制做适配在App内引导用户把应用加入“自启动管理”和“后台运行白名单”。虽然这种做法不能完全保证不被杀但实测下来掉线率降低了很多。模拟器上也遇到过一个定位不准的问题。高德和百度地图的SDK在模拟器上默认会返回模拟位置但有些模拟器的GPS模拟信号不稳定导致定位结果漂移。这个问题的排查思路是先确认定位模式然后对比系统设置里的模拟位置选项。如果确认是模拟器的问题直接换真机测试是最快的方式。4.3 问题速查表整理一个我在开发过程中最常遇到的问题对照表方便大家直接对照排查问题现象可能原因解决方案构建时AGP版本报错Gradle、AGP、Kotlin版本不匹配使用Android Studio生成的标准版本组合安装后闪退无日志64位so库缺失检查jniLibs目录确认abiFilters配置Room查询报错数据库版本未升级使用Migration迁移旧表结构权限弹窗出现两次申请时机不对且未聚合权限一次合并多个权限一起申请WebSocket长连接频繁断开客户端未发送心跳包服务端配合加心跳机制30秒发送一次通知栏收不到推送Android 13未申请通知权限在TIRAMISU版本动态申请POST_NOTIFICATIONS视频通话声音异常音频焦点未正确管理通话开始时请求音频焦点结束后释放4.3.1 一个印象最深的定位问题这块单独拎出来说因为排查过程很有意思。某天测试反馈说挂号页面的“附近医院”列表定位一直在北京但我们人在上海。我一开始怀疑是高德Key配置错误检查了一遍没问题。又怀疑是网络IP定位干扰结果也不是。最后发现是测试机之前装过一款修改虚拟定位的软件它修改了系统模拟位置设置导致定位SDK一直读到缓存的模拟位置。卸载那款软件并清掉定位SDK缓存后问题立即消失。这类问题在真机测试时特别容易忽视排查时可以先检查系统设置里的“模拟位置信息”选项是否开启。5. 上架前的收尾工作与复盘5.1 签名、混淆与多渠道打包上架前我单独花了一整天处理签名和混淆这块绝不能省。签名方面如果只是个人开发用Android Studio自带的Generate Signed Bundle或APK生成签名文件就行密钥库文件一定要妥善保管并备份一旦丢失就只能重新注册包名老用户没法覆盖升级。混淆配置上要特别小心医疗相关的数据类如果字段被混淆了解析时反射拿不到对应的属性名就会导致数据丢失。我的做法是所有Model类统一加Keep注解或者把整个model包排除出混淆范围。第三方SDK的混淆规则也按官方文档逐个配置好不然上架后SDK功能会异常而且还不好排查。多渠道打包如果只需要上架应用市场其实用Gradle配置几个不同applicationId和渠道号就够了。如果渠道特别多可以用腾讯VasDolly或者Walle这类工具做快速打渠道包不用每个渠道都重新构建一次能省很多构建时间。5.2 项目复盘时间都花在哪了整个项目做下来我统计了一下各个模块的时间占比。UI开发占了约两成这块Android Studio的可视化布局编辑器帮了很大的忙。业务逻辑和接口联调占了四成这是正常的因为医疗类接口交互很复杂状态流转多。剩下四成时间全花在适配和排坑上不同Android版本、不同手机厂商的ROM、不同屏幕尺寸的适配这些都是真实项目中无法回避的成本。最后说个个人体会。做这类垂直领域的App技术本身不是最大门槛真正花时间的反而在细节打磨上权限被拒绝后引导用户如何重新开启、弱网环境下数据怎么展示才不误导用户、后台服务被杀后如何自动恢复状态、这些“看不见”的逻辑才是决定用户愿不愿意继续用下去的关键。以后如果再做类似项目我甚至会把这一套权限管理、网络层封装、前台保活方案抽成一个基础模板库放到新的项目里直接复用能省掉前期大量重复工作。本文还有配套的精品资源点击获取