关于雷蛇手柄支持与自研触觉 SDK 的公告

更新日期：2026 年 7 月 23 日

近期有不少用户催促我们支持雷蛇手柄，尤其希望在远程串流中使用 Razer Sensa HD Haptics 等专有触觉能力。我们理解这个需求，也已经对雷蛇公开的 Remote Play 工程、Android 振动调用链以及相关二进制 SDK 进行了技术分析。

我们的结论很明确：现阶段我们不会把来源和授权边界不清晰的雷蛇私有 .so 直接整合进 USB 驱动库，也不会照搬其闭源实现。我们会继续建设自己的开放触觉 SDK，并在取得合法协议资料或官方授权后，以独立设备后端的方式支持雷蛇手柄。

我们有能力走这条捷径，但不愿拿用户和项目的长期安全，去换一次短期兼容。

为什么我们决定自研触觉 SDK

我们已经确认，雷蛇的 Sensa 触觉能力可以通过 Nexus 和专有组件驱动。能调用只说明技术上可行，并不赋予我们集成、修改和向用户分发这些组件的权利。

我们选择自研，首先是为了对用户和项目负责：

法律边界必须清晰。我们没有获得雷蛇私有 .so 的复制、修改和再分发许可；把它直接链接或打包进 GPL 项目，可能同时引发版权、许可兼容、逆向工程和下游分发风险。
核心能力必须掌握在自己手中。私有 ABI、服务鉴权和 USB 数据格式随时可能改变。依赖不可审计的黑盒，意味着兼容性、性能和安全性都受制于厂商。
触觉系统不能依赖另一个品牌应用。雷蛇公开方案需要 Remote Play 跨进程调用 Nexus；我们的 SDK 直接位于串流音频和游戏 Rumble 链路中，时钟、队列、调度和设备渲染全部由我们控制。
我们坚持真正可持续的开放开发。一个依靠 Moonlight/Sunshine 构建商业产品的厂商，应当持续提供与发行版本对应的源码，不能只留下落后于商店版本的阶段性快照。

我们反感并反对雷蛇当前 Remote Play 对 GPLv3 对应源码义务的处理方式。官方一方面宣称源码位于 GitHub，另一方面商店二进制已经更新到 2.0.5，公开仓库却仍停留在 2025 年的代码状态。根据目前可以核验的公开信息，我们认为：继续分发 Moonlight 衍生的新版本，却只提供落后的源码快照，已经违背了 GPLv3 的对应源码要求。如果雷蛇另有合规的当前版本源码渠道，应当明确向用户和社区公布，不应继续用旧仓库笼统宣传产品已经开源。

我们不能一边反对厂商只享受开源生态却不持续履行开放义务，一边又为了短期兼容，把自己的底层能力建立在它的闭源黑盒上。自研是我们基于法律、技术和开源原则作出的主动选择，也是对这套项目长期负责的方式。

为什么我们的 SDK 比雷蛇公开方案更强

我们可以明确地说：在远程串流触觉这个场景里，我们的 SDK 在架构完整性、实时性设计、同步能力、开放性和设备扩展能力上，都强于雷蛇目前公开的方案。

雷蛇公开方案的核心路径是：

Remote Play → 两个电机强度值 → AIDL → Nexus 闭源服务 → 雷蛇手柄

我们的路径是：

解码 PCM + 游戏 Rumble
        ↓
触觉事件分析与语义建模
        ↓
音频呈现时钟同步
        ↓
设备能力与配置档案
        ↓
独立渲染后端 → 手机振动器 / 普通手柄 / 专用触觉设备

雷蛇公开的是“把两个数值送进黑盒”；我们构建的是从内容、时钟、触觉语义到执行器的完整闭环。

能力	雷蛇目前公开的方案	我们的 SDK
数据链路	Remote Play 经 AIDL 依赖 Nexus 闭源服务	在串流解码链路内直接生成并调度触觉事件
输入来源	公开层主要传递高、低频电机强度	同时接收解码 PCM 与原生游戏 Rumble
内容理解	核心算法与编码过程不可见	识别瞬态冲击、持续低频、静音和场景变化
同步方式	公开代码未展示完整音画触觉时钟策略	按音频实际呈现时钟调度，并补偿执行器提前量
实时设计	依赖跨应用 Binder 服务和闭源状态	固定容量队列，音频线程不阻塞、不动态分配
积压处理	关键策略不可审计	丢弃过期瞬态、保留最新事件，STOP 指令最高优先级
设备适配	围绕雷蛇产品与 Nexus 生态	能力检测、设备档案、分级渲染与兼容降级
可观测性	外部无法检查黑盒延迟和丢包	提供调度延迟、音频偏差、丢弃和时钟状态统计
可维护性	核心能力无法由社区修复或替换	DSP、调度和渲染后端均可测试、审计和替换
授权	私有组件授权与再分发边界不透明	SDK 核心采用 Apache-2.0，便于合法集成与复用

我们怎样从声音中还原触觉

我们的 SDK 分析的是触觉事件，音量只是其中一个输入维度：

爆炸、枪击、碰撞和鼓点会被识别为短促、清晰的瞬态冲击；
引擎、机械、低频环境声会形成稳定而连续的触觉底层；
自适应频谱白化、对数压缩、频谱通量、峰值检测和静音门共同减少误触发；
游戏原生 Rumble 与音频触觉可以进入同一渲染体系，并行协作、互不覆盖；
Android 设备会根据能力选择频率控制、振幅波形或兼容降级；
新设备只需增加渲染后端，无需把厂商协议污染到音频分析和业务代码中。

最终交付的是一套面向串流场景设计的触觉运行时，能力边界远比单一厂商补丁更完整。

我们的链路更短，也更可控

触觉对时间极其敏感。一个冲击即使只晚几十毫秒，也可能从“击中目标”变成与画面无关的余震。

我们的触觉分析直接位于 Moonlight 解码后的 PCM 路径中，不需要先把信号交给外部启动器或另一个品牌应用。SDK 使用音频呈现时钟对齐触觉事件，并把设备执行器的启动时间纳入调度。实时线程不等待设备，也不会因为振动服务卡顿而阻塞音频播放。

这使我们的系统从架构上拥有更短、更确定、更容易测量的链路。我们不需要猜测黑盒做了什么，因为每一个阶段都在自己手里。

我们要解决完整的串流触觉问题

雷蛇解决的是“如何让自家应用调用自家服务和自家设备”；我们解决的是“如何让任何串流内容获得低延迟、可同步、可扩展的触觉体验”。

雷蛇掌握自家手柄的私有参数，这是它的先发条件，但这不代表其公开软件架构更先进，只代表关键资料尚未开放。我们的 SDK 不绑定 Nexus、不要求雷蛇账户、不依赖厂商启动器，也不会把整个项目的可靠性交给一个无法审计的二进制黑盒。

雷蛇公开方案止步于一个通往闭源黑盒的入口；我们的开放链路覆盖声音、时钟、触觉语义和设备执行器。我们的目标也超越了复刻 Sensa：建设一套比厂商私有方案更完整的串流触觉基础设施。

雷蛇手柄以后会不会支持

会，但必须建立在合法、可维护的基础上。

我们接受以下几种接入路径：

雷蛇提供允许集成和再分发的正式 SDK，并以书面许可覆盖我们的开源与发行方式；
雷蛇公开稳定的 USB/HID 协议，允许第三方实现兼容后端；
社区在不接触私有源码、不复制厂商代码、不绕过技术保护的条件下，依据公开资料和独立测试完成 clean-room 协议实现；
使用 Android 标准振动或标准手柄 Rumble 能力，为雷蛇设备提供不依赖专有协议的基础兼容。

一旦具备合法协议或许可，雷蛇支持只会是我们设备抽象层中的一个新后端。音频分析、时钟同步、触觉事件建模和实时调度仍然由我们的 SDK 完成，不需要向 Nexus 黑盒让渡整条链路。

给正在等待支持的用户

我们知道大家想要的是“现在就能震”，但我们更在意它半年后还能不能用、能不能维护、能不能公开发行，以及会不会让整个项目陷入版权和许可证争议。

不直接打包雷蛇私有 .so，源于我们对授权边界和长期维护的认真判断。这条路线更难，也更强：触觉算法、时间同步、实时调度和设备适配都掌握在自己手中，最终形成真正开放的基础设施。

我们欢迎雷蛇提供正式协议或授权，也欢迎社区贡献合法来源的设备信息和测试结果。但在授权边界明确之前，我们不会分发私有二进制，不会复制闭源实现，也不会拿项目和用户承担本应由厂商解决的法律风险。

感谢所有用户的耐心。雷蛇手柄仍在我们的支持计划中，我们会用经得起长期维护和公开发行的方式完成它。