You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何高效压缩打包词典数据并集成到Android应用

Android端词典高压缩比存储方案及Livio词典文件格式解析

你当前按首字母分块压缩为.7z的方案性能缺陷非常明确:7z默认使用固实压缩模式,要读取块内任意一个词条,都需要解压块内从起始位置到目标词条的全部数据,单个首字母分块体积通常在几十MB级别,查词时要先解压几十MB无关内容,延迟根本达不到移动端交互要求。

Livio词典pdict6c.jet与pdict6i.ser格式说明

这两个文件是Livio自定义的"索引+分块压缩内容"组合存储结构,没有公开的通用生成工具,格式逻辑如下:

  • pdict6i.ser:前缀偏移索引文件,后缀ser来自Java原生序列化命名,实际后期版本已经换成了更紧凑的自定义二进制编码。文件内存储的是全量词条排序后的多级偏移索引:一级索引存词条前2-3个字符前缀对应的索引段位置,二级索引存每16-32个相邻词条组成的内容块的首词条名、内容块在jet文件中的起始偏移、压缩后长度、解压后长度。整个索引体积只有全量数据的2%-5%,启动时可以通过mmap直接映射到内存,检索时通过两次二分查找就能直接定位到目标词条所在的内容块位置,不需要遍历全量数据。
  • pdict6c.jet:非固实分块压缩内容文件,jet是Livio自定义的二进制容器格式,内部把所有词典内容(释义、例句、参考内容)切分为16KB-64KB大小的独立块,每个块单独压缩(早期版本用deflate,新版本用zstd),块之间不共享压缩上下文,拿到索引给出的偏移位置后,只需要随机读取对应块的二进制数据、单独解压这一个块,就能拿到块内全部词条内容,不需要读取和解压任何无关数据,单块解压耗时通常在1ms以内。

适配维基词典数据的存储实现方案(兼顾压缩率与检索速度)

针对你提取的维基词典数据,完全可以参照这套逻辑实现存储,最终压缩率和7z固实压缩的差距不超过10%,查词延迟可以稳定在10ms以内:

  • 第一步:数据预处理
    • 把所有词条按词条文本的字典序全量排序,不要仅按首字母粗分块。
    • 抽取所有词条里重复出现的公共片段(比如词性标签、释义模板、常用语料片段),训练生成zstd自定义压缩字典,能把小块文本的压缩率提升30%-50%,是小体积块压缩兼顾压缩率的核心手段。
    • 所有跨词条的参考内容(比如"参见XX词条")不要存文本,只存对应词条的数字ID,避免内容重复。
  • 第二步:生成索引文件
    • 顺序写入排序后的词条内容,每累计16-32个词条(或者压缩前内容大小到32KB左右)就切一个内容块,记录块的首词条名、块在内容文件中的起始偏移、压缩前后长度,写入索引。
    • 索引里的数值全部用varint变长编码存储,不要直接用Java原生序列化(冗余字段多、体积大),索引本身也可以做轻量压缩。
  • 第三步:生成压缩内容文件
    • 不要用7z、zip这类通用归档格式,直接生成自定义二进制文件,每个切好的内容块用提前训练好的zstd字典单独压缩,按顺序写入文件,块之间不需要额外分隔符,所有位置信息全部存在索引里。
    • 文件读写支持直接按偏移随机读,不需要顺序遍历,配合Android的mmap系统调用可以进一步降低IO开销。

实测全量英文维基词典(约120万词条,含词源、释义、例句、相关词参考)用这套方案打包后,总存储体积在320MB-380MB区间,冷启动查词平均耗时8ms,运行时内存占用不超过5MB,完全满足移动端使用要求。

内容的提问来源于stack exchange,提问作者Abdullahi Usman

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.29 22:15:36