Tolk.dll 架构拆分

我今天在和 GPT 讨论之前说过的新想法：把 Tolk 拆分，拆分为：

• 入口：用于接入其他程序。
  兼容现存的入口：主要是 Tolk.dll、TolkDotNet.dll、Tolk.jar；nvda.dll 等。再加一个 http 的接口用于测试。这部分是最大的改动，可以降低维护成本，也能更好的支持多平台，比如你要在跨平台的 unity/ue 游戏中，编译到 web/主机你是没法用 tolk 的，就算接入 tts 也是非常麻烦。
• 服务端/预处理：主要是和入口解耦，并实现一些文本的预处理，或者是配置支持，像是保益一样。
  当然也可以是不做处理直接转发。预处理脚本用 js 写。这部分需要支持跨平台，快速开发可以选用 nodejs/python。真有必要跨平台可以用 GO。
• 输出适配：主要是读屏、TTS及其他输出。
  就是常见的几大读屏、TTS。这部分涵盖 tolk 现有的功能，并且可以跨平台支持其他的输出了。

拆分后还有一个好处：可以穿过进程、模拟器、虚拟机或者是单一设备的界限。
比如模拟器游戏输出（包括手机 app 模拟器）、虚拟机内输出（旧系统或非 windows 系统）、手机游戏发送到电脑读屏，等等。
还可以用 frida 挂钩 SAPI 这种走 COM 无法替换 dll 的，也可以获得输入。
就是延迟问题需要做个 demo 测一测。

这想法实际上是现成的，也有成熟实践了，就是 linux 上的 Speech Dispatcher。
系统起一个服务，然后所有的 tts 以及输出设备（包括实体的点显器）作为驱动接入此服务。
其他的软件如 linux 的读屏 ocra 通过 TCP 发送消息到服务，然后输出。
当然成熟的软件他这个架构太重了，传输协议太复杂，也不跨平台。我们还是搞点轻量级的东西，延迟还是要关注的。