【游戏客户端】如何高效地和服务端交互“领奖信息”

【游戏客户端】如何高效地和服务端交互“领奖信息”

      Hallo大家好~~我是Lampard猿奋，今天在做需求的时候学习到了一种如何高效地交互获奖信息的方法，在这里分享给大家~

在讲高效方法之前，我之前一般是分以下两种方法去向服务端获取领奖信息的：

（1）定义常量发状态数组

    比如1代表为解锁，2代表可领奖，3代表已领奖

RewardType = {
    Lock = 1,
    Get = 2,
    Finish = 3
}

     那么假如有5个奖励，就可以让服务端发一个领奖状态数组，如{3，3，3，2，1}，就代表前三个奖励已经领奖，第4个现在可领，第5个未达成条件

（2）只发已经领奖的信息

      如果把整个数组都下发的话，对于奖励数量多的地方还是会产生消耗，所以如果客户端可以自己读表判断是否已经达到领奖条件，则可以优化为只下发已经领奖的信息

-- Score = 1000
-- 读表获取【1】的条件为100
          【2】的条件为300
          【3】的条件为600
          【4】的条件为1000
          【5】的条件为1500

      比如现在得分1000，读表我们获取了不同奖励对应的分数要求，那么此时服务端只需要下发已经领奖的奖励Id{1,2,3}，就可以实现我们案例一的功能，这个例子只是少发两个数据，但是如果有100个奖励的话，则可以少发97个数据

（3）位操作

      大家注意了，这个操作真的是闪瞎我的dog眼，太6了！！！

      因为我们客户端和服务端进行交互，数据是需要通过协议转换的，我们的表是需要pack成字符串然后再unpack转换成本地的表的，这样子明显需要成本。

      那有没有不用转换的方式呢？有！那就是不发引用类型，直接发数据，下面通过位操作就可以告知双端当前的领奖情况！！

还是上面的例子，前三个已领奖，第四第五未领奖
那我们是可以发：bit.lshift(1) + bit.lshift(2) + bit.lshift(3) = 
二进制的1 + 10 + 100 = 
十进制的1 + 2 + 4 = 
7

      服务端这样下发之后，我们只需要对位进行“与”操作，获知二进制位是否为1，就可以每一项的奖励是否已经获得，那就和我们（二）的效果一样了，大大节省了成本

（四）结语

      今天就分享那么多啦，如果对你有帮助点赞关注走起哟~~