MLAPI项目中RPC函数重写导致重复调用问题的分析与解决方案

问题背景

在Unity的MLAPI网络框架(Netcode for GameObjects)1.9.1版本中，开发者发现了一个关于RPC(远程过程调用)函数重写的异常行为。当开发者尝试在派生类中重写基类的RPC函数并使用SendTo.Everyone参数时，如果在该重写函数中调用基类的实现(base.MethodName())，会导致RPC函数被意外地执行两次。

问题现象

具体表现为：

1. 基类中定义了一个标记为[Rpc(SendTo.Everyone)]的虚方法
2. 派生类重写了这个RPC方法并在其中调用了base.MethodName()
3. 当调用该RPC方法时，方法体中的逻辑会被执行两次

技术分析

这种异常行为的发生与MLAPI框架处理RPC消息的机制有关。当使用SendTo.Everyone参数时，框架会在网络层面确保所有客户端(包括发送方)都能接收到这个RPC调用。而在继承体系中，基类和派生类的RPC方法都被注册为可调用的RPC端点，导致消息被重复处理。

更深入的技术原因在于：

1. MLAPI框架会为每个标记为RPC的方法生成消息处理端点
2. 当方法被重写时，基类和派生类的方法都被注册为独立的端点
3. 调用base.MethodName()实际上触发了另一个RPC端点
4. 由于SendTo.Everyone的作用域，这两个端点都会被执行

解决方案

官方建议的最佳实践是避免直接重写RPC方法本身，而是采用以下设计模式：

1. 在基类中定义实际的RPC方法，但不设为虚方法
2. 同时定义一个受保护的虚方法作为RPC的实际实现
3. RPC方法内部调用这个虚方法
4. 派生类只需重写这个虚方法即可

示例代码实现：

public class Test : NetworkBehaviour
{
    protected virtual void OnTestRpc()
    {
        print("基类实现");
    }

    [Rpc(SendTo.Everyone)]
    public void TestRpc()
    {
        OnTestRpc();
    }
}

public class Test2 : Test
{
    public void Run()
    {
        TestRpc();
    }

    protected override void OnTestRpc()
    {
        base.OnTestRpc(); // 正确调用基类实现
        print("派生类扩展");
    }
}

设计考量

这种设计模式有几个显著优点：

1. 解耦网络通信与业务逻辑：将网络调用与实际实现分离，提高代码的可维护性
2. 避免框架级问题：绕过了MLAPI处理虚RPC方法时的潜在问题
3. 更好的扩展性：派生类可以灵活地扩展或修改行为而不影响网络通信
4. 清晰的职责划分：RPC方法只负责网络通信，虚方法负责实际逻辑

总结

在MLAPI框架中使用RPC时，特别是在涉及继承体系的情况下，开发者应当遵循"RPC方法非虚，实际逻辑可扩展"的设计原则。这不仅能避免重复调用的问题，还能使代码结构更加清晰、可维护性更高。理解框架底层的工作原理有助于开发者设计出更健壮的网络通信代码，避免类似的陷阱。