cocostudio导出文件的问题

　　个人认为，cocostudio有两个最大的缺点（以cocostudio 1.1.6 和 cocos2dx 3.3为准）：

　　1）部分功能实现和cocos2dx引擎有出入。比较典型的是层容器（ccui.layout）的锚点问题，还有就是UI动画节点的百分比位置属性问题，编辑器中表现和引擎中有较大出入，应是实现细节有不同。

　　2）导出大图的打包算法太差。

　　第一个缺点属于bug report范畴，有机会写个坑集，今天不赘述。主要想讲的是第二个问题，从以下几个方面开讲：

　　1）为什么使用大图？

　　首先是小图IO多，10张小图的读取需要10次IO，同样地信息量可能只需要一张大图，这样一次IO搞定。其次是opengl的drawcall数量的问题，纹理个数太多会降低绘制性能。综上，大图有优势。

　　2）大图缺点在哪？

　　应该是历史原因，部分android和老的iphone机型读取的大图规格必须是2的整次幂（关于这个问题，朕颇有微词，试过用非2的整次幂规格图片，大部分android和iphone机型都能跑，觉得应该没什么问题。但保险起见，还是按传统的来。万一上线后遇到个傻逼机型，这问题修还是不修呢？）。所以一张1025*1025的图片打包成大图后，就变成了一张2048*2048的图片，占用内存足足增加了三倍。这应该是大图最恶心的地方。

　　3）为什么说cocostudio的打包算法差？

　　同样的图片量，好的算法可以合理地安排图片位置，必要时可以旋转保存，能够最优化大图体积。比较强大的有TexturePacker，提供包括旋转图片（90或180度转）、去掉透明边保存等功能，同时提供数种常用的图片格式，包括RGBA8888、RGBA4444、PVRTC4等，实在是游戏开发的大法宝。相同的图片量，往往TP打出的大图会比cocostudio小很多，图片的走位更风骚、紧凑，一看就是专业算法。但是TP的一个小问题在于，打出的plist是用图片名做key的，不包含路径，意思是 a.png和tmp/a.png是不能被打到一张大图里去的。而cocostudio里面使用图片和打包出的plist是带路径的图片名做key，程序员在制作cocostudio重打包工具的时候应注意这一点，会引起bug，严重时会导致cocostudio的导出文件读取失败 。

　　4）怎么办？

　　还能怎么办？制作重打包工具，用TexturePacker。

　　5）还有没有坑？

　　cocostudio的动画编辑器还存在一个问题。动画节点的纹理集中所有的图片都会被打包出来，即使你并没有在任何动画中用到这个图。通常美术会犯这样的错，往节点的纹理集中加了很多图片，但是真正动画中用到的也就是一部分，无意中又增加了大图的体积。这种问题，如果每个动画都去review一遍无疑是不现实的，而且也不能就说美术制作不规范，归根结底还是编辑器没优化好。这时候就显出程序员的厉害了，重打包流程里加上这么一步，把纹理集中并未用上的图片去掉。这就需要仔细分析动画编辑器导出文件的结构了，当时也是花了我不少心力的。