现在很多的ui转化只能通过代码去控制，没有像egret可以添加state然后用currentState来切换视图，或者fgui用getControl控制器来切换。这个功能很方便，为啥creator没有，刚才在论坛看到一个大佬发布的一个UIState控件，但是看了一下不支持一些自定义的变化 Cocos Creator 最好用的UI状态管理组件 - Store - Cocos中文社区
1赞
自定义的变化指什么
如果有这功能，确实能方便不少 
我也确实很喜欢fgui的控制器，但我却并不喜欢用fgui，哈哈哈
所以一直想自己在Cocos中实现一个类似的控制器
就是类似状态机嘛
这种东西，只能消耗过多内存，完全没有存在的必要，真正的工程，绝不只是一两个节点的状态发生改变，提前存储这些状态，只会徒增内存，如果人家压根没想要过切换到那个状态，但是你却一股脑的全部状态都绑定加载上去，如果是小内存还好，可假如你10张比较大的背景图sprintFrame提供给用户做选择，提前加载到内存就完全不是正常程序员想要做的事情。
现在的程序员门槛都低了，很多人都以为客户有一堆内存，16g，8g，还差那点内存？可现实是：可不止你家app是这样想的，其他app也是这样想的，如果所有app这样想，那客户起码得人手16g内存才能勉强够用，不是人人都是iphone！android机型还是占有绝对的用户比例的。
提前定制好状态，然后必要时候切换，这种方式方便肯定是方便一丢丢，但是如同数据结构与算法中所说的那样，时间与空间不可兼得 ，这种方式不过是用内存换来的便利一点点而已，实际用得上的情况很少，毕竟还是需要拿到节点才能做相应节点变化，那么既然我都做到拿节点的那一步了，难道我还差多写几行代码来切换节点或者节点相关组件状态这点力气吗？
1赞
fairygui的控制器，用的很舒服。
好好说话，不要站在道德高地指指点点。是不是加班加傻了？还是学傻了
什么是真正的工程？
这个做法其实是将重复的代码减少。
你讲的把绑定的都加载进去的担忧，其实可弄成动态加载，只记录路径变化就行。
而且打开一个界面，大部分图片都在图集里，本来就应该加载。扣啥扣。
即使要减少内存占用，用代码还是用这种方式都可以做到。
即使你用代码处理状态变化，也不见得省多少内存。
业务处理有问题，跟控制器有什么关系？控制器用来控制状态，省事省代码。不能因为你业务处理有问题，就说控制器没有存在的必要，秀儿，是你吗？
比如一些继承Label或者Sprite的自定义组件就不能实现，需要修改
嗯啊，就可以简化一些界面的逻辑代码了
我也是啊，fgui用起来感觉还是不够丝滑
嗯啊，fgui的控制器用起来很舒服，fgui的一些组件也很好用，但是还是感觉没有在creator直接勇UI来的丝滑
对的啊，类似状态机，在状态切换的时候界面元素也会跟着切换
状态控制的本质是什么？active?active的消耗太大了。建议官方：对opacity做封装，不要用active
如果非要说Creator的UI控制器的话，那也是有的，那就是内置的 Animation，也是功能齐全的，只是用在UI控制上不那么优雅
状态控制不单单就控制active，还有scale,position，等，只要节点数据不一样就会把数据跟状态对应起来
白鹭的我用过。我是说。这些状态的切换其实不够灵活。这个其实没必要。
例如状态1是显示，状态2是隐藏。你就用active属性。但是opacity也可以用。opacity的性能比active好N倍。
具体性能的话可以用opacity代替active，这个是细节上的处理。如果没有状态切换的话还是会多很多逻辑控制的代码的
opacity为什么比active好？