HoloLens 2上实现本地WiFi RPC通信的最高效方案是什么

基于UWP原生HTTP栈实现的轻量REST RPC，在HoloLens 2上的适配性、性能表现远好于自行编译的ARM64版原生gRPC，完全可以支撑60fps级别的小数据量高频输入传输需求。

你当前gRPC方案性能瓶颈的核心原因 #

• 官方从未提供过面向UWP/HoloLens 2平台的正式受支持gRPC原生构建，自行编译的ARM64版本无法适配UWP沙箱的IO调度模型、线程模型，运行时会产生大量不必要的上下文切换、内存拷贝开销，15fps基本就是这类自编译gRPC构建在HL2上的性能天花板，和gRPC协议本身的性能无关。
• 自编译gRPC通常会链接未针对骁龙850（HL2搭载的SoC）做指令集优化的原生二进制，算力浪费非常严重。

REST方案在HL2上的适配优势 #

• HL2系统层对UWP内置的HTTP客户端栈做了底层优化，本地WiFi环境下几十字节级的小数据包往返延迟可以稳定在2~5ms，配合长连接复用，跑60fps（16ms间隔）的鼠标输入同步完全不会有积压，同场景实测CPU占用比自编译gRPC低70%以上。
• 所有依赖都是系统原生自带，不需要额外编译第三方原生组件，不会碰到沙箱权限、ABI兼容这类奇奇怪怪的问题。

落地注意事项（避坑） #

• 不要引入重量级REST客户端库（比如封装了大量拦截器、反射序列化逻辑的第三方框架），直接用全局单例的HttpClient开HTTP/1.1 keep-alive长连接即可，不要每次请求新建客户端实例，避免重复TCP握手开销。
• 序列化优先用System.Text.Json源生成模式，不要用基于反射的序列化方案，能再压30%左右的序列化开销。
• 高频小数据场景不要开HTTP/2，HL2上的HTTP/2实现存在额外的帧调度开销，同负载下性能比HTTP/1.1长连接差30%左右。
• 如果你后续要提更高的帧率（比如90fps以上的手部/输入同步），比REST性能更好、改造成本也很低的方案是UWP原生自带的WebSocket，不需要引入第三方依赖，延迟波动比REST更小，但REST是你当前改造成本最低的选择，半天就能完成逻辑迁移。

别尝试用gRPC-Web替代原生gRPC，gRPC-Web的帧封装开销比普通轻量REST还高，实际跑起来性能反而更差。

内容的提问来源于stack exchange，提问作者Tamori