为什么必须要用default?我们使用binary做完了整个项目。U3D不也只有binary?
好的，请继续用binary 
是的，但是要在debug阶段体现出来，不能在发布的时候体现出来。
这个肯定不能这么设计，引擎肯定不能为上层逻辑买单。比如，钥匙孔，不需要设计成，往里插什么都好使，但它确实也可以插别的，只是打不开门，乱插有时也会把钥匙孔插坏。
Outline在更新字型後會失效的問題，beta 6.2還是一樣
另外我發現有Outline的 Label，不止是更換字型會讓Outline失效，
部份情況連更改Label的string都會… 
Native上的设计是按照所有音频的实例数量。
如果是某个音频的实例数量，估计接口应该是：
AudioEngine::setAudioInstanceLimitByAudioId(int audioId, int limit);
设想一下，如果是同一个音频限制个数，那么native上同时播放300个不同的音频文件，那逻辑上是没问题的。但是实际上，Android最多同时播放32个实例，iOS也有一定的限制。
所以这个接口，估计是Web同步Native接口的时候，理解不同导致的。具体需要 @visualsj 确认一下web上的实现。看是否改成跟native一致的行为。
我用你给的范例测试没啥问题啊，你是看 Web 的还 Native（Windows不支持） 的？
点击前：
点击后：
我们坚持只使用binary版本原因：
1.编译速度快，比default快不只一点点。
2.超低耦合，升级引擎无压力。cocos每个稳定版本都有很多问题，我们立项时就用的1.4beta版本，问题解决的时期永远都是“下一个版本”，你懂的，我们随时准备升级。为了减少升级的工作量，强制使用binary.不对引擎做任何改动。
是这样的
1。编译速度快这个是只在第一次的时候快，以后其实是差不多的，这个不用我多讲吧？
2。项目前期确实是可以考虑binary，不过在项目的中后期，引擎版本尽量不要经常换，因为你不知道新引擎会带什么新的BUG，而这个时间点最好用Default，遇到什么BUG可以修掉它。在后期你期望通过升级引擎来解决BUG，这个太冒险了。所以我的意见还是后期用Default，然后不要换引擎了，除非引擎有重大改进。在default里面修改掉BUG，和一些性能问题。等下个项目再换成新的版本。
好的，这样我理解了，希望Web和Native上表现一致，另外API文档也应该对这个方法的含义说清楚
"国内顶级的技术团队，这里汇聚了来自游戏开发、图形渲染、原生开发、网页前端等各类前沿技术的专家，让你飞速成长。
在这里，有浓厚的技术氛围，有机会可以和各个领域的专家进行肩并肩的工作，和国内各游戏公司进行面对面的技术交流，和全球百万的使用者无缝地沟通。
在中国，每一年的榜单大作，Cocos从未缺席，市场份额占50%以上，游戏品类覆盖从轻度休闲，热火棋牌，到横版，SLG，重度MMO等市面全品类。"
国内最牛比的游戏引擎，世界第二牛比的游戏引擎开发团队，会做不好一个稳定的binary版本？会需要我们这些处围人员去修改引擎代码？我也不相信，连作者自己都解决不了的性能问题，稳定性问题，这些做外围的人员能解决得了？
所以我们坚持相信，我们自己来改，一定不会比官方的人员改得更加好。
坚决不修改引擎。
还有一个最大的原因：我太懒了,要我来改引擎，还不如让我给cocos付费。
我给Cocos团队配一个图，你还代表中国。
2赞
binary 模板的内容和 default 模板是一样的，但是没有源码没有调试信息，所以如果出了问题会比较难以定位。
这个是正常的结果，和「好」「坏」，是否「稳定」没什么关系。
就算你不打算改引擎，原生版本出问题了，用 default 调试一下看看问题是什么也是极好的。
你的 main.js 里面会怎么写？还会 require 其他 assets 里面的脚本吗
你调试看下这个 target 是什么？他没有 sgNode?
dragonbones中。我想在代码中获取一个动画中时间的事件的触发事件。。。然后看了下dragonbones_armatureDisplay的数据。我在dragonbonesData中的
frames中找到了。。 。不过这里有一个很诡异的问题。。。 同样的数据在frames存入了多份。。。不知道这样处理的原因是为什么？还是说仅仅只是个bug？
这个会不停的执行怎么调试呢，我是进入下一个Scene报的错
（帖子被作者撤销，如无标记，将在 24 小时后被自动删除）
算了还是删了！思想太激进！