终于~有人说出了我2年的心声，不过毕竟是别人的地，还是以礼相待吧，在转unity，表示丝般顺滑，哥们一起啊
赶紧撤。我们手Q和微信有很头部的产品，实话告诉你小游戏的体量太小了，H5的市场太小了不值得。 这帮逼从builder、 studio 、 2dx到，creator，creator3d没有一个能持续做下去的…，开发者基本就浮游在上面陪他们玩，不等你沉下去，又弄一套新的…
这不是重构不重构包袱不包袱的问题，你看看他们做的anysdk、analytics、以及让我彻底对这个团队失去希望的小秘书…都TM一个尿性，没有一个会深耕并做好的。
以前确实很卡的，很抱歉给大家不好的体验。但是大家对上面的测试数据可能有一些误解。
3.2 包括 3.2 以前，上面的测试其实是卡顿的，比如 inspector 1m13s 才刷出来。
3.3 我们进行了优化，正在紧锣密鼓的开发中。5.5w 资源，其实说的是 3.3。大家的声音我们听得到，会努力的完善，支持更大的项目。
如果有某种情况，我们没有照顾到，可以把稍微详细一些的信息告诉我们，比如项目内 spine json 数量大概是多少，大部分是多大的资源。是什么操作卡顿，平常点击资源，还是操作场景。
这样有助于我们再后续版本针对问题进行优化。
感谢大家
HI，各位。 所有编辑器卡顿，或者对3.x感到不适的朋友
加我微信 18081177883 （麒麟子）
我了解情况后，协调引擎组上门来分析具体情况。
希望大家支持。
这个态度… 我只能说你们很棒。但是这个卡顿时间我是预感不到有什么彻底的方法， Electron用来做个小的东西还可以。你们上层的某些X缺的行为，请你们勇敢制止。
3.3大概什么时候放出来
我觉得不是 Electron的问题，比如基于electron开发的vscode不算小东西吧
electron 确实比纯原生化慢不少。
不过这个锅不是 electron 的，应该是 nodejs 的。
我们找到的问题其实是在资源管理上，nodejs 对磁盘 io 操作度比较低，各个系统上各种的磁盘格式出现的事件、文件信息都不太好控制，我们后续会针对资源系统逐步的进行替换，升级。目标是支持更大的项目。
SJ，我让麒麟子联系帖子里吐槽比较多的几位开发者了，如果有必要的话你直接上门拜访去看看什么情况，现场解决一下吧。咱们公司里虽然有不少内容开发团队了，但感觉很难重现人家那种大型项目的环境。编辑器卡顿这事已经被社区不停抱怨非常久了。
好的，我们会努力解决大家的问题的
应该不是io，或者不仅仅是，有个现象我很早之前已经反复强调了，他们没认真分析过。看你分析的这么认真，有必要给你提示一下，就是同样数量的spine，我如果用json格式，就非常卡，如果全部替换为2进制，就一切正常了。 Electron我这也只是来做一些轻量的工具，你们编辑器也无法了解，只能通过引擎那边猜测编辑器可能是怎么做的。 感觉目前最有效的方法就是可以手动设置哪些目录不去检测刷新，除了代码和预设，动画、特效文件很少变动。我之前的做法是把所有动画从工程里独立了出去。
老铁，加我微信，谢谢。 我这边安排
我喜欢最后一句话
感谢，我搞点儿 json 的 spine 试试看。
讲道理的话，资源内容只会在第一次导入的时候进行解析。
后续运行的时候，其实只是一个 uuid 索引，具体内容固化到 library 里了，除非下次被修改，导致重新导入，不然资源内容其实不会有影响。
还是需要根据线索确认一下看看，也许有部分情况遗漏了。感谢提供这些线索吖
17 年的 Spine 性能问题，我还真没印象…… 可能当时我由于工作交接的原因没有再进一步跟进，非常抱歉。
3.3 解决的卡顿主要是资源扫描层面的，类似 Creator 2.4.6，论坛反馈的编辑器性能问题主要集中在大型项目的扫描，扫描速度慢会影响编辑器的切换。这个跟资源数量关系大，跟具体资源是什么类型无关。
Spine 导致的卡顿，我们这边应该是第一次遇到，后续会持续跟进，感谢反馈。
通通得上，多线程，数据缓存，搜索剪枝…
正常习惯就好了
玩了3D版本小半年，之前两根8G内存条 运行编辑器突然飙升到8,90%多，直接干报废一根。
现在升级 16G *2 ，我看能不能顶得住
勇士，加油