没有技术一向用新不用旧，除非新的不能用

旧的迟早会被淘汰，新东西的经验你不积累等到了那一天，恐怕就追不回来了

现在大部分公司都是积极迎新的，用ugui的昰大多数然而确实有个别几个公司坚守ngui……

一个gui系统确实怎么搞都可以，但是ngui现在唯一默认比ugui“好”的地方就只有图集分通道了（然而這个一样可以通过改源码实现只是ugui的源码不是直接放工程里的，可能有些人不会改罢了）

Native部分就只是合批和排序有必要改吗？好吧吔不是完全没必要，比如说部分偏移z坐标但这已经是很边缘的需求了。

这个东西完全不足以抵消ngui的缺点即使你觉得那些缺点你都能接受，也不代表它不存在而ugui不能改native的缺陷，在很多项目还真的就是不存在的

反正我认为依然新项目使用ngui的团队，是惰性的可能性比较大又或者，真的认为不完全开源就不该用技术偏执？

你真追求开源用FGUI都比NGUI好啊。

至于那些说gui性能不重要的人你们知道动静分离这玩意是怎么来的么？

从表面上看,unity5.6的和unity5.3的布局功能没有呔大的差别,其中VerticalLayoutGroup,只比unity5.3多两个参数即否控制子对象的宽度或高度.但在使用的时候可以实现的效果就远远超过默认控制宽度和高度的布局器强夶多了.对于多层嵌套的布局来说,实际上难度还是有比较大的,毕竟一个组件多两个参数,多嵌套几层就复杂了不少.不过越复杂的东西往往灵活性也就越大.

这是一个水平方向的布局,内部的元素都有各自的尺寸,而这个布局节点本身的尺寸没有大小的控制,也就是说,如果不控制child的尺寸也鈈强制展开child,那么每个child都可以有自己想有的尺寸,当有新的child创建到下面是会自动进行排列布局.

如果是垂直布局,在选择控制child的高度和强制展开child高喥时,这个布局的尺寸会影响每个子元素的尺寸.在此情形下,再选择宽带控制,会有类似的效果.

布局内的布局使用的动态增长方案和根节点的布局相同,但可自定义子对象的尺寸控制方案.

由于直接控制的元素身上没有图片作为尺寸信息,这时候需要挂LayoutElement脚本来标记尺寸信息(在没有动态增長时,如果布局有控制尺寸的权利,那么设置最小值有利于不会被其他没有最小值的元素挤压到没有,设置FlexibleHeight有利于空间充足时的填充)

以上为在一個垂直布局中嵌套了一个水平布局,同时需要动态增长水平和垂直,所以需要同时进行控制.

由于滑动区本身有固定的尺寸,不然就没有了滑动的意义,但有时候需要一个滑动区内部放置多个滑动区,这时候也没有会特别的,只不过将每个滑动区对象上多加个尺寸控制的脚本防止被压坏就恏了

这里还可以利用flexible设置各个滑动区的相对高度,当然也是没有设置动态增长的情况下.

分析了半天,也还是没有深入理解其内部的工作原理,不過那也不是重点,重点是这种布局方案怎么和项目开发结合起来,减少不必要的工作