大多数人应该是cocos原来的使用习惯，都是使用同步加载的，思维也都是同步加载，
突然用异步，一是不习惯，二是思维转变不过来，甚至都没用过异步，都不知道怎么处理
加上异步不能实时展示出来，还要配合各种回调，写起来有点费劲 。。。
纯属我个人看法。。。
我也希望加入同步接口
同步性能影响大。
加一个loadResSync 就行了嘛。
请问原生加载图片是调用引擎的异步接口吗？addImageSync
用 ts 可以等待异步，和同步效果一样
杀千刀的异步加载，卡我两天了。封装了一个animation类，return 封装好的各类动画，就因为异步的事 各种回调恶魔一样的体验！！！！
真是极为傻X的设计，用creator到现在还没觉得怎么样，也不想吐槽，就这个设计实在太傻了
个人认为这点对新人真的不友好。引擎组貌似总觉得这点完全没问题。。。其实稍微给点提示就行了啊。。
跟楼上说的一样，可以用ts解决，不熟悉ts也没关系，把需要用到同步的js脚本文件后缀改成ts，然后里边就可以使用es7的语法了，async await来搞同步异步。
不知道为什么引擎组从来不认为资源不能同步加载没有问题？node.js也会一起提供同步的方法啊，目前还是做native开发的居多，异步加载除了写着很麻烦没发现有什么好处。为什么资源加载就不能提供同步方法呢？在native上本身资源都是本地的。
本地就真的不要时间了 ?或许吧 至少异步加载没问题
只是看怎么 让代码更方便
写一个 比较公用的类 或者 方法啥的可以考虑
可以参考node代码，异步方法都会同时提供一个同步方法。
异步加载的确写起来不太友好,比如我写一个逻辑,本来同步的话,先判断这个预制资源是否加载了,没加载的话,我从资源里加载一下,有的话就直接赋值数据, 问题来了,如果是异步的,我一个方法写起来就得 if else 里写两段相同的代码,不好看,就得再搞个方法,等异步加载之后调用. 大家可能都是把预制资源关联到节点上,不需要这么搞,但是如果我懒加载预制资源,把预制资源放到 resorce里的话 就经常会遇到这个问题. 再者就是异步加载需要上层自己加逻辑,不然异步加载可能会逻辑问题,造成一些不想看到的bug
1赞
我有这样一个问题 webSocket 建立连接 拿到数据需要驱使view去更新 这个万恶的异步 让我无法确定当我收到网络回调时 我是否已经初始化好view 如果服务器先后来了两条消息 一条创建一个view 一条对这个view做更新 有可能第二条消息来时 view还未初始化好
如果能像白鹭一样 有个资源加载组就好了 一方面我可以预加载资源组 另一方面使用的时候同步创建 可以保证我收到第二条消息的时候 view已经初始化完成
@446413497
网络消息更新的是客户端数据, 视图异步加载资源后, 把数据更新到显示, 并且监听数据的变化事件.
网络消息再次更新本地数据, 数据发出变化事件, 视图更新显示.
这不是基本的MVC么?
IO一般都推荐使用多线程异步的, 不然会卡UI线程的.
怎么说呢 总之已经放弃使用异步了 目前使用的是loadResdir加getRes的方式 基本实现了分模块和同步加载 哎，我们的框架就是这种基本的mvc。。 就不能加载资源异步 UI线程同步么 学学别人egret
每次写一个精灵 然后做个移动要到回调里面去写 别人要依赖一下他嘛 还要判断是否存在 是否已经初始化成功 感觉非常不好用 难道是我打开姿势不对？
关键是 我加载了一次 再加载还是异步的
都是这样的
你可以加载完成这后，用一个变量保存资源的引用，下次用的时候就不用重新加载了
cocos不是已经实现了ES6的 async await吗。这不就等于同步加载了么
同感，连个同步接口都没有，回调里回调回调回调，我要吐血了