图鉴系统（总结）

最新推荐文章于 2024-08-11 22:22:51 发布

风其实不太大

最新推荐文章于 2024-08-11 22:22:51 发布

阅读量781

点赞数 20

文章标签：前端

本文链接：https://blog.csdn.net/c6ao3/article/details/139655418

版权

前言

这里是第一次单独开发一个功能之后回顾开发时遇到的问题，以及思考优化方案，对本次做的功能的一个总结。目的是总结和记录自己遇到的问题和处理方式，提高下次开发效率。

开发前遇到的问题

先把房子修好，再考虑怎么样安窗户

拿到任务没多久我就想着先构思大概应该怎么做，结果遇到了红点这个问题，一时间很多红点相关的问题就拦在我面前，然后我就在红点上看了好久，半天下来还没新建文件夹

其实这里直接做功能就好了，没必要房子地基还没搭好就想着安窗户，直接先把流程跑起来（把对应文件夹建好，数据类型想清楚），红点这种不影响流程的东西最后去单独学习单独弄也是一样的

相似不是相同，考虑分脚本编程

在正式开发的时候，因为随从图鉴和圣物图鉴的界面有很多相似的地方，就打算做在一起，写了一个HandbookDevelopUI来写两个界面的逻辑，后面做着做着发现，虽然有70%的相似，但是剩下的30%都需要分开处理，如果通过在一个脚本里面写随从和圣物的特殊处理，那写到后面可能会随着代码量的增加导致维护和修改的困难，要时刻区分两者，增加很多不必要的精力消耗。

正确的做法是应该写个基类来放70%发相同代码，剩下的分别写到两个脚本，但是本身特殊的地方不多，其他地方也不大可能复用，所以就直接把功能分开做，写两个UI界面的脚本就好了

M文件是功能的大脑

后来我就创建了两个脚本分别管理随从和圣物图鉴界面，那叫一个神清气爽，但是这个时候有个新的问题就是我没有自己的M文件，涉及的很多数据需要到处拿，导致我一开始编程的时候同时打开了十几个脚本，编程效率直线下降。

我这个时候才创建了handbook文件夹以及对应的M文件，其实拿到开发任务的时候第一时间就应该确认需要的数据类型，然后根据自己的需求添加到M文件中，因为M文件的都是缓存数据，所以在一开始就储存这些缓存数据可以避免大量的数据读取(我一开始取数据就是使用一个函数来取，这个函数被大量调用，并且里面有很多内置循环，导致了很多性能的浪费)，并且可以通过设置数据的key和value来方便自己之后读取数据以及对数据排序。之后UI界面需要的数据都可以通过在M文件里面添加函数来获取，可以说，M文件就是一个功能的大脑，记忆了该模块的所有数据

开发时遇到的问题

在分离UI脚本，创建M文件之后，接下来的开发才是步入正轨（之前全是在浪费时间）

服务器客户端对接

接下来遇到的第一个问题就是和服务器的对接问题，因为这个时候服务器已经把表给建好了，我还在想客户端如何把奖励发给玩家，后来才发现不对劲，这不应该是客户端考虑的事情。这里就是对服务器和客户端的职责还不熟悉。

服务器和客户端是两套逻辑，通过服务器给的指令和需要的参数来联系，像本次开发领取奖励的流程就是：客户端判断领取条件，开放领取按钮，点击领取按钮时会调用函数将消息发送给服务器，参数由服务器来定（可能会有返回值，但目前没有遇到）这个时候有两种情况，第一种是客户端不等服务器消息，直接创建领奖界面，第二种是服务器收到消息后直接在服务器创建领奖界面，客户端只需要做领奖按钮的状态改变显示就可以了。

服务器自己也有一套判定是否可以领取的逻辑，所以即使客户端开发了领奖按钮，但服务器那边判定不通过，依然不能领取奖励。领取完奖励之后，服务器那边会有记录，比如此次是记录在handbook_info的数据里面，一般来说，任何有关该功能的数据改变都会引起该数据的改变，所以我们可以通过监听该数据的改变做一些界面的刷新处理(涉及到M文件的事件添加)

开发中遇到的具体功能实现

剩下的问题都是一些功能上的问题，就如之前所说，做好了上面那些，相当于已经把房子修好了，接下来就是要给这个房子加门，安窗，家具的摆放等等这些事情。

具体功能实现会集中写在功能文档里面，这里仅作分析

页签功能
页签功能实际上是两个不同的界面通过一个tab的切换来创建对应界面，这样就要求这两个界面的大小必须高度一致。这里就涉及到美术的调整，严格按照美术的要求来，否则美术效果会很糟糕。
任务奖励
有一个通用的接口，这里主要是对这个接口的学习使用，接口需要接收一个bonus参数，这个bonus可以自己拼接好再使用formatReward来统一化奖励类型之后再传进去，注意，这里只是奖励的显示，实际领取的内容由服务器为准（一般来说服务器和客户端都说读的同一张表，所以不会有出入，本次功能有一个发放头像框的需求，服务器那边单独发，所以客户端也需要做对应的显示）除了bonus之外，奖励的领取状态也是重要的参数，一般会在M文件中拿到。
数据类型
虽然前面提到过了，但是鉴于这次圣物的数据类型我花的时间太多，还是单独拿出来说一下。当时为了拿到圣物的三件套类型，去对应的HeirloomM里面找了很久，找到之后觉得太麻烦，而且用的别人拿出来的，如果别人这里要改需求，那就会影响到我这里的功能，破坏了封装性，然后我就想到去遍历heirloom表，直接取想要的属性，后来发现这样子做也有很多问题，因为没有一个可以标识的属性来让我拿圣物，导致这个方法也废弃了。最后发现，别人可以拼出想要的属性来，我为什么不可以呢，我完全可以在M文件中拼出我想要的属性，然后缓存下来，就可以高效的使用了，白白浪费那么多时间
红点
终于讲到了这里，红点这个东西确实麻烦，但现在看来又不是那么麻烦，只是涉及的东西比较多，容易漏掉，不过没有关系，漏掉的发现然后解决就好了。
那么如何实现红点呢，首先将你需要刷新红点的地方单独拎出来写一个函数，每个脚本都是这样，然后在进入界面的时候调用一下这个函数，并且添加监听事件，有什么东西会导致你这个红点的变化？比如领取圣物后圣物数量会变化，那就监听heirloom这个数据，里面有圣物数量，只要圣物数量发生改变，就会触发这个监听携带的函数，从而刷新一遍红点，达到红点功能的效果
红点外传
那么问题来了，当前界面的刷新可以用上面的方法，那当前界面的红点需要传出到前一个界面这个操作应该怎么做呢。
这个分为两种情况，简单的情况就是界面A有一个通往界面B的入口，界面B里面有很多item，但这些item显示红点的规则都一样，可以通过一个函数来解决。那么界面A只需要遍历界面B的这些item，只要遇到有一个有红点，就显示红点。
复杂点的情况是像神眷界面那样，最外面的红点受到神眷界面红点的影响，但是神眷界面起码有十种以上的红点，这些红点又受到两到三种不同因素的影响，这个时候上面那种方法就完全行不通了。好在前辈们早就遇到过这些情况，直接做了一个红点的模块，这些比较复杂的界面都做了专门的处理。比如神眷界面我们只需要前往red_dot里面添加我们刷新红点需要的事件监听（这里是加入handbook_info)这样的话在该数据改变时就会刷新一下神眷界面的红点，但是红点的逻辑还是要自己去对应函数里面添加的。比如我这次是卡牌图鉴按钮的红点会传出到神眷右上角，此时就可以找到神眷右上角的按钮的红点逻辑，将我们图鉴的红点显示逻辑加上去，如果图鉴显示红点，那么这里也显示红点，这样就完成了红点的外传。也不是那么复杂嘛

开发完成后遇到的问题

这里其实就是大佬们在我提完代码后对我代码的review，提出了很多宝贵的建议，这里挑选一些重点分析，避免下次再出问题

table获取的是引用

lua中的table的赋值操作全是获取引用，这意味着使用
records = ME.user:query(“cheer_info/records”) or {};
上述这种代码要避免对records的修改，因为修改records相当于修改源数据，虽然每次重新查询的时候服务器都会下发数据，但这种操作容易出现意想不到的问题，要避免之。

查询数据的技巧

在查询服务器数据的时候我经常会使用循环来获取对应数据，但是大可不必，直接使用：
ME.user:query(“handbook_info/guard_record/” … guardId … “/” … type)；
这种方式查找更为高效简洁，没必要再写循环来查guardId和type。

少用魔鬼数字

我经常会图省事写一些return 1；的代码，但是这个1代表什么可能过不久我自己也忘了。这就是魔鬼数字。忘了还是小问题，如果后面改数据结构了，这里需要返回的不是1，是2，那我还得找到之前哪些是代表1的数据，极容易出问题。可以使用枚举，这样就算以后改数据结构了，直接改枚举里面对应的数据就好了，不用在人海里找那个1了。

排序的技巧

很多地方都要用到排序，可是有些数据拿着根本就不好排，那为什么不自己重新构建一个数据呢，里面只存放你要排序的数据。比如此时我有三个领奖状态需要排序，我只需要把这三个领奖状态按照排序规则设置为1，2，3，这样就是对这个1，2，3进行排序，直接升序排就好了，如果有其他的排序规则那也是一样，在table里面加key就好了。

及时清除缓存数据

本次功能中，使用到了缓存数据储存一开始的图鉴数据。如果不及时清除缓存，那么在切换账号重登的时候会因为M文件只加载一次，导致上个账号储存的图鉴数据污染到了下一个账号。所以应该在onStopGame()中把缓存清除掉。并且获取缓存数据时的逻辑应该是这样的：有缓存，则使用缓存，无缓存，则加载一次缓存数据。