1. 线性布局的设计思路与定位
1.1 线性布局到底解决了什么问题
我在做Android开发的前几年，有个特别深的感触：很多人一上来就去学RelativeLayout、ConstraintLayout这些“高级”布局，结果写出来的界面一团糟，改一个按钮位置得折腾半天。反倒是LinearLayout这个听起来平平无奇的基础布局，能把界面写得明明白白。
线性布局的核心思想就一句话：所有子View沿着同一方向依次排列。要么横着排，要么竖着排，排列方式极其简单。但就是这种“简单”，反而解决了实际开发中的大多数排列需求。比如顶部导航栏上的返回按钮和标题，本质就是水平排列；注册页面的用户名、密码、确认密码，本质就是垂直排列。线性布局把这种最常见的排列需求抽象成了一种机制，你只需要告诉它“横着排还是竖着排”，剩下的交给系统去算。
从实际工程角度来看，线性布局最适合的场景有三个：第一是表单类页面，从上到下逐行排列，用户阅读和操作都顺手；第二是复杂的复合控件，比如一个自定义的搜索框，左边图标、中间输入框、右边按钮，横向排开即可；第三是作为列表项的根布局，绝大多数列表条目都是左图右文，或者上标题下副标题，LinearLayout配合weight权重能非常优雅地实现等分布局。
1.2 为什么选择LinearLayout而不是其他布局
很多刚接触Android的新人会问：现在不是都在用ConstraintLayout吗？为什么还要学LinearLayout？我的回答一直很直接：LinearLayout是理解Android布局系统的基础，也是保障兼容性的兜底方案。
ConstraintLayout在Android 2.0时代才加入AndroidX库，虽然现在已经是主流，但在一些老项目的维护场景、第三方SDK的页面里，LinearLayout依然大量存在。更重要的是，LinearLayout的布局计算逻辑非常简单，绘制性能在简单场景下往往更好。我在实际项目的性能分析中测过：一个包含3-4个子控件的线性布局，measure和layout的开销微乎其微；而ConstraintLayout为了保证灵活约束，在约束较多时会做更多计算。当然这不是说ConstraintLayout不好，而是说不同布局有自己的适用面。
从学习路线上讲，我更建议初学者先用LinearLayout把两个基本功练扎实：一个是measure过程（父布局测量子View的尺寸），一个是layout过程（父布局决定子View的位置）。这两块搞明白了，再看ConstraintLayout的约束链、偏差比例这些概念，会轻松得多。说到底，LinearLayout是那个“先筑基”的布局。
2. 线性布局的核心细节与实操要点
2.1 orientation：横排还是竖排，这是一个方向问题
orientation属性是线性布局的第一个开关，取值就两个：horizontal表示水平排列，vertical表示垂直排列。这个属性直接决定了子View的排列起点坐标。
在水平排列模式下，子View的X坐标从左往右逐个累加，先放第一个，然后以第一个的右边界为起点放第二个，以此类推。这里有个初学者经常忽略的细节：如果子View的总宽度超过了父容器宽度，超出的部分不会自动换行，而是直接溢出屏幕边界。LinearLayout不具备自动换行能力，这一点和后面要讲的FlowLayout或者ConstraintLayout的链式约束不一样。如果发现内容被挤出去了，优先检查是不是orientation设错了方向，再检查子View的宽度是不是用了match_parent。
垂直排列的道理完全一样，只不过换成了Y坐标从上往下。还有一个组合技巧：外层LinearLayout用vertical，内层子布局再用horizontal，这就是“嵌套线性布局”的基本形态。比如一个聊天消息气泡，左侧头像用垂直布局（头像在上，昵称在下），右侧消息内容用垂直布局（昵称在上，内容在下），中间再用水平布局把它们并排起来，一套下来就能拼出很复杂的消息列表结构。
2.2 gravity和layout_gravity：两个重力，职责完全不同
线性布局里最容易混淆的两个属性就是gravity和layout_gravity，我在面试候选人的时候基本都会问一道相关的题。简单粗暴的记忆法是：gravity是管内部孩子的，layout_gravity是管自己位置的。
gravity写在LinearLayout上，作用对象是它内部的所有子View，控制的是子View在父布局内的对齐方式。比如一个LinearLayout的宽高都设置了match_parent，此时给它的gravity设center_horizontal，所有子View都会水平居中。这个属性对“排列起点”后的空间分配非常有用：在线性布局里，子View排完后往往会有剩余空间，gravity就是决定这些剩余空间如何分配给子View的对齐方式。
而layout_gravity写在子View上，作用对象是子View自身，控制的是这个子View在父容器里的对齐位置。这里有个特别容易踩的坑：在LinearLayout中，如果父布局方向是horizontal，那么layout_gravity的垂直对齐属性（top、bottom、center_vertical）是生效的，但水平对齐属性（left、right、center_horizontal）是失效的，因为水平位置已经被排列顺序决定了；反之亦然。很多新手把layout_gravity设成center，期待子View能在父容器正中间，结果发现纹丝不动，就是因为这个原因。正确的做法是：想让子View相对父容器居中，要么给父布局的gravity设置center，要么用layout_gravity配合正确方向。
2.3 layout_weight：线性布局里最值钱的权重机制
如果问线性布局里哪一个属性最实用，我会毫不犹豫说layout_weight。这个属性的核心作用是把剩余空间按比例分配给子View，从而实现灵活的比例布局。为什么要强调“剩余空间”？这里面有一套完整的计算逻辑。
假设有一个水平排列的LinearLayout，宽度300dp，放两个子View。第一个子View的宽度是100dp，第二个子View的宽度是100dp，它们加起来200dp，此时还剩下100dp空间。如果第一个子View没设weight，第二个子View设了weight=1，那么这剩下的100dp会全部给第二个子View，最终第一个宽100dp，第二个宽200dp。
这是weight的基本原理，但实际开发中更常用的是等分场景。要让两个子View平均占据父容器宽度，正确写法是：让它们的layout_width都设成0dp，然后各自layout_weight设为1。注意，宽度设成0dp是关键。这时候LinearLayout会把所有子View的宽度当成0来看，整块300dp都变成“剩余空间”，然后按权重比例分配，于是每个子View拿到150dp，实现精确等分。
这个计算过程可以用一个公式来总结：最终宽度 = 自身宽度 + (父容器总宽 - 所有子View宽度之和) × (自身weight / 总weight)。我见过不少人在网上问：为什么我把两个子View都设了weight=1，结果却不是等分？十有八九是忘了把宽度设成0dp，或者设成了wrap_content。当宽度是wrap_content时，子View的内容本身有宽度，剩余空间的分配会基于内容宽度之差，表现出来就是分成比例不对。所以我的建议是：需要等分就用0dp，不需要等分但只想让某个View“吃掉多余空间”，就保持它的宽度为wrap_content或固定值，只给它设weight。
2.4 尺寸、间距和其他容易被忽视的属性
除了上述核心属性外，还有几个属性虽然不起眼，但在实际开发中能救命。
weightSum是用来控制权重总和的。默认情况下，LinearLayout会拿所有子View的weight之和作为分母，但如果你手动设置了weightSum，就相当于固定了分母。这个属性用在“进度条分割”类的场景特别顺手：父布局weightSum设为10，三个子View的weight分别设为3、5、2，它们就会按照30%、50%、20%的比例占据空间，而且不管父容器尺寸怎么变，比例保持不变。
divider和showDividers是给线性布局添加分割线的。divider接收一个Drawable，showDividers支持四个值：beginning、middle、end、none。用这个组合替代在每个子View底部画一圈背景线，代码会干净非常多。这里有个细节：分割线的宽度，如果是水平布局，需要把divider的shape宽度设成具体像素值，而不是wrap_content，否则可能不显示。
baselineAligned是线性布局另一个容易出问题的属性。默认情况下，水平排列的子View会进行基线对齐，这导致一个现象：当子View里既有文本又有按钮时，文本的基线和按钮的文本基线会被强行对齐，视觉上可能出现细微偏移。如果发现水平布局里元素总是对不齐，试着加android:baselineAligned="false"，很多时候问题瞬间解决。代价是会失去基线对齐的观感，但换来的是更可控的布局。
3. 实操过程：从零搭建线性布局界面
3.1 新建项目和基础配置
我平时讲实操课，总是让学生先不急着写代码，而是把项目的底子打好。用Android Studio创建一个新项目，选择Empty Views Activity模板，语言选择Kotlin（现在Google官方推荐的也是Kotlin），最低SDK版本根据你要兼容的设备来定，一般设Android 21就够了，覆盖95%以上的用户。
在真正使用LinearLayout之前，先做两个准备。第一是打开activity_main.xml，确认根布局已经被改成了LinearLayout；第二是准备好预览工具，Android Studio自带的Preview面板能实时显示XML效果。这里提个建议：写布局代码的时候，把预览和代码编辑器设为左右分屏，每次改一个属性，右边立刻能看到变化，这种即时反馈对新手理解属性作用非常有帮助。不夸张地说，我在初学阶段有一半的知识是靠拖拽、改属性、看预览这样“玩”出来的。
3.2 第一个垂直列表界面：注册表单布局
我们来实现一个最简单的注册表单界面：用户名输入框、密码输入框、登录按钮，三行从上到下排列。根布局用垂直LinearLayout，代码如下：
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="16dp"> <EditText android:id="@+id/et_username" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入用户名" android:inputType="textPersonName" /> <EditText android:id="@+id/et_password" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入密码" android:inputType="textPassword" /> <Button android:id="@+id/btn_login" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="登录" /> </LinearLayout>这段代码里有几个细节值得说。第一个是根布局的layout_width和layout_height都用了match_parent，因为作为整个Activity的根布局，它需要填满屏幕。第二个是内边距padding，如果不加这16dp，输入框就会顶到屏幕边缘，视觉上很难看。third是EditText的inputType，密码框必须用textPassword，这样输入内容会被遮蔽，这是安全规范的一部分，做敏感信息输入时一定不能忘。
运行一下，你会发现三个控件垂直排列，每个控件的宽度都是撑满父容器的。这里还有个隐藏知识点：Button的layout_width和EditText一样是match_parent，但在垂直布局里不会出现问题；而如果放到水平布局里，一个match_parent的Button就会把后面的其他控件全部挤到屏幕外，我们在后面排查问题时会再提这个坑。
3.3 等分场景：用weight制作tab选项卡
接下来做一个小场景：一个底部的tab栏，四个图标均分宽度。这种场景在App里极其常见，底部导航栏的核心就是等分。
<LinearLayout android:layout_width="match_parent" android:layout_height="56dp" android:orientation="horizontal"> <TextView android:layout_width="0dp" android:layout_height="match_parent" android:layout_weight="1" android:gravity="center" android:text="首页" /> <TextView android:layout_width="0dp" android:layout_height="match_parent" android:layout_weight="1" android:gravity="center" android:text="发现" /> <TextView android:layout_width="0dp" android:layout_height="match_parent" android:layout_weight="1" android:gravity="center" android:text="消息" /> <TextView android:layout_width="0dp" android:layout_height="match_parent" android:layout_weight="1" android:gravity="center" android:text="我的" /> </LinearLayout>四个TextView的宽度都设成0dp，这意味着在measure阶段，系统会跳过它们的原始宽度，把所有空间都留给weight分配。每个控件的weight都是1，总和是4，所以每个控件拿到四分之一的宽度。这段代码跑在360dp宽度的模拟器上，每个tab正好90dp，不差一像素。
这里要特别提醒一个实战心得：给TextView设置android:gravity="center"而不是layout_gravity，因为gravity在这个场景里是让“文本内容”在TextView内居中，而layout_gravity在水平排列的父布局里只能垂直微调，起不到水平居中作用。很多新手在这里栽跟头，界面上显示的文字永远偏左，其实就是写错了gravity。
3.4 动态添加子View：Java/Kotlin代码创建LinearLayout
有时候XML不够用，需要在代码里动态创建布局。最典型的是从数据列表动态生成若干条文字标签。用Kotlin写起来非常直观：
val container = LinearLayout(this).apply { orientation = LinearLayout.VERTICAL layoutParams = LinearLayout.LayoutParams( ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.WRAP_CONTENT ) } repeat(5) { index -> val textView = TextView(this).apply { text = "动态条目 $index" textSize = 16f setPadding(16, 16, 16, 16) layoutParams = LinearLayout.LayoutParams( ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.WRAP_CONTENT ) } container.addView(textView) }这段代码的要点在于LinearLayout.LayoutParams。很多人直接就用ViewGroup.LayoutParams，结果发现子View设置weight完全不生效。原因就是LinearLayout在measure子View时，会尝试把布局参数强转为它的内部类LinearLayout.LayoutParams，如果类型不对，weight字段根本没有，自然就失效了。所以我建议：只要是往LinearLayout里面addView，布局参数一律用LinearLayout.LayoutParams。
另外，动态创建时如果想让子View之间有间距，不要挨个设置margin，直接在for循环外面新建一个Space占位控件往里加，代码量反而更少，也更容易控制间隙的统一性。
4. 常见问题与排查技巧实录
4.1 weight完失效，到底哪里出了问题
我见过最多的线性布局Bug就是weight失效。表现形式有两种：一是两个子View纹丝不动，完全没有按比例分配；二是某几个子View直接不见了。
先说第一种。weight失效常见的根源有三个：第一个是子View的宽度/高度没有设为0dp，如前面所说，只有设了0dp，weight才能完全接管尺寸，否则走的是“先占位、再分配剩余空间”的复杂逻辑，比例看着总不对；第二个是父布局方向搞反了，水平排列时你给子View设的是android:layout_width的weight，结果你改的是layout_height，那自然没有效果；第三个是真的“没有剩余空间”，父容器宽度刚好被所有子View的固有宽度填满，没有剩余可言。排查顺序应该是：先看方向，再看0dp，最后看有没有别的高权重View在抢空间。
第二种“子View不见了”的案例，我印象很深。有一次同事的项目里，一个按钮在水平LinearLayout里永远不显示，查了半天才发现它的layout_width是match_parent，在水平方向上一个match_parent横扫过去，后面的控件全被挤出屏幕。因为线性布局不换行，溢出部分直接不可见。这个坑只要碰到一次就不会忘，排查思路就是按住ctrl键，在Android Studio的预览面板里鼠标点击控件，看它实际bound的位置，会发现它被推到了父容器之外。
4.2 嵌套层级过深，布局卡顿怎么优化
有经验的工程师一定见过这种代码：LinearLayout套LinearLayout再套LinearLayout，层层叠叠十几层，页面卡得不行。这种情况在低端机上尤其明显，因为布局嵌套越多，measure和layout阶段要递归的次数就越多，每多一层嵌套，遍历的节点数就可能翻倍。
一个典型的场景是列表item：外层垂直LinearLayout，里面一个水平LinearLayout放头像和名字，再里面一个垂直LinearLayout放标题和描述，如果图标这里再来一个LinearLayout，那一次绘制就跑了五六个层级。优化思路有三个层次：第一，能用merge标签合并的就合并，当某个LinearLayout的子View只有一层时，这个LinearLayout本身往往是多余的，删掉子View直接挂在父节点上即可；第二，用ConstraintLayout减少嵌套，一个约束布局能打平原来三四层的结构；第三，给根节点加android:clipChildren="false"或者elevation属性之前一定要想清楚，不必要的setWillNotDraw调高、去掉默认背景，也能省掉一些绘制开销。
说到底，线性布局的嵌套要遵循“能少则少”的原则。一个页面里LinearLayout不超过三层是合理范围，超过五层且有大列表，建议直接用RecyclerView + ConstraintLayout重构。
4.3 对齐效果总不对，gravity和layout_gravity的坑
一个常见的错误写法是：水平LinearLayout里放一个垂直LinearLayout，希望它居中显示，于是给垂直LinearLayout设置了layout_gravity="center"。结果只实现了垂直居中，水平方向上它仍然贴着左边。原因就是水平排列的父容器里，子View的水平方向位置由“排列顺序”决定，layout_gravity只能影响对应方向。
解决办法有两种。第一种是给这个子View设置一个固定宽度，然后把layout_gravity设成center_horizontal，在水平LinearLayout里虽然这个属性看起来不生效，但其实当父容器的gravity允许“填写”时，它会作用于相反方向，原理有些绕，结论是你试了就知道并不好用。第二种经验做法更简单：在外面套一层FrameLayout，把真正想居中的LinearLayout放进去，然后用layout_gravity居中，因为FrameLayout允许子View自由对齐。
还有一种情况是文本和图标怎么都对不齐。比如一行水平布局里，左边一个图标，右边一个Text，Text总感觉比图标高一点点。这时检查baselineAligned属性，如果设成false之后反而更符合预期，说明之前是对文本基线自动对齐了。基线对齐会强制让不同控件的文字基线处在同一水平线上，但这在混排图标和文字时就反而会产生垂直偏移。方案就是显式设android:baselineAligned="false"，再手动微调margin。
4.4 屏幕适配：为什么在不同手机上比例不一样
线性布局的适配问题上，最常见的是没有处理好dp和px的换算，或者用错了match_parent和wrap_content。dp是Android推荐的尺寸单位，它保证在不同屏幕密度的设备上，物理尺寸大致相同。如果写死了layout_width="200dp"，在360dp宽度的手机上是半屏，在400dp宽度的手机上就不是半屏，于是出现比例不一致。
要保证比例一致，只能用weight，而不是固定宽度。比如一个左右结构的搜索框，左边输入区、右边按钮，想让输入区尽可能长、按钮保持固定宽度，那就输入区宽度match_parent，按钮宽度wrap_content，然后输入区加layout_weight="1"。按钮设0dp也行，总之不能两个控件都写死固定宽度。另一个适配问题是字体大小，文本要用sp，不能用dp作字号单位，并且不要把字号写死完，可以考虑用sp配合系统字体缩放，这和线性布局关系不大，但你在布局里放进TextView时一定会遇到。
屏幕适配的排查方法也比较直接：在Android Studio里建几个不同尺寸的预览设备，比如Pixel 4（尺寸小）和Pixel 6（尺寸大），然后逐个预览布局。如果某个固定宽度的View在最大尺寸的模拟器上依然顶着屏幕边缘，说明布局方案本身就没考虑适配。
5. 线性布局的优化与代码习惯建议
5.1 用include和merge提升复用，减少重复代码
实际项目中，同一个头部栏可能出现在十几个Activity中。如果每个页面都复制一份LinearLayout代码，后续想改一个背景色就得全局搜索替换，极其痛苦。正确做法是把这个头部栏的XML抽成一个独立文件layout_header.xml，然后用include标签引入：
<include layout="@layout/layout_header" android:layout_width="match_parent" android:layout_height="wrap_content" />使用include的潜规则有几个。include标签本身不是View，它的宽高属性主要用来控制被引入布局的尺寸，因此如果外部指定了宽高，内部的根布局宽高会被覆盖。如果你发现include进来的布局尺寸不可控，多半是这里的约束没搞对。另一个优化点是合并层级：如果被引入的XML根节点是LinearLayout，而你在外部又套了一个LinearLayout，就会多一层容器。此时可以让被引入布局的根节点使用merge标签，include后不会增加额外的嵌套层。例如：
<merge xmlns:android="http://schemas.android.com/apk/res/android"> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="取消" /> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="确定" /> </merge>merge标签理解起来其实不复杂：它告诉系统“我的内容直接合并进父布局”，它本身不是View节点。用这种方式，在水平LinearLayout里include这段，最终的层级就只有LinearLayout和两个Button，没有中间层。这类优化在UI层级多的时候非常值得做。
5.2 布局性能检查工具：Layout Inspector和Lint
写线性布局、排查布局问题的过程中，两个工具我用得最多。第一个是Android Studio的Layout Inspector。在模拟器上运行App后，从Tools菜单进入Layout Inspector，它可以展示当前界面的完整视图层级树，包括每个节点的测量尺寸、实际位置、以及套用的属性。排查“这个控件为什么多占了一段空间”“这个嵌套层级怎么这么深”这类问题时，Layout Inspector给的信息很直观。
第二个是Lint静态检查工具。Android Studio的Analyze菜单下有一个Inspect Code，它会扫描你的XML布局，给出性能警告。比如它可能提示“This LinearLayout can be replaced with a horizontal LinearLayout layout_weight=1”，或者告诉你某个布局层级可以被merge替代。这些提示虽然不一定百分之百准确，但八九不离十，相当于一个免费的性能顾问。我自己的做法是每周跑一次Lint，把布局相关的warning全部清掉，久而久之，代码里就没有什么隐藏的布局杀手了。
还有一个小技巧值得分享：如果你在验证一个复杂布局到底卡不卡，可以打开手机的“开发者选项”里的“显示布局边界”，屏幕上会画出每条View的边界框。边界框越多、越密，说明层级越深、越容易卡顿。这个方法帮我在很多项目里快速锁定了“元凶” —— 一个看起来毫无问题却嵌套了6层的线性布局。
5.3 什么时候该告别LinearLayout，投向ConstraintLayout
我不主张无脑推崇LinearLayout，也不觉得每个页面都非要用它。在简单结构、二三层嵌套以内的场景，LinearLayout完全够用，代码简洁易懂，维护成本极低。但如果界面结构复杂，比如一个卡片内有多组相对位置关系（头像左上角、标签比例分布、进度条底部延伸），再用LinearLayout强行拼装，层级会迅速膨胀，这种时候换成ConstraintLayout更明智。
我个人的选型标准非常主观但很实用：如果线性布局在不嵌套超过4层的情况下能表达清楚界面，就用LinearLayout；一旦发现需要在某个节点里再叠三层LinearLayout才能达到效果，立刻改用ConstraintLayout。ConstraintLayout在复杂场景下能把十几个节点压成几个，而且它的指导线、链条和偏差比例能实现更灵活的比例布局。不过我要坦白讲：约束布局的学习曲线比线性布局陡，尤其是链条（chain）和偏差（bias）的概念，需要一点时间去消化。好在它们并不冲突，把LinearLayout练熟了，再上手约束布局是水到渠成的事。
最后分享一个我个人工作中的习惯：写布局的时候，我习惯先从LinearLayout起手搭第一版结构，确保逻辑清晰地表达“有哪些区域、从上到下还是从左到右”，然后再审视哪些部分可以优化成更少的层级。很多时候第一版就能直接用，偶尔需要重构成ConstraintLayout，但重构的前提永远是“我能准确说出这个界面的排列逻辑”。如果没有这个逻辑，不管用什么布局，都会写出让人看不懂的代码。
