关于 Gboard 双拼支持、输入中出现词语和拼音被莫名分割 等问题的说明

[wuhgit]

首先说明，虽然这个名为“词库”，但对于 Gboard 而言，当前的实现方式更类似于 “自定义短语”，这两者存在巨大的区别，使用过程中出现的很多问题也是由此造成。

对于拼音输入法而言，词条对应的全拼字符串应该有正确的分割，让词条能够通过 完整全拼、全拼的首字母、部分全拼及部分首字母混合 等一切可以匹配到的形式进行匹配，并且输入法还会根据已输入的字符进行一些延伸，达到所谓智能预测输入的特性。

当设置为 双拼 输入方案时，这个过程只是多了一次键盘映射，以 小鹤双拼 为例，输入 xn，输入法仍旧是以全拼 xiao 的形式在词库中进行匹配，得到 小 字。

而自定义短语只有完整输入相应的字符串才能匹配，输入法本身无法对其进行正确的分割。

Gboard 真正的词库类型是 dict_3_3 ，通常是 user_dict_3_3 ，这也是从 谷歌拼音输入法 延续下来的。

将词库类型设置为 自定义短语 而不是 dict_3_3 ，这是对于实际使用的一个取舍。

对于 Gboard 和以前的 谷歌拼音输入法，用户在使用过程中输入的任何新词，达到一定的频次后就会被加入到词库中。
但输入法针对 dict_3_3 类型的词库设置有一个 500000 的容量上限，只要词库达到这个上限，输入法会将其整个清空。

之所以有这样的限制，显而易见的是出于运行效率的考虑，加之 Gboard 本身是一个多语言输入法，这个容量上限对于 99% 的语言都已经足够。
另外，如果用户某一次的输入无意间触发了错误的索引，也会导致词库被清空。

从 2020年11月1号 的第一个版本开始，我这个词库的数据量就远远超出了上限，如果制作一个词库就是为了它被清空，毫无必要。
之前也考虑过对词条数量进行精简，只是词条少了就无法弥补 Gboard 自带中文词库的缺点，词条多了还需要考虑到每个用户日常输入的新词数量（这个数量千差万别根本无法定量），并且可以肯定的是，这两者叠加在一起最终触发清空只是一个时间问题。

要想绕过这个限制，一个直观方法是修改源码中的容量上限做一个 mod 版的 Gboard ，但这是一个极不正确且极度危险的方法，输入法涉及到个人最基本的隐私安全，任何时候都不要做这样的决定，更不要使用任何第三方修改过的输入法。

另一个可行的方法就是使用输入法的 自定义短语 ，也就是我现在所用的类型，它没有容量上限（至少目前我没发现）。
唯一的缺点就是输入方式过于呆板，并且由于输入法并不知道如何把词条和用户输入的字符串进行对应，也就造成了 词语和拼音被莫名其妙分割 的现象。
在这种模式下，要想实现双拼输入，只能是为每一个词条存入不同的字符，比如凡是有 小 字的词条，不仅存入xn 也存入 xiao ，很显然这种粗暴的处理模式将导致最终数据量的暴涨，消耗更多的系统资源，并且在输入过程中出现过多的非必要的候选内容。
即便是单独为每一种双拼方案提供各自的双拼词库，由于双拼的特性，以及必须完全匹配才能输入相应词条的原因，输入法的重码和误码率将会异常之高，以至于这样的词库不如不用。

如果没有 root , 又或者你自己有能力动手修改了 Gboard 源码解决了隐私安全的担忧，就是想用 dict_3_3 格式以获得最好的使用体验，这时又会出现另外一个问题，那就是漫长的导入时间。

在非 root 的情况下，导入词库只能通过 txt 格式，并且这也是目前生成 dict_3_3 格式词库的唯一方法。

有网友做过实际操作，122万词条实际导入时间在 70分钟左右。
受限于每个用户设备的性能表现以及中间难免发生导入失败之类的意外，如果每一次词库更新都要这样操作，这种耐心我实在难以想象。

这也是我没有提供 txt 格式的主要原因，并且对于原版 Gboard 用户而言，如果它注定会被清空，何必浪费这么多时间和精力？
已 root 用户直接使用 Magisk 模块，刷入只需几秒钟，效果立等可得，词库有更新也能在第一时间得到通知，不想使用这个词库时清除相关数据也非常方便，唯一的缺点就是输入体验不佳，但至少够用。

如何证明我所说的“词库达到上限后会被清空”？你可以自己试一下：

未 root 的设备，首先在 Gboard 的应用信息里记录下导入前数据的空间占用，导入 txt 格式后记录下空间占用，使用一段时间后再观察空间占用，你会发现之前增加的空间已经消失了。
已 root 的设备，观察 Gboard 数据目录下 user_dict_3_3 文件尺寸的前后变化。

在刷入 Magisk 模块的时候，实际上输入法也会为这些自定义短语生成一个 dict_3_3 格式的词库，在某些版本的 Gboard 中会用类似 正在改善您的打字输入体验 这样的通知进行提示，生成的这个词库也不会存在太久，但由于这些词条数据实际存储在输入法用于提供自定义短语的数据库中，它们并不会被删除。