PurePlayer 高性能读镜像实测：50 万首曲库深翻页进入 1 秒内

在曲库规模达到数十万首时，常规列表的首屏滚动通常保持流畅，但深层分页、首字母跳转与全局检索容易产生较高的查询延时。针对大曲库的高频检索场景，我们在包含 500,500 首曲目的基准测试库上对核心读路径进行了完整耗时采样，并在 7.0 规划中引入本地只读镜像机制以加速查询。

版本说明：6.0 版本已包含基础性能优化；本文介绍的高性能读镜像面向 7.0 版本规划，目前处于内部测试阶段。文中所有测试指标均采集自内部构建环境。

该方案在本地构建一份基于 SQLite 的曲库只读派生副本。建库阶段会预先计算排序键、过滤属性与 A-Z 索引锚点并持久化至磁盘。系统主存储保持原始数据权威，只读镜像仅响应高频检索请求，支持按需独立重建与清理。

性能实测数据

测试环境为 M4 Mac mini 与 500,500 首测试数据集，各项指标均已通过逐字段一致性校验：

在 50 万曲目规模下，原生路径依赖全表扫描，深层分页开销随偏移量显著增长：在第 40 万首偏移位置拉取单页数据，基线耗时约为 1668 秒。只读镜像将同一深度的分页耗时降低至 0.8 至 1.4 秒，不同偏移深度的查询耗时保持在稳定区间。

排序标签与视图兼容

针对古典与爵士等音乐分类，用户常启用排序标签（Sort Tags）将 “The Beatles” 归入字母 B（按 “Beatles, The” 排序）。镜像为支持标签的五个字段分别物化两套独立的排序键，切换排序标签时直接在查询语句中选择对应列，无需重新生成索引，字母导航条也会同步联动。

专辑、艺人与作曲人聚合视图同样接入了镜像查询。若在聚合视图中激活排序标签，查询会自动切换至系统主存储路径，以确保实体层标签值准确映射。写侧聚合表已列入后续演进计划，届时将补齐聚合视图在标签状态下的镜像支持。

资源占用与权衡

启用本地只读镜像需要平衡索引构建耗时与本地存储开销：

• 构建耗时：全量构建在后台任务中完成。50 万首曲库初次构建实测约为 32 分钟，期间应用通过标准模式继续响应浏览；5 万首曲库构建耗时约 35 秒。
• 磁盘空间：50 万首曲库的镜像文件约占用 2.1GB 存储空间。设置页面会展示精确的磁盘占用；关闭该模式时保留索引文件便于再次开启，同时也提供完整清理选项。
• 写入延时：修改曲目元数据时会同步更新镜像，实测单次批量提交增加约 20 毫秒开销。

基于上述资源特性，该能力默认保持关闭，用户可在设置中根据曲库体量自主开启。

核心优化机制

• 轻量值映射：原生路径在读取记录时会实例化完整的上下文托管对象；镜像直接读取 SQLite 数据行并映射为轻量值类型，降低了对象生命周期管理的内存与 CPU 负载。
• 查询谓词下推：过滤条件、排序逻辑与去重操作均下推至 SQLite 引擎执行，利用数据库内核在内存加载前完成数据裁剪。
• 排序与索引键预计算：规范化的排序键与 A-Z 索引字母在入库时已完成计算与持久化。检索阶段结合键集分页（Keyset Pagination）与索引扫描直接定位数据区间，使深层分页保持稳定的查询速度。

数据一致性与实现细节

为确保镜像与系统主存储的查询结果完全一致，验证套件覆盖了 19 个排序列、升降序、排序标签状态与各类复合过滤条件的排列组合。在实际对齐过程中，有若干边界细节需要特别处理：

• 空值回退与空白字符串：排序标签逻辑遵循“优先使用标签，缺失时回退至显示名”。Swift 的空合并运算符仅针对 nil 回退，而 SQL 函数对于空白字符串的判定存在差异。为保证行为严格一致，镜像将标签键与显示名键分别物化为独立列，在查询生成时显式指定目标列。
• 特定字段的排序兼容性：历史曲库中的时长字段沿用字符串字典序比对（例如 “120.0” 排在 “90.0” 之前）。为保持既有表现，文本形态的字段单独物化对应的文本排序键，纯数值字段配置数值索引。
• 空白字符集合对齐：Swift 的字符集（包含全角空格、制表符与换行符）与标准 SQL 去除空格函数的覆盖范围略有不同。我们在写入侧增设了状态标识列，统一两端的判空标准。
• 大数据量构建的分片机制：在 50 万首曲目全量构建时，全文搜索触发器对每行执行多索引写入，耗时约为 32 分钟。构建流程被设计为分片执行并支持断点续跑，确保后台任务平稳推进。
• 并发写入仲裁：在索引重建期间发生元数据编辑时，各写入记录均附带单调递增的版本序号，通过数据库冲突处理子句实现更新版本判定，确保写入结果的正确性。

测试环境各项采样基于 Debug 构建完成，详细测试日志与复现脚本已随工程归档。