具体来说问题：
界面active=false时，如果对该界面的子对象进行修改，比如设置label的string，这时读取其宽高的值是不对的。
目前的架构设计：
游戏有2个界面，A界面和B界面，B界面是全屏界面会盖住A界面，为了减少drawcall，会把 B.active设置为false
B界面产生交互后会派发事件通知A界面，A界面会回调方法F1做以下事情：
修改A里面的 label.string=xxxx, 然后有逻辑动态读取label的width和height进行对齐等等
这样就出问题了，因为A不可见导致读取label的width、height值是不对的，最终位置错位。
B界面关闭后，A界面如果再重复执行一次方法F1 可以渲染正常，但是已经没有机制去触发执行F1了，
而且类似这种F1的方法或许有不少，请教大家这种问题怎样封装在底层或架构层面设计来规避问题
updateRenderData() 可以考虑强制刷新,看一下这个API.其它需要刷新的,也可以看看.
减少drawcall改透明度不行吗？
A.active = true，不是有 onEnable() 的机制让你来触发 F1 吗。。。怎么会没有机制呢。
但关键点在于，你既然底层提供了机制让 B 这个全屏出现的时候，A.active = false ，那应该也能有配套机制，去实现 B 消失的时候，A.active = true 呀。
这样你就把 A.active 换成方法，不就提供了更通用的机制？
修改 a 的相机分组，到一个没有相机渲染的分组
这种分组要递归子节点。。。感觉不好。而且恢复的时候，还得记住之前的分组。如果一个界面中有别的分组，那就dan疼。。。。
界面增加一个机制， 被其他界面遮挡时 lostFocus, 变为 top view 时触发 onFocus, 把 lostfocus 期间的通知存起来，onFocus 时调用
你这个机制是可以的。
刚刚试了改透明度可以，似乎不影响 label的渲染 和宽高读取。
但是透明度为0 和 active=false 2种方法对渲染性能的影响 有明显差异吗？
你这种情况透明度更适合，大多数情况透明度性能更好的
也可以在A界面上监听B界面是否关闭，关闭后再进行大小和位置的操作即可
这个我没验证过，改透明度跟设置active=false性能一样吗？
我测试下来2种情况
1、切换active 瞬间的的耗时特别高，用透明度代替 active可以大大改善，避免跳帧
2、一个复杂界面的透明度=0，比用active=false， renderer耗时会增加1-2毫秒（电脑测试）
active 为true,onEnable里写
1-2毫秒是多少,这还需要考虑吗
性能会更好