【鸿蒙优选三方库】@ohos/grpc：像调本地方法一样调远程服务> REST 轮询延迟高又费流量，WebSocket 能推送却没有类型契约、字段对不上全靠口头约定。@ohos/grpc 基于 HTTP/2 + Protobuf：四种流式 RPC 模式原生支持，.proto 文件即接口契约，编译期就能发现字段错误。> 📦 仓库地址 ｜ ohpm install @ohos/grpc ｜ v1.0.15 ｜ Apache-2.0—## 它解决什么问题需要和服务端高频通信的场景——实时行情、在线问诊、协同编辑、IoT 数据上报——用 REST 轮询总差口气：延迟最高一个轮询周期，流量浪费在重复请求上，长连接还得自己管。gRPC 是云原生时代的事实标准：HTTP/2 多路复用、Protobuf 二进制传输、四种流式模式。但它是 C/Go/Python 生态的东西，要在 ArkTS 里跑，得自己实现 HTTP/2 客户端栈、做 NAPI 桥接、处理流控。@ohos/grpc 分三层把这些封装好了：gRPC 客户端层（ArkTS） ← 四种 RPC 模式、credentials、MetadataHTTP/2 协议层（ArkTS） ← Session / Stream / 事件驱动Native 层（C++） ← nghttp2 + OpenSSL，通过 NAPI 上抛—## 核心能力| 能力 | 说明 ||------|------|| Unary RPC | 一问一答，等价于普通请求 || Server Streaming | 一次请求，服务端持续推 || Client Streaming | 客户端持续发，服务端最后响应 || Bidi Streaming | 双向同时收发 || HTTP/2 多路复用 | 单连接并发多请求 || Protobuf 契约 | 依赖 @ohos/protobufjs || 凭证与元数据 | credentials / Metadata / CallOptions |四种流模式的意义：聊天用双向流、行情推送用服务端流、日志上传用客户端流、普通查询用 Unary。REST 里这些都要各自造轮子。—## 30 秒上手bashohpm install @ohos/grpc安装后需把仓库的 protobufjs/index.d.ts 替换到 oh_modules/.ohpm/@ohos+protobufjs@2.1.0/oh_modules/@ohos/protobufjs/src/main/ets/index.d.ts，否则类型定义不全。Unary 调用：typescriptimport { grpc } from '@ohos/grpc'const client = new grpc.Client('https://grpc.example.com', { credentials: grpc.credentials.createInsecure(),})client.makeUnaryRequest( '/helloworld.Greeter/SayHello', (req) => req.serializeBinary(), (buf) => Reply.deserializeBinary(buf), Request.encode({ name: 'HarmonyOS' }).finish(), (err, res) => err ? console.error(err) : console.info(res.getMessage()),)双向流：typescriptconst call = client.makeBidiStreamRequest('/chat.Chat/Connect', ser, deser, metadata)call.on('data', (msg) => console.info('收到: ' + msg.getText()))call.on('end', () => console.info('流结束'))call.on('error', (err) => console.error(err))call.write(Message.encode({ text: '你好' }).finish()) // 随时发—## 社区已解决的典型问题并发请求导致闪退（#99 / #100 / #101）多个 gRPC 请求并发发起时崩溃，是反馈最集中的问题。已修复，并在 #102 提供了 pooled Unary 并发压测复现用例与 Demo。**上线前建议直接拿这个 Demo 压一轮。**池化模式下流数据发不连续（#95）启用连接池后，流式 RPC 的数据无法连续发送。已修复。流式 + 连接池的组合要重点测。内存泄漏（#97）更新测试 Demo 并优化了内存泄漏。长时间运行的流式连接（比如持续接收行情）要关注内存趋势。流结束的 END 数据处理（#94 / #96）补充了流式数据 END 验证 Demo 和监听事件维测 Demo。流关闭时要正确释放资源，否则连接会泄漏。—## 适合谁用- 实时行情 / 在线问诊 / 协同编辑：需要持续双向通信- IoT 网关：设备数据流式上报 + 指令下发- 服务端是 Go/Java/Python：标准 gRPC 直接对接，不用为鸿蒙单独开 REST 接口- 对延迟和流量敏感：HTTP/2 + Protobuf 比 HTTP/1.1 + JSON 常有数量级提升- 需要强类型契约：.proto 一改，两端编译期就报错93 个 Issue 已关闭，并发稳定性是社区打磨的重点。做生产级实时通信前，把 #102 的压测 Demo 跑一遍。