3.1 修复了一个类似的问题,这个确实太不应该了。。。
3.1.1 之后我们还加了一个检查上次临时记录的版本,如果和打开的不一致,会提示是否还原。
之后我们还会增加资源备份等功能。
sorry,这次我们单独的模块测试都是用 5w 以上文件进行的了。
3.3 会提升文件扫描、文件展示以及节点展示等性能。
可能没办法一次达到非常好,不过肯定会比之前的版本好,我们会持续的进行优化的。如果发现项目内有某种特殊的文件比较多、或者是某种情况下会卡顿,都可能给我们提,说下项目大概的情况,我们会努力的~
非常感谢大家的支持。
棒棒哒~~~
用了一年多的creator,个人感觉creator不适合中大型游戏。
如果你想用creator来开始一个中大型项目,请谨慎入坑。
目前遇到的主要问题有:
- 资源多了,编辑器卡。动不动就卡死。
- 资源多了,发布的时候IDE崩溃。
- 发布特别慢,每次都是全量发布。
- 想把资源放外部,手动修改发布流程,不开源,太费劲。
- 富文本在真机性能特别,特别,特别差。
- 真机情况,加载资源耗时久,本身v8不支持多线程,加载文件可能是多线程,但是处理加载后的数据,是在js里面处理的,会占用主线程的时间,当文件大,json大等等,会导致耗时久导致卡顿。
特别希望官方能把资源发布的流程开源出来,可以定制,自己实现增量的资源发布,减少发布时候的痛苦。如果不用bundle来管理资源,全部外部加载,管理起来又是一个麻烦的事情。
印象特别深刻,个人不喜欢用bundle,我看到某些大佬各种吹bundle动态加载资源,沃日,真是服这种把简单搞复杂的思维,bundle根本不适合大型项目管理,管理起来痛苦的一B,我提倡是某些不得不用bundle的地方才用,比如特别占内存的资源,否则一律都才用bundle,维护起来有的你蛋疼
我刚搞了 5.5w 张 png,总资源 57232 个
在 3.2 上从编辑器外直接点 assets 上某个资源(模拟回到编辑器的操作),inspector 大概 1m13s 才拿到数据正确渲染。扫描所有文件耗时 1m13s。
在 3.3 正在开发的版本上,同样操作,第一次操作没有延迟直接响应,立即点别的资源的话大概 8s 后正确渲染出来。扫描所有文件 40s。
之后我们还会继续优化支持更大的项目(我这是 13年的 macbook pro、固态硬盘,都是很小的图)~最终发布的时候可能会下降一些,但是体验大幅上升是肯定的。
但没有重现你们说的打开 prefab 卡顿,能提供一些详细的描述么?比如 “一打开编辑器是不卡的,越用越卡、项目里的某种资源比较多、当修改脚本后回到编辑器发现会卡的很久” 类似这种信息~能不能帮忙留意一下。
经常听人家说“开发引擎的人不拿自己开发的引擎开发游戏”,现在懂了没。。。
呵呵,引擎组还在那里扯,卡在那里自己都不知道,5万文件是个鬼了。编辑器卡在json文件的遍历,当spien等动画的json多了时,就会很卡。你特么放5万个图片有毛线用,5万个.mate才多大。
17年因为这个事情跟你们扯了半天,这都什么时候了,真想爆粗口,丫的
是真的卡 有时候卡得脾气都不好了
终于~有人说出了我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,我让麒麟子联系帖子里吐槽比较多的几位开发者了,如果有必要的话你直接上门拜访去看看什么情况,现场解决一下吧。咱们公司里虽然有不少内容开发团队了,但感觉很难重现人家那种大型项目的环境。编辑器卡顿这事已经被社区不停抱怨非常久了。
好的,我们会努力解决大家的问题的