简介这是一套面向中医大夫的Android应用源码实现病历管理、处方记录、中医药知识查询等助理功能适合希望掌握Android业务系统开发的中级学习者。压缩包共125个文件大小仅1.55MB既包含20个Java源文件、49个class字节码、16个XML界面布局与10个SQL数据库脚本也附带可直接安装的APK文件便于对照源码快速运行。目前已有172人学习/下载。通过研读项目可系统梳理Android开发中Activity生命周期、SQLite数据持久化、网络请求、运行时权限管理等核心知识点同时项目将中医诊疗场景与移动端信息管理深度融合从界面设计到业务逻辑分层都有完整实现对开发医疗健康类应用具有直接借鉴价值。整体包体虽小但目录结构涵盖UI、数据、工具等模块适合用于源码剖析与二次开发练习。1. 拿到 zz-doctor 这个安卓源码包先别急着解压“android应用源码zz-doctor中医大夫助理信息系统源码.zip”是一类很典型的交付物文件名里把技术平台、项目代号、业务定位和打包方式全写明白了内容是一个面向中医门诊场景的安卓应用工程。zz-doctor 要解决的不是挂号排班而是大夫日常的高频动作——患者建档、症状录入、辨证记录、参考方剂、复诊追踪。对刚接触安卓源码的开发者来说它比纯 Demo 多了一层业务数据流对做过一两年工程的熟手而言它值得看的反而是数据库设计和构建配置。这类 zip 从下载到跑起来最容易出问题的环节是解压编码、Gradle 版本和 SDK 平台缺失而不是代码本身。下面按“从 zip 到 APK”的顺序把解压校验、工程导入、结构分析、二次改动、命令行构建五段讲清楚每一步都给出可直接执行的命令和参数。2. 从zip到可编译工程校验、解压与 Android Studio 导入2.1 解压前先列目录确认文件名编码与完整性“源码.zip”这种交付方式最大的坑不在代码而在压缩包本身。常见 zip 是在 Windows 下用 7-Zip 或 Bandizip 打的文件名编码常用 GBK而 Android Studio 跑在 macOS 或 Linux 上时默认 unzip 按 UTF-8 解释解压出来的中文目录名就会乱码。zz-doctor 的项目路径是 ASCII风险低一些但如果 res 目录里出现中文资源名导入后布局文件可能直接找不到资源。建议的做法是先列目录再决定用哪个工具解压不要双击就解。用命令行可以同时完成查看和完整性校验# 先查看压缩包内文件清单-l 只列目录不解压 unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip # 检查是否存在路径穿越文件名带 ../摘取第四列后过滤 unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip | awk {print $4} | grep -E \.\./|^/ # 解压前做一次完整性与 CRC 校验-q 表示安静模式只报错 unzip -tq android应用源码zz-doctor中医大夫助理信息系统源码.zip第二段命令的逻辑unzip -l输出的第四列是文件名awk {print $4}只摘取文件名grep -E \.\./|^/用来找出向上跳目录或以根路径开头的条目。若输出为空说明包内路径安全。-tq这一步不要省源码包体积超过 100MB 时传输过程经常发生后段数据损坏解压到一半报错还算好的怕的是解压成功但某个 class 文件缺了尾部字节Gradle 编译时才会报ClassNotFoundException排查成本反而更高。提示Windows 上也可以用 PowerShell 的Expand-Archive解压但它对 GBK 编码文件名的处理并不理想。遇到中文乱码目录时优先用 Bandizip 或 7-Zip 打开并在解压选项里把文件名编码切到 ANSI/GBK。2.2 用 Android Studio 打开前先判断是完整工程还是裸源码解压后先看根目录长什么样再决定怎么导入。区分标准用下表最直接根目录存在的文件工程形态导入方式settings.gradle、gradlew、app/完整 Gradle 工程File → Open 选根目录只有src/、res/、AndroidManifest.xml裸源码目录新建工程后迁移只有散落的.java/.kt文件示例代码只能建模块引用多数命名为“xxx源码.zip”的交付是第一种但行业应用的源码包有时只导出app/src/main漏掉了 Gradle wrapper。此时不要直接双击.java文件去看代码——语法高亮不等于工程可编译。在 Android Studio 里新建一个空 Activity 工程把java目录、res目录和AndroidManifest.xml拷贝到新工程对应位置再改包名和依赖这才是裸源码的正确接法。Android Studio 的界面语言可以在Settings → Plugins里安装“Chinese (Simplified) Language Pack”插件重启后变成中文菜单但 Gradle 日志和代码提示仍是英文排错时看着原始报错反而更容易搜到解决方案不必强求全中文。2.3 Gradle 与 AGP 版本匹配一半的导入失败发生在这里第一次 Sync 时最常见的报错是 “Minimum supported Gradle version is X.X.X”。这是因为gradle-wrapper.properties里的 Gradle 版本与build.gradle里声明的 Android Gradle Plugin 版本不匹配。以 zz-doctor 这类较老的中医业务工程为例如果插件版本是 4.x 或 7.0而你的 Android Studio 是最新版本不要直接把插件升到 8.x——老工程里的compile依赖写法、Android配置块在 AGP 8 下会大面积报错。打开gradle/wrapper/gradle-wrapper.properties确认 distributionUrldistributionUrlhttps\://services.gradle.org/distributions/gradle-7.5-bin.zip参数说明distributionUrl决定 Gradle 运行时版本build.gradle里的com.android.tools.build:gradle:7.4.2决定 AGP 版本。两者对应关系是固定的常用组合如下AGP 版本最低 Gradle 版本建议 compileSdk7.1.x7.2327.4.x7.5338.2.x8.234如果下载 Gradle 发行包时遇到 “invalid zip archive: could not find eocd” 报错原因通常是~/.gradle/wrapper/dists目录下缓存了损坏的 zip。eocd 是 zip 格式的中央目录结束标记读不到说明文件不完整。处理办法是删掉本地 wrapper 缓存重新下载# macOS / Linux 下删除 Gradle wrapper 与依赖缓存 rm -rf ~/.gradle/wrapper/dists rm -rf ~/.gradle/caches/modules-2删除后回到 Android Studio 点击Sync Project with Gradle Files。如果官方分发地址下载慢可以把 distributionUrl 换成国内云厂商的 Gradle 镜像地址这属于公共基础设施加速不影响工程行为但要注意镜像路径下必须存在对应版本目录。2.4 SDK 平台缺失与三处源码联动报错Gradle 版本对上以后编译还卡在 SDK 上。老项目的compileSdkVersion往往写的是 28、30而新安装的 Android Studio 只自带最新平台。打开 SDK Manager勾选对应版本即可命令行环境下则用 sdkmanager 安装# 安装 compileSdk 对应的平台版本Y 表示接受许可 sdkmanager platforms;android-33 build-tools;33.0.2SDK 就绪后再看三处源码联动问题app/libs/里有本地 jar 但build.gradle没写implementation fileTree(dir: libs, include: [*.jar])applicationId和AndroidManifest.xml里的包名不一致项目用了 Java 8 语法但没开compileOptions。这三处在源码 zip 里出现频率最高同步报错时按 dependencies、manifest、compileOptions 的顺序逐个排查比看堆栈更有效。工程同步通过之后先别急着改代码。把项目结构完整读一遍评估源码包是否值得继续投入再谈二次开发。3. 拆解 zz-doctor 的工程结构中医大夫助理系统的数据流3.1 从分包反推模块zz-doctor 的典型 Android 分层对“大夫助理”这类业务系统代码组织通常逃不出三层界面层、数据层、工具层。如果让我重新组织一个同类型项目我会把包结构设计成下面这样拿到源码包时也按这个思路去对照com.zz.doctor ├── ui # Activity / Fragment / Adapter │ ├── login # 登录与账号切换 │ ├── patient # 患者列表与建档 │ └── prescription # 处方录入与参考方剂 ├── data # 数据层 │ ├── db # SQLiteOpenHelper 与建表语句 │ ├── model # 实体 Bean │ └── repository # 数据仓储 ├── service # 复诊提醒等后台服务 └── utils # 日期、字符串等工具这种分层的核心价值是引用方向单向UI 依赖 AdapterAdapter 依赖 Entity数据不反向流动。读源码时我习惯先在 Android Studio 里用Call Hierarchy快捷键 CtrlAltH追踪一个点击事件比如“点击患者列表项后发生了什么”链路短就说明工程结构健康链路绕了三层 Activity 还没到底层数据就要警惕后续改动会牵一发动全身。3.2 患者建档与辨证记录SQLite 表设计的关键字段业务系统的重心在数据库。zz-doctor 这类不依赖云端的中医助理应用用 SQLite 落地的表至少有四张患者表、病历表、处方表、药材表。如果由我从头设计初版建表语句会写成这样CREATE TABLE patient ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, gender INTEGER DEFAULT 0, birth_date TEXT, phone TEXT, remark TEXT, created_at TEXT DEFAULT (datetime(now,localtime)) ); CREATE TABLE medical_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER NOT NULL, symptom TEXT, -- 主诉症状 tongue TEXT, -- 舌象 pulse TEXT, -- 脉象 diagnosis TEXT, -- 辨证结论 create_time TEXT DEFAULT (datetime(now,localtime)), FOREIGN KEY (patient_id) REFERENCES patient(id) ON DELETE CASCADE ); CREATE TABLE herb ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, property TEXT, -- 药性寒热温凉平 flavor TEXT, -- 药味酸苦甘辛咸 category TEXT -- 分类解表、补气等 );索引策略和普通 CRM 不一样中医门诊查询量小但会频繁按patient_id拉取历次病历时间线所以联合索引建在medical_record(patient_id, create_time)上。herb表的category字段不要建索引——药材表几百行全表扫描比维护索引 B 树快得多。数据层和界面层之间建议加 repository 做转换不让SQLiteCursor直接暴露给 Adapter。Cursor 的列索引可读性差每个页面都要重复写moveToFirst和getColumnIndex一旦表结构微调改起来是全局性的痛苦。3.3 大夫工作台的状态流转从待诊列表到处方提交如果只把 zz-doctor 理解成增删改查会错过它真正的核心——工作流支持。接诊流程在 UI 上是登录进入工作台 → 查看今日待诊列表 → 选择患者 → 查看历次辨证记录 → 录入本次症状与舌脉 → 生成参考方剂 → 大夫确认后落库。这个流程在工程实现里最常见的坑是跨界面传参。Activity A 跳 B 时把整个 PatientBean 对象塞进 IntentB 再跳 C 时又传一次——对象一旦变大序列化开销增加而且 C 界面拿到的是旧数据。我一般只传主键 IDC 界面在onCreate里通过 ID 重新查一次 SQLite既保证数据新鲜也避免大对象序列化的性能问题。另一个隐蔽点接诊完成后按返回键回工作台工作台列表必须重查数据库而不是复用进入前的数据。没写onResume重新加载的话刚保存的病历不会出现在列表里用户会以为保存失败了。4. 在 zz-doctor 里做二次开发列表、数据库与业务逻辑4.1 患者列表加科室筛选从 BaseAdapter 到增量刷新相当一部分课程设计源码还在用 ListView 加 BaseAdapter。ListView 不是不能跑而是状态维护麻烦列表项复用逻辑写错会闪烁全量刷新在数据量上来后有明显卡顿。如果 zz-doctor 里已经是 RecyclerView改造空间在 DiffUtil如果是 ListView优先保留原结构在 Activity 层做筛选反而更稳。给患者列表加一个“按科室过滤”的按钮最直接的写法是filterButton.setOnClickListener(v - { ListPatientBean filtered new ArrayList(); for (PatientBean p : allPatients) { if (selectedDepartment.equals(p.getDepartment())) { filtered.add(p); } } adapter.setData(filtered); // 适配器内部替换数据源 adapter.notifyDataSetChanged(); // 触发列表重绘 });代码逻辑说明allPatients是 Activity 启动时从 repository 拉取的全量数据筛选操作不重新查询数据库而是对内存列表做条件过滤。setData替换 Adapter 持有的引用notifyDataSetChanged强制列表重绘。这样改的好处是保留原有数据源清空筛选时把allPatients重新塞回去即可。如果列表项包含图片比如患者头像全量重绘会有明显闪烁。此时可以把 Adapter 换成ListAdapter配合DiffUtil做差值计算areItemsTheSame比较 idareContentsTheSame比较业务字段列表更新只刷新变化的行。改动量不大但体验提升明显。4.2 数据库加字段改了 CREATE TABLE 别忘 onUpgrade二次开发中最常见的需求是加字段比如给patient表增加allergy_history。直接改建表语句重装应用没意义线上用户的数据会清空。正确姿势是把DBHelper里的DATABASE_VERSION从 1 改成 2并在onUpgrade里加迁移override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) { if (oldVersion 2) { // 用户从 v1 升级到 v2新增过敏史字段 db.execSQL(ALTER TABLE patient ADD COLUMN allergy_history TEXT DEFAULT ) } // 后续 v3、v4 继续用 if 累加不能用 else if }参数说明oldVersion是当前安装版本的数据库版本号newVersion是代码里定义的新版本号。onUpgrade里的判断必须用连续的if而不是else if这样用户从 v1 直升 v3 时v2 的迁移逻辑也会被执行。注意SQLite 的ALTER TABLE ADD COLUMN不支持回滚上线前先备份旧库。另外它只能加列不能改列名、删列这类操作只能“建新表 → 导数据 → 删旧表 → 重命名”四步走。4.3 处方建议逻辑把“推荐”和“决策”分开zz-doctor 作为“助理”系统处方建议模块最容易写成硬编码。如果代码里是一长串 if-else 拼接常用方剂名后续调整会很痛苦。我会把这个逻辑抽成独立类返回候选药材集合而非最终处方public class PrescriptionSuggest { public ListHerbBean suggest(String diagnosis) { if (diagnosis.contains(风寒)) { return herbDao.queryByCategory(解表); } if (diagnosis.contains(气虚)) { return herbDao.queryByCategory(补气); } return herbDao.queryDefault(); } }这个方法的参数diagnosis是大夫录入并经辨证后的结论文本返回值是候选药材集合。界面拿到候选集后展示给大夫勾选勾选结果才写进prescription表。“推荐”和“决策”分层是医疗信息系统必须保留的边界算法只能辅助最终确认必须交给人。修改时也要注意contains的误命中比如“气虚”会被“气虚血瘀”命中如果想精确匹配可以改成按关键词集合过滤。5. 用命令行把 zz-doctor 构建成 APK 并做交付前检查5.1 命令行构建与 APK 输出路径Android Studio 里点 Run 按钮谁都会但交付、备份、CI 场景下还是命令行更可控。工程根目录下执行# 构建 debug 包跳过单测和 lint 加速 ./gradlew assembleDebug -x test -x lint # 构建 release 包需要已配置 signingConfigs ./gradlew assembleRelease构建产物位于app/build/outputs/apk/debug/app-debug.apk或app/build/outputs/apk/release/下。首次构建慢是正常的主要耗时在依赖下载和 Transform 流程不代表代码有问题。5.2 真机运行前检查五个易漏点AndroidManifest.xml是否声明了INTERNET、READ_EXTERNAL_STORAGE等权限安卓 11 以上读写公共目录还需要MANAGE_EXTERNAL_STORAGE并引导用户到设置页授权。targetSdkVersion是否过高高于 30 且未适配分区存储时文件访问会静默失败表现为导出病历无反应。药材库是否预置。如果运行时在onCreate里循环插入几百条药材数据冷启动会很慢正式交付应把预置库.db文件放到assets/首次启动时复制到databases/目录。主 Activity 的exported是否为true否则桌面点击图标会提示找不到入口 Activity。真机调试时先用adb devices确认设备被识别并检查 USB 调试授权弹窗是否被点掉了。5.3 二次交付打一个干净的可编译 zip最后一步是把改动后的源码打包回传。打包前务必要排除构建产物和本地配置文件zip -r zz-doctor-v2-src.zip . -x */build/* -x */.gradle/* -x *.iml -x .idea/*命令解释-x后跟排除通配符*/build/*匹配任意层级的 build 目录.idea/*排除本地 IDE 配置。构建产物目录常有几 GB排除后源码包能缩到几十 MB同时接收方解压后不会看到别人的本地 SDK 路径直接进入 Sync 环节即可重新构建。本文还有配套的精品资源点击获取 zz-doctor中医大夫助理系统源码解析：从zip到APK的构建与二次开发
简介这是一套面向中医大夫的Android应用源码实现病历管理、处方记录、中医药知识查询等助理功能适合希望掌握Android业务系统开发的中级学习者。压缩包共125个文件大小仅1.55MB既包含20个Java源文件、49个class字节码、16个XML界面布局与10个SQL数据库脚本也附带可直接安装的APK文件便于对照源码快速运行。目前已有172人学习/下载。通过研读项目可系统梳理Android开发中Activity生命周期、SQLite数据持久化、网络请求、运行时权限管理等核心知识点同时项目将中医诊疗场景与移动端信息管理深度融合从界面设计到业务逻辑分层都有完整实现对开发医疗健康类应用具有直接借鉴价值。整体包体虽小但目录结构涵盖UI、数据、工具等模块适合用于源码剖析与二次开发练习。1. 拿到 zz-doctor 这个安卓源码包先别急着解压“android应用源码zz-doctor中医大夫助理信息系统源码.zip”是一类很典型的交付物文件名里把技术平台、项目代号、业务定位和打包方式全写明白了内容是一个面向中医门诊场景的安卓应用工程。zz-doctor 要解决的不是挂号排班而是大夫日常的高频动作——患者建档、症状录入、辨证记录、参考方剂、复诊追踪。对刚接触安卓源码的开发者来说它比纯 Demo 多了一层业务数据流对做过一两年工程的熟手而言它值得看的反而是数据库设计和构建配置。这类 zip 从下载到跑起来最容易出问题的环节是解压编码、Gradle 版本和 SDK 平台缺失而不是代码本身。下面按“从 zip 到 APK”的顺序把解压校验、工程导入、结构分析、二次改动、命令行构建五段讲清楚每一步都给出可直接执行的命令和参数。2. 从zip到可编译工程校验、解压与 Android Studio 导入2.1 解压前先列目录确认文件名编码与完整性“源码.zip”这种交付方式最大的坑不在代码而在压缩包本身。常见 zip 是在 Windows 下用 7-Zip 或 Bandizip 打的文件名编码常用 GBK而 Android Studio 跑在 macOS 或 Linux 上时默认 unzip 按 UTF-8 解释解压出来的中文目录名就会乱码。zz-doctor 的项目路径是 ASCII风险低一些但如果 res 目录里出现中文资源名导入后布局文件可能直接找不到资源。建议的做法是先列目录再决定用哪个工具解压不要双击就解。用命令行可以同时完成查看和完整性校验# 先查看压缩包内文件清单-l 只列目录不解压 unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip # 检查是否存在路径穿越文件名带 ../摘取第四列后过滤 unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip | awk {print $4} | grep -E \.\./|^/ # 解压前做一次完整性与 CRC 校验-q 表示安静模式只报错 unzip -tq android应用源码zz-doctor中医大夫助理信息系统源码.zip第二段命令的逻辑unzip -l输出的第四列是文件名awk {print $4}只摘取文件名grep -E \.\./|^/用来找出向上跳目录或以根路径开头的条目。若输出为空说明包内路径安全。-tq这一步不要省源码包体积超过 100MB 时传输过程经常发生后段数据损坏解压到一半报错还算好的怕的是解压成功但某个 class 文件缺了尾部字节Gradle 编译时才会报ClassNotFoundException排查成本反而更高。提示Windows 上也可以用 PowerShell 的Expand-Archive解压但它对 GBK 编码文件名的处理并不理想。遇到中文乱码目录时优先用 Bandizip 或 7-Zip 打开并在解压选项里把文件名编码切到 ANSI/GBK。2.2 用 Android Studio 打开前先判断是完整工程还是裸源码解压后先看根目录长什么样再决定怎么导入。区分标准用下表最直接根目录存在的文件工程形态导入方式settings.gradle、gradlew、app/完整 Gradle 工程File → Open 选根目录只有src/、res/、AndroidManifest.xml裸源码目录新建工程后迁移只有散落的.java/.kt文件示例代码只能建模块引用多数命名为“xxx源码.zip”的交付是第一种但行业应用的源码包有时只导出app/src/main漏掉了 Gradle wrapper。此时不要直接双击.java文件去看代码——语法高亮不等于工程可编译。在 Android Studio 里新建一个空 Activity 工程把java目录、res目录和AndroidManifest.xml拷贝到新工程对应位置再改包名和依赖这才是裸源码的正确接法。Android Studio 的界面语言可以在Settings → Plugins里安装“Chinese (Simplified) Language Pack”插件重启后变成中文菜单但 Gradle 日志和代码提示仍是英文排错时看着原始报错反而更容易搜到解决方案不必强求全中文。2.3 Gradle 与 AGP 版本匹配一半的导入失败发生在这里第一次 Sync 时最常见的报错是 “Minimum supported Gradle version is X.X.X”。这是因为gradle-wrapper.properties里的 Gradle 版本与build.gradle里声明的 Android Gradle Plugin 版本不匹配。以 zz-doctor 这类较老的中医业务工程为例如果插件版本是 4.x 或 7.0而你的 Android Studio 是最新版本不要直接把插件升到 8.x——老工程里的compile依赖写法、Android配置块在 AGP 8 下会大面积报错。打开gradle/wrapper/gradle-wrapper.properties确认 distributionUrldistributionUrlhttps\://services.gradle.org/distributions/gradle-7.5-bin.zip参数说明distributionUrl决定 Gradle 运行时版本build.gradle里的com.android.tools.build:gradle:7.4.2决定 AGP 版本。两者对应关系是固定的常用组合如下AGP 版本最低 Gradle 版本建议 compileSdk7.1.x7.2327.4.x7.5338.2.x8.234如果下载 Gradle 发行包时遇到 “invalid zip archive: could not find eocd” 报错原因通常是~/.gradle/wrapper/dists目录下缓存了损坏的 zip。eocd 是 zip 格式的中央目录结束标记读不到说明文件不完整。处理办法是删掉本地 wrapper 缓存重新下载# macOS / Linux 下删除 Gradle wrapper 与依赖缓存 rm -rf ~/.gradle/wrapper/dists rm -rf ~/.gradle/caches/modules-2删除后回到 Android Studio 点击Sync Project with Gradle Files。如果官方分发地址下载慢可以把 distributionUrl 换成国内云厂商的 Gradle 镜像地址这属于公共基础设施加速不影响工程行为但要注意镜像路径下必须存在对应版本目录。2.4 SDK 平台缺失与三处源码联动报错Gradle 版本对上以后编译还卡在 SDK 上。老项目的compileSdkVersion往往写的是 28、30而新安装的 Android Studio 只自带最新平台。打开 SDK Manager勾选对应版本即可命令行环境下则用 sdkmanager 安装# 安装 compileSdk 对应的平台版本Y 表示接受许可 sdkmanager platforms;android-33 build-tools;33.0.2SDK 就绪后再看三处源码联动问题app/libs/里有本地 jar 但build.gradle没写implementation fileTree(dir: libs, include: [*.jar])applicationId和AndroidManifest.xml里的包名不一致项目用了 Java 8 语法但没开compileOptions。这三处在源码 zip 里出现频率最高同步报错时按 dependencies、manifest、compileOptions 的顺序逐个排查比看堆栈更有效。工程同步通过之后先别急着改代码。把项目结构完整读一遍评估源码包是否值得继续投入再谈二次开发。3. 拆解 zz-doctor 的工程结构中医大夫助理系统的数据流3.1 从分包反推模块zz-doctor 的典型 Android 分层对“大夫助理”这类业务系统代码组织通常逃不出三层界面层、数据层、工具层。如果让我重新组织一个同类型项目我会把包结构设计成下面这样拿到源码包时也按这个思路去对照com.zz.doctor ├── ui # Activity / Fragment / Adapter │ ├── login # 登录与账号切换 │ ├── patient # 患者列表与建档 │ └── prescription # 处方录入与参考方剂 ├── data # 数据层 │ ├── db # SQLiteOpenHelper 与建表语句 │ ├── model # 实体 Bean │ └── repository # 数据仓储 ├── service # 复诊提醒等后台服务 └── utils # 日期、字符串等工具这种分层的核心价值是引用方向单向UI 依赖 AdapterAdapter 依赖 Entity数据不反向流动。读源码时我习惯先在 Android Studio 里用Call Hierarchy快捷键 CtrlAltH追踪一个点击事件比如“点击患者列表项后发生了什么”链路短就说明工程结构健康链路绕了三层 Activity 还没到底层数据就要警惕后续改动会牵一发动全身。3.2 患者建档与辨证记录SQLite 表设计的关键字段业务系统的重心在数据库。zz-doctor 这类不依赖云端的中医助理应用用 SQLite 落地的表至少有四张患者表、病历表、处方表、药材表。如果由我从头设计初版建表语句会写成这样CREATE TABLE patient ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, gender INTEGER DEFAULT 0, birth_date TEXT, phone TEXT, remark TEXT, created_at TEXT DEFAULT (datetime(now,localtime)) ); CREATE TABLE medical_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER NOT NULL, symptom TEXT, -- 主诉症状 tongue TEXT, -- 舌象 pulse TEXT, -- 脉象 diagnosis TEXT, -- 辨证结论 create_time TEXT DEFAULT (datetime(now,localtime)), FOREIGN KEY (patient_id) REFERENCES patient(id) ON DELETE CASCADE ); CREATE TABLE herb ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, property TEXT, -- 药性寒热温凉平 flavor TEXT, -- 药味酸苦甘辛咸 category TEXT -- 分类解表、补气等 );索引策略和普通 CRM 不一样中医门诊查询量小但会频繁按patient_id拉取历次病历时间线所以联合索引建在medical_record(patient_id, create_time)上。herb表的category字段不要建索引——药材表几百行全表扫描比维护索引 B 树快得多。数据层和界面层之间建议加 repository 做转换不让SQLiteCursor直接暴露给 Adapter。Cursor 的列索引可读性差每个页面都要重复写moveToFirst和getColumnIndex一旦表结构微调改起来是全局性的痛苦。3.3 大夫工作台的状态流转从待诊列表到处方提交如果只把 zz-doctor 理解成增删改查会错过它真正的核心——工作流支持。接诊流程在 UI 上是登录进入工作台 → 查看今日待诊列表 → 选择患者 → 查看历次辨证记录 → 录入本次症状与舌脉 → 生成参考方剂 → 大夫确认后落库。这个流程在工程实现里最常见的坑是跨界面传参。Activity A 跳 B 时把整个 PatientBean 对象塞进 IntentB 再跳 C 时又传一次——对象一旦变大序列化开销增加而且 C 界面拿到的是旧数据。我一般只传主键 IDC 界面在onCreate里通过 ID 重新查一次 SQLite既保证数据新鲜也避免大对象序列化的性能问题。另一个隐蔽点接诊完成后按返回键回工作台工作台列表必须重查数据库而不是复用进入前的数据。没写onResume重新加载的话刚保存的病历不会出现在列表里用户会以为保存失败了。4. 在 zz-doctor 里做二次开发列表、数据库与业务逻辑4.1 患者列表加科室筛选从 BaseAdapter 到增量刷新相当一部分课程设计源码还在用 ListView 加 BaseAdapter。ListView 不是不能跑而是状态维护麻烦列表项复用逻辑写错会闪烁全量刷新在数据量上来后有明显卡顿。如果 zz-doctor 里已经是 RecyclerView改造空间在 DiffUtil如果是 ListView优先保留原结构在 Activity 层做筛选反而更稳。给患者列表加一个“按科室过滤”的按钮最直接的写法是filterButton.setOnClickListener(v - { ListPatientBean filtered new ArrayList(); for (PatientBean p : allPatients) { if (selectedDepartment.equals(p.getDepartment())) { filtered.add(p); } } adapter.setData(filtered); // 适配器内部替换数据源 adapter.notifyDataSetChanged(); // 触发列表重绘 });代码逻辑说明allPatients是 Activity 启动时从 repository 拉取的全量数据筛选操作不重新查询数据库而是对内存列表做条件过滤。setData替换 Adapter 持有的引用notifyDataSetChanged强制列表重绘。这样改的好处是保留原有数据源清空筛选时把allPatients重新塞回去即可。如果列表项包含图片比如患者头像全量重绘会有明显闪烁。此时可以把 Adapter 换成ListAdapter配合DiffUtil做差值计算areItemsTheSame比较 idareContentsTheSame比较业务字段列表更新只刷新变化的行。改动量不大但体验提升明显。4.2 数据库加字段改了 CREATE TABLE 别忘 onUpgrade二次开发中最常见的需求是加字段比如给patient表增加allergy_history。直接改建表语句重装应用没意义线上用户的数据会清空。正确姿势是把DBHelper里的DATABASE_VERSION从 1 改成 2并在onUpgrade里加迁移override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) { if (oldVersion 2) { // 用户从 v1 升级到 v2新增过敏史字段 db.execSQL(ALTER TABLE patient ADD COLUMN allergy_history TEXT DEFAULT ) } // 后续 v3、v4 继续用 if 累加不能用 else if }参数说明oldVersion是当前安装版本的数据库版本号newVersion是代码里定义的新版本号。onUpgrade里的判断必须用连续的if而不是else if这样用户从 v1 直升 v3 时v2 的迁移逻辑也会被执行。注意SQLite 的ALTER TABLE ADD COLUMN不支持回滚上线前先备份旧库。另外它只能加列不能改列名、删列这类操作只能“建新表 → 导数据 → 删旧表 → 重命名”四步走。4.3 处方建议逻辑把“推荐”和“决策”分开zz-doctor 作为“助理”系统处方建议模块最容易写成硬编码。如果代码里是一长串 if-else 拼接常用方剂名后续调整会很痛苦。我会把这个逻辑抽成独立类返回候选药材集合而非最终处方public class PrescriptionSuggest { public ListHerbBean suggest(String diagnosis) { if (diagnosis.contains(风寒)) { return herbDao.queryByCategory(解表); } if (diagnosis.contains(气虚)) { return herbDao.queryByCategory(补气); } return herbDao.queryDefault(); } }这个方法的参数diagnosis是大夫录入并经辨证后的结论文本返回值是候选药材集合。界面拿到候选集后展示给大夫勾选勾选结果才写进prescription表。“推荐”和“决策”分层是医疗信息系统必须保留的边界算法只能辅助最终确认必须交给人。修改时也要注意contains的误命中比如“气虚”会被“气虚血瘀”命中如果想精确匹配可以改成按关键词集合过滤。5. 用命令行把 zz-doctor 构建成 APK 并做交付前检查5.1 命令行构建与 APK 输出路径Android Studio 里点 Run 按钮谁都会但交付、备份、CI 场景下还是命令行更可控。工程根目录下执行# 构建 debug 包跳过单测和 lint 加速 ./gradlew assembleDebug -x test -x lint # 构建 release 包需要已配置 signingConfigs ./gradlew assembleRelease构建产物位于app/build/outputs/apk/debug/app-debug.apk或app/build/outputs/apk/release/下。首次构建慢是正常的主要耗时在依赖下载和 Transform 流程不代表代码有问题。5.2 真机运行前检查五个易漏点AndroidManifest.xml是否声明了INTERNET、READ_EXTERNAL_STORAGE等权限安卓 11 以上读写公共目录还需要MANAGE_EXTERNAL_STORAGE并引导用户到设置页授权。targetSdkVersion是否过高高于 30 且未适配分区存储时文件访问会静默失败表现为导出病历无反应。药材库是否预置。如果运行时在onCreate里循环插入几百条药材数据冷启动会很慢正式交付应把预置库.db文件放到assets/首次启动时复制到databases/目录。主 Activity 的exported是否为true否则桌面点击图标会提示找不到入口 Activity。真机调试时先用adb devices确认设备被识别并检查 USB 调试授权弹窗是否被点掉了。5.3 二次交付打一个干净的可编译 zip最后一步是把改动后的源码打包回传。打包前务必要排除构建产物和本地配置文件zip -r zz-doctor-v2-src.zip . -x */build/* -x */.gradle/* -x *.iml -x .idea/*命令解释-x后跟排除通配符*/build/*匹配任意层级的 build 目录.idea/*排除本地 IDE 配置。构建产物目录常有几 GB排除后源码包能缩到几十 MB同时接收方解压后不会看到别人的本地 SDK 路径直接进入 Sync 环节即可重新构建。本文还有配套的精品资源点击获取