最近才开始接触cocostudio，主要是用来做UI。不想过多吐槽了，只想说一点，备受推崇、重金研发的一个编辑器还比不上Unity中的一个插件。之前我感觉NGUI很难用，但那是跟DF GUI相比，现在感觉NGUI实在是太方便、太强大了。
1、基础使用：
在CocoStudio中编辑界面，然后导出资源，导出后会有资源目录和csb文件。我们使用时直接加载这个csb文件就可以了。它是protobuffer序列化的，CocoStudio2.0版本暂不支持json格式。
lua加载代码：
local node = cc.CSLoader:createNode(file) -- TODO 貌似是全屏的
local panel = node:getChildByName(panel) -- 对话框panel
scene:addChild(node)
2、多分辨率处理：
cc.Director:getInstance():getOpenGLView():setDesignResolutionSize(1280,720,cc.ResolutionPolicy.FIXED_HEIGHT)
通过这个来设置设计分辨率，设计分辨率就是在制作UI和游戏内容时的默认分辨率，这个一旦决定下来就不会轻易动了。最后一个参数决定了实际屏幕分辨率不同时窗口的缩放。具体是SHOW_ALL还是NO_BORDER还是FIXED_HEIGHT看实际需求。事实上哪个都不能完美的解决我的实际问题。
一般来说，非全屏的UI可以不用关心多分辨率，里面的控件也不需要关心锚点，相对位置什么的，因为界面大小是固定的（无论是960x640还是1024x768界面都是那么大）。而一些需要全屏处理的UI内容就要特殊处理了，比如主界面。一般来说主界面的需求是左上角显示头像相关内容，右下角是一系列按钮，右上角也会有一系列按钮。这个时候在cocostudio中只用一个界面就显得力不从心了。 我的处理方法是把这些内容划分成三个panel，分别加载这三个panel，然后再根据对应的锚点关系把panel放置在争取的位置（比如锚点在右上角的，就把对应panel的anchor point设置成1,1，然后把它的坐标设置成winSize.width winSize.height）。
全屏拉伸的背景图片也需要特殊处理下，一般来说我们的需求是背景图片不变形的拉伸（保持高宽比），并铺满整个屏幕，不留黑边。
总结一下，感觉是这样子的，无法使用cocostudio完成整个ui系统的控制，界面的显示位置还是需要上层逻辑代码来控制。虽然不是非常麻烦，但是总归感觉是比较low的。当然，也可能是我没有掌握好对应技巧，欢迎批评指正。
3、Node:getChildByName是非递归的：
直接通过getChildByName是非递归的，无法直接通过一个rootNode来获取子控件。cocos2d-x v3.2提供了这样一个函数来解决这个问题：enumerateChildren。使用方法如下：
function util.ui.getControl(root,name)
local control;
root:enumerateChildren('//' .. name,function(ret)
control = ret;
return false;
end);
return control;
end 这个函数使用方式略显怪异，但是功能还是比较强大的，可以指定路径，也可以模糊查找，具体可以参考源代码中函数的注释
4、Panel默认是颜色填充的，而cocos2d-x v3.3版本貌似还是有bug，panel里面直接选择Fill为None，在实际游戏中依然会有填充色，必须要手动把Opacity的值设置为0才行。而CocoStudio和其自带的程序是没有这个问题的。
5、坐标设置可以是像素也可以是相对于父窗口的百分比
这个不算坑，估计原本他们也想用这套系统来替代锚点的布局系统。不过略显鸡肋，因为大多数对话框只需要配置好绝对的像素坐标就足够了，而当需要自动布局适应多分辨率的时候，这套百分比相对布局依然无法正常适配。也就是说正常的时候怎么都正常，不正常的时候怎么都不正常。
6、不提供打包功能了，导入资源的时候就需要打包好
这个也不算坑，本来统一化的打包就存在一些恶心的问题，比如背景图或一些比较大的图片不应该打包，但是也一并打包进来了。现在的方式更加自由。 我还没有尝试texture packer打包的兼容性，我猜想会存在这样的问题，我使用原始图片配置好的界面，当我换成plist后，所有的界面图片都要重新指定。 如果真是这样的话，也无法过于苛责，只不过显得不够人性化。
7、控件不够全，并且功能比较弱
比如三态Button，单选Button组，Tab标签等等功能都没有，而我想直接通过设置Button状态来控制其图片样式也做不到。
当然，这些并不是说真的做不到，只不过需要额外写一些代码来处理。相比起来NGUI和DF GUI乃至Unity新推出的uGUI都比它强多了。
8、导入图片资源比较混乱
导入的图片资源一开始会散列在编辑器资源窗口中（资源可能来自不同的文件夹），然后可以拖动资源到我们编辑器中创建好的目标文件夹。这个操作会移动实际的文件。而如果我们一开始就把资源放在目标文件夹中就麻烦了。 与其这样，还不如像eclipse一样，按F5直接刷新资源，更近一步就是像Unity一样，自动检测文件变化。
导入图片资源时无法直接把图片拖到目标文件夹，必须要两步操作。
删除资源会重置控件中的图片属性到默认值，如果一不留神删了资源文件夹就over了，所有的控件都要重新指定一下图片内容。
9、拖动控件，改变其父节点的时候，坐标没有重新计算，导致一旦改变控件的父节点，控件就不知道飞哪里去了，必须要重新调整坐标。 据说Flash也这样，但是至少Unity不是这样，而且Unity操作起来非常方便。
10、点选控件很让人恼火，如果控件的遮挡关系一复杂，就很容易让人点到错误的控件。 Unity的NGUI虽然有的时候也不是很方便，但感觉还是方便一点点，而且它的属性值是可以通过拖动操作来微调的，这个要比只能填数值要方便多了。
11、精灵对应的是cc.Sprite，图片对应的是ccui.ImageView。ImageView维护的是一个九宫格图片（如果不勾选这个选项，图片可以正常显示，但是使用的依然是这个类）。理论上cc.Sprite效率要高一些。但是由于Sprite不是Widget，不支持addTouchEventListener方法。所以想要处理点击的话，就必须使用图片控件，并且要设置setTouchEnabled为true。
12、偶尔会因为某些bug，导致csd文件被清空。所以最好建立个svn或者git仓库，时常保存一下。否则万一中招就悲剧了。
13、UI动画的使用方式：
self.buttonPanelAnimation = cc.CSLoader:createTimeline("GUI.csb");
self.buttonPanel:runAction(self.buttonPanelAnimation);
self.buttonPanelAnimation:gotoFrameAndPlay(0,25,false); 传入的文件就是GUI文件，动画制作的关键帧信息是保存在一起的。所以如果有多段动画的话，要分开帧段单独制作。比如菜单的收缩和展开就需要分两段动画来制作，播放的时候通过帧来控制播放哪段动画