引子：我走了一条"反"的路

翻遍应用商店里的读书类 App，再看开发者社区里的同类文章，注意力几乎都压在同一个地方：阅读器。字体要不要衬线、主题要不要羊皮纸、翻页是仿真还是滑动、夜间模式护不护眼——大家都在打磨"打开书的那几十分钟"。

我做「静读」的时候，一开始也在这条路上。做到第三周我停下来问自己一个问题：用户合上书之后，这个 App 还为他做了什么？

答案是：几乎什么都没有。进度条躺在那里，书签散落在各章，读了多久、读了哪一类、坚持了几天，全要靠用户自己回忆。于是我做了一个反向的决定——把开发重心从"读"挪到"读完之后"。阅读器当然要做好，但它只是"生产数据"的车间；真正让用户第二天还想打开的，是合上书之后那层"记忆与成长"。

这篇文章就是这次反向选择的记录。我用 5 张界面截图，把「静读」拆成一条"阅读记忆"流水线，顺便聊聊这套设计落到 HarmonyOS / ArkUI 上时，它对我提了什么要求、又给了我什么启发。

一、录入：把门槛降到"只填一个书名"

书架会不会荒废，取决于第一本书放进去有多难。

我见过太多读书 App 的添加流程：书名、作者、ISBN、出版社、封面、简介……填到第三项用户就放弃了。所以「静读」的添加弹窗只做一件事：让你最快开始读。书名必填，作者可留空，章节数给一个默认值 8，分类从 8 个方向里点一个（认知 / 心理 / 商业 / 传记 / 文学 / 历史 / 哲学 / 技能），再选放进"在读 / 想读"哪个书架，完事。

关键在那句提示文案：“填好书名即可开始。阅读时按章节自动生成可划线的内容。”——它提前告诉用户：你不需要现在把书录完整，结构是读的时候长出来的。把"录入成本"从一次性前置，摊薄到整个阅读过程里，是这个小弹窗最重要的设计。

二、管理：筛选负责"找得到"，推荐负责"想得起"

书库页我分成上下两半，各解决一个问题。

上半部分是管理：搜索框按书名或作者过滤，分类下拉做二级收敛，状态页签（全部 / 在读 / 读完 / 想读）做三级收敛。三层筛选叠起来，书架哪怕堆到几十本，也能几秒内定位到"那本读到一半的心理书"。每本书的卡片上不放假大空的简介，只放三个真正有用的数字：几条书签、读了多久、读到第几章——这是"管理"视角需要的信息密度。

下半部分是发现：“值得一读"只推带完整章节结构的书，每条给一个"查找"按钮。它和管理区是两套逻辑：管理是"在我有的里面找”，发现是"在我没有的里面想"。把两者放在同一屏但明确分区，用户不会把"推荐"误当成"我的书"，也不会忘了自己还有一份想读清单。

三、回到现场：首页第一屏只回答一个问题

首页（书房）我砍掉了所有"运营位"，第一屏只回答一个问题：“我上次读到哪了？”

继续阅读卡片把答案摊开：《软件工程》，佚名 · 认知 · 共 8 章，已读到第 1 章 · 全书 0% · 已记录 0 条书签。两个按钮：继续阅读（直接跳回上次的章节位置）、章节与书签（跳去目录和本书书签）。没有推荐、没有广告、没有"猜你喜欢"——因为对一个读书 App 来说，打断"回到上次阅读"的任何元素都是噪音。

卡片下方才是统计：连续阅读几天、今日读了几分钟。我把它们放在第二屏的入口位置，作为"回到现场"之后顺手能看到的反馈，而不是第一屏的主角。主角永远是"继续读"。

四、沉淀：用空态"逼"出第一条书签

书签是「静读」记忆里最细的颗粒：划线、想法、疑问、行动，四种类型，按时间倒序排成时间线。

但新功能最大的敌人是"没人用第一次"。所以我在时间线的空态上花了比功能本身更多的心思。空态不是冷冰冰的"暂无数据"，而是一句教学加一个动作："阅读时选中正文，就能把打动你的句子留在这里。“下面跟一个按钮"去读第一章”——把用户从"看空态"直接推进"产生第一条书签"的场景里。

统计区同理：连续阅读、今日阅读、书签记录、在读/读完四张卡片，哪怕全是 0，也先把"这个 App 会记录什么"展示给用户看。空态不是失败状态，是产品说明书。

五、回收：让坚持变成看得见的曲线

成长页是整条流水线的终点，也是"合上书之后"价值的集中兑现。

近七日阅读时长做成柱状图，横轴是星期，右上角给合计；它不追求好看，追求"诚实"——读了几分钟就是几分钟，不放大不修饰。下方"下一个里程碑"把抽象的坚持拆成可完成的小目标：连续阅读 3 天，已完成 0%，还差 3 天，配一条进度条。再往下是常读方向（你读得最多的分类）和投入最多的书。

这一页的设计原则是：只展示用户自己行为的结果，不做横向比较。没有"你超过了 80% 的用户"，因为没有服务器、没有别人，只有你和你的书。成长曲线一旦掺了攀比，就会从"激励"变成"焦虑"。

六、落到 HarmonyOS：这套设计对 ArkUI 提的要求，和它给我的启发

把上面这套"单一记忆层"的设计落到 HarmonyOS 上，ArkUI 的声明式范式几乎是为我量身定做的，同时也逼着我改了几个旧习惯。

1. 状态只能有一份，UI 是它的投影。 阅读进度、书签、时长、打卡，本质是同一份"阅读记忆"状态图。书房首页的进度、书库卡片的书签数、成长页的时长，都是这份状态的不同投影。ArkUI 的 @State / @Provide + @Consume / AppStorage 让我把这份状态集中建模：任何一页改了进度，其余页自动刷新，不需要手写"通知—刷新"的胶水代码。这是声明式 UI 给我最大的解放。

2. 存储要分层，别全塞一个库。 设置项、连续打卡日期这类轻量键值，用 Preferences 足够；书签、章节进度、书籍元信息这种结构化、要查询要排序的数据，用关系型数据库（relationalStore）更稳。一开始我想图省事全放 Preferences，结果书签一多，"按时间倒序取前 N 条"就得把全量读进内存自己排——分层之后这类查询交给数据库，干净很多。

3. 时长结算要挂在生命周期上，而且必须诚实。 阅读时长我在离开阅读页时结算（onPageHide / aboutToDisappear），但切后台、锁屏必须暂停计时，否则时长会虚高，成长页的"诚实"就破产了。把计时器和页面生命周期、应用前后台状态绑定，是这套统计能立住的前提。

4. 鸿蒙的系统能力是"合上书之后"的天然放大器。 沉浸光感与深色模式让夜间阅读更沉浸；折叠屏上书库与阅读可以做 SplitView 双栏；而我最想做的，是把"连续阅读天数"做成一张元服务服务卡片放到桌面——让"合上书之后"的价值不止留在 App 里，而是出现在用户每次点亮屏幕的瞬间。这是 HarmonyOS 区别于普通移动平台、让我最兴奋的地方。

七、踩坑与反思（诚实版）

• 空态文案比功能重要。 书签时间线第一版空态只写了"暂无书签"，测试时没人知道能划线；改成教学文案加"去读第一章"按钮后，第一次划线的转化明显不一样。空态是产品说明书，不是占位符。
• "连续打卡"是双刃剑。 连续阅读天数能激励人，也能在断了一天之后让人索性放弃。我在文案上刻意弱化"断签"的惩罚感——断了一天只说"今天还没开始"，不说"你断签了"——把打卡做成鼓励而非枷锁。
• 分类不是越多越好。 分类第一版列了十几个，结果用户添加书时在分类上停留最久、甚至乱选；收敛到 8 个高频方向后，录入顺畅了很多。选项越多，决策成本越高。
• 进度与书签要讲事务性。 出现过"划了线但进度没保存"的不一致：书签写进了库，进度却因为退出时机没落盘。后来把"保存进度"和"写入书签"归到同一次落盘时机统一处理，才消除这类脏状态。

结语

做「静读」给我最大的心得，不是某个 ArkTS 语法或某个组件怎么用，而是一个产品判断：读书 App 的护城河不在阅读器里，而在合上书之后。 阅读器决定用户愿不愿意打开这本书，而记忆与成长层决定用户愿不愿意明天再打开这个 App。

五个界面，一条流水线：录入一本书、管理一个书架、回到一个现场、沉淀一条书签、回收一段成长。HarmonyOS 的声明式 UI 和系统级能力，让这条流水线从"想法"变成"手感"的过程比想象中顺。如果你也在做工具类应用，不妨问问自己同一个问题——

用户离开你的 App 之后，你还为他留着什么？

下一篇：《一个状态，五个投影：我把读书 App 的"阅读记忆"建成了一张状态图》——记忆层的工程面：五个界面其实是同一份状态，以及我能删掉多少胶水代码。

---

#鸿蒙 #HarmonyOS #ArkUI #读书App #开发心得