UI的骨骼•盒式模型 (优化版)

盒式模型的作用

UI的骨骼系列的第二篇文章，要探讨组成界面的基本单位–盒子。先来看一下盒式模型可以解决哪些问题。

内容简介

在android平台中，盒子被称为View，尽管名字不同，但本质没有变。本文会讲到以下内容：

盒子的种类和功能

既然是盒子，功能肯定是“装东西”，装什么东西呢？盒子的类型不同，装的东西也不一样。

第一类：

显示文字、图片和视频等信息，一般带有“操作”，这类盒子被称为控件，代表是按钮和文字编辑框。

第二类：

显示其他盒子，这类盒子一般用来搭建界面的结构，这类盒子被称为布局容器。需要强调一下的是，布局容器一般“不可见”。

控件和布局容器统称为组件，一个组件通常只属于其中一类（HTML语言特例），多数设计师都接触过第一类组件，对第二类可能比较陌生，第二类组件正是今天的重点内容。

一起来看看下面的界面中有哪些盒子（组件）。

界面中有一个文本框、一个按钮和三个容器布局。我把他们填充上彩色，会看的更清楚一些。

所以，UI设计师应该建立一个认识，构成界面的元素不仅仅有控件，还有布局容器。

通用的布局属性

盒子通过布局属性来控制内容的显示效果，每种布局容器都有自己的布局属性，其中有一部分是相同的，先来讲讲这些通用的布局属性。

上图是android平台的盒式模型图（与标准 w3c 盒式模型有差异），一共有10个通用的布局属性。

height（盒子高度）：
盒子的高度=内容区高度+顶部内间距+底部内间距。可以设置为具体数值、与内容高度一致（动态）或与父容器高度一致（动态）。

width（盒子宽度）：
盒子的宽度=内容区宽度+左侧内间距+右侧内间距。可以设置为具体数值、与内容宽度一致（动态）或与父容器宽度一致（动态）。

padding-top（顶部内间距）：
盒子内的顶部隔离区，内容无法显示在此区内。属于盒子高度的一部分，只能设置为“具体数值”。

padding-bottom（底部内间距）：
盒子内的底部隔离区，内容无法显示在此区内。属于盒子高度的一部分，只能设置为“具体数值”。

padding-left（左侧内间距）：
盒子内的左侧隔离区，内容无法显示在此区内。属于盒子宽度的一部分，只能设置为“具体数值”。

padding-right（右侧内间距）：
盒子内的右侧隔离区，内容无法显示在此区内。属于盒子宽度的一部分，只能设置为“具体数值”。

margin-top（顶部外间距）：
盒子外的顶部隔离区，使盒子的上边界与相邻盒子保持固定的距离。属于盒子实占区的一部分，只能设置为“具体数值”。

margin-bottom（底部外间距）：
盒子外的底部隔离区，使盒子的下边界与相邻盒子保持固定的距离。属于盒子实占区的一部分，只能设置为“具体数值”。

margin-left（左侧外间距）：
盒子外的左侧隔离区，使盒子的左边界与相邻盒子保持固定的距离。属于盒子实占区的一部分，只能设置为“具体数值”。

margin-right（右侧外间距）：
盒子外的右侧隔离区，使盒子的左边界与相邻盒子保持固定的距离。属于盒子实占区的一部分，只能设置为“具体数值”。

在10个属性的定义中，还提到了两个名词：内容区与实占区。

内容区：
盒子内实际可显示内容的区域，高度=盒子高度-顶部内间距-底部内间距，宽度=盒子宽度-左侧内间距-右侧内间距。

实占区：
盒子实际占用父容器的区域，高度=盒子高度+顶部外间距+底部外间距，宽度=盒子宽度+左侧外间距+右侧外间距。

看到这么多类似的定义，估计已经有人晕了。我用快递盒做了个模型，可以更直观地表现每个布局属性的含义。

灵活地组合这些布局属性，可以做出多种多样的布局结构，另外高度和宽度可以设置动态参数，布局就拥有了一定的“自适应”能力，但只使用这些通用布局属性还远不能满足设计排版的需求，还需要更多的布局属性来支持。

两种经典的布局容器

到目前为止，在android平台中一共有6类布局容器：

• LinearLayout
• RelativeLayout
• FrameLayout
• GridLayout（TableLayout）
• AbsoluteLayout
• ConstraintLayout

  LinearLayout（线性布局）与RelativeLayout（相对布局）目前应用最多，先来看看LinearLayout。

  LinearLayout：
  放置于LinearLayout中的组件会横向或者纵向依次排列。

  看下图，界面上部分展示了LinearLayout纵向排列的布局效果，下部分展示了LinearLayout横向排列的布局效果。

LinearLayout还有一个独特的布局属性–尺寸权重。

尺寸权重：
可将组件的尺寸按照父容器尺寸的一定比例进行设置，所以尺寸权重也属于动态属性。

下面的例子中，将三个按钮的高度分别设置为屏幕高度的10%、30%和60%，在横屏模式下，按钮会进行自适应。

在纵向排列的LinearLayout中，组件会从LinearLayout的上边界开始显示，且只能设置为横向居中显示。

在横向排列的LinearLayout中，组件会从LinearLayout的左边界开始显示，且只能设置为纵向居中显示。

如果希望一个图标显示在父容器的中心，LinearLayout会有点力不从心，必须使用两个嵌套在一起的LinearLayout，如下图所示。

为了解决这个问题便有了今天的第二个主角RelativeLayout（相对布局）。

RelativeLayout：
放置于RelativeLayout中的组件都会寻找一个参考点来设置自己的尺寸和位置。

看下图，灰色区域就是RelativeLayout，首先设置图标显示在灰色区域的中心（不需要双层嵌套），然后设置文本框位于图标下方并且与图标左对齐。在横屏模式下，界面会进行自适应。

RelativeLayout的布局原理与设计原理类似，支持以下属性：

layout_above：

在某个组件的上方

layout_below：

在某个组件的下方

layout_toLeftOf：

在某个组件的左边

layout_toRightOf：

在某个组件的右边

layout_centerVertical：

在父容器中水平居中

layout_centerHorizontal：

在父容器中垂直居中

layout_alignParentTop：

与父容器上边界对齐

layout_alignParentBottom：

与父容器下边界对齐

layout_alignParentLeft：

与父容器左边界对齐

layout_alignParentRight：

与父容器右边界对齐

layout_alignTop：

与某个组件上边界对齐

layout_alignBottom：

与某个组件下边界对齐

layout_alignLeft：

与某个组件左边界对齐

layout_alignRight：

与某个组件右边界对齐

RelativeLayout看起来非常的强大，但是缺少两类属性：

1.使两个组件横向或纵向居中对齐
2.将组件的尺寸按照父容器尺寸的一定比例进行设置

这正好是LinearLayout的强项，所以合理地嵌套这两种布局，就可以实现大部分常规APP的界面。

控件知多少

平时在设计界面的时候，少不了跟各种各样的控件打交道，那到底在有多少种控件呢？

上图列举了一些最常用的控件，需要强调一下，所有的组件（控件和布局容器）都可以添加“按下”、“滑动”、“长按”和“抬起”操作，所以“操作”并非按钮的特权。

TextView控件：
可以设置多行或者单行显示、文字的样式以及省略号出现的位置等属性。

Button和ImageButton控件：
都是按钮，但是Button是TextView的近亲，而ImageButton却是ImageView的近亲。Button是在TextView的基础上增加的点击操作，而ImageButton在ImageView的基础上增加了点击操作。所以，控件可以被“拓展”。

CheckBox和RadioButton：
很容易搞混的两种控件。

上图取自《GUI设计禁忌2.0》一书，强烈建议互联网从业者阅读此书，书中列举了很多优秀的和劣质的设计案例，对多种控件做了详细的介绍。对于CheckBox和RadioButton，只要从字面理解就足以分清楚。

上图可以代替一切解释，关于CheckBox和RadioButton的区别就不再赘述。

Switch控件：
用来开启或者关闭某个功能，一般单独使用。在一些旧的android系统上，此情况可能会采用CheckBox控件，从6.0版本开始，已经都替换成了Switch开关。

其他控件还有“进度条”、“seekbar（滑块条）”以及“输入框”等等，如果以为这就是全部的控件，那就天真啦。

Actionbar、Menus、Navigation 以及Dialogs都属于控件，这种组合了几个小控件的大控件称为控件组，所以控件可以组合起来形成一个新的控件。除此之外，为了满足APP设计的各种需要，还会开发“自定义控件”，下图中心的圆环–时间设置控件，就是一个变种的Seekbar控件。

自定义控件的工作量比较大，尤其对新手程序员简直就是一个噩梦，然后大家看着办吧。

一点感悟，一点感激

今天我重新优化了文章的措辞与排版，一方面希望提供更好的阅读体验，另一方面作为设计者的自己理应追求设计的最大价值。

UI设计是由艺术、计算机科学、心理学以及社会科学等多个学科相结合的产物，因此UI设计天生就拥有着“艺术”与“技术”的两面性。

作为一名UI设计师经常会在工作中遇到“技术性”问题，我们无法回避它们，也不应该回避它们。

现在，我想通过这些 “不一样”的文章揭开UI设计的“技术面”，让我们勇敢地面对UI设计的“完全体”，同时，努力成为“完全体”的UI设计师吧。

最后，感谢每一位读者，如果觉得文章不错，别忘了分享给他人，希望有越来越多的UI设计师跟我一起研究“UI设计中的科学性问题”，发现UI设计的科学之美与逻辑之美。