刚接触Android布局时，几乎所有人学的第一个容器就是线性布局（LinearLayout）。它把子View按水平或垂直方向排成一条直线，看起来没有任何门槛，但实际写起来，"两个按钮宽度为什么不一致""layout_gravity设了没反应""嵌套一多就卡"这类问题，就算写了三五年代码的人也会踩。这篇文章我打算把线性布局从设计逻辑、属性原理、权重计算到真实页面搭建、排错方法完整过一遍，既适合刚入门的新手，也适合那些被gravity和weight折磨到怀疑人生的开发者。

1. 为什么是线性布局：设计逻辑与适用边界

1.1 它解决的到底是什么问题

线性布局解决的核心问题只有一句话：让一组子View按照先后顺序对齐排列。垂直排列就是从上往下一个个排，水平排列就是从左往右一列列排。这里的"对齐"不是说随便摆，而是系统自动按顺序计算每个子View的位置，开发者只需要告诉它方向、尺寸、权重，剩下的坐标计算全部交给框架。

这个逻辑和生活中排队很像：大家按顺序站成一列，每个人的位置由前面的人决定。对应到Android里，父布局记录前一个View的结束位置，把它当作下一个View的起始位置，中间再留出margin、padding等空隙。LinearLayout默认不会重叠子View，也不会自由摆放，这也是它名字里"线性"二字的由来。

很多人觉得线性布局太简单不值得深究，但从实际项目看，它依然是出现频率最高的基础布局之一。原因很现实：很多界面天然就是一行一行或者一列一列排下来的，用LinearLayout写起来最短最直白。尤其在不同屏幕尺寸下，配合权重能做到漂亮的自适应，这是其他布局很难替代的。

1.2 为什么它依然值得认真学

现在ConstraintLayout被官方主推，很多人直接从约束布局入门，导致对LinearLayout的底层逻辑一知半解。这里我想说一个观点：LinearLayout是理解Android测量与布局机制的最佳入口，没有之一。

原因在于，LinearLayout的行为足够简单可预期，非常适合用来学习measure、layout这两个核心阶段。你设置一个wrap_content，系统怎么量，设置match_parent，系统怎么量，设置weight后又发生了什么变化——这些在LinearLayout里很容易通过实验观察。把这一套搞明白，后面再看ConstraintLayout、FrameLayout，很多概念都是相通的。

从实际开发效率角度看，线性布局也不是能被完全替代的。登录页面的纵向排列、底部按钮的一行平分、列表项里左侧图标右侧文字的经典结构，用LinearLayout写出来代码量少，可读性高，配合layout_weight做比例分配尤其方便。与其盲目追求"少嵌套"而把所有布局都强行改成约束布局，不如先确认线性布局在这个场景下是不是更直接的答案。

1.3 哪些场景应该绕开

线性布局不是万能钥匙。一旦界面需要自由定位、层叠覆盖、复杂网格时，硬用LinearLayout就会堆出一大串嵌套。我见过最夸张的案例，是一个简单的四宫格，开发者用三个横向LinearLayout嵌在一个垂直LinearLayout里，每行再套两个子LinearLayout，代码写了上百行，测量时系统层层计算，打开页面有明显卡顿。

这种场景显然应该用GridLayout或者ConstraintLayout。不过嵌套本身也不是洪水猛兽，两三层的线性布局性能完全没问题，真正要警惕的是超过四层的深度嵌套。因为每次measure都是从父到子递归调用，层级越深，调用次数越多，遇到复杂布局很容易掉帧。

我自己的选择标准很简单：内容排列符合"线性顺序"就用LinearLayout；需要按行列网格就考虑GridLayout；需要自由约束、百分比定位、复杂对齐就上ConstraintLayout。每种布局都有它的生态位，没必要神化某一个。

2. 核心属性全拆解：从orientation到weightSum

2.1 orientation与宽高尺寸

LinearLayout最根上的属性是android:orientation、android:layout_width和android:layout_height。orientation只有两个值：horizontal和vertical，默认值是horizontal。这个默认值是个经典坑，很多人写LinearLayout时忘了声明orientation，结果发现子View全部横着排，跟直觉里的"应该竖着排"完全相反。

尺寸方面，match_parent表示占满父容器剩余空间，wrap_content表示包住内容，也可以写具体dp值。线性布局有一个很重要的特性：在主轴方向（也就是orientation指定的方向）上，子View的layout_width或layout_height会直接影响后面的权重计算。很多"权重不生效"的假象，根源就是子View在主轴方向上用了wrap_content，导致初始尺寸不为零，分掉了一部分空间。

副轴方向通常简单一些。垂直布局时，副轴是水平方向，子View宽度可以match_parent，也可以wrap_content再配合layout_gravity控制对齐。水平布局时，副轴是垂直方向，子View高度一般wrap_content，再用gravity控制垂直居中。

还要区分两个尺寸概念：margin和padding。margin是当前View与外部兄弟节点或父容器之间的间距，padding是当前View内部内容与自身边框之间的间距。两者在测量时的计算方式不同：margin会占用父容器的剩余空间，padding则在布局内部被消耗掉。

2.2 gravity与layout_gravity的混淆点

这两个属性是新手重灾区，几乎每周都会有人因为这个写错布局。android:gravity是加在LinearLayout父容器上的，控制的是所有子View内容在容器内的对齐方式；android:layout_gravity是加在子View上的，控制的是这个子View在父容器内的对齐方式。名字长得像，作用对象完全不同。

举一个具体对比：在垂直LinearLayout里放一个TextView，TextView宽度是wrap_content。如果给LinearLayout设置gravity="center_horizontal"，那么TextView会水平居中；如果给LinearLayout设置gravity="bottom"，容器里的TextView会被压在底部。但如果给TextView本身设置layout_gravity="center_horizontal"，同样会居中——看起来结果一样，实际原理不同。一个是父容器统一指挥所有子View，一个是子View单独表达位置诉求。

还有一个经常被忽略的点：在LinearLayout的主轴方向上，layout_gravity往往无效。垂直布局时，子View垂直方向的位置已经被排列顺序决定了，你写layout_gravity="center_vertical"基本没用；水平布局时，layout_gravity="center_horizontal"也不起作用。想要在主轴方向偏移，只能用布局嵌套或者margin来做。

2.3 weight与weightSum的定位

权重是LinearLayout区别于其他布局的最核心能力，它的作用可以概括为一句话：让子View按比例瓜分"剩余空间"。这里的关键词是"剩余"，而不是"整体"。后面我会专门讲计算公式，现在先建立一个整体印象。

weightSum表示父容器声明出来的总权重值。默认情况下，系统把所有子View的weight值相加作为总分母。如果手动指定weightSum，分配比例就以这个数字为准。给人的感觉像是人为规定了"整个空间分成多少份"，再让各个子View申领其中的几份。

一个典型场景：底部两个按钮想平分宽度。可以把两个Button都放在一个水平LinearLayout里，宽度都设0dp，weight都设为1，父容器不声明weightSum，系统自动算出总权重为2，每个按钮分到一半。如果想做成"第一个按钮占四分之一，第二个按钮占四分之三"，就把第一个weight设为1，第二个设为3，总权重为4。

如果容器里还混着没有weight的子View，那些View先按照layout_width或layout_height占据原始尺寸，剩下的空间才交给设置了weight的View去分。这个机制很容易让人困惑，但理解了公式后一切都会变得清晰。

2.4 divider与基线对齐

divider相关属性常被忽略但很实用。android:divider指定一个Drawable作为分割线，android:showDividers控制显示位置，取值有none、beginning、middle、end，支持用竖线分隔多个值。如果列表项之间需要一条细线，不用额外画View，直接在LinearLayout里配一个shape Drawable就能搞定。

使用divider时有几个细节容易出错。第一，showDividers默认是none，只设divider不设showDividers，什么都不会显示。第二，divider的尺寸和方向要匹配，水平LinearLayout里的分割线通常是一个宽1dp、高match_parent的矩形，垂直LinearLayout里的分割线则相反。第三，dividerPadding不是每个方向都生效，在水平LinearLayout里设置dividerPadding，改的是分割线上下两端的间距，而不是左右间距。

baselineAligned是另一组关于文字基线的属性。默认值为true，表示水平LinearLayout里的子View按文字基线对齐。如果你在水平方向排了一个TextView和一个EditText，希望它们的文字底边对齐而不是顶部对齐，用这个属性就可以实现。baselineAlignedChildIndex可以指定以第几个子View的基线为基准。但实际项目里，基线对齐很容易造成"用起来莫名其妙"的偏移，尤其是混入Button、ImageView这种没有明确文本基线的控件时，我会直接关掉baselineAligned，改用layout_gravity="center_vertical"保持视觉居中。

3. 权重机制深入：公式、案例与常见坑

3.1 剩余空间分配公式的手算过程

要真正搞懂weight，必须做一次手算。假设父容器是一个水平LinearLayout，总宽度为200dp，里面有两个Button。按钮A设置layout_width="100dp"，weight="1"；按钮B设置layout_width="50dp"，weight="1"。

系统第一遍测量时，先按照每个子View的layout_width算出原始尺寸：A占100dp，B占50dp，两者合计150dp。父容器总宽200dp，剩余空间就是200减150等于50dp。接着开始分配剩余空间，总权重是1加1等于2，A分到50乘以二分之一等于25dp，B也分到25dp。最终A宽125dp，B宽75dp。

看到这里你应该明白了，权重不是在原始宽度上按比例缩放，而是在剩余空间上按比例分配。所以两个子View即使weight完全相同，如果原始尺寸不同，最终宽度也完全不同。这就是为什么很多人写了weight之后发现"怎么还不是均分"的原因。

如果你想让两个子View严格等比，正确做法是把它们的主轴尺寸都设为0dp。此时A原始尺寸是0，B原始尺寸也是0，剩余空间等于父容器总宽200dp，总权重为2，A和B各分到100dp，真正实现了五五分。

3.2 wrap_content与0dp的经典纠葛

很多人在使用weight时保留layout_width="wrap_content"，期望达到按比例分配的效果，结果发现内容更长的那个View明显更宽。这仍然是公式在起作用。我们再来算一个例子：父容器宽300dp，两个TextView，左边内容实际宽80dp，右边内容实际宽20dp，两者weight都为1。

第一遍测量后，左边原始尺寸80，右边原始尺寸20，剩余空间200。按权重分配后，两边各得到100。于是左边最终宽度是180，右边最终宽度是120。表面上看两个View的weight都是1，但宽度比是3比2而不是1比1。内容越长，原始尺寸越大，差距越明显。

解决套路非常简单：只要你想在主轴方向按权重精确分配，就把主轴方向上的layout_width或layout_height设置为0dp。0dp消除了"原始尺寸"这个变量，让剩余空间成为唯一决定性因素。反过来，如果你希望先让View按照内容自适应、再用权重处理多余空间，那就要有意保留wrap_content，并利用上面的公式做混合布局。

3.3 weightSum的使用边界与两个大坑

weightSum的常见用法是"规定剩余空间的分母"。比如有三个按钮，我希望B占剩余空间的一半，A和C只按内容显示。可以给父容器设android:weightSum="2"，给B设置android:layout_weight="1"，A和C不设weight。这样剩余空间先减去A和C的原始宽度，剩余值乘以二分之一归B。

这个写法很适合做自适应间距，比写死dp值优雅得多。但两个坑必须记住。第一个：如果所有子View的weight之和大于weightSum，系统不会报错，表现是子View们按各自权重抢占超出分母的份额，最终比例可能完全失控。第二个：如果weightSum设得很大，而某个子View的weight也很大的时候，这个View可能会把剩余空间全部吃掉，其他子View被压缩到最小甚至消失。

排查这类问题，最直接的办法是把weightSum先删掉，观察默认情况下的比例，确认无误后再把总和带进去。如果删掉后一切正常，加回来就出问题，那一定是weightSum与子View总权重不匹配。

3.4 测量过程中到底发生了什么

虽然普通开发者不需要精通View的measure源码，但知道基础流程能帮你少踩很多坑。LinearLayout在onMeasure阶段会做两次测量。第一次测量先按照子View的layout_width或layout_height、margin等计算出每个子View的原始尺寸，得到剩余空间；如果检测到有子View设置了weight并且剩余空间不为0，就会触发第二次测量，把新计算出来的尺寸赋给对应子View。

这正是weight在wrap_content下不够精确的根本原因：第二次测量不是从零开始，而是在第一次wrap_content结果的基础上叠加剩余空间的分配。也就是说，原本"内容决定尺寸"的结果被保留了一部分，权重只能分配到剩余的那部分。

还有一个隐蔽问题：如果你给某个子View设置weight="0"，它不参与分配，但如果同时把它主轴方向上的尺寸也写成0dp，它的原始尺寸就是0，最终可能完全不显示。遇到这种情况，要么给一个具体宽度，要么把尺寸改回wrap_content。

4. 从零搭建一个真实界面：完整实操过程

4.1 目标场景描述

为了让前面这些概念落到实处，我模拟一个非常典型的界面：登录表单页。页面从上到下依次是标题、手机号输入框、密码输入框、性别选项行、底部按钮行、提示文本。这个页面只用LinearLayout就能完成，同时能练到orientation、gravity、layout_gravity、weight、margin、divider等几乎全部基础属性。

4.2 第一版：搭建垂直骨架

我先写根节点LinearLayout，方向设成vertical，让所有内容按从上到下的顺序排列。为了让界面不顶到屏幕边缘，给根布局设置16dp的padding。输入框之间用marginTop来分隔，而不是加入一堆空的View占位。空View占位是新手很常见的坏习惯，它会让布局层级变多，而且维护起来很痛苦，一个margin就能解决的事完全没必要引入新节点。

下面是第一版的XML骨架：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="vertical" android:padding="16dp"> <TextView android:id="@+id/tv_title" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="欢迎登录" android:textSize="24sp" /> <EditText android:id="@+id/et_phone" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入手机号" android:inputType="phone" android:layout_marginTop="16dp" /> <EditText android:id="@+id/et_password" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入密码" android:inputType="textPassword" android:layout_marginTop="16dp" /> </LinearLayout>

这里有两个细节值得说明。第一个，TextView宽度用wrap_content，因为标题文字撑开就够了，不需要占满整行，这样点击区域只在文字周围，不会误触整行。第二个，EditText宽度用match_parent，因为输入框希望尽量宽，方便用户点击和输入。

4.3 第二版：加入性别选项行

接下来加一行性别选项，用水平LinearLayout容纳两个RadioButton。父容器宽度设wrap_content，这样只是包住内容，不占满整行。两个RadioButton之间用marginStart隔开。

<LinearLayout android:layout_width="wrap_content" android:layout_height="wrap_content" android:orientation="horizontal" android:layout_marginTop="16dp"> <RadioButton android:id="@+id/rb_male" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="男" /> <RadioButton android:id="@+id/rb_female" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="女" android:layout_marginStart="16dp" /> </LinearLayout>

我在这里用了marginStart而不是marginLeft，这是Android官方推荐的做法，目的是兼容从右往左排列的语言区域。中文环境下两者效果一致，但从代码规范角度，新项目最好统一使用Start和End。RadioButton默认自带一定的内边距，所以不需要额外加太多间距。

4.4 第三版：用权重做底部按钮行

经典的登录页底部，通常会放"登录"和"注册"两个按钮各占一半宽度。如果直接把两个Button宽度写成match_parent，第一个Button会占满一行，第二个只能另起一行。正确写法是把它们放进一个水平LinearLayout里，宽度match_parent，两个Button的宽度都设为0dp，再分别设置weight="1"。

<LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="horizontal" android:layout_marginTop="24dp"> <Button android:id="@+id/btn_login" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="登录" /> <Button android:id="@+id/btn_register" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="注册" /> </LinearLayout>

这里特别提醒：两个Button之间不要只在一个按钮上添加marginEnd，因为这样会导致两侧剩余空间分配时出现微小偏差，视觉上两个按钮宽度会差1到2dp。如果真的需要按钮之间的间距，正确做法是给两个Button分别设置左右margin，并且让它们的横向margin值加起来一致，或者用一个固定宽度的Space控件作为间隔。最省心的方案是直接不设间距，用背景色或分割线来区分。

4.5 第四版：加一条分割线和提示信息

在性别选项和按钮行之间，如果想加一条水平分割线，可以用divider。先定义一个shape Drawable文件divider_h.xml：

<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape="rectangle"> <size android:height="1dp" /> <solid android:color="#DDDDDD" /> </shape>

然后在任意LinearLayout中启用：

android:divider="@drawable/divider_h" android:showDividers="middle" android:dividerPadding="8dp"

注意，这个divider如果用在水平LinearLayout里，高度必须设置为1dp，但宽度要足够参考实际需求；如果用在一个垂直LinearLayout里，shape的宽度要设为match_parent，高度保持1dp。大部分人不显示分割线的原因都是忘了写showDividers，因为默认值是none。

提示信息我放在底部，宽度match_parent，文字用gravity="end"靠右显示。这里用gravity而不是layout_gravity，是因为TextView已经占满整行，需要控制的是文字在控件内部的位置。如果写成layout_gravity="end"，由于控件本身宽度已经等于父容器宽度，没有任何剩余空间，属性会被忽略。

4.6 运行效果与调整实录

把上述页面跑起来后，最典型的问题是输入法弹出后页面被顶上去，底部按钮被软键盘遮挡。这个问题的根因不在LinearLayout，而是Activity的软键盘模式。在Manifest里给当前Activity设置android:windowSoftInputMode="adjustResize"，并且把根布局替换成ScrollView包裹，就能在多数情况下避免遮挡。

这里要特别说明：ScrollView本身不是布局容器思维，它只允许一个直接子View。通常做法是ScrollView下面直接挂一个垂直LinearLayout作为唯一子View，再在这个LinearLayout里放内容。同时ScrollView需要设置fillViewport="true"，否则当内容高度不足时，内部LinearLayout不会自动撑满全屏，背景色或底部内容的位置会和预期不符。

另外在调试过程中我发现，标题TextView一开始用了match_parent加上gravity="center_horizontal"，等价于文字居中，但整个标题区域会占据一整行宽度，导致点击标题时整个屏幕宽度范围都是响应区域。后来改成wrap_content加layout_gravity="center_horizontal"，让控件只包住文字本身，点击区域更合理。

5. 常见问题与排查技巧实录

5.1 layout_gravity设了没反应

这个问题的出现频率非常高。报错形式通常是：在垂直LinearLayout里给子View设了layout_gravity="center_vertical"，但位置纹丝不动。首先要理解，LinearLayout的layout_gravity只在副轴方向生效。垂直布局的副轴是水平方向，所以center_horizontal、start、end这些有效，而center_vertical属于主轴方向，基本无效。水平布局则相反，layout_gravity="center_horizontal"无效，center_vertical才有效。

除了方向问题，还有两个容易踩的原因。第一个是控件尺寸已经占满了父容器的剩余空间，比如宽度match_parent，没有剩余空间自然无法对齐。第二个是属性写错了位置，layout_gravity是子View的属性，而不是父容器的属性，很多人写在LinearLayout节点上，当然不会对子View产生任何效果。检查时可以先在调试阶段加上不同背景色，确认剩余空间是否存在，再判断方向问题。

5.2 权重没有按预期比例分布

权重问题九成出在layout_width或layout_height与weight的组合上。前面反复强调过，只有0dp加weight才能实现纯粹的按比例分配。如果发现weight为2的按钮只比weight为1的按钮多了一丁点宽度，几乎可以断定那个按钮的宽度是wrap_content，内容大小把权重效果稀释了。

另一个隐蔽坑是父容器在主轴方向上的尺寸是wrap_content。如果你给垂直LinearLayout高度设为wrap_content，那么子View们拿到的剩余空间天然就是0，因为父容器的高度等于所有子View高度之和。此时子View就算写了weight也不会生效。把父容器改成match_parent或固定高度，效果立刻出现。

weightSum不匹配也会引发诡异现象。当子View的总权重大于weightSum时，比例会失真；当总权重小于weightSum时，剩余空间分不完，留出一段空白。排查思路是去掉weightSum，用默认总权重跑一遍，看比例是否正常。

5.3 嵌套过多导致卡顿或宽度无限撑大

LinearLayout层层嵌套带来的问题有两个：一是性能，二是布局计算的不确定性。在measure阶段，每一层都要递归调用子View的测量方法，层级越深，调用次数越多。如果页面上有列表，列表项里再嵌套五层LinearLayout，滚动时卡顿会非常明显。

优化方式不只是"改成ConstraintLayout"这一条路。很多嵌套可以用单个LinearLayout加weight解决。比如"左侧图标、中间文字、右侧箭头"这类经典列表项，一个水平LinearLayout就能搞定，没必要再包一层相对布局。真正复杂到自由定位、百分比约束的时候，再考虑ConstraintLayout也不迟。

宽度无限撑大这个问题也常见于水平LinearLayout：某个子View内容非常长，且子View宽度是wrap_content，系统会优先满足它的测量需求，导致这个子View把父容器宽度不断撑大，直到超出屏幕。解决办法是给这个子View设置layout_width="0dp"+weight，限制它在父容器宽度范围内分配空间，或者使用android:maxWidth限制最大宽度。

5.4 divider不显示或显示位置不对

如果你配好了divider却什么都没出现，检查顺序如下。第一，确认showDividers不是none，必须设置为beginning、middle、end或者组合。第二，确认Drawable的尺寸方向与LinearLayout方向匹配。水平LinearLayout需要宽度很小的分割线，垂直LinearLayout需要高度很小的分割线。如果是shape，宽度或高度至少要有一个确定值。第三，确认Drawable的可见性，solid颜色不能是纯透明。

如果divider出现了但位置奇怪，多半是dividerPadding的方向理解错了。在水平LinearLayout中，dividerPadding调整的是分割线上下两端的间距；在垂直LinearLayout中，调整的是左右两端的间距。很多人在水平布局里想调整左右间距，却设置dividerPadding，自然没有效果。

5.5 基线对齐造成意外偏移

baselineAligned默认是true，在水平排列的多个纯TextView场景下通常符合直觉。但一旦混入Button、EditText、ImageView，基线参考点就很难控制。Button文本默认垂直居中，EditText有自己的文字内边距，ImageView完全没有基线概念，系统最终只能强行找某个子View的基线来对齐，于是整个组件组出现肉眼可见的偏移。

我比较推荐的替代方案是：先用gravity="center_vertical"让组件在副轴方向居中，如果必须让两段文字底部对齐，就给他们设置相同的高度，再用gravity="bottom"内部对齐。这样比依赖baselineAligned稳定得多。当然，理解baselineAligned仍然有必要，因为不少第三方控件内部会默认使用它，出了问题要知道去android:baselineAligned="false"关闭。

5.6 我说一个一直有效的排查习惯

写了很多年布局，我慢慢养成了一个固定习惯：每写一个LinearLayout之前，先在脑子里把主轴方向想清楚，然后问自己三个问题。第一，子View在主轴方向需不需要按比例分配空间？如果需要，就坚定地使用0dp加weight。第二，副轴方向要对齐到什么位置？用父容器的gravity还是子View自己的layout_gravity？第三，父容器在主轴方向是否有剩余空间？如果没有，权重写了也白写。

这三步想清楚，大部分布局异常都能在写代码之前避免。另一个小技巧是，调试时给LinearLayout和子View都加上临时背景色，用色块直观观察每个控件实际占用的空间边界，比盯着属性文件猜快得多。问题修复后再把背景色删掉。这套方法陪伴了我很长时间，遇到再复杂的布局问题，我都会先回到这一步。