Android备忘录源码解析：SQLite持久化与RecyclerView增删改查实战

简介：这份Android备忘录源码压缩包面向具备一定Android基础的开发者与移动应用学习者，提供一套可直接研读的完整项目实例，帮助理解备忘录类应用的架构设计与核心功能实现。包内共190个文件，以74个png界面素材、61个class编译产物、22个xml布局与配置、20个java源码为主，另含prefs偏好设置、ogg音频、apk安装包及dex等文件，整体约1.29MB，体量轻便，便于快速导入Android Studio对照分析。源码覆盖Activity入口、SQLite数据库持久化、ContentProvider数据共享、ViewModel状态保持、Adapter列表渲染、Notification提醒以及权限声明等典型模块，并附带drawable、values、styles等UI资源，可直观看到从界面布局到数据存储的完整链路。目前已有1802人学习下载，适合作为课程设计、毕业项目或自学练手的参考范例，通过拆解目录结构与关键类，读者能系统掌握Android应用从搭建到落地的实践思路。

1. 一份 Android 备忘录源码，到底能拿来干什么

很多人第一次拿到「Android代码-备忘录源码.zip」这种资源时，第一反应是解压、用 Android Studio 打开、点运行，然后看到界面能弹出来就以为搞定了。但真正做过 Android 开发的人会告诉你，一份备忘录源码的价值不在于它能不能跑起来，而在于它把「本地数据持久化 + 列表增删改查 + 界面状态同步」这条最经典的移动端业务链路完整地摆在你面前。备忘录这个场景看起来简单，实际上它同时踩中了数据库建表、Cursor 读取、RecyclerView 适配器刷新、Activity 生命周期恢复这几个新手最容易翻车的点。如果你正在学 Android 的本地存储，或者想找一个体量不大但五脏俱全的练手项目，这份源码就是一个很合适的起点。它适合两类人：一类是刚学完四大组件、想找一个完整小项目串一遍知识点的初学者；另一类是想快速搭一个本地记录类 App 原型、不想从零写数据库层的开发者。

2. 备忘录源码的典型结构：先看懂再动手改

2.1 一份标准备忘录工程通常包含哪些模块

拿到源码后不要急着改代码，先花十分钟把目录结构过一遍。绝大多数 Android 备忘录源码的模块划分是固定的，因为这类 App 的业务边界非常清晰。常见做法是下面这种分层：

这个结构里最关键的是NoteDbHelper和NoteDao两个文件。前者决定了数据库长什么样，后者决定了业务层怎么读写数据。很多人改源码时直接去动 Activity，结果发现数据对不上，就是因为没先搞清楚 DAO 层的接口约定。

2.2 用 Android Studio 打开并跑通第一个界面

把 zip 解压到一个不含中文和空格的路径下，然后用 Android Studio 的「Open an Existing Project」导入。导入后先不要点运行，按顺序检查三件事：

# 第一步：确认 gradle 版本和本地环境匹配 # 打开 gradle/wrapper/gradle-wrapper.properties # 看 distributionUrl 里的 gradle 版本，比如 7.5 # 如果你本地 Android Studio 版本较老，这里会直接同步失败 # 第二步：确认 compileSdk 和 targetSdk # 打开 app/build.gradle # 常见配置是 compileSdk 33 或 34 # 如果本地没装对应 SDK，Sync 会报错，去 SDK Manager 补装 # 第三步：确认 minSdk 不要低于 21 # 低于 21 会缺少很多新 API 支持，备忘录用不到那么老的兼容

这三步做完再点 Sync，成功率会高很多。Sync 通过后连接真机或启动模拟器，点 Run。如果界面能正常显示一个空列表或者几条示例数据，说明工程本身是完整的。

2.3 数据库建表逻辑：备忘录的核心就这一张表

备忘录的数据模型极其简单，通常就是一张表搞定。下面是一个典型的建表语句，来自NoteDbHelper的onCreate方法：

// NoteDbHelper.java public static final String TABLE_NAME = "note"; public static final String COLUMN_ID = "_id"; public static final String COLUMN_TITLE = "title"; public static final String COLUMN_CONTENT = "content"; public static final String COLUMN_TIME = "update_time"; @Override public void onCreate(SQLiteDatabase db) { // 建表语句：主键自增，标题和内容为文本，时间为整型时间戳 String sql = "CREATE TABLE " + TABLE_NAME + " (" + COLUMN_ID + " INTEGER PRIMARY KEY AUTOINCREMENT, " + COLUMN_TITLE + " TEXT NOT NULL, " + COLUMN_CONTENT + " TEXT, " + COLUMN_TIME + " INTEGER)"; db.execSQL(sql); }

这段代码有几个参数需要你理解清楚。INTEGER PRIMARY KEY AUTOINCREMENT保证每条记录有唯一 id，删除后 id 不会复用，这对后续做列表点击定位很重要。TEXT NOT NULL加在标题上，意味着标题不能为空，但内容可以为空，这符合备忘录「先写标题再补内容」的使用习惯。update_time用整型存时间戳而不是文本存日期字符串，好处是排序时直接按数值比较，不用做字符串解析，性能更好。

2.4 增删改查四个方法的写法与调用时机

DAO 层的四个方法决定了整个 App 的数据流。下面是最小可用版本的实现：

// NoteDao.java public long insert(Note note) { ContentValues cv = new ContentValues(); cv.put(NoteDbHelper.COLUMN_TITLE, note.getTitle()); cv.put(NoteDbHelper.COLUMN_CONTENT, note.getContent()); cv.put(NoteDbHelper.COLUMN_TIME, System.currentTimeMillis()); // insert 返回新记录的行号，-1 表示失败 return db.insert(NoteDbHelper.TABLE_NAME, null, cv); } public int delete(long id) { // 返回被删除的行数，0 表示没有匹配记录 return db.delete(NoteDbHelper.TABLE_NAME, NoteDbHelper.COLUMN_ID + "=?", new String[]{String.valueOf(id)}); } public List<Note> queryAll() { List<Note> list = new ArrayList<>(); // 按更新时间倒序，最新的备忘排在最前面 Cursor cursor = db.query(NoteDbHelper.TABLE_NAME, null, null, null, null, null, NoteDbHelper.COLUMN_TIME + " DESC"); while (cursor.moveToNext()) { Note n = new Note(); n.setId(cursor.getLong(cursor.getColumnIndexOrThrow(NoteDbHelper.COLUMN_ID))); n.setTitle(cursor.getString(cursor.getColumnIndexOrThrow(NoteDbHelper.COLUMN_TITLE))); n.setContent(cursor.getString(cursor.getColumnIndexOrThrow(NoteDbHelper.COLUMN_CONTENT))); n.setUpdateTime(cursor.getLong(cursor.getColumnIndexOrThrow(NoteDbHelper.COLUMN_TIME))); list.add(n); } cursor.close(); // 必须关闭，否则会泄漏 return list; }

insert用ContentValues而不是拼 SQL 字符串，是为了避免特殊字符导致的语法错误和注入风险。delete的第二个参数是占位符?，第三个参数才是实际值，这种写法比直接拼字符串安全得多。queryAll里用getColumnIndexOrThrow而不是getColumnIndex，是因为前者在列名写错时会直接抛异常，能让你在开发阶段就发现问题，而不是拿到一个 -1 然后取到错误数据。cursor.close()这行是血泪经验，忘记关游标在数据量大了之后会直接崩。

3. 把源码跑成自己的项目：三个必改的地方

3.1 改包名：不改会和其他项目冲突

源码的包名通常是com.example.memo这种通用名。如果你直接安装到手机上，可能和之前装过的测试包冲突，导致覆盖安装或者签名不一致装不上。改包名的正确步骤是：

# 第一步：在 Android Studio 里右键包目录 # Refactor -> Rename -> Rename package # 输入你自己的包名，比如 com.myname.memo # 第二步：手动检查 AndroidManifest.xml # 里面的 package 属性有时候不会自动改，需要手动同步 # 第三步：检查 build.gradle 里的 applicationId # 这个才是真正决定安装包唯一标识的地方 # 改成和包名一致，或者单独指定

改完之后 Clean Project 再 Rebuild。如果报R文件找不到，多半是 Manifest 里的包名和 build.gradle 里的 applicationId 不一致导致的。

3.2 改数据库版本：加字段时必须走 onUpgrade

很多人想给备忘录加一个「分类」字段，直接去onCreate里加了一列，然后发现已经安装过的手机上根本看不到新字段。原因是onCreate只在数据库第一次创建时执行，已经存在的数据库不会重新建表。正确做法是升版本号并在onUpgrade里写迁移逻辑：

// 版本号从 1 升到 2 public static final int DB_VERSION = 2; @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion < 2) { // 新增分类字段，默认值为空字符串 db.execSQL("ALTER TABLE " + TABLE_NAME + " ADD COLUMN category TEXT DEFAULT ''"); } }

这里oldVersion < 2的判断是为了支持跨版本升级。如果用户从版本 1 直接升到版本 3，这段逻辑会先执行版本 2 的迁移，再执行版本 3 的迁移，保证每一步都不漏。注意ALTER TABLE加字段时如果设了NOT NULL就必须给默认值，否则已有数据行会违反约束导致升级失败。

3.3 改列表刷新逻辑：notifyDataSetChanged 不是万能的

源码里最常见的刷新写法是每次增删改之后重新查询全部数据，然后调notifyDataSetChanged。数据量小的时候没问题，但备忘录条目多了之后会有明显卡顿。更合理的做法是只更新变化的那一项：

// 新增一条后，插入到列表头部并通知适配器 noteList.add(0, newNote); adapter.notifyItemInserted(0); recyclerView.scrollToPosition(0); // 删除一条后，先记录位置再移除 int position = holder.getAdapterPosition(); noteList.remove(position); adapter.notifyItemRemoved(position); // 通知后面的项位置变了，否则点击事件会错位 adapter.notifyItemRangeChanged(position, noteList.size() - position);

notifyItemInserted和notifyItemRemoved会触发局部刷新动画，比全局刷新体验好很多。但要注意删除后必须调notifyItemRangeChanged，否则被删除项后面的 ViewHolder 位置没有更新，点击时会拿到错误的 position，这是 RecyclerView 最经典的坑之一。

4. 备忘录源码避坑：五个真实翻车现场

4.1 现象：旋转屏幕后输入框内容全没了

原因：Activity 在屏幕旋转时会销毁重建，如果没有在onSaveInstanceState里保存状态，输入框里的内容会丢失。备忘录的编辑页尤其容易踩这个坑，用户写了半天一旋转全白写。

解决：在EditActivity里重写onSaveInstanceState，把标题和内容存进 Bundle，在onCreate里判断 Bundle 是否为空再恢复。或者更简单粗暴地在 Manifest 里给 EditActivity 加android:configChanges="orientation|screenSize"，让 Activity 不重建。两种方式各有取舍，前者更规范，后者更省事但要注意手动处理布局变化。

4.2 现象：数据库查询在主线程执行，列表滑动卡顿

原因：SQLite 查询是 IO 操作，放在主线程会阻塞 UI。数据量小的时候感觉不出来，条目超过几百条之后滑动明显掉帧。

解决：把查询放到子线程，用 Handler 或者 ExecutorService 回到主线程更新 UI。如果项目里已经引入了 Kotlin 协程，用withContext(Dispatchers.IO)包住查询逻辑是最简洁的写法。注意数据库 helper 要保持单例，多线程下反复创建 helper 会导致连接泄漏。

4.3 现象：删除后列表位置错乱，点 A 删掉了 B

原因：Adapter 里的 position 在数据变化后没有同步更新，getAdapterPosition拿到的是旧位置。

解决：在点击事件里用holder.getAdapterPosition()而不是构造时传入的 position，并且在删除后调用notifyItemRangeChanged。如果用了notifyDataSetChanged，要确保数据源已经先更新再通知，顺序反了也会错位。

4.4 现象：空标题的备忘也能保存，列表里显示一片空白

原因：保存前没有做输入校验，EditText的getText().toString()拿到空字符串直接入库了。

解决：在保存按钮的点击事件里先判断标题是否为空，为空时用Toast提示并 return。更严谨的做法是在 DAO 层也做一次校验，因为 UI 层可能有多处入口。数据库层面NOT NULL只能挡住 null，挡不住空字符串，所以业务层的 trim 判断不能省。

4.5 现象：升级数据库版本后，老用户打开 App 直接闪退

原因：onUpgrade里写的迁移语句有语法错误，或者漏了某个版本的迁移分支，导致数据库结构和新代码不匹配。

解决：升级前先用adb把老版本的数据库文件拉出来，在本地用 SQLite 工具验证迁移语句。迁移逻辑要写成链式的，每个版本一个 if 分支，从 oldVersion 一路升到 newVersion。测试时至少覆盖「全新安装」和「从上一个版本升级」两条路径，有条件的话把前几个版本都测一遍。

5. 在源码基础上加一个搜索功能：完整实现与验证

搜索是备忘录最实用的进阶功能，也是检验你有没有真正理解 DAO 层和列表刷新的好练习。下面是从数据库到界面的完整实现路径。

先在 DAO 层加一个带条件的查询方法：

public List<Note> search(String keyword) { List<Note> list = new ArrayList<>(); // 用 LIKE 做模糊匹配，前后加 % 表示包含即可 String selection = NoteDbHelper.COLUMN_TITLE + " LIKE ? OR " + NoteDbHelper.COLUMN_CONTENT + " LIKE ?"; String[] args = new String[]{"%" + keyword + "%", "%" + keyword + "%"}; Cursor cursor = db.query(NoteDbHelper.TABLE_NAME, null, selection, args, null, null, NoteDbHelper.COLUMN_TIME + " DESC"); while (cursor.moveToNext()) { // 解析逻辑和 queryAll 一致，可以抽成一个公共方法 list.add(parseNote(cursor)); } cursor.close(); return list; }

然后在 Activity 里给搜索框加文本变化监听，每次输入变化时重新查询并刷新列表：

searchEditText.addTextChangedListener(new TextWatcher() { @Override public void beforeTextChanged(CharSequence s, int start, int count, int after) {} @Override public void onTextChanged(CharSequence s, int start, int before, int count) { String keyword = s.toString().trim(); List<Note> result; if (keyword.isEmpty()) { result = noteDao.queryAll(); // 空关键词恢复全量列表 } else { result = noteDao.search(keyword); } noteList.clear(); noteList.addAll(result); adapter.notifyDataSetChanged(); } @Override public void afterTextChanged(Editable s) {} });

这段代码有两个参数需要你根据实际情况调整。一是LIKE的匹配范围，上面是标题和内容都匹配，如果你只想搜标题，把OR后面那半段去掉即可。二是查询频率，onTextChanged每输入一个字符就查一次库，输入快的时候会有多次无效查询。优化方式是用 Handler 做 300 毫秒的防抖，或者用postDelayed延迟执行，新字符进来时先取消上一次的延迟任务。

验证搜索功能是否正常，按这个顺序测：输入一个存在的关键词，看列表是否只剩匹配项；清空关键词，看是否恢复全部；输入一个不存在的关键词，看列表是否为空且不崩溃；输入%或_这类 SQL 通配符，看是否被当成普通字符处理。最后一条尤其重要，因为LIKE语句里的%和_有特殊含义，如果用户输入了这些字符，查询结果会不符合预期。要彻底解决这个问题，需要在拼接参数时对%和_做转义，或者改用ESCAPE子句指定转义符。

我自己改这类源码的习惯是：先把数据库层单独抽出来写一个测试类，用纯 Java 跑一遍增删改查，确认数据层没问题了再去调界面。这样出问题的时候能快速定位是数据错了还是 UI 刷新错了，不用在 Activity 和 Adapter 之间来回猜。备忘录这种小项目，数据层稳了，界面就是水到渠成的事。希望帮到你。

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