掘友等级
获得徽章 0
#每天一个知识点#
2023/07/06
说说资源加载这个大头，之前我们的游戏，一打开就会非常卡，会卡上好几帧，这样的用户体验是非常不好的，当时排查问题，这是问什么呢？是因为我们一打开游戏就有数百个节点开始实例，读取资源，IO是一个非常耗时的操作，尤其是没有对这一块的加载做处理，这些加载都在同一时刻加载，导致IO堵塞，就会卡。
后面这一快的改动是，所有资源都是改为队列的方式加载，这就避免了一帧内过多的读取导致堵塞，同时我们在进入游戏的loading阶段就先做打开游戏就需要的资源的预加载，相当于是把一部分资源加载放到加载界面，进一步减卡顿的问题。
#每天一个知识点#
2023/07/05
事件总线
事件总线也叫EventBus，其实表现的方式都很多，但是基本来说都是一个思路和实现，优点和弊端也是一样的。
优点是什么呢？那就是能够很便捷的跨文件（组件）传递数据，缺点也是因为这种能够全局飞数据的方式带来的不好维护。
具体是怎么实现的呢？简单来说事件总线其实是发布 - 订阅者模式的一种实现。定义了一对多或者多对多，当发布者发布事件的时候，所有订阅者都能够得到响应，进行各自对应的操作。
比如在游戏中，我们监听数据接口，当有数据来的时候，我们可以对绑定该监听的所有视图进行数据更新。
在使用事件总线的时候，还需要注意的是取消注册，当我们离开，或者不再使用的时候，需要把之前注册的事件移除，避免错误的响应
#每天一个知识点#
有限状态机
首先说概念吧，有限状态机也就是 Finite-state machine, 英文简称FSM，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
也就是当我们能够确定一个东西的所有状态的时候，我们列举出所有状态，通过不同的条件，进行不同的动作，达成最后的状态。这其中三点关键就是条件，动作，状态。
其实实际上面对这些转态转换的也就是我们常使用的 if- else ，但是使用 if- else 在一些更复杂的场景下，可读性，扩展性都不够，并且容易出错。而使用 fsm 能够对我们状态和事件统一管理。我们也可以通过画图来把转态转移画出来，这样就能更加清晰的编码状态机了。特别是在游戏中，状态的变化也是常态。
#每天一个知识点#
2023/07/03
我们写代码功能的时候回，要尽量事件是事件，实现是实现，建议区分开来，比如一个点击节点显示弹板的功能，这里应该分为点击触发的事件函数，和显示弹板的实现函数。因为不分开处理，不便于后续开发（哪天策划想要不同的时候点击显示不同的内容呢~，以及一般我们显示弹板，还会有比如三秒后自动消失/点击空白处消失/某种情况下不能出现/消失之类的情况，区分事件和实现会便于我们后续开发）
#每天一个知识点#
2023/07/02
简单说说依赖注入吧，依赖注入其实是实现控制反转的一种设计方法，消除类之间依赖关系的设计模式。比如A类要依赖B类，A类不再直接创建B类，而是传入给A。举个例子来说就是，工厂伐木，每个员工的斧头，是员工自带的，还是工厂给的。使用依赖注入的话，我们可以是实现松耦合，如果工厂现在突然急需要完成任务，改用电锯，那么改通知每一个员工带电锯，这实现起来可能就很多问题了，但是如果工厂提供的，那么相当于对于员工来说，只是接收到的该工具不同。这也就是依赖注入，实现松耦合的目的了
#每天一个知识点#
2023/07/01
说说控制类吧，之前做web开发，其实基本不需要写控制类，因为web开发，大多就是服务器拿数据，然后进行即时刷新。但是在游戏开发中，往往是分过程的，我们得存起数据，以及对数据的一些处理之类的。那么比如一个活动中的控制类就得有构造函数和析构函数，构造函数中我们需要对数据做初始化的处理，确保即使后端给我们的数据有问题，也是能够不报错运行的。同时我们的控制类中一般得使用单例模式，来确保控制类是唯一的。当然控制类里面的东西还不止这点，根据你活动的复杂度之类的，考虑资源的加载，等各种条件。
#每天一个知识点#
2023/06/30
我们在使用缓动的时候要小心，当我们在一个节点绑定缓动，如果关闭了该节点（action 置为 false）然后再打开，这时候上面挂载的缓动就会被清除掉了，如果我们需要能够再次执行，我们可以在 onEnable 里面重新打开
#挑战每日一条沸点#
2023/06/29
野指针问题，这算是个比较隐蔽的问题，还不好发现。当时的场景就是想在缓动中设置缩放，先放大，然后再缩小，结果最后看到的比原本的小，这就很奇怪。后面很久才发现，当时设置缓动中变化的值是个指针地址，这就导致每次变化并不是想象中放大的倍数，而是变化后的值继续乘以变化目标值。
#每天一个知识点#
2023/06/28
游戏中开发要切实注意的三个地方，一个是网络，二来是读取资源，三来是多节点处理。
这三个地方主要的问题是基本是异步的行为，不可控，很多时候我们没法确保信息是否回来了，资源是否加载好了，而不考虑这些因素很容易造成卡顿的现象，或者错误。比方说我们如果没有用异步其读取资源，加载资源是一个高IO的操作，这就会到导致一帧内无法执行完毕，导致看起来卡顿的感觉。
#每天一个知识点#
2023/06/27
分享个思路吧，今天做的业务中，发现需要处理很多种类的奖励领取，这里不同的奖励领取，流程和事件都是不确定的，并且他们没有各自的回调。这就导致没发知道这个领取是否完成结束了，来通知我走后面的步骤。当时起初的想法是有使用一个队列来维护，并且轮帧的去询问。但其实感觉这么写挺麻烦的。想有没有更加简单的，后面想到的是，在引擎垃圾回收和资源引用的地方常常是使用计数器来判断是否释放。这种计数器的思想就挺适合当前的情况的，当开始领取的地方打上加一，结束的地方减一，那么无论多少个什么种类的领取，我们只需要判断当前计数器是否为 0 ，是的话就执行下面的步骤，不是就继续等待。
