简介一份基于Android平台的读书笔记App毕业设计论文文档面向高校计算机专业学生与Android开发初学者采用Java语言开发设计解决了传统Web应用只能在PC机上使用、无法随时随地阅读的问题。文档从选题背景、研究现状出发完整覆盖开发环境介绍、Android系统架构与内核分析、需求分析、系统设计、系统测试与维护等环节客户端注册登录、书籍添加、空间查看、书籍搜索等核心功能均有详细阐述并突出“操作简单、功能实用”的设计理念。读者可借此了解Android移动应用从需求到实现的全过程同时获得毕业设计论文结构、摘要撰写、目录编排等方面的规范参考。资源为1个docx文件压缩包大小853KB内容结构清晰便于直接查阅与修改。目前已有59人学习下载适合作为毕业设计选题、课程设计报告撰写及Android入门实战的参考资料具有较强的参考和复用价值。1. 为什么要自己做一个读书笔记App而不是用现成的笔记软件很多做本地阅读的开发者都会遇到同一个问题用户在阅读器里花了两个小时划线、批注真正想回看时才发现笔记和原文是脱节的。市面上的笔记工具以“文档”为记录单位你找不到一本书的第 137 页第二段划线文字更别说按书籍、章节、页码回看自己的批注。标题里“设计”和“实现”并置意味着这不是一个换皮的文本编辑器而要把数据模型、编辑体验和检索路径都围绕“书 笔记”设计。这篇博文按我实际做类似项目的顺序展开先定 Room 表结构再把编辑页的状态恢复和防抖保存做扎实然后补上全文检索和 SAF 导出最后说模拟器和真机在发布前的验证细节。适合正在做本地阅读类 App 的开发者、把毕业设计当独立项目的学生以及准备上架工具类应用的小团队。2. 数据层设计Room 表结构决定书与笔记怎么关联2.1 为什么选 Room 而不是手写 SQLiteOpenHelper书架、图书、笔记、阅读进度这几类数据都是强关系模型用文件存储虽然快但做“某本书下的所有笔记”“某页的第几条划线”这类查询会写出大量遍历代码。Room 在 SQLite 之上提供了编译期校验和 LiveData/Flow 响应式支持DAO 接口写错了在编译时就能暴露这对单人维护项目是很大的兜底。GreenDAO 或 ActiveAndroid 也不是不能选但它们近年的维护节奏已经放缓而 Room 作为 Android 官方架构组件迁移路径最明确先用Migration加列再逐步替换 SQLiteOpenHelper 手写逻辑。需要说明的是Room 对 FTS 虚拟表的原生支持并不完整第 4 章里全文检索部分我会用原生 SQL 方式建虚拟表直接用SupportSQLiteOpenHelper来创建避免 DAO 注解与虚拟表约束冲突。2.2 三张核心表books、notes、reading_state笔记不是独立的字符串它的最小关联单位是book_id page_index start_offset end_offset这四个字段决定了“在哪本书的哪一页、从哪个字符到哪个字符”。start_offset 和 end_offset 是相对该页纯文本的偏移量不能用绝对行号因为换行符和排版在不同字体下会变化。CREATE TABLE books ( book_id INTEGER PRIMARY KEY AUTOINCREMENT, file_name TEXT NOT NULL, title TEXT, author TEXT, pages INTEGER DEFAULT 0, cover_path TEXT, add_time INTEGER NOT NULL ); CREATE TABLE notes ( note_id INTEGER PRIMARY KEY AUTOINCREMENT, book_id INTEGER NOT NULL, page_index INTEGER NOT NULL, start_offset INTEGER DEFAULT 0, end_offset INTEGER DEFAULT 0, note_text TEXT NOT NULL, tag TEXT, create_time INTEGER NOT NULL, update_time INTEGER NOT NULL ); CREATE TABLE reading_state ( book_id INTEGER PRIMARY KEY, page_index INTEGER DEFAULT 1, chapter_title TEXT, scroll_y INTEGER DEFAULT 0, update_time INTEGER NOT NULL );三段字段类型中note_text保存用户真正输入的批注文字而划线选中的原文放在另一张 highlight 表或作为start_offset/end_offset配合原文动态截取。我一般会单独存一份selected_text因为原文件可能被重新排版或替换完全依赖偏移量重建原文并不可靠。reading_state和 books 是 1:1 关系直接以book_id作为主键避免每次翻页都写大字段。last_read_page可以放 books 表但scroll_y这类视图状态不属于书籍实体放独立表能在未来加阅读统计时不动主表结构。2.3 用 DAO 写入一条笔记的最小路径Dao interface NoteDao { Insert suspend fun insertNote(note: NoteEntity): Long Query( SELECT * FROM notes WHERE book_id :bookId AND page_index :page ORDER BY start_offset ASC ) suspend fun getNotesByPage(bookId: Long, page: Int): ListNoteEntity Query( DELETE FROM notes WHERE note_id :noteId ) suspend fun deleteNote(noteId: Long) }Insert返回的 Long 是路由 rowid后续如果要建立 note 和 tag 的多对多关系可以用这个值做关联表的 joinId。getNotesByPage用start_offset ASC排序保证同一页多条笔记的显示顺序与原文位置一致而不是按创建时间。除非笔记数超过几万条否则不必给 notes 表加content_length这种预计算列。偏移量查询依赖索引时直接在(book_id, page_index)上建联合索引即可CREATE INDEX idx_notes_book_page ON notes(book_id, page_index);这个索引会把同页笔记聚簇在相邻位置翻页加载时只扫几十行性能远好于全表过滤。3. 编辑器核心让笔记输入框不丢字、不卡顿3.1 用 ViewModel 保存选中区间与草稿状态读书笔记的输入场景和普通聊天框不同用户经常划选一段原文、思考几十秒、再输入批注。这个过程中一旦 Activity 因屏幕旋转或内存不足被重建EditText 里的文字和光标位置都会丢失。setText 后系统虽会尝试恢复光标但状态一旦落到数据库读取之后的重建流程里恢复时机稍微错位就会跳到开头。常见做法是让 ViewModel 持有两个字段startIndex和endIndex在 TextWatcher 之外用setSelection回调更新。注意不要在 TextWatcher 的afterTextChanged里读selectionStart因为此时文本已经变化索引可能越界应该用 EditText 的onSelectionChanged回调去记录class EditorViewModel : ViewModel() { val selectionStart MutableLiveDataInt() val selectionEnd MutableLiveDataInt() val draftText MutableLiveDataString() } editText.setOnSelectionChangedListener { selStart, selEnd - viewModel.selectionStart.value selStart viewModel.selectionEnd.value selEnd } override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putInt(sel_start, viewModel.selectionStart.value ?: 0) outState.putInt(sel_end, viewModel.selectionEnd.value ?: 0) }ViewModel 持有的 draftText 不能直接作为 EditText 的唯一数据源因为它是防抖保存的输入副本不是实时绑定源。正确做法是让 EditText 保持自由输入ViewModel 只负责持久化和恢复避免每次按键都回到主线程做 IO。3.2 防抖自动保存合并 300ms 内的连续输入直接在afterTextChanged里写库输入法连续上屏时会击穿 SQLite 的事务吞吐。Lite 模式下每秒可接受几十次写入但每次写操作都会触发 Binder 调用和磁盘同步键盘明显掉帧的系统不在少数。用协程做防抖是更干净的选择private val saveJob Job() private val scope CoroutineScope(Dispatchers.IO saveJob) fun scheduleSave(content: String, noteId: Long) { scope.launch { delay(300) withContext(Dispatchers.IO) { noteDao.updateText(noteId, content) } } }delay(300)的语义是只要 300ms 内没有新的输入事件才真正执行写入。连续输入时每次scheduleSave都会把上一个协程取消掉。需要特别处理的是退出编辑页的时机——防抖任务可能还没执行完Activity 就销毁了解决办法是在onStop里直接调用一次同步或挂起保存。防抖时长的选择要看用户输入习惯快速打字时两次按键间隔一般不超过 200ms300ms 可以合并绝大部分冗余写入如果加入了标记语法或图片引用需要把时长提高到 800ms因为粘贴大段文本时系统会逐段回调 TextWatcher。3.3 标记底色与字号调整的轻量做法读书笔记里最常见的标记是黄色底色高亮原文、红色标注重点这不是富文本编辑器里的整段样式而是基于偏移量的区间样式。用SpannableString动态绘制即可不需要引入 span 序列化库fun applyHighlight(text: String, start: Int, end: Int, colorHex: Int): Spanned { return SpannableString(text).apply { setSpan( BackgroundColorSpan(colorHex), start, end.coerceAtMost(text.length), Spannable.SPAN_EXCLUSIVE_EXCLUSIVE ) } }SPAN_EXCLUSIVE_EXCLUSIVE表示在区间边界输入的字符不会被继承样式这符合笔记场景高亮只作用于划选的原文后续输入的文字自动使用默认样式。字号调整则不用 Span直接给整个 EditText 设置textSize保存时只记一个 float 字段。表格对比纠结的点保存时机优点缺点适用场景每次 onTextChanged数据最安全IO 频繁键盘卡顿短文本、无性能要求防抖 300ms 合并兼顾安全和流畅进程被杀可能丢最近 300ms 内容通用笔记输入onStop 强制保存兜底防丢无法覆盖崩溃场景所有 EditText 页面真正要避免的是在onTextChanged里做字符串拼接、长度统计、Spannable 重建。这些操作会成倍放大输入法上屏的耗时把一次 5ms 的插入拉到 30ms 以上。4. 搜索与备份把笔记捞回来再把它带出去4.1 用 FTS4 虚拟表给 note_text 建全文索引读书笔记通常只有几百到几千条但 LIKE 查询在几万条记录上会全表扫描而且不带索引。SQLite 自带的 FTS4 虚拟表能把查询路径从“遍历全部笔记”变成“扫描倒排索引”配合MATCH语法做词级检索。建表时遵守“虚拟表 rowid 对应 notes.note_id”的约定CREATE VIRTUAL TABLE notes_fts USING fts4(note_text, tokenizeunicode61); INSERT INTO notes_fts(rowid, note_text) SELECT note_id, note_text FROM notes;unicode61分词对英文按空格和标点分割对中文基本无效。维护虚拟表时要在notes表插入后同步执行INSERT INTO notes_fts删除时用DELETE FROM notes_fts WHERE rowid :noteId否则会出现索引和主表数据不一致的脏结果。4.2 中文检索的 2-gram 方案与命中高亮中文分词在 Android 端没有现成的标准方案引入 jieba 分词库重且慢。对读书笔记这个体量2-gram 是性价比最高的做法把用户输入的关键词拆成相邻双字组合如“读书笔记”拆成“读书”“书笔”“笔记”在写入 FTS 时同样按 2-gram 切分 note_text。这样查询时用AND组合多个 tokenSELECT n.note_id, n.note_text, n.book_id, n.page_index FROM notes n JOIN notes_fts f ON f.rowid n.note_id WHERE notes_fts MATCH 读书 OR 书笔 OR 笔记 ORDER BY f.rank LIMIT 50;rowid关联是 FTS 查询的核心不能写成JOIN notes ON notes.note_id f.note_id因为虚拟表里没有 note_id 这一列。ORDER BY f.rank让最相关的匹配优先返回排名由词频和文档频率共同决定。2-gram 索引体积约为原文的 1.5 到 2 倍对 Apk 体积和磁盘占用影响很小但建索引时要注意在INSERT INTO notes_fts前用BEGIN TRANSACTION包裹加快回填速度。命中高亮用offsets()函数拿到的字节偏移量是按原始字符串字节位置计算的不能直接用于 UI 的字符索引。正确做法是先用snippet(notes_fts)生成带高亮标记的片段再对b标签做一次转换val snippetText cursor.getString(snippetIndex) val highlightPattern Regex(lt;bgt;(.*?)lt;/bgt;)避免自己遍历匹配关键词位置中文双字切分在边界字符上很容易错位依赖 SQLite 提供的 snippet 实现既省事又不容易出StringIndexOutOfBoundsException。4.3 用 SAF 把笔记导出成 Markdown让用户能带走的笔记才有真正价值。导出到 App 专属外部目录会导致用户升级后目录清空或换个文件管理器就找不到正确路径是通过 Storage Access Framework 创建用户可见文件val createFileLauncher registerForActivityResult(ActivityResultContracts.CreateDocument(text/plain)) { uri - if (uri ! null) { contentResolver.openOutputStream(uri)?.use { os - val markdown buildMarkdown(notes) os.write(markdown.toByteArray(Charsets.UTF_8)) } } }CreateDocument会弹出系统文件选择器用户自主选择下载目录或云盘目录权限由系统授权不需要申请WRITE_EXTERNAL_STORAGE也不需要在清单里声明存储权限这是 Android 11 及以上最稳妥的导出方式。buildMarkdown(notes)里按照“书名为一级标题、章节为二级标题、笔记内容按时间排序”拼字符串每条笔记引用原书页码# 《置身事内》 ## 第一章 地方政府的权力与事务 第 12 页 原句土地本身并不值钱 笔记这里可以和分税制改革联系起来看。MARKDOWN_BLOCK_PLACEHOLDERcontentResolver.openOutputStream默认覆盖已有文件如果用户选择同名文件系统会提示确认替换不用自己处理文件冲突。导出完成后建议发一个 Toast 并带上文件路径用户最关心的是“存到哪里了”而不是抽象的通知文案。5. 从能跑到能发布android测试、签名与验证脚本5.1 模拟器上的冒烟验证adb 检查 note 是否真正落盘很多人写完笔记功能只测试界面能否输入却不知道数据有没有落库。用 Debug 包跑模拟器时可以直接通过 adb 检查 SQLite 文件adb shell run-as com.example.readnote cat databases/note.db local_note.db sqlite3 local_note.db select count(*) from notes; sqlite3 local_note.db select note_text, page_index from notes order by note_id desc limit 5;run-as依赖应用是 debug 版本release 包无法使用但这对于自动化冒烟测试已经足够。配合adb shell input tap和input keyevent可以在不打开 App 的情况下模拟一段输入再重启 App 验证防抖保存是否真正生效——重启后翻到上一次的页码确认文本和光标都还在这是笔记类功能最少要跑通的稳定性测试。如果发现 read 出来是空表先检查 Room 数据库是否被fallbackToDestructiveMigration或版本号变更清空了这是开发期“假装数据丢了”的头号原因。5.2 上架前检查exported 声明、签名 SHA1 与最少权限Android 12 起 targetSdkVersion 提高到 31 之后未声明android:exported的 Activity 无法安装。笔记 App 通常只有启动入口设置为activity android:name.MainActivity android:exportedtrue只有被系统或第三方应用通过 Intent 调用的组件才需要 exportedtrueEditorActivity、SearchActivity 这类仅供内本文还有配套的精品资源点击获取