把一位重度用户的 315 本书倒进来，然后随机抽十本

测试机是一台 vivo 折叠屏，存储里灌的是一份真实手机的存储快照（91 个文件、570MB）， 加上设备既有的历史素材，智能扫描一共扫出 315 本网文 txt—— QQ 浏览器下载目录里的、其它阅读器私有文件夹里的、藏在以点开头的隐藏目录里的，编码五花八门， 最大的一本 30MB。这正是我们想要的测试环境：不是实验室里造出来的干净数据， 是书虫手机里真实的存书结构原样。

测法很简单：智能扫描，全选，导入，然后随机抽十本进去读。下面是两台真机的账本。

数字

几个数字的口径说明。「批量入库约 8 秒」是 315 本（合计约 1GB）从确认导入到全部上架的时间—— 导入走「先登记后转换」策略，书以待转换状态先进书架，第一次打开时才做全文解析， 所以入库快不等于偷工减料，代价摊到了每本书的首开上（3 到 7 秒；之后打开跳过转换走索引，快得多）。 卡顿率用的是 Android 系统自带的帧渲染统计，不是我们自己的埋点自报。

测试测出来的一个真隐患

这轮实测的最大收获不是好看的数字，是一个数据安全 bug。批量导入时， 从系统文件选择器拿到的书会先拷贝一份暂存；旧实现把这份暂存放在了系统缓存目录， 而「待转换」的书会长期指向它。问题来了：系统缓存目录是操作系统随时可以清理的—— 意味着你导入了 315 本书，还没来得及打开的那些，可能在某次系统清理后永久损坏。

修复是把暂存搬到持久目录，转换成功后立刻回收拷贝，导入收尾时清扫孤儿文件。 修完在两台真机上都复验了一轮。写出来是想说明一件事：性能实测的价值不只在跑分， 在于逼着功能走一遍真实规模的完整链路——315 本 1GB 的书堆出来的场景， 单元测试里造不出来。

为什么盯着「导入」这么较劲

因为搬家成本是换阅读器的第一道墙。书虫的存量不在云端，在手机的各个犄角旮旯里， 谁让搬家这一步顺畅，谁才有资格谈后面的体验。我们的取舍是：扫描要全（隐藏目录也要扫到）、 入库要快（三百本量级约 8 秒给完反馈）、解析可以懒（摊到首开），错误要兜（编码识别失败自动回退重试）。

书进来之后的事，是另外几篇的主题了：划词让 AI 续写并保留成分支、 通勤路上用 TTS 听完整章， 或者干脆把书切进剧场模式当游戏玩。 入口都在同一个书架上。