安卓图书管理系统开发实战：从SQLite数据设计到APK打包全解析

简介：这是一套安卓图书管理系统完整工程源码，基于安卓Studio开发，面向安卓初中级开发者、计算机专业学生以及需要管理个人藏书或小型图书室的用户。系统实现了图书信息增删改查、用户登记与权限控制、借阅归还、支持按书名、作者、分类进行模糊检索，借阅排行与逾期统计等核心模块，并涵盖书名、作者、出版社、ISBN等字段的规范管理，覆盖了管理类应用从界面布局、数据存储、业务处理到打包上线的完整链路。压缩包共110个文件，核心由30个Java源码、34个XML界面与配置、25张PNG图片资源构成，同时附带Gradle构建脚本、SQLite数据库、二维码扫描库、JKS签名文件以及可直接安装的APK安装包，整体仅3.77MB，目录结构清爽，适合按模块逐个阅读。借助APK可先运行体验，数据库与二维码库为二次开发提供了现成基础，能有效减少环境搭建与基础功能编写的时间。目前已有281人学习下载，无论课程设计、毕业设计还是自学实战，都具有不错的参考价值。

1. 拿到“安卓图书管理系统.zip”，先判断它是作业还是工程

在网盘和课程设计频道里，安卓图书管理系统.zip是出现频率最高的压缩包之一。它是安卓开发课的期末作业、本科毕设的常见选题，也是很多人第一次完整写出增删改查的练手项目。标题里三个词分别指向三条主线：“安卓”决定运行环境和交互范式，“图书管理系统”要求覆盖图书档案维护、借阅流转、读者查询这些真实业务闭环，.zip则意味着你拿到的是一堆源码与资源的集合体，而不是一个可直接安装的 APK。解压之前先想清楚自己面对的是什么：一套能跑通的 Demo，还是一次需要重构、补课和重新打包上线的开发任务。这篇文章从拆包开始，把数据表设计、借还状态机、搜索排序和打包验证的关键路径走一遍，适合要接手旧工程、改造期末作业或从零重写这套系统的人。

2. 拆开 zip：目录结构、构建脚本与关键依赖怎么读

2.1 从 build.gradle 判定项目基线

拿到压缩包后第一件事是解压，然后看它是不是一个完整的 Android Studio 工程。常见的做法是解压后先看根目录有没有settings.gradle、build.gradle，以及gradle/wrapper目录。这三个文件同时存在，说明项目可以导入 Android Studio 直接构建；如果只有AndroidManifest.xml和一个src目录，那是 Eclipse 时代的老工程，需要先转换才能继续开发。

unzip 安卓图书管理系统.zip -d book-manage cd book-manage tree -L 2 -I "build|.gradle|.idea"

这段命令把压缩包解压到book-manage目录，然后以两层深度列出目录树，排除掉build、.gradle和.idea这些生成目录。接下来重点看app/build.gradle，这个文件直接决定了你基于什么版本的 SDK 和依赖在开发，也是接管项目后最容易踩坑的地方。

android { compileSdkVersion 30 buildToolsVersion "30.0.3" defaultConfig { applicationId "com.example.bookmanager" minSdkVersion 21 targetSdkVersion 30 versionCode 1 versionName "1.0" } } dependencies { implementation 'androidx.appcompat:appcompat:1.3.0' implementation 'androidx.recyclerview:recyclerview:1.2.1' implementation 'com.google.android.material:material:1.4.0' }

以上是典型的 Groovy DSL 写法。compileSdkVersion是编译时使用的 API 版本，minSdkVersion表示最低支持到 Android 5.0，targetSdkVersion则影响运行时权限模型和行为兼容性。如果依赖里能看到androidx.room，说明数据层已经有官方 ORM；如果只有sqlite或什么都没有，那多半是原生SQLiteOpenHelper的写法。这套判断方法对 5 年以上经验的开发者同样有用，因为很多旧项目的targetSdkVersion停留在 28 以下，放到今天的应用市场上会直接触发安装拦截。

观察点	旧项目特征	可维护性
依赖管理	使用libs/放 jar 包	低，升级困难
包名前缀	com.example	一般，上架前要改
minSdkVersion	16 以下	中，兼容工作量大
构建工具	非 Gradle 或旧版 Wrapper	低，先补版本再编译

2.2 从 AndroidManifest.xml 看权限与入口配置

app/src/main/AndroidManifest.xml是系统认识这个应用的入口。先看权限声明，再找MainActivity是不是LAUNCHER，这一步能快速确定打开 App 后第一个页面是登录页还是图书列表页。很多课程设计会把入口直接设为管理员登录，这意味着你需要准备一组默认账号，否则真机安装后没法进入主界面。

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <application android:label="@string/app_name" android:icon="@mipmap/ic_launcher" android:theme="@style/Theme.AppCompat.Light.DarkActionBar"> <activity android:name=".ui.LoginActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name=".ui.MainActivity" /> </application>

READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE在 Android 6.0 以上属于运行时权限，只写在清单里不够，还要在代码里动态申请。这句参数说明对应到一个高频报错：SecurityException: Permission Denial，多半就是你只加了<uses-permission>但没走requestPermissions。如果项目里同时看到android:requestLegacyExternalStorage="true"，说明作者针对 Android 10 做了旧存储适配，升级 targetSdkVersion 到 31 以上后这个配置会失效，需要改成分区存储方案。

2.3 拿到源码后的几个必查位置

把源码当工程接管时，我一般会优先看三个位置：数据库帮助类、工具类里的账号密码硬编码、以及图书列表用的适配器。数据库帮助类能直接告诉你数据存在哪、表结构长什么样；硬编码的admin/123456这类默认账号要替换或保留并提示用户；适配器则暴露了列表项用的是RecyclerView还是已经过时的ListView。这些位置不直接关乎功能能否运行，但决定了你改造时的工作量边界。

解压后如果在assets/或res/raw/下看到预置的.db文件，那说明系统用现有库初始化数据。要注意库里字段有没有_id这一列，Android 的SimpleCursorAdapter强制要求_id作为主键列名，少了它列表加载时会直接抛出IllegalArgumentException。这套老适配器在校验时比Room严格得多，先确认它再动代码，能省下不少排查时间。

3. 图书管理系统的数据层怎么设计：SQLite 与 Room 的取舍

3.1 三张表能覆盖的核心业务模型

图书管理系统再复杂，落到数据层也就是三张核心表：book存图书信息，reader存读者，borrow_record存借还流水。很多课程设计还会加一张admin表或直接把管理员字段写死在Preference里，这取决于登录模块怎么实现。我的建议是保留admin表，因为后续如果你加“修改密码”功能，改表比改代码更符合业务直觉。

CREATE TABLE book ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, author TEXT, isbn TEXT UNIQUE, category TEXT, publisher TEXT, publish_year INTEGER, stock INTEGER DEFAULT 1, status INTEGER DEFAULT 0, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE reader ( id INTEGER PRIMARY KEY AUTOINCREMENT, reader_no TEXT UNIQUE NOT NULL, name TEXT NOT NULL, phone TEXT, grade TEXT, max_borrow INTEGER DEFAULT 5 ); CREATE TABLE borrow_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, book_id INTEGER NOT NULL, reader_id INTEGER NOT NULL, borrow_time TEXT DEFAULT (datetime('now', 'localtime')), due_time TEXT, return_time TEXT, status INTEGER DEFAULT 0, FOREIGN KEY (book_id) REFERENCES book(id), FOREIGN KEY (reader_id) REFERENCES reader(id) );

book.status用 0 表示在馆、1 表示借出，避免每次通过关联表统计来算状态，查询更快也更直观。stock和status并存要注意逻辑一致性：同一本书有多册时，status描述的是“当前这条记录”的状态，否则会出现库里显示在馆但实际已借空的矛盾。borrow_record.status保留 0 借出中、1 已归还、2 逾期未还的枚举，这样统计报表时不需要 join 时间字段判断。

3.2 用 SQLite 写一个可运行的 DAO

原生的SQLiteOpenHelper在 README 里最好用且不需要加依赖，适合老项目和课程设计。下面的帮助类定义了单例模式，onCreate里一次性执行建表语句，后面每次升级版本号时在onUpgrade里做增量迁移。

public class DBHelper extends SQLiteOpenHelper { private static final String DB_NAME = "book_manager.db"; private static final int DB_VERSION = 1; private static volatile DBHelper instance; public static DBHelper getInstance(Context context) { if (instance == null) { synchronized (DBHelper.class) { if (instance == null) { instance = new DBHelper(context.getApplicationContext()); } } } return instance; } private DBHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL("CREATE TABLE IF NOT EXISTS book (...);"); db.execSQL("CREATE TABLE IF NOT EXISTS reader (...);"); db.execSQL("CREATE TABLE IF NOT EXISTS borrow_record (...);"); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion < 2) { db.execSQL("ALTER TABLE book ADD COLUMN location TEXT"); } } }

注意onUpgrade不要写DROP TABLE IF EXISTS，否则用户升级 App 会丢数据。这里DB_VERSION从 1 升到 2，只执行ALTER TABLE增加一列，属于安全的增量迁移。DAO 层的写法也很直接，用一个BookDao把Cursor转成 Java 对象，避免在 Activity 里到处写 SQL。

public List<Book> queryByKeyword(String keyword, String orderBy) { List<Book> list = new ArrayList<>(); SQLiteDatabase db = DBHelper.getInstance(context).getReadableDatabase(); String sql = "SELECT * FROM book WHERE title LIKE ? OR author LIKE ? ORDER BY " + orderBy; Cursor cursor = db.rawQuery(sql, new String[]{"%" + keyword + "%", "%" + keyword + "%"}); while (cursor.moveToNext()) { Book book = new Book(); book.setId(cursor.getLong(cursor.getColumnIndexOrThrow("id"))); book.setTitle(cursor.getString(cursor.getColumnIndexOrThrow("title"))); book.setAuthor(cursor.getString(cursor.getColumnIndexOrThrow("author"))); book.setStatus(cursor.getInt(cursor.getColumnIndexOrThrow("status"))); list.add(book); } cursor.close(); return list; }

getColumnIndexOrThrow的好处是列不存在时直接抛异常，比getColumnIndex返回 -1 更容易暴露字段名拼写错误。ORDER BY这里用字符串拼接有注入风险，不过orderBy如果是内部代码传入的固定值，比如"publish_year DESC"，风险可控；如果来自用户输入，就必须改用白名单校验。

3.3 如果换成 Room，改造代价有多大

Room 是 Google 推出的官方 ORM，解决的是 SQLite 样板代码多和 Cursor 容易忘关这两个问题。换成 Room 最少要改四样东西：build.gradle加annotationProcessor或 KSP 插件，把DBHelper改成@Database注解的抽象类，把 DAO 接口化，把实体类加上@Entity。如果原工程用SQLiteOpenHelper直接操作，且所有 UI 层都依赖 Cursor，那么换 Room 的改动面会扩散到每一个查询调用点。

改造项	SQLite 原生	Room	工作量评估
建表	DBHelper 拼接 SQL	@Entity + @Database	中
查询	rawQuery + Cursor	@Query 方法直接返回 List	需要逐方法替换
异步	手动线程	LiveData + Flow	小到中，需引入新依赖
字段变更	ALTER TABLE	Migration 类写迁移 SQL	小，但版本管理要跟上

什么时候值得换？当系统要加“借阅历史报表”“排行统计”这类带聚合函数的查询时，Room 的@Query比手撕 Cursor 舒服很多。如果只是现存系统跑得很稳，没有新增复杂查询的需求，我不建议单纯“为了架构”去换。数据库层稳定性的优先级高于框架潮流，把SQLiteOpenHelper封装到 DAO 里，UI 层不要直接见Cursor，也能达到接近 Room 的维护体验。

4. 业务闭环：借书、还书、逾期与搜索排错

4.1 列表页的查询与状态渲染

图书列表页是所有业务的主入口。列表项至少要显示封面占位图、书名、作者和状态标签。查询接口上一章已经写好了queryByKeyword，在 Activity 里调用后，把结果传给RecyclerView.Adapter，状态列根据status显示不同颜色的标签。这里有一个常见失误：直接在适配器里做数据库查询。每个列表项的onBindViewHolder如果都去查一次库，列表稍微一长就会出现卡顿和Application Not Responding。

public class BookAdapter extends RecyclerView.Adapter<BookAdapter.ViewHolder> { private List<Book> data; public void updateData(List<Book> newData) { this.data = newData; notifyDataSetChanged(); } @Override public void onBindViewHolder(ViewHolder holder, int position) { Book item = data.get(position); holder.title.setText(item.getTitle()); holder.author.setText(item.getAuthor()); if (item.getStatus() == 0) { holder.status.setText("在馆"); holder.status.setTextColor(Color.parseColor("#2E7D32")); } else { holder.status.setText("借出"); holder.status.setTextColor(Color.parseColor("#C62828")); } } }

updateData方法一次性传入整份数据，然后notifyDataSetChanged刷新整个列表。这个方案在前台线程查询几百条记录时问题不大，但如果数据量上万条，就要考虑把查询放进子线程，用Handler或协程回传结果。状态渲染的另一个隐藏坑是颜色写死在 Java 代码里，最好抽取成资源色，否则做深色模式适配时要改所有setTextColor调用点。

4.2 借书操作的状态机

借书是系统里最容易出 bug 的部分。用户在详情页点“借阅”时，需要同时完成几件事：检查读者剩余可借额度、检查这本书是否在馆、插入借阅记录、更新图书状态。任何一步失败，都不能留下半截数据。Android 的SQLiteDatabase提供了事务方法beginTransaction，把这几步包进一个事务里执行。

public boolean borrowBook(long bookId, long readerId) { SQLiteDatabase db = DBHelper.getInstance(context).getWritableDatabase(); boolean success = false; db.beginTransaction(); try { // 1. 检查读者当前未还数量是否达到上限 Cursor c = db.rawQuery( "SELECT COUNT(*) FROM borrow_record WHERE reader_id = ? AND status = 0", new String[]{String.valueOf(readerId)}); int count = 0; if (c.moveToFirst()) { count = c.getInt(0); } c.close(); if (count >= MAX_BORROW) { throw new IllegalStateException("已达到最大借阅数量"); } // 2. 检查图书状态并改为借出 Cursor bc = db.rawQuery( "SELECT status FROM book WHERE id = ?", new String[]{String.valueOf(bookId)}); if (!bc.moveToFirst() || bc.getInt(0) != 0) { bc.close(); throw new IllegalStateException("图书不存在或已借出"); } bc.close(); db.execSQL("UPDATE book SET status = 1 WHERE id = ?", new Object[]{bookId}); // 3. 写入借阅记录 db.execSQL( "INSERT INTO borrow_record(book_id, reader_id, due_time) VALUES(?, ?, datetime('now', 'localtime', '+30 days'))", new Object[]{bookId, readerId}); db.setTransactionSuccessful(); success = true; } catch (Exception e) { Log.e("borrowBook", "借书失败: " + e.getMessage()); } finally { db.endTransaction(); } return success; }

借阅流程里最关键的是先检查后更新的顺序，以及异常时通过endTransaction回滚所有修改。due_time的 30 天借期用datetime('now', 'localtime', '+30 days')在 SQL 层生成，这样移动端 App 与以后可能存在的其他客户端共用同一套日期逻辑。MAX_BORROW要和reader表里max_borrow字段保持一致，我这里直接用了常量，更稳妥的读法是每次查询读者信息时把上限一并查出再比较。

还书流程是对称的：更新borrow_record的return_time和status = 1，再把book.status重置为 0。如果系统还需要记住是谁借的这本书、什么时候还的，这些信息都在流水表里保留，图书表本身只负责当前状态。逾期判断我建议用 SQL 直接比较日期，不要用 Java 的SimpleDateFormat每次解析字符串，统一让 SQLite 的日期函数做比较更省心。

4.3 搜索与排序：LIKE、排序参数和索引

图书检索是这类管理系统的高频操作。大多数 Demo 的做法是拿关键词对书名和作者做LIKE模糊匹配，条件允许时再加 ISBN 精确匹配。LIKE的性能瓶颈在于前置通配符%keyword%无法使用索引，数据量几千条时感受不明显，但到了数万册的规模，就要考虑引入全文搜索或改用fts4虚拟表。

-- 简单模糊查询 SELECT * FROM book WHERE title LIKE '%图书%' OR author LIKE '%李%' ORDER BY publish_year DESC, id DESC; -- 使用 FTS4 的替代方案 CREATE VIRTUAL TABLE book_fts USING fts4(title, author, content=book); INSERT INTO book_fts(book) VALUES('rebuild'); SELECT * FROM book_fts WHERE book_fts MATCH '图书* 李*';

ORDER BY publish_year DESC, id DESC的排序规则是我个人习惯：年份新的在前，同年份按入库顺序倒排，这样搜索结果看起来是最新上架的，而不是最早录入的。至于用户输入了%或_这两个LIKE通配符，会导致查询结果和预期不一致，处理方式是在拼搜索词前先转义，把%换成\%，_换成\_，并在 SQL 末尾加ESCAPE '\'。这个问题排查起来很隐蔽但复现率极高，值得在封装 DAO 时统一处理。

5. 打包前的调优与验证：从 APK 到上传市场的检查清单

5.1 APK 构建与真机安装验证

在 Android Studio 里点绿色三角形运行只能证明 Debug 包能跑，上架和交付要用 Release 包。命令行构建可以把步骤固化进脚本，团队接手时不需要装 IDE 也能出包。

./gradlew clean assembleRelease cp app/build/outputs/apk/release/app-release.apk ./图书管理系统_$(date +%Y%m%d).apk

构建成功后先别急着上传市场，装到真机上走一遍核心流程。至少在 Android 9 和 Android 13 这两台设备上各跑一轮，重点验证存储权限、数据库初始化、借还书事务这三处。真机调试时用adb logcat抓本地日志，AndroidRuntime开头的 FATAL 异常直接定位崩溃点。

adb install -r app-release.apk adb logcat -s AndroidRuntime:E SQLiteLog:E

-r参数允许覆盖安装，-s按 tag 过滤日志只显示运行时错误和 SQLite 错误。如果在SQLiteLog里看到database disk image is malformed，多半是用户在低版本升级时onUpgrade没处理好，属于数据迁移事故。这类问题靠 logcat 排查只是治标，治本要在onCreate的建表语句里把所有旧版本迁移路径都写清楚。

5.2 上架主流安卓应用市场前必改的几个配置项

现在的应用市场主流要求targetSdkVersion不低于 30，部分渠道已经要求 33 以上。这个配置除了影响审核，还直接改变运行时行为，比如 31 以上强制分区存储，33 以上通知权限需要动态申请。很多老笔记本项目编译通过后一上传就被拒，基本都是这里的版本配置没过关。

android { defaultConfig { targetSdkVersion 33 } signingConfigs { release { storeFile file('../keystore/release.keystore') storePassword 'your-store-password' keyAlias 'bookapp' keyPassword 'your-key-password' } } buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.release } } }

需要强调：storePassword和keyPassword不应该明文写在build.gradle里，放进~/.gradle/gradle.properties或用环境变量注入是更稳妥的做法；否则代码一旦上传到公开仓库，证书口令直接泄漏，后续所有版本更新都要换签名。minifyEnabled true开启代码压缩，注意如果项目里用了反射或Gson解析实体类，混淆规则必须补充keep规则，否则 Release 包运行时字段全变成a、b，接口解析直接拿不到数据。

5.3 给项目留一个可维护的小工具：导出书目到 CSV

演示系统交付后最常遇见的请求是“帮我把书单导出来做盘点”。与其临时在数据库工具里复制，不如在应用里做一个隐藏的导出功能，把图书表全量导出为 CSV 文件，通过FileProvider分享到微信或邮件。下面这段代码不依赖第三方 CSV 库，用StringBuilder拼接并处理了字段中含逗号和换行的情况。

public static File exportBooksToCsv(Context context) { SQLiteDatabase db = DBHelper.getInstance(context).getReadableDatabase(); Cursor cursor = db.rawQuery( "SELECT title, author, isbn, category, status FROM book ORDER BY id", null); String[] columns = {"书名", "作者", "ISBN", "分类", "状态"}; StringBuilder sb = new StringBuilder(); sb.append(String.join(",", columns)).append("\n"); while (cursor.moveToNext()) { String[] line = new String[columns.length]; for (int i = 0; i < columns.length; i++) { String value = cursor.getString(i); if (value == null) value = ""; if (value.contains(",") || value.contains("\"")) { value = value.replace("\"", "\"\""); value = "\"" + value + "\""; } line[i] = value; } sb.append(String.join(",", line)).append("\n"); } cursor.close(); File dir = context.getExternalFilesDir("export"); if (dir == null) return null; if (!dir.exists()) { dir.mkdirs(); } File file = new File(dir, "books_" + System.currentTimeMillis() + ".csv"); try (FileOutputStream fos = new FileOutputStream(file); OutputStreamWriter writer = new OutputStreamWriter(fos, StandardCharsets.UTF_8)) { writer.write('\ufeff'); writer.write(sb.toString()); } catch (IOException e) { Log.e("export", "导出失败", e); return null; } return file; }

导出的核心细节有两处：写文件时加上 UTF-8 BOM，这样用 Excel 打开时中文不会乱码；文件放在getExternalFilesDir目录下，这是应用专属外部目录，不需要申请存储权限，用户用文件管理器可能直接看不到，但通过分享功能发给别人没有问题。把这段逻辑挂到列表页右上角的菜单里，点一下就能生成当前书单快照，无论是交给老师验收还是做日常盘点都够用。

本文还有配套的精品资源，点击获取