在Android的线性布局LinearLayout中，layout_weight是一个非常常用却又容易出错的属性。它可以按照比例分配剩余空间，实现按钮平分屏幕宽度、输入框自适应拉伸等效果。但如果对其分配机制理解不透彻，写出来的界面经常出现比例失调、控件被压缩甚至消失的情况。这篇文章就把layout_weight的计算逻辑、常见用法和性能注意点一次讲清楚。
layout_weight的分配原理：剩余空间是怎么算的
很多人以为weight是直接按比例分配父容器的全部空间，其实不是。LinearLayout分配的是剩余空间，也就是父容器总尺寸减去所有子控件自身尺寸之后多出来的那部分。系统默认的计算公式是：子控件最终尺寸 = 子控件原始尺寸 + 权重比例 × 剩余空间。其中权重比例等于该控件的weight值除以所有控件weight之和。
举个具体例子：一个水平方向的LinearLayout宽度为300dp，里面放两个TextView，宽度都设为0dp，weight分别为1和2。由于两个控件本身宽度是0，剩余空间就是完整的300dp，于是第一个分到100dp，第二个分到200dp。这就是最典型的等比分配写法。
但如果不把宽度设为0dp，情况就变了。假设两个TextView宽度都是100dp，weight分别是1和1，此时剩余空间为300 - 200 = 100dp，每个控件各分得50dp，最终宽度都是150dp。可以看到，控件自身宽度参与了计算，这也解释了为什么同一个weight值在不同写法下效果完全不同。
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal">
<TextView
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="占三分之一" />
<TextView
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="2"
android:text="占三分之二" />
</LinearLayout>weightSum属性与0dp写法的最佳实践
LinearLayout还提供了一个weightSum属性，用来手动指定权重的总和。设置之后，子控件的weight是相对于weightSum来分配的，而不是所有子控件weight的实际和。比如父容器weightSum设为3，一个子控件weight设为1，它就占父容器的三分之一。这个属性在只需要一个子控件按比例占位时特别有用，不用为了凑比例额外塞占位控件。
关于宽度到底写0dp还是match_parent，社区有过不少讨论。在weight分配机制中，写0dp表示控件自身不占用初始空间，所有空间都按权重分配，这是最直观、最推荐的方式。而早期有一种写法是把宽度设为match_parent并配合weight，利用负的剩余空间实现反比例压缩，这种写法虽然曾经被用来解决某些分割线场景，但可读性差、行为反直觉，现在已经不推荐使用。
还有一个常见的坑：在垂直方向的LinearLayout里给子控件设置weight时，对应的高度也应该写0dp；水平方向则对应宽度写0dp。方向搞反了会导致测量结果异常，控件可能完全不显示。另外，weight值支持小数，比如0.5、1.5都是合法的，按需设置即可。
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:weightSum="4">
<!-- 顶部内容占四分之一 -->
<View
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1"
android:background="#4CAF50" />
<!-- 底部内容占四分之三 -->
<View
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="3"
android:background="#2196F3" />
</LinearLayout>性能问题与替代方案：weight用多了会怎样
layout_weight除了语义上的坑，还有性能上的代价。当LinearLayout中存在带weight的子控件时，系统需要对子控件测量两次：第一次正常测量确定原始尺寸，第二次再根据剩余空间重新分配。对于简单的布局这点开销可以忽略，但如果weight出现在列表项RecyclerView的item布局中，每个条目渲染时都重复执行两次测量，滚动性能就会受到明显影响，尤其在低端设备上更容易掉帧。
所以在列表item这类高频渲染的布局里，应尽量减少weight的使用。能通过固定尺寸、ConstraintLayout的百分比约束或者Guideline实现的等比效果，优先考虑替代方案。ConstraintLayout提供了layout_constraintWidth_percent等属性，可以直接按父容器百分比设定尺寸，一次测量即可完成，性能优于weight方案。
当然，weight本身并不是禁用的属性。在Activity整体布局、设置页面分区、登录界面表单区域这类只渲染一次的场景中，weight依然是最简洁的比例分配手段，代码量少、意图清晰。关键是要理解它的分配逻辑：记住剩余空间的概念、对应方向写0dp、列表布局慎用，就能避开绝大多数问题。
<!-- 典型的登录表单场景：输入框自适应，按钮固定 -->
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
android:padding="16dp">
<EditText
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:hint="请输入用户名" />
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="搜索" />
</LinearLayout>总结一下，layout_weight的核心是按权重分配剩余空间，配合0dp使用才能得到纯粹的等比效果；weightSum可以手动约定权重基数；性能敏感的列表布局建议用ConstraintLayout替代。掌握这几点，线性布局的权重设置基本就不会再出问题了。
layout_weight线性布局Android开发修改时间：2026-09-13 16:34:59