说个反常识的笑话，小小输入法很占内存

大家初次接触小小输入法时，第一印象往往是安装包体积极小；待到实际运行，会觉得它资源占用极低、响应迅速。不过，但实际并不如此。

小小输入法的确基础内存开销很小，这得益于它直接与操作系统底层交互，刻意回避了那些功能强大却体积臃肿的第三方组件。然而，真正影响内存占用的关键，在于它的码表引擎机制——码表和词库会被完整加载进内存，而内存中的实际占用大约会膨胀到码表文件大小的三倍左右（拼音码表的情况通常更为夸张）。如果加载了超过 200 万条词汇的大词库，输入法的内存占用量就很可能突破百兆。

另一个不容忽视的内存开销来源是字体文件，这一点颇有些无奈。如今字体包越来越庞大，明明日常用字不过三千，字体却动辄收录十几万个字形，其中充斥着大量几乎永无用武之地的“死字”。好在这些死字平时并不会被实际渲染，基本只占据硬盘空间，对内存影响有限。真正的内存大户是 emoji 表情符号。随着 emoji 在日常输入中的普及，输入法已无法回避对它的支持。如果你打开软键盘上的 emoji 面板，就能直观感受到那种瞬间的卡顿——输入法的内存占用会从 10MB 以下直线飙升到七八十兆（不同系统表现或有差异，我在 Windows 11 中稳定复现过此现象，而在 Windows 10 上反倒没什么问题）。

小小输入法使用纯 C 语言开发，先天具备极低的基础内存占用优势。但在实现过程中，我大量运用了“指针魔法”，这也导致在从 32 位向 64 位架构迁移时，内存用量一度暴涨——64 位版本的内存占用量比 32 位版高出 50% 以上。经过近期版本的调优，64 位版的内存占用已被压至与 32 位版相近的水平（严格来说还是会稍高一些），不过这种优化也带来了一些副作用：当使用超大词库时，程序更容易出现崩溃（主要影响 Android 平台以及 Windows 10 1803 之前的版本，懂的兄弟马上看出我干了什么）。当然，小小输入法本身也一贯不提倡使用体量过大的词库。