怎么说呢，从前我一直觉得风后很有道理，毕竟后端就是快，无脑快
在优化NpcScan的时候……我终于意识到了什么。
已知大概有7000个class要传，传过来之后要实例化几万个字符串
后端的确快，但后端快的代价是前端卡顿。
曾经风后说，“前端就应该异步啊，写成同步不符合编码规范”
emmm，几万个需要更新的字符串（物品，可能不止几万），要不然异步加载，每帧加载若干个，花费好几秒钟加载完成，在此期间需要冻结NpcScan的一切功能，否则前端逻辑会不准确（比如搜不到汗血宝马的原因是汗血宝马没有更新）
要不然卡顿几十到几百毫秒（视优化等级而定，原NpcScan几百ms，现在几十ms）等待所有数据更新完毕
要不然后端执行一切运算但是翻页时候需要从后端重传全部翻页数据……于是一次长卡顿变成每次翻页的短卡顿。
当然，理论上有万能解法避免上述一切缺点，但万能解法有一个后遗症，就是，程序员花费在编写万能解法上的时间，严格大于，其他所有人能因万能解法节省的时间的和。
不得不说风后的用心真的良苦……毕竟，风后的后端，的确快到亲🐴上天
但是，这里的快是以前端变卡为代价的。
就比如，打开所有界面，只要界面的人一多，就会卡。
卡的道理非常简单：
前后端的分离增加了开销。
你永远需要做一个，我在NpcScan中遇到的三选一
而本来你根本不需要选。
没有后端，最差最差的编程习惯，也能保证200ms刷新出50个NpcScan条目
加上后端，会变快多少，我不知道
我只知道，序列化与反序列化加起来基本上需要1秒。

怪不得风后吹他的后端写得没有问题，原来他把所有程序要处理的压力都丢给前段，根本没有考虑整体延迟问题。在他自己意识到这个前后分裂框架卡顿延迟问题后，自己也没有办法解决然后就跑路了是吧

🐴

只能说🍆识人不明了

说白了就是没自知之明的废物。

旧日本陆海矛盾是吧

记得很久很久以前，风后解释过为什么上前后端的原因
“Mono对多线程的支持不好”
emmm这个我也发现了，NpcScan中Aux-Model.CS的第63行有一个完美的吐槽
风后表示，Mono在new object的时候有全局锁，这完美地阻止了程序的并行
这点真是我的知识盲区，毕竟我是真的不知道编译型语言可以差到这种程度
然而，后端的计算部分并不会牵扯过多new object的动作，反而是反序列化的时候，需要new一大堆东西。
也就是说后端其实加速了一个寂寞。该卡的地方，并不会因为跑到后端就不卡了。卡顿只会因为对应数据的缺失而加剧。
理论上，前后端分离是一种非常优秀的设计模式
毕竟玩网游的时候，如果前后端必须黏在一起……那么网吧的生意或许会因此红火不少。
但……前后端分离的时候，玩家有可能接触到的所有的数据，都应该尽量在前端有备份
不然？
不妨想象一下，LOL切换地图的时候，需要等数据包跑一个来回，才能看见地图上有没有野怪，有没有人
不妨想象一下，CS
中门对狙
时，需要等数据包跑一个来回，才能一个幽灵凭空刷新在你面前
不妨想象一下，炉石传说，卡牌结算到一半忽然卡住，原因是后续结算结果没过来
……
如果数据都放在后端，游戏外挂会少很多很多
所以，你聪明的，猜猜看
为什么网游外挂如此流行呢？

不管谁对，🍆都得站还在岗位的上的人那一边。这是职场的基本逻辑。

后排update
几万个字符串是第一版NpcScan
我已经优化过了
但还是慢
毕竟反序列化的开销不小（目前还是Json反序列化，手写二进制反序列化实在太恶心了）

所以说不如全丢内存里

单机游戏做前后端分离得不偿失吧

这类需求，我不信其他场景没有。自己空想出一个方案，来处理复杂问题，是极不靠谱极不负责的。

这个类似于一个窗口排了好长的队，而且吃饭的地方只有一张桌子

可不可以这样优化一下，不换地图，所有对象先放内存里，换地图的时候再统一序列化

我焯，这下真的是游戏养成游戏了哈哈哈，这里是一枚应届毕业的php和java程序员，收藏了，坐等大佬们给思路。我这边抱着薯片看大佬们如何对屎山斗法