同步的方法有啊，只是不是像unity一样，一个api解决而已。
如果creator和unity一样，都以原生为主，那为什么不直接用unity呢？
creator目前最大的优势就是”多端统一”，你别管这个口号实现的怎么样。
假设creator现在提供了，那么现在creator的大部分开发者都会用这个接口，那么出现
调试没问题、原生没问题，小游戏和web端非常卡，然后主战场还是小游戏，那么大部分人会反馈有问题。
而现在当前这种方案的结果，就是creator都发展到3.8.5了，反馈这个问题的寥寥无几。
你猜官方选哪种方案。
1赞
可不是寥寥无几，而是反馈了很多次 官方都不带搭理你的 然后大家也就不在提了
谁还提啊？都知道结果了 还提什么提啊
归根结底嘛，就是官方人手不够。
如果够，搞两套api，然后提示这套api主要用于原生。
在两者不能同时兼容的情况下，要两者相比取相对值~
同步获取，这个在web及大部分小游戏下都不可行。
为什么不兼容两者，看楼上。
官方不回应可能是官方觉得这个有用，但有替代方案，所以优先级降低
如果有同步接口,你会看到99%的人都会用它
其实就是这个问题，一般来说引擎可以提供同步的，不过在项目里面，肯定要把这个同步接口屏蔽掉。因为程序都比较懒，造成同步大量使用，导致最终的产品比较卡。产品的性能表现还是比开发效率优先级高的，宁愿程序苦一点，也要产品表现好一点。
不过话说回来，关于资源操作，有的接口还真的比较适合同步，例如exist,status这些查询状态的接口，用在if里面的，异步会比较难用。我看微信小游戏sdk连status这样的接口都提供了异步的，那是有点过了。
主要是需要个确定性的回复嘛。要么直接说creator完全不会加，直接死心了；要么说人手不够，放到计划列表里面，后续再加；
现在在论坛看到都是，你们开发者不需要这个功能，不需要加（也不报什么期望了）。
问就是await/async写法不香吗？
技能解决不了，采取别的方法，比如 1先加载资源，到时候直接使用 2 虚拟列表，超长的列表，滚动刷新的时候，可能前面还在加载图片1，滚动后，id变了，需要加载图片2。网络问题，可能导致先加载完图片2，后加载图片1，结果就是列表显示错乱。可以在加载完资源后，再将图片名字和id对比一次，如果对得上就使用，对不上就不使用。 做游戏和做app一个很大的区别，就是app技术很重要，做游戏技术真不是非常重要