简介本资源是一份完整的Android备忘录应用实战源码包面向Android开发初学者与进阶学习者聚焦UI设计、SQLite本地存储、Activity跳转、RecyclerView列表展示及事件响应等核心开发能力训练。压缩包共194个文件含20个Java源文件涵盖MainActivity、NoteEditor等关键逻辑、22个XML布局与资源文件定义界面结构与样式、77张PNG界面截图直观呈现主界面、编辑页、列表页等交互效果以及61个编译生成的class文件和1个可直接安装运行的APK整体体积仅809KB轻量易学。已有1171人下载学习资源结构清晰附带源码说明.txt文档详解模块职责与实现逻辑并包含prefs配置、ogg音效等完整工程要素助读者快速理解从界面搭建、数据增删改查到打包部署的全流程开发实践。 拿到这份 Android 备忘录源码的时候我先在模拟器上跑了一遍又在真机上装了同一份包试了试多任务切换、锁屏后恢复、连续增删笔记等场景发现整体架构干净没有绕弯子。老实说备忘录这类应用在很多人眼里就是“增删改查”四个字的代名词但实际上它恰恰是 Android 开发里最适合拿来练手、也最适合用来完整走一遍项目全流程的题材没有之一。这篇就是我基于这份源码做的完整拆解从数据层到 UI 层从选型理由到实际操作的坑一次说清楚。如果你正处于刚学完 Kotlin 基础、想找项目练手或者做完了好几个 Demo 但始终没串起一个完整应用的阶段这篇非常适合你。我会直接告诉你这份源码里哪些地方值得抄哪些地方实际上手要改以及我踩过的几个数据库和界面上的坑。1. 为什么是备忘录这个项目到底练了什么很多人挑练手项目一上来就奔着购物 App、社交 App 去结果写了两个星期连登录都没做完心态直接崩掉。备忘录这种项目看起来简单但它把一个 Android 应用该有的核心环节全串起来了界面搭建、数据持久化、列表展示、编辑交互、状态恢复。你做完这一个相当于把 Android 开发的主干道走了一遍。1.1 一个备忘录项目覆盖的核心知识点我可以直接给你列一下这份源码里能学到的知识点你会发现它其实一点都不“小”Activity 生命周期从列表页跳到编辑页再返回数据怎么保持、状态怎么恢复这是备忘录应用最基础也最重要的场景。RecyclerView 列表展示备忘录列表是 RecyclerView 最典型的使用场景涉及 Adapter、ViewHolder、item 布局、点击事件。本地数据库操作Room 框架下的增删改查CRUD包括 DAO 层的编写、SQL 语句的编写、LiveData 的配合使用。数据持久化方案选型为什么用 Room 而不是直接用 SQLite或者用 SharedPreferences这里头有很实际的理由。UI 交互细节编辑框的焦点处理、软键盘弹出时的布局调整、删除操作的确认机制。所以说到底备忘录不是一个“小项目”它是一个“小而全”的项目。它的核心价值不在功能多而在每一条技术线都足够清晰适合用来建立完整的项目思维。1.2 哪些人最适合拿这份源码学习刚学完 Kotlin 语法还没做过完整 App 的人你可以从这份源码里看到业务代码是怎么组织的而不是停留在语法层面的“会读不会写”。做过几个 UI Demo但没碰过数据库的人备忘录是你接触 Room、DAO、SQLite 的最佳跳板复杂度刚好够用。准备面试前需要快速复习 Android 基础的人一个备忘录项目在手生命周期、数据持久化、列表复用一轮全部带过比死记概念强太多。我记得我第一次完整跟做备忘录项目是在大二当时最大的感受是原来一个 App 不是“画界面”和“写逻辑”分开的两件事而是靠数据模型把界面和业务绑在一起。这份源码同样是这个逻辑所以我会先从数据层开始拆。2. 数据层设计与选型为什么用 Room 而不是裸 SQLite数据层是整个备忘录源码的骨架。你别看笔记内容看起来只是“标题 内容 时间”三个字段真正要落地的时候光数据库选型就能引出不少门道。2.1 数据持久化选型对比我在很多教程里见过直接用 SQLiteOpenHelper 手写数据库操作的写法但这份源码用的是 Room这个选择我认为是近几年 Android 开发里最值得坚持的实践。我用一张表给你看清楚它们的差异方案优点缺点适用场景SharedPreferences使用简单适合存键值对不适合存结构化数据、不支持查询保存设置项、登录态原生 SQLite功能强SQL 全支持需要手写大量模板代码、无编译期检查极度简单的数据场景Room编译期检查 SQL 语法、支持 LiveData/Flow、与协程配合好有学习成本底层仍是 SQLite绝大多数本地数据场景Room 最大的好处是它在编译期就能帮你检查 SQL 语句是不是写错了而不是留到运行时才 Crash。这一点我实测下来非常省心。以前用原生 SQLite哪天写错一个列名往往要跑到真机上操作好几步才能触发那条逻辑而 Room 在 build 阶段就报出来了。2.2 表结构设计备忘录只有三四个字段也需要设计这份源码里的数据表结构大概是这样的Entity(tableName notes) data class Note( PrimaryKey(autoGenerate true) val id: Long 0, val title: String, val content: String, val timestamp: Long System.currentTimeMillis() )看起来很简单但这里有几个细节值得你注意。第一主键用自增长 Long 类型。自增长主键在新增和更新的时候非常方便不用手动生成 ID也不容易出现重复。有些新手喜欢用时间戳当主键这在快速连点保存的时候会产生极小概率的冲突虽然概率低但没必要赌。第二时间戳建议用 Long 存储不要直接存格式化之后的字符串。这个是我在实际开发中吃过亏的地方。如果你存的是“2025-01-15 14:30:00”这种字符串后续想按日期范围查询、想按时间排序都得依赖字符串比较格式一旦调整就全乱了。存 Long 类型的时间戳展示的时候再格式化想怎么排序、怎么过滤都随意。第三标题和正文分开存储。列表页往往只需要显示标题和摘要如果把全文加载进来再截取既浪费内存也不好实现后续的搜索功能。分开存列表页查询时就可以只取部分字段性能上有肉眼可见的差别。2.3 数据访问层 DAO 设计这份源码的 DAO 接口也走的是标准路线Dao interface NoteDao { Query(SELECT * FROM notes ORDER BY timestamp DESC) fun getAllNotes(): LiveDataListNote Insert suspend fun insertNote(note: Note): Long Update suspend fun updateNote(note: Note) Delete suspend fun deleteNote(note: Note) }我重点说一下用到 LiveData 的原因。LiveData 是 Android 生态里一个非常适合列表展示的数据容器它能够在数据库内容变化的时候自动通知界面刷新。这意味着你不需要在每次增删改之后手动调用“重新加载列表”的逻辑数据一变UI 自动跟着变。配合 Kotlin 协程的话DAO 方法直接声明成 suspend 函数数据库操作自动切到后台线程不会卡主线程。这一点对于新手的价值很大你不用担心自己是不是写了一个会导致 UI 卡顿的数据库操作框架层面已经帮你兜底了。说实话这可能是这份源码里最值得直接“抄作业”的一段代码。你以后做任何需要本地数据的应用这套 DAO 模板基本可以原封不动地复用。3. 核心实操从数据库到界面完整实现一套增删改查这块我按完整的操作流程来讲不单独挑一个点而是把“列表页 → 编辑页 → 保存 → 回到列表刷新”整条链路走一遍并标出关键位置应该怎么写。3.1 项目初始化与依赖引入如果你是从零开始照着这份源码搭项目第一步是在 build.gradle 里加上 Room 相关依赖。注意现在新项目一般都用 Kotlin DSL 和 version catalog写法会和旧版有点区别dependencies { val roomVersion 2.6.1 implementation(androidx.room:room-runtime:$roomVersion) implementation(androidx.room:room-ktx:$roomVersion) kapt(androidx.room:room-compiler:$roomVersion) }如果是纯 Kotlin 项目用 kapt 还是 ksp 取决于你的插件配置。新项目建议直接用 KSP构建速度会快不少plugins { id(com.google.devtools.ksp) version 2.0.0-1.0.21 } dependencies { implementation(androidx.room:room-runtime:$roomVersion) implementation(androidx.room:room-ktx:$roomVersion) ksp(androidx.room:room-compiler:$roomVersion) }这一步看着简单其实新手最容易卡在“依赖加完了依然报 cannot find symbol”这种问题上。绝大多数情况是注解处理器没配好KSP 插件和 Kotlin 版本不匹配或者忘了启用对应插件。你看到编译报错先不要慌检查顺序永远是Kotlin 插件版本 → KSP 插件版本 → Room 编译器版本三者对应上才稳妥。3.2 数据库实例的创建对象别乱 new接下来是创建 RoomDatabase。这里有个非常关键的实践整个应用应该只保留一个数据库实例。原因很简单每 new 一个 RoomDatabase 对象你就等于多建了一条数据库连接池多个实例同时操作数据库在高频场景下容易出幺蛾子。所以源码里通常采用伴生对象加双重校验锁的方式来实现单例Database(entities [Note::class], version 1, exportSchema false) abstract class AppDatabase : RoomDatabase() { abstract fun noteDao(): NoteDao companion object { Volatile private var INSTANCE: AppDatabase? null fun getInstance(context: Context): AppDatabase { return INSTANCE ?: synchronized(this) { val instance Room.databaseBuilder( context.applicationContext, AppDatabase::class.java, note_database ).build() INSTANCE instance instance } } } }注意这里用的是applicationContext而不是 Activity 的 context这能避免数据库实例持有 Activity 引用导致的内存泄漏。这种细节看起来不起眼但在项目大了之后会直接影响稳定性。exportSchema false这里也可以解释一句Room 可以自动导出数据库的 schema 文件方便以后做版本迁移对比。如果你没有做严格的数据库版本管理需求先关掉省得 build 的时候多产出一堆 json 文件影响阅读。3.3 列表页Adapter 与 ViewHolder列表页是整个备忘录的门面。用户在列表页看到一条条笔记的标题、摘要和时间点击任意一条进入编辑页修改长按可以删除还有悬浮按钮来新建笔记。RecyclerView 的 Adapter 写法已经非常成熟我直接说你最容易写错的几个点第一Click 和 LongClick 要分离。单击进入编辑长按弹删除确认框。不要把两个事件混在一个监听器里写否则后面扩展“长按多选”功能时会非常痛苦。第二ViewHolder 里做绑定不要在 onBindViewHolder 里 new 监听器。正确做法是在 ViewHolder 初始化的时候把 itemView 的点击监听器设置好在 onBind 时通过 adapterPosition 或 binding 变量来获取当前数据。这样列表滑动时会少创建大量无用对象性能差在数据量大了之后才能感觉到但习惯一定要从一开始就养好。第三列表数据的增删要使用 DiffUtil 或 ListAdapter。源码里如果不小心用的是notifyDataSetChanged()那在数据量超过几十条时就能明显感到卡顿和闪烁。Google 官方现在推荐使用 ListAdapter 配合 DiffUtil它能自动计算数据差异只刷新发生变化的那一行视觉上不会出现整页闪一下的问题。3.4 编辑页与保存逻辑编辑页是备忘录里交互最复杂的部分因为它涉及到“用户正在打字的时候突然退出内容怎么处理”的经典问题。源码里通常的处理方式是这样的编辑页收到一个可空的 Note 对象如果为 null 说明是新建否则是编辑已有笔记。保存时判断当前是新建还是更新分别调用 DAO 的 insert 或 update。点击返回键时先把当前编辑框的文本存回 ViewModel再 finish。但我拿到这份源码后实际跑了一下发现它有一个小坑如果用户新建了一条笔记一个字都没打就直接返回数据库中会产生一条空记录。这个问题在改 bug 时非常常见解决办法也不复杂if (title.isBlank() content.isBlank()) { return }也就是在 insert 之前做一个空内容的判断内容为空就不入库。这个判断看似简单但很多真实上线的 App 里都会漏掉最后数据库里躺着一堆空白记录。另外我强烈建议你在编辑页加上草稿恢复逻辑。具体做法是在onPause或onStop时把未保存的内容写入 ViewModel 或内存缓存返回编辑页时再恢复出来。否则用户在编辑框里写了三百字突然来个电话回来发现内容没了这种体验是很打击人的。3.5 删除操作与交互反馈删除备忘录的操作源码里用的是点击列表项进入编辑页编辑页里通过菜单删除或者列表页长按删除。但我自己实测之后觉得在列表页直接加一个“左滑删除”的交互体验更好。用 ItemTouchHelper 实现左滑删除其实并不难val callback object : ItemTouchHelper.SimpleCallback( 0, ItemTouchHelper.LEFT or ItemTouchHelper.RIGHT ) { override fun onMove(...): Boolean false override fun onSwiped(viewHolder: RecyclerView.ViewHolder, direction: Int) { val position viewHolder.bindingAdapterPosition val note adapter.currentList[position] viewModel.deleteNote(note) } } ItemTouchHelper(callback).attachToRecyclerView(recyclerView)额外加一层确认弹窗会更稳妥。我在项目里是左滑后先弹出 AlertDialog让用户确认“删除 / 取消”确认后再执行删除。这样既保留了手势操作的便利性又避免了一不小心删掉重要笔记后没法恢复的尴尬。4. 工程化细节ViewModel、Repository、依赖注入与主题适配如果这份源码只是一个“Activity 直接操作数据库”的写法那它和教程 Demo 就没区别了。真正让它值得参考的是它在这三层上做了清晰分层以及我对其中工程化细节的补充。4.1 ViewModel 与 Repository 的分层逻辑好的 Android 项目会遵循“界面不直接碰数据库”的原则。界面层Activity/Fragment只和 ViewModel 打交道ViewModel 持有 LiveData/StateFlow数据来自 RepositoryRepository 再访问 DAO。这样的分层有啥实际好处最直接的一点是当 App 旋转屏幕时Activity 会销毁重建但 ViewModel 不会。所以你的数据加载状态、正在编辑的文本内容都能在 ViewModel 里存活下来。你不需要在onSaveInstanceState里打包一堆乱七八糟的数据省心很多。Repository 层则更像一个“数据总管”它对外屏蔽了数据来源。今天你用 Room 存本地明天你想加一个云端同步只要改 Repository 的内部实现UI 层几乎不用动。这就是分层的价值——不是炫技而是真的能省下将来重构的时间。4.2 手写依赖注入与 Hilt 的取舍这份源码大概率没有引入 Hilt因为项目规模不大手工实例化 Database 和 DAO 也完全够用。我自己在实际项目里的经验是项目不到 10 个类别急着上 Hilt。Hilt 的注解编译、模块配置都有学习成本小项目用它纯属自找麻烦。如果你以后项目变大了再考虑引入 Hilt。这里给你一个判断标准当你在多个 Activity 或 Fragment 里重复写AppDatabase.getInstance(context).noteDao()这种代码写到自己都觉得烦的时候再上 Hilt 不迟。过早的架构设计是负担恰到好处的分层才是效率。4.3 深色模式与主题适配现在 Android App 都要考虑深色模式适配备忘录这种以文字内容为主的应用尤其重要因为白底黑字在夜间环境下真的很刺眼。主题适配在源码里如果没有写全我建议你按这个思路补上颜色资源不要硬编码在布局里统一使用?attr/colorSurface、?android:attr/textColorPrimary这类系统属性。编辑页的背景和文字颜色跟随系统主题用values-night目录下的颜色资源覆盖。时间戳文字用次要文字颜色保证在浅色和深色模式下都有足够的对比度。这套做法的核心是让主题切换不需要改 Java/Kotlin 代码全靠资源目录按限定符自动匹配。系统切到深色模式App 自动加载values-night下的颜色值界面就跟随着变了。这是 Android 官方推荐的做法也是源码后续最容易让人眼前一亮的功能点。5. 源码之外我踩过的坑和给你的优化建议下面的内容是纯经验区。我把从这份源码基础上扩展时踩过的坑和解决思路整理出来每一条都是实操中真真实实遇到过的。5.1 时间显示如何让时间戳更符合直觉备忘录列表页的时间显示我建议做成“上午 10:30 / 昨天 14:00 / 2025-01-15”这种相对时间格式比单纯显示一长串数字直觉得多。实现的时候需要写一个格式化函数把时间戳和当前时间做比较今天内显示“今天 HH:mm”昨天显示“昨天 HH:mm”早于昨天但同一周内显示“周X HH:mm”更早显示“yyyy-MM-dd HH:mm”在 Kotlin 里用java.time包API 26会非常顺手如果你的minSdkVersion低于 26可以考虑使用SimpleDateFormat加自定义逻辑或者干脆引入 ThreetenABP 兼容库。这块代码逻辑不难但很多人会忽略“时间应该跟着用户习惯走”这个点。5.2 数据库版本升级提前想好别上线后慌张备忘录的核心数据是用户自己写的文字数据丢了基本等于灾难。等版本升级的时候数据库结构大概率会变比如新增一个“标签”字段、增加一个“置顶”标志位这就涉及 Room 的数据库迁移。Room.databaseBuilder(...).addMigrations(MIGRATION_1_2)是官方提供的方案。每次修改表结构你都要写一个 Migration 对象在里面执行ALTER TABLE之类的 SQL把旧数据保留下来。我遇到过有人图省事直接改成.fallbackToDestructiveMigration()然后一升级就把用户表全清了。这种做法在开发阶段能用在正式发布就是事故。写迁移的时候建议这么做先保留一份旧版数据库文件然后在测试环境做一次真实升级路径的验证。比如你 v1 的表结构是notes(id, title, content, timestamp)v2 要新增一个color字段那么迁移代码是val MIGRATION_1_2 object : Migration(1, 2) { override fun migrate(db: SupportSQLiteDatabase) { db.execSQL(ALTER TABLE notes ADD COLUMN color INTEGER NOT NULL DEFAULT 0) } }然后创建数据库的时候把它传进去Room.databaseBuilder(...) .addMigrations(MIGRATION_1_2) .build()这里有个小细节如果你在新建数据库时直接删掉旧的安装包重装是测不出来升级路径的。一定用旧包在手机上创建数据装升级到新版本再检查旧数据是否都还在。我在这个坑上栽过一次刚上线新版本的时候几乎所有用户都反馈笔记丢了后来发现是开发时只测了全新安装没有走真实升级流程。5.3 搜索功能给备忘录加一个放大镜备忘录的功能一旦有了一定数量笔记搜索就成了刚需。最简单的实现是在 DAO 里写LIKE查询Query(SELECT * FROM notes WHERE title LIKE % || :keyword || % OR content LIKE % || :keyword || % ORDER BY timestamp DESC) fun searchNotes(keyword: String): LiveDataListNote在 Activity 里配合 SearchView 或 MaterialSearchBar监听文本变化把关键字实时传给 ViewModelViewModel 再调用这个搜索方法界面就会自动刷新结果。虽然LIKE查询在大数据量下性能一般但对个人备忘录来说完全够用。如果你以后真的需要全文搜索可以再考虑接入 SQLite 的 FTS4/FTS5 虚拟表但那属于进阶玩法现阶段不建议上来就搞。5.4 数据备份导出让笔记不丢才敢放心用备忘录的备份功能源码里大概率没有但实用性极高。我的做法是提供两个入口一个是导出到本地 JSON 文件一个是导出为纯文本.txt。本地文件可以用MediaStore.Downloads写入到系统下载目录这样即使用户卸载重装备份文件还在。导出的核心思路很简单把 Room 里所有笔记查出来转成 JSON 字符串写入到用户选择的目录。恢复时反向解析 JSON 再逐条插入。不需要引第三方库用org.json就能搞定val notes noteDao.getAllNotesOnce() val jsonArray JSONArray() notes.forEach { note - val json JSONObject() json.put(title, note.title) json.put(content, note.content) json.put(timestamp, note.timestamp) jsonArray.put(json) } val jsonString jsonArray.toString()getAllNotesOnce()这个方法是和 LiveData 版并行存在的一个挂起函数直接返回 List适合做导出、统计这类一次性操作。注意备份文件里不要存 id 字段的对应关系恢复时靠时间戳去重就可以了反正新的自增长主键会重新生成。5.5 崩溃恢复与异常防护虽然 MVP 看起来简单但“用户在编辑页打字打到一半 App 被系统回收”这个场景依然存在。如果 ViewModel 没有正确持有正在编辑的内容Activity 销毁后文本就没了。可以用 SavedStateHandle 在 ViewModel 里存草稿class EditViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() { fun saveDraft(title: String, content: String) { savedStateHandle[draft_title] title savedStateHandle[draft_content] content } fun loadDraft(): PairString, String { return savedStateHandle[draft_title] to savedStateHandle[draft_content] } }配合 Activity Result API 和onStop生命周期基本能覆盖绝大多数进程被杀场景。当然完全恢复到一个字都不差的草稿只靠 SavedStateHandle 还不够内存压力大的时候这玩意儿也有被清掉的风险。更稳妥的做法是草稿在一定周期内自动存入数据库的草稿表但那就把备忘录做成一个完整笔记产品了。至少在当前源码规模下SavedStateHandle 是个性价比很高的方案。6. 常见问题速查表把上面提到的坑整理成一张表方便你以后排查问题的时候直接看。问题症状原因解决方案编译报 cannot find symbolRoom 相关类找不到KSP/KAPT 插件未配置确认 Kotlin/KSP/Room 版本对应列表刷新频繁闪动数据一改整页刷新用了 notifyDataSetChanged改用 ListAdapter DiffUtil空白笔记入库数据库出现空记录没有做空内容判断insert 前加 title/content 判空App 升级后数据丢失升级后用户表全空用了 destructive migration写 Migration测试真实升级路径编辑框文字被清空电话或切后台返回后丢失没有做草稿保存ViewModel SavedStateHandle序号乱跳列表删除后 item 错位使用 adapterPosition 不当使用 bindingAdapterPosition我在实际带新人的时候发现大多数人第一次做备忘录都会在“列表刷新闪动”这个点上犯迷糊。原因是notifyDataSetChanged看起来很直观数据变了就刷新但它会让整个列表全部重建正在滑动的用户能明显看到视觉上的割裂感。ListAdapter 配合 DiffUtil 后列表只会精准刷新变化的那一行体验完全不同。还有一个隐藏的小坑如果你在 Adapter 里用了onClick拿到 position 后直接取dataList[position]在列表发生删除操作后position 可能已经和 ViewHolder 绑定的 item 不对应导致点击事件窜行。这也是为什么我上面强调要用bindingAdapterPosition它是 RecyclerView 提供的当前真正绑定位置的接口。7. 从这份源码还能延伸出什么如果你已经跑通了这份源码想继续往上加东西练手我建议按下面的路线做几个迭代版本版本二加搜索。把 DAO 的 LIKE 查询和 SearchView 接上练字符串匹配和状态保持。版本三加标签或分类。新增一张标签表笔记和标签做多对多关联练 SQL 联表和数据库迁移。版本四加备份和恢复。把笔记导出成 JSON 再导入练文件读写和第三方存储交互。版本五加云同步。接一个后端或者本地网络服务练网络请求和本地缓存合并。每加一个功能你都会发现原有代码需要微调这反而是最好的学习过程。很多人做完一个项目就丢一边了但我觉得把一个项目滚到第三版、第四版比新开十个项目练手的效果都好因为重构才是最考验对架构理解能力的。我第一次完整做完备忘录项目加了搜索和备份功能之后再回头去看之前觉得云里雾里的 RecyclerView 复用机制一下就通了。很多时候不是概念太难而是没有在真实项目里反复碰到它。最后分享一个我自己的小习惯每次拿到一份源码不要只跑起来看效果先画一遍它的数据流和调用链。哪一层负责数据、哪一层负责界面、数据怎么从数据库流到屏幕上画明白了这个项目才算真正吃透了。就像这份备忘录看似简单但把 Room、LiveData、RecyclerView、ViewModel 这一套连起来你的 Android 基本功就已经立住了一大半。本文还有配套的精品资源点击获取