项目进入到调优阶段 发现产品性能问题较大，需要较大的调整。问题点列表如下，有部分已解决，有部分尚待解决。抛砖引玉，希望大神提供思路。
问题
1：安桌真机渲染性能很低，部分UI面板帧速低于10帧（手机比较破）。
渲染的优化基本集中于降低draw call。引擎本身有对同一图集的相领渲染节点做同一批次的处理。
如
**如果A B C三个精灵的spriteFrame来自于同一图集，那么将共用一次drawcall. **
如果A C来自于同一图集，B来自另一图图集，那么将占用三次 draw call。
如果A B 来自于同一图集，C来自于另一图集，那么将占用2次draw call.
draw call的次数来次于渲染过程中图集的切换次数。
于是优化的点便来自于对节点层级进行规划。让来自于相同图集的处于连续的位置。 这需要在制作UI的过程中非常精细的控制图片的来源和节点顺序。 经过优化，部分面板的draw call降了很多。部分甚至超过一半。
另外需要注意的是每个Label会单独占用一次draw call。并且会打断连续的节点。 所以在面板规功的时候最好把所有的label单独提出到一个空节点。 否则会吃大亏。draw call翻倍不是梦。稍不注意就过百。
另外对于label这个 创建性能极差 渲染性能极差 又大量要用的东西有另外一种优化方案。
> BMFont会让多个连续的label共用同一次draw call。注意 多个BMFont label中间不要置入普通的label，否则draw call一样会被打断。
2：cc.instantiate()实例化对像性能极差，造成打开面板 批量创建对像(列表cell)时响应速度很差。
简单跟踪了一下cc.instantiate方法的实现。发现只是深度拷贝一个对像。JS的深拷贝性能一直极其坑爹。也没有想到什么合适的方法能优化这一块。求大神给予指导。 另外对像池有利于减少cc.instantiate()的调用，复用之前的对像。但是在面板上需要一下子批量创建出大量面板图标的情况下。cc.instantiate性能实在着急。 询问官方人员，说以后有可能用类似jit的方式去实现对像的拷贝。 不懂什么是jit方式。只求快一点。
3：scrollView拖动体验不尽如人意。有顿挫感。安桌不说，IOS上也会。
暂时还没找原因。只是发现这个问题。scroll上有很多个卡牌的精灵。这体验实在着急。另外这里已经使用了对像池。新出现的scrollview仅仅是从池中取出再add到节点上。
4：tiledMap在地图超大时会出现内存爆增，直接卡死。
这个之前有发帖写过。http://forum.cocos.com/t/ccc-tiledmap-demo/37879 解决方法也有共享到git。思路对超大型地图的实现有用。代码不够优美。参考即可。
5:手动load的prefab spriteAtls spriteFrame 几乎不能release掉。造成内存只涨不减。
》暂未解决
很感谢天天被我烦的工作人员 Jare