请问在断开之前有什么错误日志吗？

我测试了一下，每 3s 修改一下房间属性，并在小米 Max 手机上运行了，并没有出现你描述的情况。
下面是我的测试代码：

// Start is called before the first frame update
    async void Start()
    {
        // 设置 SDK 日志委托
        LeanCloud.Common.Logger.LogDelegate = (level, log) => {
            if (level == LeanCloud.Common.LogLevel.Debug) {
                Debug.LogFormat("[DEBUG] {0}", log);
            } else if (level == LeanCloud.Common.LogLevel.Warn) {
                Debug.LogFormat("[WARN] {0}", log);
            } else if (level == LeanCloud.Common.LogLevel.Error) {
                Debug.LogFormat("[ERROR] {0}", log);
            }
        };

        // App Id
    var APP_ID = "xxxx";
    // App Key
    var APP_KEY = "yyyy";
    // 域名
    var playServer = "https://g2b0x6om.lc-cn-n1-shared.com";
    // 这里使用随机数作为 userId
    var random = new System.Random();
    var randId = string.Format("{0}", random.Next(10000000));

    // 初始化
    client = new Client(APP_ID, APP_KEY, randId, playServer: playServer);
    await client.Connect();
    Debug.Log("connected");
    // 根据当前时间（时，分）生成房间名称
    var now = System.DateTime.Now;
    var roomName = string.Format("{0}_{1}", now.Hour, now.Minute);
    await client.JoinOrCreateRoom(roomName);
    Debug.Log("joined room");

    StartCoroutine(ChangeProperty());
}

IEnumerator ChangeProperty() {
    int i = 0;
    while (i < 10) {
        client.Room.SetCustomProperties(new PlayObject {
            { "gold", i }
        });
        yield return new WaitForSeconds(3);
        i++;
    }
}

下图是每次更新房间属性的消息日志：

image.png3210x1832 728 KB

如果你那边还没有解决，可以提供一个可复现的 demo 工程给我。

PS：这个仓库是一直维护的。

1，现在房间是没有接口主动销毁到吗，比如我是房主，我退出就相当于解散房间

目前房间销毁策略是「房间里没有人」的情况下，由服务端销毁。客户端只能选择创建，加入，离开，并没有主动销毁的接口。

2，unity现在avobject子类化使用起来不太方便，因为一般是player用户数据，很多用户属性，每一个属性都要加标签和重复到getset，要么你们把SubclassingController.GetPropertyMappings开放自定义，要么用cecil自动注入setget代码

这部分算是存储 SDK 做的工作，我目前正在重构。
关于子类化这部分，我这边的初步考虑的方案是：只设置类名 / 构造方法，然后根据 C# 的 Getter/Setter 映射到数据表的字段，减少目前 Attribute 的使用。

这个实现的目的在于让开发者少关心一些细节，如果由开发者决定是否销毁，可能由于疏忽会导致很多资源浪费。开发者可以认为房间里没人了，这个房间便销毁了。

我理解您描述的使用方案更类似于我们之前的设计，使用 JsonObject/Dictionary 去表示复杂的类型。但是通过 key 获取 value 会导致编译期的错误不能及时发现，还会造成开发者侧代码各种类型转换，另外 json 造成的序列化开销也是很大的。
扩展一下，如果在 PlayObject 里只存放一个 string/byte[]，开发者侧拿到 Raw data 之后，可以通过各种序列化工具（json/protobuf，thrift 等）解析，是不是可以省掉「头大的序列化代码」呢？

我不是很理解你们的需求，有人的情况下，为什么要销毁房间呢？

如果方便的话，可以把方案详细的记在我们仓库的 issue 里。
感谢关注！

这个需求可以尝试我们的 Client Engine 服务，即房主运行在 LeanCloud 服务端，尽可能保证房主不掉线。
参考文档2

这个问题在这里我们不就不展开讨论了，您可以把您的方案记录在 issue 里，我们再做详细跟进分析。

我回复的子类化是指「存储 SDK」的子类化，存储功能下个月会开源发布，RTM 服务要晚一些。
Play 服务短时间不会对序列化再做什么开发。
您在这方面的问题或建议都可以提到对应的仓库里，我们共同讨论优化！
再次感谢关注！