尧图网站建设 
简介zz-doctor中医大夫助理信息系统是一份面向安卓开发者的完整项目源码围绕中医大夫日常诊疗辅助、病历记录与中药知识查询等实际场景设计适合需要借助真实案例掌握移动端复杂应用架构的学习者以及医疗信息化方向的技术人员参考。压缩包共125个文件总体积约1.55MB包含20个Java源文件、49个class编译产物、16个XML界面布局、10个SQL数据库脚本同时附带APK安装包、图片、GIF演示和配置文件等目录组织清晰便于从界面到数据层逐模块对照分析。目前已有172人学习下载作为医疗类安卓实例具有不错的参考价值。资源内置欢迎页、药材查询、处方编辑与数据库辅助等模块覆盖诊疗信息流关键环节深入学习可掌握自定义界面组件、SQLite持久化存储、运行时权限申请、网络数据接入及清单文件配置等核心技能还可直接运行自带APK验证完整业务流程也可作为课程设计或毕设选题的参考范例是理解安卓应用生命周期与数据层的实用素材。1. 一个中医大夫助理信息系统的源码包值得拆开看什么拿到android应用源码zz-doctor中医大夫助理信息系统源码.zip这个压缩包第一反应可能是个简单的课程设计但实际拆开看它跟普通的学习项目有本质区别名字里带了信息系统四个字就意味着它不是单页面示例而是一个围绕患者、病例、辨证、方剂、药嘱的多表管理应用。对这种项目真正值钱的部分不在界面多华丽而在数据模型怎么组织、业务状态怎么流转、离线场景下数据怎么落盘。这篇文章就顺着一个 Android 工程源码包从解压到运行的完整路径讲清楚 zz-doctor 这类中医业务信息系统的骨架怎么搭、参数怎么调、坑在哪以及拿到这样一个 zip 包之后如何快速把它变成能在 Android Studio 里跑起来、改得动的工程。2. 从源码包结构反推 zz-doctor 的技术选型与分层方案2.1 源码包解压后先看哪几层目录zip 格式的 Android 源码包解压后第一步不是急着用 Android Studio 打开而是先看目录层级是否完整。一个标准工程至少包含settings.gradle、build.gradle、app/模块目录以及gradle/wrapper下的gradle-wrapper.properties。zz-doctor 这种命名的项目通常会带一个app/src/main/java下的业务包路径比如com.zzdoctor或者com.clinic.doctor包路径决定后续改动时 import 的根地址也直接看出作者的分层习惯。查看源码包内部结构常见做法是解压后先跑一行命令确认没有缺失文件unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip | head -80unzip -l只列内容不实际解压能快速看到压缩包内部是否有app/src/main/AndroidManifest.xml、res/布局资源目录、java/源码目录以及gradle目录。如果输出里缺少gradle-wrapper.jar或者gradle-wrapper.properties说明这个包不是从标准工程直接压缩的导入时会需要手动指定 Gradle 版本这是后续构建最容易卡住的坑之一。2.2 信息系统的数据持久化选型SQLite、文件还是 SharedPreferences中医大夫助理系统本质上是一个垂直领域的业务管理系统它的核心场景是大夫录入患者信息、记录辨证结果、开方剂、生成药嘱。这类需求对数据持久化的要求是结构化查询、多表关联、单机可用因此 SQLite 是这类项目几乎唯一合理的选择。SharedPreferences 适合存配置项比如登录会话、主题设置文件存储适合存图片、语音或导出病历文件而患者列表、辨证记录、方剂明细必须进数据库表。对比三者在 zz-doctor 类项目中的适用位置持久化方式适合存储的内容在 zz-doctor 中的典型场景缺陷SQLite结构化业务数据患者档案、辨证记录、方剂主表与药嘱明细需要手写 SQLiteOpenHelper 与 DAOSharedPreferences轻量 KV 配置当前登录医生 id、界面语言、字体大小不能做条件查询文件存储二进制或大文本舌象照片、体质报告导出文件无索引查询困难如果源码包里看到的不是 SQLite 而是 JSON 文件直接读写那这个系统的完整性是存疑的。zz-doctor 标题里带着信息系统后缀工程内出现db/、dao/、entity/这类目录层的概率更高。这也是判断一个 zip 源码质量的最快方式看它有没有独立的数据库帮助类以及建表语句是写在 Java 代码里还是放在assets/下的.sql文件中。2.3 界面层与业务层的模块边界Android 信息系统项目的架构往往比表面看起来要传统Activity 负责界面跳转和数据展示业务逻辑挤在一个Service或Manager类里SQLiteOpenHelper 用单例持有。zz-doctor 这类以功能完整性为首要目标的项目不需要引入 MVVM 或 Jetpack Compose 这样的重架构但不代表可以没有边界。至少应该看到entity/实体类、dao/数据访问、activity/界面、adapter/列表适配这类基础分包。一个小技巧是直接搜索工程里的onCreate方法里 Activity 的数量如果超过五个却没有独立的BaseActivity抽取公共逻辑说明作者在复用性上做得不够二次开发时改公共行为会很痛。反过来如果所有页面都继承同一个基类再配合统一的标题栏和加载中动画说明工程有基本工程化意识值得在它的基础上继续堆功能。3. 把 zip 源码包变成可运行的 zz-doctor 工程3.1 解压、编码与项目完整性检查拿到 zip 包后的第一个实际操作是解压。要注意 Windows 系统下用资源管理器直接解压有时会产生路径过长的问题Android 工程的app/src/main/java/...嵌套层级很深加上中文包名路径在 Windows 上容易触发 260 字符路径上限导致部分文件解压失败且不报错。建议用 7-Zip 或命令行工具解压到盘符根目录下的短路径比如D:\zzdoctor能避免大部分路径类问题。解压之后需要立刻验证的关键文件是gradle/wrapper/gradle-wrapper.properties它记录了构建工具版本直接决定 Android Studio 能不能顺利识别工程。常见的失败现象是Gradle sync failed: Could not find com.android.tools.build:gradle:3.x.x这说明本地没有缓存对应版本的构建插件而不是源码本身有问题。此时需要检查工程根目录build.gradle里声明的插件版本并确认和当前 Android Studio 版本兼容。3.2 用 Android Studio 导入 zz-doctor 的两种路径选择导入这类源码常见做法有两种。第一种是 Android Studio 直接Open选中解压后的根目录等待 Gradle Sync第二种是先在工程根目录执行一次 Gradle 包装器命令确认依赖能拉取再用 IDE 打开。第二种更稳健推荐从命令行先跑一次构建cd D:\zzdoctor gradle wrapper --gradle-version 8.7提示Android Studio 从 Koala 版本开始对新版 Gradle 的 AGP 兼容范围有严格校验直接打开工程时如果 Gradle 版本和 AGP 版本不匹配Sync 会报Minimum supported Gradle version is X.X。这时候不要手动乱改 Gradle 版本应该看 AGP 插件要求的对应 Gradle 版本。gradle wrapper --gradle-version 8.7的意思是重新生成 wrapper 配置并指定 Gradle 版本为 8.7。如果你不需要指定版本直接在 IDE 里 Sync 也完全可以。这个过程的作用是为后续所有构建操作建立一个确定的构建环境规避 IDE 缓存干扰。3.3 首次构建失败最常见的三个参数问题zz-doctor 这类源码包构建不成功的案例里九成是历史版本依赖问题不是代码问题。第一个是distributionUrl对应的 Gradle 版本与实际 JDK 不兼容。新版 Gradle 8.x 要求 JDK 17而工程源码如果是两三年前写的可能默认 JDK 8。出现Unsupported class file major version时在项目根目录执行java -version确认 JDK 版本。Android Studio 自带的 JBR 在jbr/目录里可以在File Project Structure SDK Location里指定 Gradle JDK。第二个是compileSdkVersion与buildToolsVersion不匹配。有些老工程会写死buildToolsVersion 28.0.3而新装的 Android Studio 没有下载对应版本。最干净的解决方法是直接去掉buildToolsVersion这一行让 AGP 使用默认构建工具。第三个是仓库地址访问失败。老工程用的jcenter()已经停止服务必须在build.gradle里替换为阿里云镜像或 Maven Centralbuildscript { repositories { google() mavenCentral() maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } } }提示maven.aliyun.com是会拖慢国外依赖下载速度的镜像仓库适用于国内网络环境。如果在海外环境直接使用官方仓库即可。4. 核心数据模型患者档案与方剂表结构设计4.1 从建表 SQL 反推业务边界zz-doctor 的核心业务域是大夫助理业务对象大致包括患者、辨证、方剂、药嘱、复诊记录。看一个中医信息系统源码是否成熟直接看它的数据库表设计患者表和辨证记录表是否分开、方剂和药嘱是否分主从表、是否预留复诊关联字段。如果一张大表装所有字段那后续查历史辨证、按症状检索方剂都会变成全表扫描性能和维护性都差。一个合理的最小表结构至少是这样的CREATE TABLE patient ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, age INTEGER, gender TEXT, phone TEXT, created_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE syndrome ( id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER NOT NULL, syndrome_type TEXT, tongue TEXT, pulse TEXT, description TEXT, FOREIGN KEY (patient_id) REFERENCES patient(id) ); CREATE TABLE formula ( id INTEGER PRIMARY KEY AUTOINCREMENT, syndrome_id INTEGER NOT NULL, formula_name TEXT, total_days INTEGER, note TEXT, FOREIGN KEY (syndrome_id) REFERENCES syndrome(id) ); CREATE TABLE formula_item ( id INTEGER PRIMARY KEY AUTOINCREMENT, formula_id INTEGER NOT NULL, herb_name TEXT, dosage TEXT, FOREIGN KEY (formula_id) REFERENCES formula(id) );第一张表存患者基本信息第二张表存辨证内容第三张表存方剂主信息第四张表存方剂明细。把方剂和药嘱拆成主从表的原因在于一个方剂包含多味药每味药有药名和用量如果存成 JSON 数组后续要统计高频用药会非常麻烦。拆表后一条 SQL 就能统计SELECT herb_name, COUNT(*) AS cnt FROM formula_item GROUP BY herb_name ORDER BY cnt DESC LIMIT 10;这类统计功能就是系统二字相比于普通记事本应用的差异所在。4.2 数据访问层的常规写法与参数说明源码里常见的 SQLite 辅助类会继承SQLiteOpenHelper关键方法是onCreate和onUpgrade。onCreate在数据库文件首次创建时执行所有建表语句onUpgrade处理版本升级时的表结构变更。常规做法是定义一个DBHelper.java统一管理版本号版本号变更时自动触发升级逻辑。public class DBHelper extends SQLiteOpenHelper { private static final String DB_NAME zzdoctor.db; private static final int DB_VERSION 2; public DBHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } Override public void onCreate(SQLiteDatabase db) { db.execSQL(CREATE TABLE patient (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, age INTEGER)); db.execSQL(CREATE TABLE syndrome (id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER, syndrome_type TEXT)); } Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE patient ADD COLUMN phone TEXT); } } }代码的逻辑是两个方法分别应对第一次安装与后续升级场景onCreate只在数据库文件不存在时执行onUpgrade则只有在DB_VERSION变大后触发。ALTER TABLE只会执行一次不会重复加列。DB_VERSION每改一次老用户升级时都会走一遍onUpgrade所以这里面写的每个操作都要考虑幂等性也就是即使重复执行也不会报错。4.3 界面层读取数据时的主线程与游标处理Android 信息系统里最常见的性能隐患是在主线程直接查数据库。zz-doctor 这类数据量不大的单机应用主线程查询一两百条记录通常不会崩但进入列表页滑动时反复查询就会卡顿掉帧。常规做法是列表页用CursorLoader或直接在子线程里查询后在主线程更新RecyclerView。看源码时重点检查 adapter 里有没有把数据库查询放进getView或onBindViewHolder如果有说明数据访问层设计得比较粗糙。正确的取值方式是一次性查出结果集关闭游标再交给适配器渲染。典型写法SQLiteDatabase db dbHelper.getReadableDatabase(); Cursor cursor db.rawQuery(SELECT id, name FROM patient ORDER BY created_at DESC, null); ListPatient list new ArrayList(); while (cursor.moveToNext()) { Patient p new Patient(); p.id cursor.getLong(cursor.getColumnIndexOrThrow(id)); p.name cursor.getString(cursor.getColumnIndexOrThrow(name)); list.add(p); } cursor.close();getColumnIndexOrThrow在列名不存在时直接抛异常可以在开发期就发现 SQL 与实体类字段不匹配而不是等到运行期拿到-1再越界。数据库连接不要在这里关闭因为getReadableDatabase()返回的连接由SQLiteOpenHelper统一管理多次调用close()反而会导致后续查询报database closed的误报。5. 换个思路复用数据迁移验证与应用内外网对接5.1 用 adb 命令验证数据库文件是否正常生成zz-doctor 工程跑起来之后验证数据层是否工作正常的最高效方式不是看界面而是直接从设备把数据库 pull 出来。连接调试设备后执行adb shell run-as com.zzdoctor ls /data/data/com.zzdoctor/databases/ adb exec-out run-as com.zzdoctor cat /data/data/com.zzdoctor/databases/zzdoctor.db zzdoctor_backup.db第一条命令查看包名com.zzdoctor下的数据库目录是否存在第二条命令用exec-out加run-as将私有目录下的数据库文件重定向到本地。run-as只对 debuggable 应用生效所以一定要确认 AndroidManifest.xml 里的debuggable为true否则会报Package com.zzdoctor is not debuggable。拿到本地数据库后用 SQLite 命令行工具或者 DB Browser 打开直接验证表结构和数据。这一步相当于给整个信息系统做健康体检比在日志里翻输出要直观得多。5.2 方剂数据的只读打包方案中医行业对数据准确性要求极高方剂库的数据通常是运营同学整理好后统一提供而不是让大夫在终端上手输。zz-doctor 这类项目二次开发时最适合的方案是把方剂基础数据做成只读数据库放进assets/目录首次启动时拷贝到应用私有目录cp -r app/src/main/assets/zhongyi_formula.db app/src/main/assets/formula_data/assets目录下的文件不会被压缩可以放 SQLite 文件但注意 Android 的 AssetManager 对单文件 1MB 以上资源的读取速度有明显劣化因此超过 5MB 的数据库建议用扩展名.mp3伪装绕过压缩或者用res/raw存放。拷贝完成后的数据库文件用SQLiteOpenHelper的只读方式打开杜绝大夫误改基础方剂数据。5.3 与第 2 章设计呼应三层结构下的数据同步第 2 章提到 zz-doctor 这类系统的核心是单机可用但作为一个真实在门诊环境使用的系统数据要能导出来给院内系统用。这里推荐一个不侵入原工程的轻量方案在 app 里加一个导出功能把 SQLite 内容序列化成 JSON 输出到共享目录供院内 HIS 系统轮询。导出代码要跑在子线程避免文件大时 ANR导出完成后发送一个通知。这个做法不破坏原有三层结构又给信息系统补齐了数据流通的短板。整个 zip 包的精髓不在界面多好看而在于围绕患者档案组织起来的数据关系理清这些关系拿到任何类似的 Android 业务系统源码都能快速上手。本文还有配套的精品资源点击获取 Android中医大夫助理信息系统源码解析与工程化实践
简介zz-doctor中医大夫助理信息系统是一份面向安卓开发者的完整项目源码围绕中医大夫日常诊疗辅助、病历记录与中药知识查询等实际场景设计适合需要借助真实案例掌握移动端复杂应用架构的学习者以及医疗信息化方向的技术人员参考。压缩包共125个文件总体积约1.55MB包含20个Java源文件、49个class编译产物、16个XML界面布局、10个SQL数据库脚本同时附带APK安装包、图片、GIF演示和配置文件等目录组织清晰便于从界面到数据层逐模块对照分析。目前已有172人学习下载作为医疗类安卓实例具有不错的参考价值。资源内置欢迎页、药材查询、处方编辑与数据库辅助等模块覆盖诊疗信息流关键环节深入学习可掌握自定义界面组件、SQLite持久化存储、运行时权限申请、网络数据接入及清单文件配置等核心技能还可直接运行自带APK验证完整业务流程也可作为课程设计或毕设选题的参考范例是理解安卓应用生命周期与数据层的实用素材。1. 一个中医大夫助理信息系统的源码包值得拆开看什么拿到android应用源码zz-doctor中医大夫助理信息系统源码.zip这个压缩包第一反应可能是个简单的课程设计但实际拆开看它跟普通的学习项目有本质区别名字里带了信息系统四个字就意味着它不是单页面示例而是一个围绕患者、病例、辨证、方剂、药嘱的多表管理应用。对这种项目真正值钱的部分不在界面多华丽而在数据模型怎么组织、业务状态怎么流转、离线场景下数据怎么落盘。这篇文章就顺着一个 Android 工程源码包从解压到运行的完整路径讲清楚 zz-doctor 这类中医业务信息系统的骨架怎么搭、参数怎么调、坑在哪以及拿到这样一个 zip 包之后如何快速把它变成能在 Android Studio 里跑起来、改得动的工程。2. 从源码包结构反推 zz-doctor 的技术选型与分层方案2.1 源码包解压后先看哪几层目录zip 格式的 Android 源码包解压后第一步不是急着用 Android Studio 打开而是先看目录层级是否完整。一个标准工程至少包含settings.gradle、build.gradle、app/模块目录以及gradle/wrapper下的gradle-wrapper.properties。zz-doctor 这种命名的项目通常会带一个app/src/main/java下的业务包路径比如com.zzdoctor或者com.clinic.doctor包路径决定后续改动时 import 的根地址也直接看出作者的分层习惯。查看源码包内部结构常见做法是解压后先跑一行命令确认没有缺失文件unzip -l android应用源码zz-doctor中医大夫助理信息系统源码.zip | head -80unzip -l只列内容不实际解压能快速看到压缩包内部是否有app/src/main/AndroidManifest.xml、res/布局资源目录、java/源码目录以及gradle目录。如果输出里缺少gradle-wrapper.jar或者gradle-wrapper.properties说明这个包不是从标准工程直接压缩的导入时会需要手动指定 Gradle 版本这是后续构建最容易卡住的坑之一。2.2 信息系统的数据持久化选型SQLite、文件还是 SharedPreferences中医大夫助理系统本质上是一个垂直领域的业务管理系统它的核心场景是大夫录入患者信息、记录辨证结果、开方剂、生成药嘱。这类需求对数据持久化的要求是结构化查询、多表关联、单机可用因此 SQLite 是这类项目几乎唯一合理的选择。SharedPreferences 适合存配置项比如登录会话、主题设置文件存储适合存图片、语音或导出病历文件而患者列表、辨证记录、方剂明细必须进数据库表。对比三者在 zz-doctor 类项目中的适用位置持久化方式适合存储的内容在 zz-doctor 中的典型场景缺陷SQLite结构化业务数据患者档案、辨证记录、方剂主表与药嘱明细需要手写 SQLiteOpenHelper 与 DAOSharedPreferences轻量 KV 配置当前登录医生 id、界面语言、字体大小不能做条件查询文件存储二进制或大文本舌象照片、体质报告导出文件无索引查询困难如果源码包里看到的不是 SQLite 而是 JSON 文件直接读写那这个系统的完整性是存疑的。zz-doctor 标题里带着信息系统后缀工程内出现db/、dao/、entity/这类目录层的概率更高。这也是判断一个 zip 源码质量的最快方式看它有没有独立的数据库帮助类以及建表语句是写在 Java 代码里还是放在assets/下的.sql文件中。2.3 界面层与业务层的模块边界Android 信息系统项目的架构往往比表面看起来要传统Activity 负责界面跳转和数据展示业务逻辑挤在一个Service或Manager类里SQLiteOpenHelper 用单例持有。zz-doctor 这类以功能完整性为首要目标的项目不需要引入 MVVM 或 Jetpack Compose 这样的重架构但不代表可以没有边界。至少应该看到entity/实体类、dao/数据访问、activity/界面、adapter/列表适配这类基础分包。一个小技巧是直接搜索工程里的onCreate方法里 Activity 的数量如果超过五个却没有独立的BaseActivity抽取公共逻辑说明作者在复用性上做得不够二次开发时改公共行为会很痛。反过来如果所有页面都继承同一个基类再配合统一的标题栏和加载中动画说明工程有基本工程化意识值得在它的基础上继续堆功能。3. 把 zip 源码包变成可运行的 zz-doctor 工程3.1 解压、编码与项目完整性检查拿到 zip 包后的第一个实际操作是解压。要注意 Windows 系统下用资源管理器直接解压有时会产生路径过长的问题Android 工程的app/src/main/java/...嵌套层级很深加上中文包名路径在 Windows 上容易触发 260 字符路径上限导致部分文件解压失败且不报错。建议用 7-Zip 或命令行工具解压到盘符根目录下的短路径比如D:\zzdoctor能避免大部分路径类问题。解压之后需要立刻验证的关键文件是gradle/wrapper/gradle-wrapper.properties它记录了构建工具版本直接决定 Android Studio 能不能顺利识别工程。常见的失败现象是Gradle sync failed: Could not find com.android.tools.build:gradle:3.x.x这说明本地没有缓存对应版本的构建插件而不是源码本身有问题。此时需要检查工程根目录build.gradle里声明的插件版本并确认和当前 Android Studio 版本兼容。3.2 用 Android Studio 导入 zz-doctor 的两种路径选择导入这类源码常见做法有两种。第一种是 Android Studio 直接Open选中解压后的根目录等待 Gradle Sync第二种是先在工程根目录执行一次 Gradle 包装器命令确认依赖能拉取再用 IDE 打开。第二种更稳健推荐从命令行先跑一次构建cd D:\zzdoctor gradle wrapper --gradle-version 8.7提示Android Studio 从 Koala 版本开始对新版 Gradle 的 AGP 兼容范围有严格校验直接打开工程时如果 Gradle 版本和 AGP 版本不匹配Sync 会报Minimum supported Gradle version is X.X。这时候不要手动乱改 Gradle 版本应该看 AGP 插件要求的对应 Gradle 版本。gradle wrapper --gradle-version 8.7的意思是重新生成 wrapper 配置并指定 Gradle 版本为 8.7。如果你不需要指定版本直接在 IDE 里 Sync 也完全可以。这个过程的作用是为后续所有构建操作建立一个确定的构建环境规避 IDE 缓存干扰。3.3 首次构建失败最常见的三个参数问题zz-doctor 这类源码包构建不成功的案例里九成是历史版本依赖问题不是代码问题。第一个是distributionUrl对应的 Gradle 版本与实际 JDK 不兼容。新版 Gradle 8.x 要求 JDK 17而工程源码如果是两三年前写的可能默认 JDK 8。出现Unsupported class file major version时在项目根目录执行java -version确认 JDK 版本。Android Studio 自带的 JBR 在jbr/目录里可以在File Project Structure SDK Location里指定 Gradle JDK。第二个是compileSdkVersion与buildToolsVersion不匹配。有些老工程会写死buildToolsVersion 28.0.3而新装的 Android Studio 没有下载对应版本。最干净的解决方法是直接去掉buildToolsVersion这一行让 AGP 使用默认构建工具。第三个是仓库地址访问失败。老工程用的jcenter()已经停止服务必须在build.gradle里替换为阿里云镜像或 Maven Centralbuildscript { repositories { google() mavenCentral() maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } } }提示maven.aliyun.com是会拖慢国外依赖下载速度的镜像仓库适用于国内网络环境。如果在海外环境直接使用官方仓库即可。4. 核心数据模型患者档案与方剂表结构设计4.1 从建表 SQL 反推业务边界zz-doctor 的核心业务域是大夫助理业务对象大致包括患者、辨证、方剂、药嘱、复诊记录。看一个中医信息系统源码是否成熟直接看它的数据库表设计患者表和辨证记录表是否分开、方剂和药嘱是否分主从表、是否预留复诊关联字段。如果一张大表装所有字段那后续查历史辨证、按症状检索方剂都会变成全表扫描性能和维护性都差。一个合理的最小表结构至少是这样的CREATE TABLE patient ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, age INTEGER, gender TEXT, phone TEXT, created_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE syndrome ( id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER NOT NULL, syndrome_type TEXT, tongue TEXT, pulse TEXT, description TEXT, FOREIGN KEY (patient_id) REFERENCES patient(id) ); CREATE TABLE formula ( id INTEGER PRIMARY KEY AUTOINCREMENT, syndrome_id INTEGER NOT NULL, formula_name TEXT, total_days INTEGER, note TEXT, FOREIGN KEY (syndrome_id) REFERENCES syndrome(id) ); CREATE TABLE formula_item ( id INTEGER PRIMARY KEY AUTOINCREMENT, formula_id INTEGER NOT NULL, herb_name TEXT, dosage TEXT, FOREIGN KEY (formula_id) REFERENCES formula(id) );第一张表存患者基本信息第二张表存辨证内容第三张表存方剂主信息第四张表存方剂明细。把方剂和药嘱拆成主从表的原因在于一个方剂包含多味药每味药有药名和用量如果存成 JSON 数组后续要统计高频用药会非常麻烦。拆表后一条 SQL 就能统计SELECT herb_name, COUNT(*) AS cnt FROM formula_item GROUP BY herb_name ORDER BY cnt DESC LIMIT 10;这类统计功能就是系统二字相比于普通记事本应用的差异所在。4.2 数据访问层的常规写法与参数说明源码里常见的 SQLite 辅助类会继承SQLiteOpenHelper关键方法是onCreate和onUpgrade。onCreate在数据库文件首次创建时执行所有建表语句onUpgrade处理版本升级时的表结构变更。常规做法是定义一个DBHelper.java统一管理版本号版本号变更时自动触发升级逻辑。public class DBHelper extends SQLiteOpenHelper { private static final String DB_NAME zzdoctor.db; private static final int DB_VERSION 2; public DBHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } Override public void onCreate(SQLiteDatabase db) { db.execSQL(CREATE TABLE patient (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, age INTEGER)); db.execSQL(CREATE TABLE syndrome (id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id INTEGER, syndrome_type TEXT)); } Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE patient ADD COLUMN phone TEXT); } } }代码的逻辑是两个方法分别应对第一次安装与后续升级场景onCreate只在数据库文件不存在时执行onUpgrade则只有在DB_VERSION变大后触发。ALTER TABLE只会执行一次不会重复加列。DB_VERSION每改一次老用户升级时都会走一遍onUpgrade所以这里面写的每个操作都要考虑幂等性也就是即使重复执行也不会报错。4.3 界面层读取数据时的主线程与游标处理Android 信息系统里最常见的性能隐患是在主线程直接查数据库。zz-doctor 这类数据量不大的单机应用主线程查询一两百条记录通常不会崩但进入列表页滑动时反复查询就会卡顿掉帧。常规做法是列表页用CursorLoader或直接在子线程里查询后在主线程更新RecyclerView。看源码时重点检查 adapter 里有没有把数据库查询放进getView或onBindViewHolder如果有说明数据访问层设计得比较粗糙。正确的取值方式是一次性查出结果集关闭游标再交给适配器渲染。典型写法SQLiteDatabase db dbHelper.getReadableDatabase(); Cursor cursor db.rawQuery(SELECT id, name FROM patient ORDER BY created_at DESC, null); ListPatient list new ArrayList(); while (cursor.moveToNext()) { Patient p new Patient(); p.id cursor.getLong(cursor.getColumnIndexOrThrow(id)); p.name cursor.getString(cursor.getColumnIndexOrThrow(name)); list.add(p); } cursor.close();getColumnIndexOrThrow在列名不存在时直接抛异常可以在开发期就发现 SQL 与实体类字段不匹配而不是等到运行期拿到-1再越界。数据库连接不要在这里关闭因为getReadableDatabase()返回的连接由SQLiteOpenHelper统一管理多次调用close()反而会导致后续查询报database closed的误报。5. 换个思路复用数据迁移验证与应用内外网对接5.1 用 adb 命令验证数据库文件是否正常生成zz-doctor 工程跑起来之后验证数据层是否工作正常的最高效方式不是看界面而是直接从设备把数据库 pull 出来。连接调试设备后执行adb shell run-as com.zzdoctor ls /data/data/com.zzdoctor/databases/ adb exec-out run-as com.zzdoctor cat /data/data/com.zzdoctor/databases/zzdoctor.db zzdoctor_backup.db第一条命令查看包名com.zzdoctor下的数据库目录是否存在第二条命令用exec-out加run-as将私有目录下的数据库文件重定向到本地。run-as只对 debuggable 应用生效所以一定要确认 AndroidManifest.xml 里的debuggable为true否则会报Package com.zzdoctor is not debuggable。拿到本地数据库后用 SQLite 命令行工具或者 DB Browser 打开直接验证表结构和数据。这一步相当于给整个信息系统做健康体检比在日志里翻输出要直观得多。5.2 方剂数据的只读打包方案中医行业对数据准确性要求极高方剂库的数据通常是运营同学整理好后统一提供而不是让大夫在终端上手输。zz-doctor 这类项目二次开发时最适合的方案是把方剂基础数据做成只读数据库放进assets/目录首次启动时拷贝到应用私有目录cp -r app/src/main/assets/zhongyi_formula.db app/src/main/assets/formula_data/assets目录下的文件不会被压缩可以放 SQLite 文件但注意 Android 的 AssetManager 对单文件 1MB 以上资源的读取速度有明显劣化因此超过 5MB 的数据库建议用扩展名.mp3伪装绕过压缩或者用res/raw存放。拷贝完成后的数据库文件用SQLiteOpenHelper的只读方式打开杜绝大夫误改基础方剂数据。5.3 与第 2 章设计呼应三层结构下的数据同步第 2 章提到 zz-doctor 这类系统的核心是单机可用但作为一个真实在门诊环境使用的系统数据要能导出来给院内系统用。这里推荐一个不侵入原工程的轻量方案在 app 里加一个导出功能把 SQLite 内容序列化成 JSON 输出到共享目录供院内 HIS 系统轮询。导出代码要跑在子线程避免文件大时 ANR导出完成后发送一个通知。这个做法不破坏原有三层结构又给信息系统补齐了数据流通的短板。整个 zip 包的精髓不在界面多好看而在于围绕患者档案组织起来的数据关系理清这些关系拿到任何类似的 Android 业务系统源码都能快速上手。本文还有配套的精品资源点击获取