有点高级，可以聊聊你思路中背后的机制么？如何管理？如何跟踪使用状况？用什么策略去做自动化？
内部还是引用计数的实现，加载与释放均由引擎本身实现，在用户走释放通道出现误删其他资源，这是BUG
这个思路很像 pixi 的 Texture Garbage Collector
引用计数有一个绕不过的问题，如何跟踪引用者的释放，在原生实现中，一般是在析构函数中去给引用的资源计数减一。但是 JS 不存在析构函数，这个问题有没有想法该怎么解？
用户持有分情况，组件中属性持有，这个引擎肯定有办法，临时持有不用理会，跨scene持有走特定通道
Texture GC 是轮询 texture 的使用状态，并不是完全可靠的，但是可以认为是有用并且在大多数情况下足够可靠的，我觉得是一个很简单优雅的方案，但是它仅适用于 texture，对于 prefab 等其他 asset 又需要另寻他法
这个真的没办法，即便是引擎内部的组件所持有，我们也无法得知何时这个组件被释放。当然 destroy 中是可以做引用计数的操作，但是这只是把问题上升到组件层面而已，因为不在场景中的组件是需要手动 destroy 的，在涉及到对象复用的时候，会引起很大的问题，用户的控制成本也很高。另外，依然无法解决用户自己去引用导致的问题。
我认为如果追求的是用户使用起来足够简单，那么这些控制和学习成本都不应该有，而在我们无法提供这样简单的体验之前，我们宁愿提供简单易理解，但是需要用户手动控制的方式
释放走引擎的释放通道，如果不走就残留，这样用户至少是知道是因为自己没有走释放导致泄漏
区分用户bug和引擎bug。
如果简单明确的内存管理。哪怕是用户控制成本高也是可以的，至少是属于明确可用的
多谢吐槽，关于资源释放，我在 roadmap 上加了个卡片： https://trello.com/c/tp4udibN/86-memory-auto-release-unused-assets
不论如何我们会继续完善
释放走引擎的释放通道
我不是很理解你说的这个引擎的释放通道指的是什么
加油，大家一起来想办法
就是你们提供的接口
那目前就是你说的这样，用户主动 release 的就会释放，但是用户需要确定自己真的不再需要这个资源了，如果不调用释放，那么会一直缓存
A、B都使用了贴图C，A走了释放通道，B没有，C这时应该还在，用户一看怎么C还在啊，然后看代码，原来B直接=null了，他就知道忘记走释放通道了。
现在的实现是A走了释放通道，删除了C，但是B还在使用，而且认为C这时候应该是在的，B使用的时候就出现贴图丢失，然后B得想办法把C搞出来，但是C只是B里面使用的1%（子的子的子的子使用），这样复杂度就非常高
这锅甩的！
既然你们把龙骨动画内置进去了（而不是用插件的方式）
那就应该保证其质量！(其实这个问题并不是多难， 龙骨封装的比较好，CCFactory都单独提出来实现，看下源码！
要改这个问题不需要半个小时)
我只是提出我的想法！
用户用到你们的东西(大多是入门级)
这种入门级出现问题了，给他们的印象就是creator很坑！到处都是坑！
我只是希望Creator给别个的感受就是高质量的产品！
这部分应该是可以改善的，谢谢建议
坦白说，现在使用creator做商业项目的都是看中creator的未来，但在这个时间点甚至更前的时候，要说服公司去开creator项目是非常困难的，让公司放弃几年的项目积累来尝试新的技术框架这需要很大的魄力，所以对于我们来说也是非常希望creator能够做得更好，当然也可以以此来证明我们的决策是有前瞻性的
2赞
我们也是基于龙骨官方的库去实现的，我们不可能重新实现一遍龙骨。龙骨有质量问题我们当然是跟龙骨反馈。至于你说的改这个问题不需要半小时…… 欢迎你给龙骨提交 PR。
不知道龙骨是怎样的态度，如果是 Spine 这种奇葩的政策，是不允许我们在引擎中帮他修 bug 的。只能等官方修复。
如果用户不用 creator，一样会遇到这个 bug。creator 已经帮他避免了这个坑了，只不过性能不是特别好罢了。