@panda 我想借这里问你一个问题：
Creator的JS引擎会依赖C++层的CC_ENABLE_GC_FOR_NATIVE_OBJECTS这个编译条件吗？
也就是如果我在C++层把这个编译条件去掉，引擎层能正常执行吗？
我有点想把这个去掉，直接用引用计数来管理原生结点。
我们测试发现：长时间刷新一个界面的内容（释放和创建结点），内存会一直涨，涨到6，700M左右，游戏就卡10秒左右，然后内存开始往下降。
初步的预估是GC的时候，大量被JS引用的结点开始释放，这里导致卡住的。
1赞
嗯，你的估计是有道理的，目前 1.6 应该不会出现这样的大规模卡顿，因为开启了 Generational GC，或者卡顿的原因可能是在性能热点时触发了比较重的 GC 操作。
CC_ENABLE_GC_FOR_NATIVE_OBJECTS 其实就是新内存模型的标签，在 creator 中是默认开启的，1.5 版本还可以关闭，但是在 1.6 中升级了 Spidermonkey 后，它的 root 方式被改变了，以前的 API 都无法使用，所以暂时不支持关闭这个选项。
你的测试是什么版本？
1.6性能提升我在ios上感觉不出来， prefab加载还有 instantiate的速度并没有提升。游戏中各种打开面板卡顿，加载资源卡顿 这个性能的提升我认为很重要啊
解决这种内存问题，一般是需要用对象池来避免内存的频繁创建销毁的
比较麻烦的是，我1.5.2和1.6 beta 6-2都试过了，都有这个问题
1.5.2大概在600M左右出现卡顿
1.6大概在800M左右出现卡顿
我用Win PC的模拟器测的
出现这个卡顿的详细过程是：
有一个自动强化的功能，点了之后，每0.5秒向服务器发包强化。然后服务器下发强化成功，界面就自动刷新：其中会涉及到结点的删除和创建的操作。这个自动化的过程中，内存一直在涨，每一次测1到2M，直到一定的阈值，然后就卡住10秒。然后内存就往下降到200多M。
嗯，我们在角色特效等很多方面都用了缓存了，界面这块太多太繁琐，就全部用缓存需要很多工作量。
我昨天直播的时候强调了一下，1.6 在 iOS 版本中并没有性能提升，因为 iOS 禁止使用 jit，而 Spidermonkey 从 v33 到 v52 集中改进的就是 jit compiler 的性能，自然在 iOS 上就没有效果了。
不过不用担心，1.7 我们的绑定层就支持 JavaScriptCore 了，iOS 原生的 JSCore 是支持 jit 的，所以会有比较明显的性能提升
一楼提到的这个很多retainNativeScriptObject这样的 c++调用js的方法会不会占用较多的性能开销呢？能否优化呢
那有没有办法从游戏逻辑层面预测这种界面的刷新呢？如果进入到这样的状态，就缓存住这个界面，然后通过修改组件数值来刷新？
嗯嗯，这个会有性能开销，也在优化的计划中
是要到 1.7了吗？
这个我得看看任务情况，能加快的话会尽早
游戏层的逻辑，我正在想办法优化，只能针对性的优化。我现在对创建和释放结点的性能代价已经有深刻的体会了。如果你们就这个点能有大的优化，我相信引擎的性能立马会上一个新的台阶：）
目前游戏还没有移到1.6。我们还在1.5.2，大概可能就固定在这个版本。
1.6说好的native优化 目前感觉效果不明显，觉得应该尽早安排
你不能只靠引擎，游戏逻辑层的优化也必须得做。
游戏层的优化就两个字：缓存
1.6 的 native 优化主要是 iOS 以外的平台，iOS 确实得等 1.7
第一次加载卡卡的主要还是得看引擎
你的 QQ 号多少？找你要一下崩溃的测试
说的应该是列表之类的容器吧，我之前的做法是自己实现一个列表容器组件，实现对列表中节点的缓存管理，只要是用到列表的都不存在问题
不是找我吧：），没有崩溃的测试