好好说话，不要站在道德高地指指点点。是不是加班加傻了？还是学傻了
什么是真正的工程？
这个做法其实是将重复的代码减少。
你讲的把绑定的都加载进去的担忧，其实可弄成动态加载，只记录路径变化就行。
而且打开一个界面，大部分图片都在图集里，本来就应该加载。扣啥扣。
即使要减少内存占用，用代码还是用这种方式都可以做到。
即使你用代码处理状态变化，也不见得省多少内存。
业务处理有问题，跟控制器有什么关系？控制器用来控制状态，省事省代码。不能因为你业务处理有问题，就说控制器没有存在的必要，秀儿，是你吗？
比如一些继承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好？
看源码啊。
内存消耗的大头不在这里。面向瓶颈做优化,而不是魔怔般想要优化一切时间复杂度和空间复杂度。在这个维度上来讲，程序员的时间远比这一点点内存消耗值钱。
我开源的项目有，看我发帖
这确实是个很常见的需求，我刚更新了代码，现在可以更方便的支持自定义组件了
可能是因为设置active的时候会同时遍历当前节点下的所有子节点和所有节点下的组件这些并改变他们的状态这些，就是会在设置的那一帧耗时比较长，理论上几十节点这样改变也不会有啥感觉，控制器控制改变的active下的节点也不会太多，这个设置的频率也不是很高，而且设置了active之后后续流程都不会再渲染这些节点了，而设置opacity为0的节点还是会一直渲染的，所以并不能说设置active没有就没有opacity好，还是要根据具体情况来的
你的意思是只在部分节点上使用“UI控制器”？
