Posts

前两篇文章更偏“怎么用”：

• 《用 ULinkRPC 从零搭一个 Unity 和 .NET 双向通信项目》

但如果你准备把 ULinkRPC 真正放进项目里，通常会继续问这几个问题：

• 它为什么要强依赖“共享契约 + 代码生成”？
• 它和“手写消息号 + switch 分发”相比，本质差别是什么？
• 双向通信到底是怎么落到一条连接上的？
• Transport、Serializer、Runtime、CodeGen 之间是怎么解耦的？
• 服务端 callback、客户端 push、请求响应、保活、压缩、加密，这些东西分别在哪一层？

这篇文章不再讲环境搭建，只讲设计本身：它为什么这样分层，为什么一定要 codegen，双向通信到底是怎么落到一条连接上的。

先给一句总纲：ULinkRPC 其实是“契约驱动 + 代码生成 + 帧级运行时”的组合

先记住一句话就够了：你写的是契约，生成器把契约翻译成胶水代码，运行时再把胶水代码变成真实网络收发。

如果拆开看，它大致是三层：

1. 契约层：只描述“谁可以调用谁”

这一层只关心共享接口和 DTO：

• [RpcService] 标记服务接口
• [RpcMethod] 标记客户端可调用的方法
• [RpcCallback] 标记服务对应的回调接口
• [RpcPush] 标记服务端主动推送的方法

这一层只定义“能调什么、能推什么”，不处理网络细节。

2. 生成层：把契约翻译成“可运行的胶水代码”

这一层由 ULinkRPC.CodeGen 负责。它会读取 contracts 源码，然后分别生成：

• 客户端 service proxy
• 客户端 callback binder
• 客户端统一入口 RpcApi
• 服务端 binder
• 服务端 callback proxy
• 服务端 AllServicesBinder

生成层的职责，就是把“接口定义”翻译成“可发包、可收包、可分发”的代码。

如果你现在想开始一个新的 ULinkRPC 项目，最直接的方式已经不是手工搭目录、手工建 Shared、手工跑 codegen，而是直接用 ULinkRPC.Starter。

它会一次性帮你生成：

• Shared 共享契约项目
• Server 服务端项目和解决方案
• Client Unity 2022 客户端骨架
• 默认 Ping 契约、服务实现、Unity 测试入口和示例场景
• ULinkRPC.CodeGen 本地工具清单和两侧生成代码

也就是说，你现在的推荐起步方式是：

先选 transport 和 serializer，然后让 starter 直接产出一份可运行的最小项目。

前提条件

开始之前，请先安装 .NET 10 SDK：

• 下载地址：https://dotnet.microsoft.com/en-us/download/dotnet/10.0

后面的 dotnet tool install、dotnet tool restore、dotnet run 等命令都依赖本机已经可用的 .NET SDK。

Quick Start

如果你只想最快跑起来，直接照下面做：

1. 安装 starter
2. 生成一份 websocket + json 项目
3. 启动服务端
4. 用 Unity 打开客户端
5. 执行 NuGet -> Restore Packages
6. 进入 ConnectionTest.unity 并点击 Play

对应命令如下：

dotnet tool install -g ULinkRPC.Starter
ulinkrpc-starter --name MyGame --transport websocket --serializer json
cd MyGame
dotnet run --project Server/Server/Server.csproj

然后：