有可能不编译pinyin功能来避免引动端的包体增长过大么

[Hoikiiz]

咨询一下，移动端对包大小普遍比较敏感，有可能在编译的时候不引入拼音库或者通过接入注入拼音库嘛

[wangfenjin]

你不想要拼音功能吗？但是这个包主要解决的就是拼音功能

[wangfenjin]

可以考虑动态下发编译好的文件？不把这个库打包到发版的包里面去 https://juejin.cn/post/6897095308157648910

[Hoikiiz]

可以考虑动态下发编译好的文件？不把这个库打包到发版的包里面去 https://juejin.cn/post/6897095308157648910

嗯，不过iOS端似乎没有什么比较好的处理方案，android确实可以通过插件的方式来规避拼音和sqlite带来的包体压力

[calvin2021y]

是否可以binary assets的方式加载 pinyin模块？

这样的话可以从网页下载，macOS/ ios的 fat binary， 以及安卓同时支持多个架构的apk体积都会减小。

[wangfenjin]

可以具体说说方案吗？或者提PR

[calvin2021y]

在我的测试中：

pinyin.txt.cpp (这个文件 4.2M )，  pinyin.txt.cpp.o ( 604K ), ./contrib/pinyin.txt (601K)

pinyin.txt.cpp.o 仅仅包含了完整txt版本 ./contrib/pinyin.txt 文件。

可以写一个工具， 把 ./contrib/pinyin.txt 转换为 binary文件，不能保存在动态库。

修改PinYin::build_pinyin_map, 接受 一个二进制数组来初始化map。

二进制数组可以使用定长的Unicode格式，或者其他可以压缩体积的格式。

二进制数组由用户自己加载。

[wangfenjin]

个人看法，

• 改 pinyin.txt 的格式会让代码更复杂，甚至需要引入其他依赖，效果不一定好
• 把 pinyin.txt 这样打包进去是为了让大家使用上更方便，不用像 jieba 那样除了依赖一个 so 文件，还要 copy dict 目录，因为让用户自己设置目录就会有一些人会做错，导致使用的成本变高

如果你觉得你的方案可行，可以提 PR，如果没问题的话我会考虑合入