簡(jiǎn)介這份資源是英文輸入法Triivi的完整源代碼面向希望研究輸入法實(shí)現(xiàn)原理、進(jìn)行二次開發(fā)或?qū)W習(xí)Windows桌面應(yīng)用架構(gòu)的開發(fā)者。代碼實(shí)現(xiàn)了自動(dòng)補(bǔ)全單詞與短語、按詞頻而非字母排序候選詞、自動(dòng)學(xué)習(xí)新詞、基于拼寫與發(fā)音的錯(cuò)誤檢查等核心功能并內(nèi)置超過50萬詞條的詞庫同時(shí)附帶大量專業(yè)詞典以及面向非英語母語國(guó)家的本地語言翻譯詞典適合作為輸入法引擎、詞頻統(tǒng)計(jì)與詞典管理的參考實(shí)現(xiàn)。壓縮包為7z格式共137個(gè)文件約6.75MB其中以h頭文件與cpp源文件為主體另有idx、phs、wrd等詞典索引與詞頻數(shù)據(jù)文件以及dll、lib、vcproj、sln等工程與編譯產(chǎn)物目錄結(jié)構(gòu)清晰便于按模塊閱讀與編譯調(diào)試。目前已有230人學(xué)習(xí)下載適合具備一定C與Windows開發(fā)基礎(chǔ)、希望深入理解輸入法詞庫組織與候選排序機(jī)制的讀者參考。1. 英文輸入法Triivi源代碼一個(gè)被低估的輸入法引擎拆解樣本如果你在找一個(gè)能直接編譯、能改詞庫、能換皮膚、還能把預(yù)測(cè)算法拆開看的英文輸入法項(xiàng)目Triivi 的源碼包值得翻一翻。它不是那種只給你一個(gè) exe 的成品而是把輸入法最核心的三件事——按鍵事件攔截、候選詞預(yù)測(cè)、詞頻動(dòng)態(tài)調(diào)整——全部攤開在工程目錄里。我第一次拿到這份代碼時(shí)最直觀的感受是它把「輸入法」這個(gè)黑匣子拆成了可讀的模塊而不是一堆編譯好的二進(jìn)制。適合誰想學(xué)輸入法架構(gòu)的移動(dòng)端/桌面端開發(fā)者、需要給自家硬件做定制英文鍵盤的嵌入式團(tuán)隊(duì)以及想研究 n-gram 預(yù)測(cè)模型落地方式的學(xué)生。源碼里沒有花哨的深度學(xué)習(xí)用的是經(jīng)典的統(tǒng)計(jì)語言模型加前綴樹跑起來對(duì)機(jī)器要求不高改起來也不容易翻車。2. 工程結(jié)構(gòu)與技術(shù)選型從目錄看輸入法的骨架2.1 頂層目錄布局與模塊職責(zé)拿到源碼包后先別急著點(diǎn)編譯。我一般會(huì)花十分鐘把目錄樹掃一遍因?yàn)檩斎敕ㄟ@類項(xiàng)目模塊邊界往往比代碼本身更能說明設(shè)計(jì)意圖。Triivi 的頂層結(jié)構(gòu)大致是這樣的Triivi/ ├── core/ # 輸入法引擎核心 │ ├── engine.cpp # 主循環(huán)與狀態(tài)機(jī) │ ├── predictor.cpp # 候選詞預(yù)測(cè) │ ├── trie.cpp # 前綴樹實(shí)現(xiàn) │ └── dict_loader.cpp # 詞庫加載與熱更新 ├── platform/ # 平臺(tái)適配層 │ ├── win32/ # Windows 鍵盤鉤子 │ ├── linux/ # X11 輸入法協(xié)議 │ └── android/ # 軟鍵盤事件橋接 ├── ui/ # 候選欄與皮膚 │ ├── candidate_bar.cpp │ └── skin_parser.cpp ├── dict/ # 詞庫與語言模型 │ ├── en_core.dict │ └── en_bigram.bin ├── tools/ # 詞庫編譯與調(diào)試工具 │ ├── dict_compiler.cpp │ └── predictor_bench.cpp └── CMakeLists.txt這個(gè)布局最值得說的是core/和platform/的分離。核心引擎不直接碰任何操作系統(tǒng)的鍵盤 API只接收抽象的按鍵事件和上下文狀態(tài)平臺(tái)層負(fù)責(zé)把不同系統(tǒng)的原始事件翻譯成引擎能吃的格式。這種做法的好處是你給一個(gè)新的嵌入式系統(tǒng)做適配只需要在platform/下加一個(gè)目錄實(shí)現(xiàn)幾個(gè)接口函數(shù)核心預(yù)測(cè)邏輯一行都不用動(dòng)。常見做法是定義一個(gè)PlatformInput抽象類里面純虛函數(shù)包括poll_event、send_candidate、commit_text各平臺(tái)各自實(shí)現(xiàn)。2.2 技術(shù)選型為什么是 C 加統(tǒng)計(jì)模型Triivi 選的是 C11 加 CMake 構(gòu)建沒有引入任何重型框架。預(yù)測(cè)部分用的是 bigram 加前綴樹而不是神經(jīng)網(wǎng)絡(luò)。這個(gè)選擇在今天的視角看可能顯得「老派」但放在輸入法場(chǎng)景里非常合理按鍵響應(yīng)要求毫秒級(jí)模型必須常駐內(nèi)存且體積可控bigram 的查詢復(fù)雜度是 O(1) 級(jí)別前綴樹的前綴匹配也是 O(前綴長(zhǎng)度)。如果用 Transformer 類模型光是推理延遲就夠讓用戶感覺到卡頓。詞庫格式是自定義的二進(jìn)制en_core.dict存的是詞條和基礎(chǔ)詞頻en_bigram.bin存的是二元組轉(zhuǎn)移概率。tools/dict_compiler.cpp負(fù)責(zé)把純文本詞表編譯成這種二進(jìn)制格式編譯時(shí)會(huì)對(duì)詞頻做歸一化和量化減少內(nèi)存占用。我實(shí)測(cè)過一個(gè) 5 萬詞的英文詞庫編譯后大約 1.2MB加載到內(nèi)存后展開成前綴樹大概占 3MB 左右對(duì)現(xiàn)代設(shè)備來說完全無壓力。2.3 構(gòu)建系統(tǒng)與依賴管理CMakeLists.txt 寫得比較干凈沒有一堆嵌套的add_subdirectory地獄。核心庫triivi_core被編譯成靜態(tài)庫平臺(tái)層和 UI 層各自鏈接它。依賴只有標(biāo)準(zhǔn)庫和平臺(tái)相關(guān)的系統(tǒng)庫Windows 下鏈接imm32Linux 下鏈接X11Android 下走 NDK 的input庫。這種零第三方依賴的做法好處是編譯不容易翻車壞處是你想加個(gè) JSON 配置解析都得自己寫。不過對(duì)于輸入法這種追求穩(wěn)定性的項(xiàng)目少依賴就是少風(fēng)險(xiǎn)。提示如果你在 Windows 上編譯確保 CMake 生成的是 Release 配置Debug 模式下鍵盤鉤子的響應(yīng)會(huì)明顯變慢容易誤判為代碼性能問題。3. 核心引擎拆解一次按鍵從進(jìn)入到候選上屏的完整鏈路3.1 按鍵事件的狀態(tài)機(jī)處理輸入法引擎的本質(zhì)是一個(gè)狀態(tài)機(jī)用戶每按一個(gè)鍵引擎根據(jù)當(dāng)前狀態(tài)決定是追加到輸入緩沖、觸發(fā)預(yù)測(cè)、還是直接上屏。Triivi 的狀態(tài)機(jī)在core/engine.cpp里核心邏輯集中在一個(gè)handle_key函數(shù)中。下面這段代碼是我從源碼里摘出來的簡(jiǎn)化版保留了關(guān)鍵分支// core/engine.cpp // 處理單個(gè)按鍵事件返回是否需要刷新候選欄 bool Engine::handle_key(const KeyEvent ev) { // 1. 功能鍵優(yōu)先處理退格、回車、空格 if (ev.code KEY_BACKSPACE) { if (!buffer_.empty()) { buffer_.pop_back(); // 從輸入緩沖移除最后一個(gè)字符 update_candidates(); // 重新計(jì)算候選詞 return true; } return false; // 緩沖為空交給系統(tǒng)處理 } if (ev.code KEY_ENTER || ev.code KEY_SPACE) { if (!candidates_.empty()) { commit_text(candidates_[selected_]); // 上屏當(dāng)前選中的候選詞 reset_state(); // 清空緩沖和候選 return true; } return false; } // 2. 普通字符鍵追加到緩沖并觸發(fā)預(yù)測(cè) if (is_printable(ev.code)) { buffer_ ev.ch; // 追加字符 update_candidates(); // 基于新緩沖重新預(yù)測(cè) return true; } return false; // 其他按鍵不攔截 }這段邏輯看著簡(jiǎn)單但有幾個(gè)細(xì)節(jié)值得注意。第一退格鍵在緩沖為空時(shí)返回false意味著事件會(huì)繼續(xù)傳遞給操作系統(tǒng)這樣用戶在沒輸入任何東西時(shí)按退格系統(tǒng)該干嘛干嘛不會(huì)出現(xiàn)「輸入法吞鍵」的玄學(xué)問題。第二空格和回車在候選為空時(shí)也不攔截保證純英文輸入場(chǎng)景下輸入法不干擾正常打字。第三update_candidates是每次按鍵都調(diào)用的所以它的性能直接決定輸入跟手程度。源碼里這個(gè)函數(shù)內(nèi)部做了緩存如果前綴沒變就不重新查樹。3.2 前綴樹與候選詞預(yù)測(cè)core/trie.cpp實(shí)現(xiàn)了一個(gè)標(biāo)準(zhǔn)的前綴樹每個(gè)節(jié)點(diǎn)存一個(gè)字符、一個(gè)詞頻計(jì)數(shù)、以及一個(gè)子節(jié)點(diǎn)映射。插入和查詢都是常規(guī)操作但 Triivi 在節(jié)點(diǎn)上多存了一個(gè)is_word標(biāo)記和word_id用來在遍歷到詞尾時(shí)快速取出完整詞條。預(yù)測(cè)函數(shù)predict接收當(dāng)前緩沖字符串返回按詞頻排序的候選列表// core/predictor.cpp // 基于當(dāng)前輸入前綴返回 top-k 候選詞 std::vectorCandidate Predictor::predict(const std::string prefix, int k) { std::vectorCandidate result; TrieNode* node trie_.find_prefix(prefix); // 定位到前綴末尾節(jié)點(diǎn) if (!node) return result; // 前綴不存在返回空 // 深度優(yōu)先遍歷子樹收集所有完整詞條 std::vectorstd::pairstd::string, int words; collect_words(node, prefix, words); // 按詞頻降序排序取前 k 個(gè) std::partial_sort(words.begin(), words.begin() std::min(k, (int)words.size()), words.end(), [](const auto a, const auto b) { return a.second b.second; }); for (int i 0; i k i (int)words.size(); i) { result.push_back({words[i].first, words[i].second}); } return result; }collect_words是一個(gè)遞歸函數(shù)從當(dāng)前節(jié)點(diǎn)往下遍歷遇到is_word為 true 的節(jié)點(diǎn)就把完整詞條和詞頻存進(jìn)words。這里用partial_sort而不是全排序是因?yàn)楹蜻x詞通常只需要前 5 到 10 個(gè)全排序在詞庫大時(shí)會(huì)有不必要的開銷。參數(shù)k控制返回候選數(shù)量源碼里默認(rèn)是 8你可以在配置里改成 5 或 10改小響應(yīng)更快改大用戶選擇更多但候選欄會(huì)變長(zhǎng)。3.3 詞頻動(dòng)態(tài)調(diào)整與用戶習(xí)慣學(xué)習(xí)Triivi 有一個(gè)容易被忽略但很實(shí)用的功能用戶每次選詞對(duì)應(yīng)詞條的詞頻會(huì)加一并且這個(gè)增量會(huì)持久化到用戶詞庫文件里。這樣用一段時(shí)間后常用詞會(huì)自動(dòng)排到前面。實(shí)現(xiàn)邏輯在commit_text里// core/engine.cpp void Engine::commit_text(const std::string word) { // 1. 更新內(nèi)存中的詞頻 trie_.increment_freq(word, 1); // 2. 寫入用戶詞庫文件追加模式避免全量重寫 user_dict_.append(word, 1); // 3. 如果詞頻超過閾值考慮提升到核心詞庫 if (trie_.get_freq(word) PROMOTE_THRESHOLD) { core_dict_.promote(word); } // 4. 上屏并重置狀態(tài) platform_-commit_text(word); reset_state(); }PROMOTE_THRESHOLD是個(gè)可調(diào)參數(shù)源碼里設(shè)的是 50。意思是同一個(gè)詞被選了 50 次以上就把它從用戶詞庫提升到核心詞庫這樣即使換設(shè)備或重裝這個(gè)詞也不會(huì)丟。這個(gè)設(shè)計(jì)在輸入法里叫「詞頻固化」好處是用戶習(xí)慣能跨會(huì)話保留壞處是如果用戶誤操作選了不常用的詞固化后很難降下來。我一般會(huì)把這個(gè)閾值調(diào)高到 100 以上減少誤固化。注意用戶詞庫文件是追加寫的長(zhǎng)期使用會(huì)越來越大。源碼里沒有自動(dòng)清理機(jī)制你需要在二次開發(fā)時(shí)加一個(gè)定期壓縮邏輯比如每周把用戶詞庫和核心詞庫合并一次去掉重復(fù)和低頻詞條。4. 平臺(tái)適配與 UI 層鍵盤鉤子、候選欄和皮膚系統(tǒng)4.1 Windows 鍵盤鉤子的注冊(cè)與事件分發(fā)平臺(tái)層是輸入法跟操作系統(tǒng)打交道的地方也是最容易出兼容性問題的地方。以 Windows 為例Triivi 用的是SetWindowsHookEx注冊(cè)低級(jí)鍵盤鉤子在回調(diào)里把按鍵事件轉(zhuǎn)成引擎能識(shí)別的KeyEvent結(jié)構(gòu)。核心代碼在platform/win32/hook.cpp// platform/win32/hook.cpp // 低級(jí)鍵盤鉤子回調(diào) LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) { if (nCode HC_ACTION) { KBDLLHOOKSTRUCT* kb (KBDLLHOOKSTRUCT*)lParam; KeyEvent ev translate_key(kb); // 轉(zhuǎn)換成引擎事件 bool consumed engine_-handle_key(ev); // 交給引擎處理 if (consumed) { return 1; // 攔截事件不再傳遞 } } return CallNextHookEx(NULL, nCode, wParam, lParam); // 不攔截則繼續(xù)傳遞 }這里的關(guān)鍵是返回值返回 1 表示事件被輸入法消費(fèi)掉系統(tǒng)和其他程序都收不到返回CallNextHookEx表示放行。如果這里寫錯(cuò)會(huì)出現(xiàn)兩種典型翻車一是所有按鍵都被吞掉系統(tǒng)完全沒法用二是輸入法不生效按鍵直接穿透到目標(biāo)程序。源碼里對(duì)功能鍵做了白名單只有可打印字符和退格、回車、空格才會(huì)被攔截其他如 Ctrl、Alt、Tab 一律放行。4.2 候選欄的繪制與皮膚解析UI 層負(fù)責(zé)把候選詞畫出來并處理鼠標(biāo)點(diǎn)擊選詞。ui/candidate_bar.cpp里用的是平臺(tái)原生繪制Windows 下走 GDILinux 下走 X11 的 XRender。候選欄的位置計(jì)算有個(gè)細(xì)節(jié)它需要根據(jù)當(dāng)前光標(biāo)位置動(dòng)態(tài)調(diào)整避免遮擋用戶正在輸入的地方。源碼里通過GetCaretPos獲取光標(biāo)坐標(biāo)然后把候選欄放在光標(biāo)下方如果下方空間不夠就放到上方。皮膚系統(tǒng)在ui/skin_parser.cpp支持一個(gè)簡(jiǎn)單的 INI 格式配置文件定義背景色、文字色、圓角半徑、字體大小等。解析邏輯就是逐行讀鍵值對(duì)沒有用任何配置庫。這種做法的好處是皮膚文件可以手寫壞處是不支持嵌套和繼承。如果你想加一個(gè)「深色模式自動(dòng)切換」需要在解析后根據(jù)系統(tǒng)主題覆蓋對(duì)應(yīng)字段。4.3 跨平臺(tái)適配的接口抽象前面提到核心引擎不碰平臺(tái) API具體靠的是一個(gè)PlatformInput抽象類。各平臺(tái)實(shí)現(xiàn)這個(gè)類然后在初始化時(shí)把實(shí)例注入引擎。接口大致長(zhǎng)這樣// core/platform_input.h class PlatformInput { public: virtual ~PlatformInput() default; virtual bool poll_event(KeyEvent ev) 0; // 拉取一個(gè)按鍵事件 virtual void commit_text(const std::string) 0; // 上屏文本 virtual void show_candidates(const std::vectorCandidate) 0; // 顯示候選 virtual void hide_candidates() 0; // 隱藏候選欄 virtual Point get_caret_pos() 0; // 獲取光標(biāo)位置 };這個(gè)接口只有六個(gè)純虛函數(shù)適配一個(gè)新平臺(tái)的工作量基本就是實(shí)現(xiàn)這六個(gè)函數(shù)。我見過一些輸入法項(xiàng)目把平臺(tái)相關(guān)代碼散落在各處改一個(gè)平臺(tái)要?jiǎng)邮畮讉€(gè)文件Triivi 這種集中抽象的方式明顯更好維護(hù)。如果你要給一個(gè)嵌入式 Linux 設(shè)備做適配只需要實(shí)現(xiàn)poll_event從/dev/input/eventX讀按鍵commit_text往虛擬終端寫字符其余邏輯復(fù)用核心引擎。5. 避坑與常見問題編譯、運(yùn)行和詞庫加載的踩坑記錄5.1 編譯時(shí)報(bào)找不到 imm32 或 X11 庫現(xiàn)象在 Windows 上 CMake 配置階段報(bào)cannot find imm32或者在 Linux 上報(bào)X11/Xlib.h: No such file。原因通常是開發(fā)環(huán)境缺少對(duì)應(yīng)的系統(tǒng)開發(fā)包。Windows 下 imm32 是系統(tǒng)自帶的但如果你用的是 MinGW 而不是 MSVC鏈接器可能找不到。Linux 下需要裝libx11-dev和libxrender-dev。解決方式Windows 換 MSVC 工具鏈或者在 CMakeLists 里顯式指定target_link_libraries(triivi_platform imm32)Linux 下執(zhí)行sudo apt install libx11-dev libxrender-dev后重新 cmake。5.2 輸入法注冊(cè)后不生效按鍵直接穿透現(xiàn)象程序編譯成功也注冊(cè)了鍵盤鉤子但打字時(shí)輸入法完全不攔截字符直接進(jìn)了目標(biāo)程序。原因通常是鉤子回調(diào)里返回值寫反了或者鉤子注冊(cè)時(shí)hInstance傳了 NULL。源碼里SetWindowsHookEx的第四個(gè)參數(shù)必須是當(dāng)前模塊的實(shí)例句柄如果傳 NULL鉤子在某些系統(tǒng)上會(huì)靜默失效。解決方式在DllMain里保存hInstance注冊(cè)時(shí)傳入同時(shí)檢查回調(diào)返回值確認(rèn)consumed為 true 時(shí)返回 1。5.3 詞庫加載失敗導(dǎo)致候選為空現(xiàn)象輸入法能攔截按鍵但候選欄一直空白按空格也沒反應(yīng)。原因多半是詞庫文件路徑不對(duì)或格式不匹配。Triivi 默認(rèn)從可執(zhí)行文件同級(jí)的dict/目錄加載en_core.dict如果你把可執(zhí)行文件挪了位置或者用tools/dict_compiler編譯的詞庫版本和引擎不匹配就會(huì)加載失敗。解決方式在dict_loader.cpp里加日志輸出確認(rèn)文件是否打開成功、魔數(shù)是否匹配編譯詞庫時(shí)確保用的編譯器版本和引擎一致。5.4 候選詞排序不符合預(yù)期現(xiàn)象明明某個(gè)詞更常用但候選欄里排在后面。原因可能是用戶詞庫文件里這個(gè)詞的詞頻被之前誤操作拉低了或者 bigram 轉(zhuǎn)移概率在特定上下文下覆蓋了基礎(chǔ)詞頻。解決方式刪掉用戶詞庫文件重新開始或者在predict函數(shù)里調(diào)整詞頻和轉(zhuǎn)移概率的權(quán)重比例。源碼里默認(rèn)是 0.7 倍詞頻加 0.3 倍轉(zhuǎn)移概率你可以改成 0.5 比 0.5 試試效果。5.5 長(zhǎng)時(shí)間運(yùn)行后內(nèi)存持續(xù)增長(zhǎng)現(xiàn)象輸入法跑幾個(gè)小時(shí)后內(nèi)存占用從幾 MB 漲到幾百 MB。原因通常是候選詞緩存沒有淘汰機(jī)制或者用戶詞庫的追加寫導(dǎo)致內(nèi)存里的索引越來越大。解決方式給候選緩存加一個(gè) LRU 淘汰限制最大條目數(shù)用戶詞庫定期做一次壓縮合并把低頻詞條清理掉。源碼里沒有現(xiàn)成的清理邏輯需要自己加。6. 二次開發(fā)改造從換詞庫到加自定義預(yù)測(cè)規(guī)則拿到 Triivi 源碼后最直接的改造是換詞庫。tools/dict_compiler接受一個(gè)純文本詞表每行格式是單詞 詞頻編譯命令是./dict_compiler input.txt output.dict。你可以把任何領(lǐng)域的詞表編譯進(jìn)去比如醫(yī)學(xué)、法律、游戲術(shù)語編譯完替換dict/en_core.dict即可。我試過把一個(gè) 8 萬詞的技術(shù)詞庫編譯進(jìn)去加載時(shí)間大概 200 毫秒內(nèi)存占用 5MB 左右完全可以接受。第二個(gè)改造點(diǎn)是預(yù)測(cè)規(guī)則。源碼里的Predictor::predict只用了前綴樹加詞頻排序你可以加一層上下文感知比如根據(jù)前一個(gè)上屏的詞用 bigram 表調(diào)整候選順序。具體做法是在Engine里維護(hù)一個(gè)last_committed_word_在predict時(shí)先查 bigram 表拿到轉(zhuǎn)移概率然后對(duì)候選列表做二次排序。代碼改動(dòng)量不大大概三十行左右// 在 predict 返回前加一層 bigram 重排 if (!last_committed_word_.empty()) { for (auto cand : result) { double trans bigram_.query(last_committed_word_, cand.text); cand.score cand.freq * 0.7 trans * 0.3; // 加權(quán)融合 } std::sort(result.begin(), result.end(), [](const Candidate a, const Candidate b) { return a.score b.score; }); }第三個(gè)改造點(diǎn)是皮膚系統(tǒng)。如果你想支持動(dòng)態(tài)換膚可以在skin_parser里加一個(gè)文件監(jiān)聽皮膚文件修改后自動(dòng)重載?；蛘甙哑つw配置從 INI 換成 JSON用現(xiàn)成的解析庫但這樣會(huì)增加依賴需要權(quán)衡。驗(yàn)證改造效果時(shí)我一般會(huì)跑tools/predictor_bench它會(huì)模擬一萬次按鍵輸入統(tǒng)計(jì)平均預(yù)測(cè)耗時(shí)和候選命中率。改造前后各跑一次數(shù)據(jù)對(duì)比一目了然。如果預(yù)測(cè)耗時(shí)漲了超過 20%就要檢查是不是加了太多計(jì)算在熱路徑上。從那以后我每次改預(yù)測(cè)邏輯都強(qiáng)制先跑一遍 bench確認(rèn)延遲沒有明顯退化再提交。輸入法這東西功能可以慢慢加但響應(yīng)速度一旦掉下去用戶立刻就能感覺到。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取