实操手记Android Studio 成品项目“记单词背单词系统”从设计到跑通做背单词类 APP 是个很经典也很有代表性的选题适合用来完整练手 Android 开发的整个链条界面搭建、本地数据库设计、多媒体播放、算法逻辑再到打包优化。这篇就来拆一个真实跑通的“Android Studio 成品项目——记单词背单词系统”从需求拆分到核心代码实现再讲一遍排坑经验。这套系统说白了就是三个模块词库管理、学习计划、复习调度。听上去不复杂但真正串起来的时候很多细节会被忽略——比如单词发音包放哪里、进度怎么持久化、复习算法怎么定优先级、列表滑动卡顿怎么优化。这篇会把关键环节逐个拆开讲适合刚学完 Android 基础、想找一个完整项目来对照练习的同学也适合想快速搭一个背单词 Demo 去参加实训或毕设的人。内容以常见实践和通用技术方案为主不绑定特定环境你完全可以在 Android Studio 里照着重做一遍。1. 项目整体设计与思路拆解1.1 定清边界什么才算“成品项目”做这种项目最忌讳上来就写代码。先把边界画清楚不然写一半就会失控。所谓“成品项目”在我理解里有几个硬指标能正常安装运行不闪退、不丢数据核心链路闭环选词库 → 进入学习 → 完成打卡 → 次日复习数据持久化杀掉 APP 重进学习进度还在界面不要求多漂亮但层级清晰、关键操作不超过两个点击代码结构至少分清楚 UI 层、数据层、逻辑层。在这个背单词系统里我把它拆成下面几个逻辑模块模块主要职责技术选型词库模块内置基础词库支持自定义导入SQLite Asset 拷贝学习模块单词卡片展示、发音、释义RecyclerView MediaPlayer复习模块根据遗忘曲线调度单词复习自研优先级队列算法记录模块学习进度、收藏、错题本SQLite 多表关联设置模块每日目标、提醒开关、发音开关SharedPreferences拆完之后再看每个模块的职责就单一了。词库只管数据来源学习模块只负责展示和交互复习模块算权重记录模块存状态。这样后续改成 Room、加网络同步、换新界面都不会推倒重来。1.2 技术选型背后的“为什么”在选型上有人一上来就上 Room ViewModel Flow有人坚持原生 SQLite Handler。这个项目我选了 SQLite RecyclerView SharedPreferences 的组合核心原因是学习链路短、数据量可控、重点在业务逻辑的完整闭环。SQLite 在这里比 Room 更合适的一个理由很实际背单词的业务需要频繁拼接 SQL 来做自定义查询比如“查出生词表里、今天还没学、且按记忆阶段排序的 20 个单词”用原生 SQL 写起来更直接排查逻辑也直观。Room 固然规范但中间多了一层 DAO 的抽象对刚好处于进阶阶段的同学来说先穿透一层用原生 SQLite 把表结构玩明白收益更大。MediaPlayer 选择它而不是 SoundPool是因为单词发音需要支持暂停、重新播放、连续多个插入队列等操作。MediaPlayer 的状态机制虽然烦但可控性高。后来实测在低端机上连续播放 50 个单词也没有明显卡顿这个选型是稳的。1.3 数据流走向一个完整的学习闭环整个系统最核心的数据流是这样的启动时从 Asset 里的词库 JSON 初始化 SQLite → 用户选择词库 → 读取“未掌握”单词生成今日学习队列 → 用户逐卡片学习点击“认识”“模糊”“不认识”分别落入阶段值 3、1、0 → 当日学习结束后提交学习记录 → 次日启动时复习模块根据阶段值和时间差计算复习优先级生成复习列表。这串流程实现下来你会发现真正的难点不是界面也不是播放而是状态值的流转。一个单词从“新词”到“已掌握”中间要经历多次复习每次复习结果不同学到的“熟练度”就不同。这块做好了整个系统的核心价值就有了也是区别于普通“查单词工具 APP”的关键。2. 数据层设计词库表结构与会话记录2.1 单词表的字段到底怎么定我最后落地的单词表结构长得像这样CREATE TABLE word_table ( id INTEGER PRIMARY KEY AUTOINCREMENT, word TEXT NOT NULL UNIQUE, phonetic TEXT, meaning TEXT, mp3_fname TEXT, familiar INTEGER DEFAULT 0, -- 熟练度: 0-5 last_study_time INTEGER DEFAULT 0, -- 上次学习时间戳 study_count INTEGER DEFAULT 0, -- 学习次数 familiar_count INTEGER DEFAULT 0, -- 标记“认识”的次数 is_favorite INTEGER DEFAULT 0, book_id INTEGER DEFAULT 1 );几个容易被忽略的字段需要解释一下familiar不是简单的“记住没记住”布尔值而是 0-5 的阶段值。每次学习会按结果增减阶段值同时参与复习优先级计算。last_study_time用System.currentTimeMillis()存的毫秒值这样后续做“是否到期复习”时才好做差值计算。别用DATE字符串存做区间查询效率差也容易有时区问题。mp3_fname存的是 assets/audio 目录下的相对文件名不是完整路径。发行时音视频资源要放 asset 里动态取不能直接依赖绝对路径。book_id这个字段很重要。如果你只有单词表用户切换“四级核心”“考研词汇”时只能清空重来。加上它之后每个词库都是独立的数据域进度也不会混。我开始漏了这个字段后来加词库功能时被迫做了整表迁移教训深刻。2.2 会话记录表为什么要单独存日志进度存在单词表里就够了但“每日复盘”需要知道“我今天学了 30 个单词其中 22 个是重现过的”。这就要单独的会话记录表CREATE TABLE study_session ( id INTEGER PRIMARY KEY AUTOINCREMENT, date TEXT NOT NULL, new_count INTEGER DEFAULT 0, review_count INTEGER DEFAULT 0, mastered_count INTEGER DEFAULT 0, duration_ms INTEGER DEFAULT 0 );这张表的作用除了在首页展示学习统计外更重要的是帮你计算“今天应该安排多少新词”。很多背单词 APP 会限制“每日新学上限”以免用户两天冲完整个词库然后弃用。实现方式就是开场时查今天会话记录里的new_count如果超过上限就先把入口引导到复习队列。用date TEXT存yyyy-MM-dd格式而不是简单用时间戳是因为统计维度是按自然日字符串格式虽然存储大一点但语义清晰索引也够用。2.3 数据库升级怎么防丢数据Android 里 SQLite 升级是个常见翻车点。我第一版直接在onUpgrade里执行DROP TABLE IF EXISTS结果一次改结构就清空了所有进度后来养成了“每个版本做增量迁移”的习惯Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(ALTER TABLE word_table ADD COLUMN book_id INTEGER DEFAULT 1); } if (oldVersion 3) { db.execSQL(ALTER TABLE word_table ADD COLUMN is_favorite INTEGER DEFAULT 0); } }提示正式发布前一定要留一台“旧版本数据机器”实测迁移路径。脚本迁移和你本地新建库跑的结果经常不一样缺索引、缺默认值都是这种时候发现的。3. 核心功能实现记忆算法与复习队列3.1 简单但有效的五阶段记忆模型背单词系统的算法部分不需要上什么人工智能模型。真正可落地、效果又接近商业产品的是五阶段记忆模型新词、学习期(阶段0-1)、成长期(阶段2-3)、巩固期(阶段4)、掌握(阶段5)。每个阶段对应不同的复习间隔我用一个REVIEW_INTERVALS数组来维护private static final int[] INTERVALS_DAY {0, 1, 2, 4, 7, 15};含义很简单阶段 0 的词当天学完再背一遍阶段 1 的词隔 1 天复习阶段 2 隔 2 天以此类推。用户在背单词过程中选“认识”或“模糊”会推动阶段值增/减。具体规则是选“认识”且是第一次学阶段 0 → 1选“模糊”阶段值退回 0 或 1具体看当前值防止半生不熟直接跳到巩固期选“不认识”阶段值归 0同时加入错题本连续两次以上在巩固期选“认识”阶段 1直到 5 封顶。这个方案的好处是运算量极小数据库里只是一次UPDATE操作完全不需要后台计算断网也能跑。3.2 复习队列的排序逻辑优先级 紧迫度 乱序因子光有间隔还不够“今天该复习哪些词”要有一个稳定的排序规则。我用了非常直觉的公式priority (now - last_study_time) / 86400000.0 - INTERVALS_DAY[familiar]这个值越大说明该词超出计划复习时间越久就越应该排在前面。每次进入复习页面前我按这个公式计算优先级再取前 N 个生成列表。但直接用这个顺序会有个问题如果前 10 个词的优先级差异都很大那用户每次复习看到的都是同一批最难、最卡的词体验很压抑。所以实际实现里我会在优先级排序后的结果上做一次同优先级内的随机洗牌Collections.shuffle(prioritySubList);这样既保证科学复习的紧迫度优先又让每次展示有一定新鲜感用户不会形成“看到第一个词就知道后面都是难的”的抵触心理。3.3 学习会话的生成流程学习会话的生成链路一句话概括就是先取到期复习词再取一部分新词补位最后合并成一张卡片流。ListWordEntity reviewWords queryByFamiliarAndDueTime(); ListWordEntity newWords queryNewWords(limit - reviewWords.size());这里有个细节limit是用户设定的“每日学习目标”复习词不够时用新词补。这样保证用户每天刷的单词量是稳定的同时对新词的节奏有控制。当复习词量超过limit时则只进复习队列当天不再加入新词。这个逻辑放在生成队列的入口处界面层不需要关心后续加入“加量包”功能也很方便。3.4 MediaPlayer 播放发音的坑与正确姿势发音播放是个小功能但如果不注意状态流转很容易出现“按完没声音”或“App 突然静音了”的诡异现象。最核心的要点每次播放前先 reset播放完后不要立刻 release。private void playWord(String fname) { try { if (mediaPlayer null) { mediaPlayer new MediaPlayer(); } mediaPlayer.reset(); AssetFileDescriptor afd getAssets().openFd(audio/ fname); mediaPlayer.setDataSource(afd.getFileDescriptor(), afd.getStartOffset(), afd.getLength()); afd.close(); mediaPlayer.prepare(); mediaPlayer.start(); } catch (IOException e) { Log.e(TAG, play error: fname, e); } }项目中我把音频文件按word.mp3命名放在 assets/audio 下播放时动态拼接路径。注意openFd拿到的AssetFileDescriptor用完后要 close否则连续播放几十个单词后会有大量文件句柄泄漏低内存机器上真会被系统杀掉。还有一点整页退出时要记得mediaPlayer.release()否则播放器驻留后台下次新建MediaPlayer实例时会重复占用音频焦点扬声器会短暂变成“和尚念经”一样叠音。建议放在 Activity 的onDestroy中统一处理。4. 实操过程从零搭起项目骨架与关键代码4.1 创建工程与模块划分Android Studio 里新建一个 Empty Activity 项目包名建议形如com.domain.wordbook然后用四个包来组织源码ui、data、logic、util。data包放数据库辅助类和实体类logic包放复习算法和队列生成逻辑ui包放 Activity 和 Adapterutil包放播放器和时间工具。这个分包方式比较贴近小团队习惯代码量大时不至于全堆在一起。如果你之前习惯一个包塞所有文件这个项目正好练一下分包思维。4.2 词库初始化从 Asset 复制到 SQLite内置词库如果用“APP 首次启动时一键 INSERT 两千行”体验会非常差。正确做法是把词库做成 SQLite 数据库文件放在 assets 目录首次启动时整体拷贝到应用私有目录之后再打开就直接 attach。public void initWordDbIfNeeded() { File dbFile context.getDatabasePath(wordbook.db); if (dbFile.exists()) { return; } try (InputStream is context.getAssets().open(wordbook.db)) { dbFile.getParentFile().mkdirs(); OutputStream os new FileOutputStream(dbFile); byte[] buffer new byte[8192]; int len; while ((len is.read(buffer)) ! -1) { os.write(buffer, 0, len); } os.flush(); os.close(); } catch (IOException e) { e.printStackTrace(); } }这个方案比启动时跑 SQL 快得多实测 5000 词的库在低端机上也只要不到 1 秒。如果想词库文件小一点可以在工程里把 list 导出造库而不是打包一份巨大的文本。4.3 首页学习流程的界面状态设计学习卡片页我用的是 ViewPager2 RecyclerView 的横向滑动方案。每一页对应一个单词卡片顶部显示词性、音标、释义中间大字号显示单词本体底部三个按钮“认识”“模糊”“不认识”。这里有个很实用的细节卡片左滑右滑只能翻页真正的选择必须点按钮避免用户误触导致误标记熟练度。三个按钮点击后立刻更新数据库再调用viewPager.nextItem()滑到下一个。刚开始做的时候我把“滑下一页”和“标记结果”绑定用 gesture 触发实测误判率极高后来切成按钮方案后测试反馈舒适度高非常多。状态设计方面“今日已完成 N 个”进度的底部进度条是从learning_progress这个内存变量算的每点一次按钮就 1。会话结束时统一往study_session表写一条记录不实时写减少数据库写频率。4.4 复习页的时间筛选复习页的逻辑入口是查询“到期”的单词我的筛选 SQL 按优先级公式写SELECT * FROM word_table WHERE familiar 0 AND last_study_time INTERVALS_DAY[familiar] * 86400000 ? ORDER BY ( ? - last_study_time ) / 86400000.0 - INTERVALS_DAY[familiar] DESC LIMIT 20;这里的?是currentTimeMillis()。SQLite 里没法直接引用 Java 数组所以INTERVALS_DAY[familiar]要先把间隔数组查出来拼进 SQL也可以把间隔算好后直接传参进语句。实战中我用的是更简单的方式把 0-5 各阶段对应的到期词分别查一次合并 List 后再在内存里排序。数据量不大时一两千行这种写法反而最直观、最好调试。5. 常见问题与排查技巧实录做这个项目过程中我遇到的坑比想象中多挑几个最典型的记录下来应该能帮你省不少时间。5.1 发音播放器反复初始化导致无声现象连续学习七八个单词后点发音没声音但 Log 里没有异常。原因MediaPlayer每播完一个单词就release()再下一次播放时重新new MediaPlayer()。此时系统音频焦点被上一个实例释放新实例还没获取焦点声音发不出来。解决把MediaPlayer声明为 Activity 级单例全局只初始化一次。播放完只reset()不release()退出页面时统一释放。改完这个问题后再也没出现过无声。5.2 列表滑动时偶发闪动现象单词列表滑动快了卡片背景色会闪现默认白底看起来像刷新没完成。原因ViewHolder 复用时没有重置根布局的选中状态。我的 item 根布局是 CardViewsetCardBackgroundColor只在部分 item 条件中调用导致复用 item 时旧背景色残留。解决在onBindViewHolder里无条件先重置背景色再按阶段值设置对应的颜色。颜色状态机集中到一个方法内杜绝这种“只有一部分 item 被设置”的逻辑漏洞。5.3 SQLite 查询在主线程导致 ANR现象词库 5000 词、首次首屏加载时偶发卡顿低端机直接弹“无响应”框。原因首屏加载需要关联查询word_table和study_session数据量大时耗时超过 100ms直接卡在主线程。解决首屏数据加载放进子线程完成后runOnUiThread回填数据库接口全部改成回调式不直接同步返回 List。这个改动也顺带让首页从冷启动到可用的时间缩短了不少高刷屏上体验差异明显。5.4 复习队列学完 10 个就重复现象复习列表长度为 20但用户学到第 10 个后列表尾部出现前面学过的词。原因学习过程中“模糊”按钮会把单词的阶段值回退而复习队列的排序计算是在进入复习页时生成的快照。如果学习动作修改了阶段值等进度条推进到末尾时末尾的单词已经变成了“新到期的”出现在列表中看起来像重复。解决复习队列在页面打开时生成一个不可变的QueueIdList学习过程中的状态变化只更新数据库和当前卡片的 UI不回写队列。整轮复习结束后再基于最新数据重新生成第二天的复习队列。这是“队列快照”思想也是很多实际项目里容易漏掉的点。5.5 APK 体积暴涨发音包太大词库 5000 词MP3 发音文件按平均 100KB 算光语音就 500MB。这个体积对 APK 完全不可接受。后来做了两个调整词库音频不放进 APK改为首次启动后从 App 内下载或提示用户去指定位置手动导入。这样 APK 保持在 30MB 以内内置词库只保留常用高频词发音其他词舁用系统在线 TTS。如果你做的是实训项目不想引入在线依赖建议把发音资源保持在校验过的 300-500 词规模以内后续再扩展为在线加载。这是我个人反复权衡后的建议保证体验演示完整又不把安装包撑爆。5.6 实测后的两个体会这个项目做下来最让我意外的不是算法也不是数据库而是用户反馈“看着列表复习”和“一张卡片复习”的效果差异。列表复习节奏快但没有“获取-回忆-确认”的记忆步骤留存效果弱很多。后来我在复习模块里强制切成单卡片模式并且遮住释义先回忆再点击显示才真正达到“复习”的目的。另外关于学习记录我建议在study_session中额外存finished_total字段。实战中发现很多用户学了两三天后会直接看“总学习天数”来给自己打鸡血有这个字段之后首页文案做起来非常顺手也让后续做连续打卡功能有了现成的数据源。如果你准备基于这套项目扩展我的建议优先级是先加每日提醒因为背单词类的应用最核心的留存手段就是固定提醒其次是词库导入导出让用户能自己灌入考试词书最后才是社交排行之类的外围功能。核心链路稳稳当当了加什么都不会乱。
