仓库地址： 77dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6A6j5$3I4G2N6h3c8*7j5g2)9J5c8Y4t1I4M7Y4m8U0

有些能力，不好抠出纯算或者是抠不了纯算，也有些逆向成本不如直接hook来的实在，比如 iOS 的 DeviceCheck / App Attest，比如 App 内部的加密签名，比如某些必须在真机、特定环境、特定 SDK 里才肯正常工作的能力。
这类函数如果硬搬到后端，在我看来非常困难，成本代价极高。

所以我做了一个项目，叫 r1rpc。

它的思路很直接：

调用方照常发一个普通 HTTP 请求。
服务端收到后，不是自己算，而是把请求转发给在线真机。
真机上的常驻客户端执行指定能力，再把结果同步回传给服务端。
最后，调用方拿到的仍然是一个标准的 HTTP 响应。

一句话概括就是：

把只能在真机或特定环境里跑的函数，封装成一个 HTTP 接口。

在很多真实场景里，后端并不是“想算什么都能算”。

有些逻辑必须依赖设备状态：

• iOS 真机环境
• 设备硬件信息
• App 内部运行上下文
• 反调试、反篡改、签名校验
• 某些只能在本地 SDK 或受限环境里完成的动作

你可以把这些能力理解成“设备侧函数”。

r1rpc 做的事，就是把这些设备侧函数，变成一个统一的 HTTP 能力层。

它怎么工作的

整体链路是这样的：

1. 你的后端发起 HTTP 请求
2. r1rpc Server 接到请求
3. Server 根据分组和在线状态，选择一台可用设备
4. Server 通过 WebSocket 把任务下发给客户端
5. 真机客户端执行具体动作
6. 结果再通过 WebSocket 返回
7. Server 把结果同步回 HTTP 调用方

也就是说：

HTTP 负责入口和出口，WebSocket 负责设备侧通信，真机负责执行。

这样设计的好处很明显：

• 调用方完全不用关心设备在哪
• 服务端可以统一做路由、鉴权、审计
• 客户端只需要实现自己的能力集合
• 多台设备可以做分组和负载均衡

项目特点

1. 同步 HTTP 体验，底层却是设备执行

对上层调用者来说，r1rpc 还是一个普通接口。
你发请求，等结果，拿响应。
中间到底是不是远端真机在干活，不影响使用方式。

1. 真机常驻客户端

设备不是临时连一下就完了，而是作为在线节点常驻接入。
这意味着：

• 可以多设备做负载均衡
• 可以持续接收任务
• 可以保持能力在线
• 可以做分组
• 可以做任务分发

1. 能力自动发现

设备连上之后，会把自己支持的 actions 报给服务端。
这样管理端能自动看到设备到底能做什么，不用你手工维护一堆路由表。

1. 分组路由

当多台设备属于同一组时，r1rpc 可以在组内做轮询和调度。
这对高可用、并发和容量扩展都很有帮助。

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。