背景：

经常布局相关的问题反馈，引起的问题大体都类似，如：显示不全，滚动条不见、控件看不到、甚至，打开单据非常慢、布局死循环造成客户端奔溃，浏览器奔溃等严重现象，这些原因大多都是布局设计不当问题，看到类似现象，二开需要第一想到布局是否不当的改动影响

布局设计概述：

布局设计是根据不同的单据使用场景，开发人员进行在BOS设计器里面进行设计完成，布局设计本身也是一个开发中比较重要的一个环节，布局设计的好，界面就整洁简洁性能好，布局设计的不当，严重会造成打开单据慢等问题，很多开发人员为了图方便，为了少写代码，直接拖字段，加字段，就造成单据的臃肿，过于复杂，造成严重的性能现象，这种得不偿失，应当根据业务特性和功能，适当相关结合的设计思路，尽量将复杂单据简单化。

一个高性能的布局一般设计上的避免以下几种布局设计：

1、单据页签过多

描述：如果很多，可以适当根据业务特性进行分类，采用页签显示隐藏的特性进行简化，并且通过什么操作进行显示等

2、表格过多

描述：表格承载数据，大数据的容器载体，无论放哪里都需要考虑其在大数据下的渲染，否则严重影响单据打开速度，单据上尽量缩减表格的数量，可以适当根据业务特性进行分类，使用多级表单的交互形式，尽量说服用户要遵循高性能的单据特性，不能为了图方便，就将单据承载数据的表格不断无限制的增加。（表格过多时，不宜采用显示隐藏方式）

描述：根据业务特性适当分类，灵活借用，单据类型+布局方案的方式，可以多加单据类型，不同单据类型使用不同布局方案，多视图的方式，尽量将单据简单化

4、多层单据嵌套（单据插件showform嵌套）

描述：很多二开为了简单，将多业务功能集成在一个单据上，然后不同情况使用多层嵌套方式，传入参数不同，功能不同，一般单据嵌套尽量不要大于3层，否则极其造成布局运算死循环问题，前端渲染一个单据本身就是一个很复杂的渲染过滤，多个控件的坐标计算，多层情况下，会影响布局运算的深度

5、表格显示列过多

描述：这是常见问题，前端表格控件有时候也是爱莫能助，很多二开无限制，无限拖加字段列，在大数据情况，造成打开单据慢等问题，表格本身是一个很复杂控件，承载着几十种不同字段数据类型的列的渲染，其中数字、日期、图片、附件、基础资料等几个字段类型的列是极其重的控件，属性多，逻辑严谨复杂，渲染上会产生无数个底层对象，在大数据情况下，行X列，实际是个笛卡尔积的渲染性能，所以，根据业务特性，适当拆解多个表格，或者适当使用字段代理的平台特性功能，尽量减少表格列的渲染展示

好了，前面啰嗦了点，现在小编将布局应用常见的问题分享下^_^

一、布局重叠问题 

1、错误现象： 

2、描述： 

上面2个截图，上面是客户端效果，下面是H5端效果，实际上都是错误的，上面是布局重叠问题，因为客户端WPF技术和H5端web技术不同，控件渲染机制也不同，所以客户端看上去是显示出了里面的编辑控件，而H5端没有，实际布局上都是错误的，编辑控件和下面的过滤条件表格控件重叠了 正确修复： 整个条件页签里面应该是两个平级的容器，上面可以拖一个面板，将编辑控件放在一个面板里，并且设置上停靠，下面是一个过滤条件表格，并且设置充满 

3、BOS设计器正确设计： 

4、布局遵循规则： 

1）、多个同时都是可见的控件如果重叠，则有可能底下的会被遮挡，不可重叠 

2）、多个编辑控件需要放在一个面板里，对这个面板进行布局排布，利用停靠属性，以及滚动条属性进行控制自适应父级容器

二、显示不全问题 

1、错误现象： 

2、描述： 

该现象是被截断问题，一般BOS设计器里面进行设计时的窗体的宽高，并不代表所有用户电脑显示器的显示宽度，设计时把窗体或者面板拖到很大，并且可以看全，但是到分辨率比较小的显示器下面，由于整个窗体是自适应显示器分辨率，就会被截断，这时候就需要使用面板滚动条 

3、BOS设计器正确设计 

4、布局遵循规则： 

1）、容器里面含有绝对坐标时的容器，需要正确使用滚动条，解决小分辨率显示不全问题

三、页签控件最大化按钮（页签控件最右）消失问题 

也即绝对控件对充满容器的影响问题 

1、错误现象： 

2、描述： 

上面截图，分割容器上部分虽然是一个充满的页签控件，但是上面的页签控件看不到最大化，因此，这个现象就是被截断了，这个并不是滚动条问题，而且是和这个页签平级有一个绝对位置的控件影响导致

3、BOS设计器正确设计： 

4、遵循布局规则： 

1）、充满容器和绝对位置控件在同一个父级容器时（