RelativeLayout实战指南：锚点思维、性能优化与ConstraintLayout迁移

1. 为什么现在还要学RelativeLayout？先想清楚使用场景

1.1 一个被误解的"老家伙"

先说个我自己的经历。前两年我接手维护一个老项目，里面有一套复杂的个人中心页面，最外层就是RelativeLayout。当时我已经习惯了ConstraintLayout，第一反应是想重构。但等我真正把布局上的约束关系捋了一遍才发现：这套界面有大量的"底部对齐""左边+右边同时锚定""根据控件A的位置决定控件B"的需求，用RelativeLayout表达起来反而是最直观的。后来我没动它，只改了里面的几个嵌套层级。

这就引出一个很朴素的问题：RelativeLayout到现在还有没有学习的必要？我的答案是，有，而且每个Android开发者都应该把它吃透。原因有三：

• 它是理解Android布局体系的一把钥匙。ConstraintLayout的很多约束概念，其实就是从RelativeLayout的相对定位思路扩展出来的。搞懂RelativeLayout，再看ConstraintLayout的constraint_toLeftOf、constraint_alignParentTop这些属性，几乎零成本。
• 老代码和开源项目里到处都是。GitHub上大量早期的开源项目、公司内部维护多年的代码库，RelativeLayout使用率依然很高。读得懂、改得动，是基本职业素养。
• 某些场景下它依然是最优解。往深处说，RelativeLayout的子View不需要像LinearLayout那样层层嵌套，一个布局就能表达"左上右下全对齐"的关系；而ConstraintLayout在这种简单对齐场景下反而显得配置啰嗦。工具链完整、写法直接，是它至今没有被淘汰的理由。

1.2 这篇文章的受众和阅读方式

我默认你至少有Android XML布局的基础，知道怎么新建一个布局文件，看得懂match_parent和wrap_content的区别。如果你完全零基础，也没关系，我会把RelativeLayout的每一个核心属性都拆开讲，配合可运行的代码片段和实际界面效果说明。

你可以把这篇文章当一份"查漏补缺"的复习资料，也可以当成第一次系统学习RelativeLayout的入门教程。核心就一件事：看完之后，你拿到一个界面原型，能第一时间判断该不该用RelativeLayout，并且能熟练写出对应的XML。这篇内容还会穿插一些我实际开发中踩过的坑，这些坑在官方文档里可查不到。

2. RelativeLayout的底层逻辑：两个参照系看懂全部属性

2.1 布局的"锚点思维"

RelativeLayout，翻译过来就是"相对布局"。它和LinearLayout最本质的区别在于：LinearLayout是"排队"，子View按照顺序一个挨一个排；RelativeLayout是"定位"，每个子View都相对于某个"锚点"来决定自己的位置。锚点可以是整个父容器，也可以是另一个子View。

听起来简单，但很多人写RelativeLayout写不好，就是因为没把"锚点"这件事想清楚。我见过不少初级开发者写出这样的代码：想做一个居中标题，用了layout_centerInParent="true"，同时又写了layout_alignParentTop="true"，然后对着屏幕陷入沉思，为什么标题跑到了顶部而不是居中？

这就涉及RelativeLayout一个基本特性：同一个子View的多个定位属性是可以叠加生效的，它们不是互斥关系。alignParentTop把View的上边缘对齐父容器顶部，centerInParent要求View在父容器里水平和垂直都居中，这两个条件同时成立，系统最终会把View放在顶部居中——是的，垂直方向被alignParentTop锁死了，centerInParent只在未被约束的方向生效。这种"约束叠加"的理解方式，是掌握相对布局的第一步。

2.2 相对父容器定位的属性群

RelativeLayout把定位属性分成两大类：一类相对于父容器，另一类相对于兄弟控件。先看相对于父容器的这一组，也是最常用的一组：

layout_alignParentTop 上边缘对齐父容器顶部 layout_alignParentBottom 下边缘对齐父容器底部 layout_alignParentLeft 左边缘对齐父容器左侧 layout_alignParentRight 右边缘对齐父容器右侧 layout_centerHorizontal 水平居中 layout_centerVertical 垂直居中 layout_centerInParent 水平+垂直居中

每个属性的作用都如其名，但有几个细节值得多说两句。

第一个细节：layout_alignParentBottom和layout_centerInParent同时用会怎样？结果是View相对父容器垂直居中的同时，下边缘又对齐父容器底部。如果View高度是固定值，它就会往下沉；如果View高度是wrap_content，那么它的中心会被拉到父容器垂直中心，同时下边缘对齐底部，这两个约束同时要求View的底部等于父容器底部、View的中心等于父容器中心——唯一的办法是View的高度为0，所以实际渲染时会出现难以预料的结果。这个组合基本属于"逻辑上互相矛盾"的配置，实际开发中看到这种写法，大概率是开发者没想清楚要什么效果。

第二个细节：这些属性名称里的Parent指的是"父容器"，也就是RelativeLayout本身。如果你把RelativeLayout嵌在LinearLayout里，alignParentTop锚定的依然是RelativeLayout内部顶部，而不是外面的LinearLayout——除非外层LinearLayout的orientation和gravity恰好把它推到某个位置。锚定的坐标系永远作用于"直接父容器"。

这一组属性在写全屏弹窗、底部操作栏、顶部标题栏时非常高效。举个我经常用的例子，一个"右上角关闭按钮"只需要三行：

<ImageView android:id="@+id/btn_close" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentTop="true" android:layout_alignParentRight="true" android:src="@drawable/ic_close" />

放在任何RelativeLayout里，它都自动待在右上角，完全不需要处理不同屏幕宽度下的位置计算。

2.3 相对兄弟控件定位的属性群

这组属性是RelativeLayout真正有独特价值的地方。先记住一个总原则：凡是带layout_to或layout_align开头、后面跟Left/Right/Top/Bottom、且值写了一个View的id的属性，都是锚定另一个子View。

核心属性如下：

layout_toLeftOf 本View的右边缘在指定View的左边缘左侧 layout_toRightOf 本View的左边缘在指定View的右边缘右侧 layout_above 本View的底部在指定View的顶部之上 layout_below 本View的顶部在指定View的底部之下 layout_alignLeft 本View的左边缘与指定View的左边缘对齐 layout_alignRight 本View的右边缘与指定View的右边缘对齐 layout_alignTop 本View的上边缘与指定View的上边缘对齐 layout_alignBottom 本View的下边缘与指定View的下边缘对齐 layout_alignBaseline 本View的baseline与指定View的baseline对齐

layout_toRightOf是出现频率最高的需求场景：文字左边放一个图标，按钮左边放一个输入框，标签右边放一个数值，全部用它。字面上看，layout_toRightOf的意思是"本View在指定View的右边"，但注意它的精确语义是"本View的左边缘位于指定View的右边缘的右侧"——这是**"不重叠"关系**，而不是"贴住"关系。两个View之间要留间距，就用layout_marginLeft，比如android:layout_marginStart="8dp"。

这组属性还有一个优点：Anchor View（锚定参照物）的位置一旦确定，被锚定的View会自动跟随变化，不需要额外的代码。实际项目里动态增删View时，这个特性省了一大堆重新测量的逻辑。

2.4layout_alignBaseline：文字对齐的最后一块拼图

很多人写表单、写列表项时遇到过这样的问题：一行里左边一个TextView，右边一个TextView，用layout_alignTop对齐，结果两边的文字基线就是差那么几个像素，怎么调都不舒服。这是因为TextView的高度不只包含文字本身，还有fontPadding和行高。用layout_alignTop只能对齐View的上边缘，不能保证文字对齐。

正确的做法是用layout_alignBaseline：

<RelativeLayout android:layout_width="match_parent" android:layout_height="wrap_content"> <TextView android:id="@+id/label" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="价格" /> <TextView android:id="@+id/value" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_toRightOf="@id/label" android:layout_alignBaseline="@id/label" android:text="￥199.00" /> </RelativeLayout>

这样两个TextView的baseline（文字基线）严格对齐，即使一个字号大一个字号小，视觉上也始终是整齐的。这个细节是真正用过RelativeLayout的人才会注意到的。

3. 实战拆解：用相对布局搭一个"商品详情页头部"

3.1 需求分析和布局设计

理论看再多，不动手等于白看。我挑一个电商类App常见的"商品详情页头部"来做完整拆解。

需求描述：

• 最上面是一个占满顶部区域的商品大图
• 图片的左下角叠加一个"包邮"标签
• 图片右下角叠加一个"收藏"按钮
• 大图下方是一行商品名称，文字长度不固定，最多两行
• 名称下方是价格信息，价格左边有一个"促销"角标

这个需求看似简单，但如果你用LinearLayout来写，大图上的标签和按钮需要FrameLayout来完成叠加，价格和角标又要额外嵌套一层Horizontal方向的LinearLayout，至少三层嵌套才能搞定。用RelativeLayout，一个布局就能全部表达：

<RelativeLayout android:layout_width="match_parent" android:layout_height="wrap_content"> <!-- 商品大图 --> <ImageView android:id="@+id/image" android:layout_width="match_parent" android:layout_height="200dp" android:scaleType="centerCrop" android:src="@drawable/product" /> <!-- 包邮标签：相对父容器，左下角 --> <TextView android:id="@+id/tag_free_shipping" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentLeft="true" android:layout_alignParentBottom="true" android:layout_margin="8dp" android:background="@drawable/bg_tag_orange" android:paddingLeft="6dp" android:paddingRight="6dp" android:text="包邮" android:textColor="#FFFFFF" android:textSize="12sp" /> <!-- 收藏按钮：相对大图，右下角 --> <ImageView android:id="@+id/btn_favorite" android:layout_width="32dp" android:layout_height="32dp" android:layout_alignParentRight="true" android:layout_alignBottom="@id/image" android:layout_margin="8dp" android:src="@drawable/ic_favorite" /> <!-- 商品名称：在大图下方 --> <TextView android:id="@+id/title" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_below="@id/image" android:layout_marginLeft="12dp" android:layout_marginRight="12dp" android:layout_marginTop="8dp" android:ellipsize="end" android:maxLines="2" android:text="这是一段很长的商品名称文本，用来演示相对布局中TextView的实际换行效果" android:textColor="#333333" android:textSize="16sp" /> <!-- 促销角标：相对商品名称，左边 --> <TextView android:id="@+id/tag_promo" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignBaseline="@id/title" android:layout_toLeftOf="@id/title" android:background="@drawable/bg_tag_red" android:paddingLeft="4dp" android:paddingRight="4dp" android:text="促销" android:textColor="#FFFFFF" android:textSize="12sp" /> <!-- 价格：在商品名下方，促销角标右边 --> <TextView android:id="@+id/price" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_below="@id/title" android:layout_marginLeft="12dp" android:layout_marginTop="4dp" android:text="￥199.00" android:textColor="#FF2D2D" android:textSize="20sp" android:textStyle="bold" /> </RelativeLayout>

注意我在这里用一个稍作妥协的方案来演示：tag_promo用的是layout_alignBaseline和layout_toLeftOf同时锚定title，而title本身是layout_below="@id/image"，整条链路的参照关系是层层递进、有据可循的。

3.2 每一行代码背后的选择逻辑

刚才的XML里几个决定值得单独拿出来说：

为什么"收藏按钮"用的是layout_alignParentRight+layout_alignBottom="@id/image"，而不是layout_alignParentBottom？从实现效果上看，大图的底部就是父容器相对布局的底部，两个写法效果一致。但语义上，layout_alignBottom="@id/image"更明确：按钮是贴住图片的，如果以后在图片下方加了一个高度为16dp的优惠券区域、且原RelativeLayout的height是wrap_content，按钮就会跟着优惠券区域往下沉，而不是停留在原图片底部。锚定具体View比锚定父容器更抗布局变更。

为什么"包邮标签"不锚定大图？因为大图是match_parent宽、200dp高，它的左边缘和底边缘与父容器完全重合，所以锚定父容器和锚定大图没有差别。但如果大图改成了wrap_content或者加了scaleType调整，锚定对象不同就会产生差异。我的建议是：视觉上确实要贴住哪个对象，就锚定哪个对象，别省这一行。

为什么"促销"角标要用layout_toLeftOf="@id/title"而不是放在title内部用drawableLeft？因为角标需求是独立的、可能有自己的点击事件，和文本内容没有关系。drawableLeft虽然也能画出一个小图标，但无法独立控制它的点击区域、背景形状和间距，维护性差。

3.3 看看最终效果的等价关系

你可以把上面这个布局在Android Studio的Preview里跑一下，再看一眼布局层级结构：整个页面只有一个RelativeLayout节点，下面全是平级的子View，没有任何嵌套。这就是相对布局最大的结构优势：扁平化。

嵌套深度直接影响性能。Android的measure和layout过程是递归执行的，嵌套越深，一次布局计算的耗时越大，特别是在列表滚动时会被放大。官方Performance文档专门点过，尽量保持布局层级扁平。RelativeLayout用一张"平面上的锚点关系网"取代了多层级容器，这个优势在复杂头部这类场景里体现得非常直接。

4. RelativeLayout、LinearLayout与ConstraintLayout，到底怎么选

4.1 不同场景下的取舍标准

很多人以为RelativeLayout已经过时了，写新界面就应该无脑上ConstraintLayout。这话说对了一半，但忽略了一个关键点：布局选型要考虑维护成本、团队认知和具体需求的复杂度，工具本身没有绝对的好坏。

我做个简单的对比，方便你按场景选择：

这个表是我的个人实践经验总结，不是官方定论。具体到选型时，我通常遵循三个标准：

1. 如果这个界面可以用LinearLayout平铺完成，且嵌套不超过两层，优先LinearLayout。骨架简单时用简单工具。
2. 如果界面里有明显的"叠层"和"多向锚定"需求——比如某个View要贴住另一个View的右下，同时还要对齐父容器的顶部——直接考虑RelativeLayout或ConstraintLayout。这种需求用LinearLayout硬凑会付出嵌套代价。
3. 如果页面有动态伸缩、按比例分配空间、或者复杂的对位需求，用ConstraintLayout。它的Guideline和Barrier等特性确实是RelativeLayout不具备的。

4.2 一个"用RelativeLayout反而更好"的真实案例

我参与维护过一个直播间礼物面板，界面需求是这样的：一个全屏半透明遮罩，中央区域有一个礼物列表，列表底部固定一个"充值"按钮，按钮上方一排礼物Tab。原来的实现是：外层FrameLayout，内层两个RelativeLayout分居上下，两个RelativeLayout里面又套了LinearLayout若干。总层级达到五层。列表滑动时，部分中低端机型有明显的掉帧。

后来我重构时只保留了一个RelativeLayout作为根节点，礼物Tab锚定面板底部（layout_alignParentBottom）、列表在Tab上方（layout_above）、充值按钮再锚定Tab的底部下方。层级从五层压到两层，刷新的measure耗时肉眼可见地降了下来。

这个案例想表达的是：RelativeLayout并没有"淘汰"，它在某个具体的层级约束问题里甚至比ConstraintLayout更干脆利落。因为RelativeLayout的属性系统就是围绕"相对锚定"设计的，你在写layout_below、layout_toRightOf、layout_alignParentBottom时，思路是直来直去的。

4.3 新手最容易陷入的"嵌套陷阱"

很多从LinearLayout入门的人容易形成惯性：先竖着排一根LinearLayout，发现左右排不下了，再在中间嵌一根水平LinearLayout。这样一层层叠下去，直到写出一棵"圣诞树"。问题是，LinearLayout嵌套的层级成本比RelativeLayout和ConstraintLayout都要高，因为每个LinearLayout在measure时都要遍历子View，嵌套层级每增加一层，整个布局树的计算量就显著放大。

RelativeLayout强烈建议用于替代这种"多方向排列靠嵌套"的写法。你只需要在根布局里定义好每个View之间的锚点关系，层级是平的，阅读者一眼就能看出"谁在谁的右边""谁在谁的下面"，维护起来省心得多。

5. RelativeLayout的性能误区和踩坑记录

5.1 一个流传很广的"性能差"传言，真相是什么

说到RelativeLayout，总绕不开一个传言：RelativeLayout会对子View进行两次measure，性能不如LinearLayout。这个说法有历史背景，在Android 2.x时代确实存在，当时RelativeLayout的measure逻辑会对部分子View额外测量，以保证锚定关系正确。但随着Android版本迭代，这一点早已经大幅改进了。在Android 4.0之后，系统对RelativeLayout的measure过程做了大量优化，现代设备上，只要你的RelativeLayout层级不深、子View数量不过多，性能差异几乎可以忽略。

那为什么项目里RelativeLayout偶尔还是很卡？我观察到的真正原因往往不是RelativeLayout本身，而是：

• 内部嵌套了多层其他布局，导致整体层级膨胀
• 子View数量过多（超过十几个），单个布局承担了太多职责
• 在列表项中使用带复杂测量的RelativeLayout，且列表滚动频繁触发measure

优化思路是：一个RelativeLayout只承担一类明确的布局职责，子View数量控制在合理范围内。如果发现一个RelativeLayout里有二十几个子View，说明这个布局该拆了。

5.2wrap_content和match_parent的"神秘失踪"

情况是这样的：RelativeLayout根节点加上android:layout_height="wrap_content"，里面有一个子View设置layout_alignParentBottom="true"。你会发现，在某些情况下子View并没有出现在父容器的底部，甚至父容器看起来"塌"了。

原因要从RelativeLayout的测量机制说起。RelativeLayout的wrap_content高度需要根据所有子View的位置关系来推算，但子View的alignParentBottom是指向父容器底的——这里形成了一个循环依赖：父容器高度依赖于子View，子View位置依赖于父容器高度。系统解决不了这个死循环，实际执行时alignParentBottom会被忽略，或者高度计算产生意外结果。

经验法则：如果子View用了layout_alignParentBottom，父RelativeLayout的高度就固定用match_parent或者明确指定值，不要用wrap_content。反之，如果父容器是wrap_content，尽量用layout_below、layout_above这类锚定兄弟控件的属性，而不是锚定父容器。

5.3layout_gravity在RelativeLayout中不生效

这是很多从LinearLayout转过来的人踩过的第一坑。layout_gravity是LinearLayout和FrameLayout的属性，用来控制子View在父容器里的对齐方式。RelativeLayout里根本没有这个概念，子View的定位完全由锚点属性控制。

我见过有人写出这样的代码：

<RelativeLayout ...> <TextView android:id="@+id/title" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center_horizontal" android:text="标题" /> </RelativeLayout>

结果TextView安静地待在左上角，完全无视layout_gravity。正确做法是改用android:layout_centerHorizontal="true"，或者用layout_centerInParent="true"实现完全居中。

类似的，layout_weight只属于LinearLayout，RelativeLayout里写了也不生效。布局系统里每种布局都有自己的一套"接口"，跨布局用属性就是在写无效代码，而且编译器不一定报错。

5.4layout_margin和锚定属性的顺序陷阱

XML属性在标签里的书写顺序不会影响布局结果，所以下面这段代码是合法的：

<TextView android:id="@+id/label" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginLeft="16dp" android:layout_toRightOf="@id/icon" />

但很多人被误导，以为margin写在toRightOf后面会"先定位再加边距"，写在前面就"加完边距再定位"，其实没有这个区别。RelativeLayout的规则是：锚定属性和margin属性独立作用于最终位置。layout_toRightOf="@id/icon"确定了本View的左边在icon的右边，layout_marginLeft="16dp"在这基础上再向左增加16dp间距。两个属性互不干扰，无论书写顺序如何，结果都一样。

5.5 动态添加View时记住"锚点必须先存在"

这是开发过程中最容易"写完不报错，运行就崩溃"的一个点。RelativeLayout里，子View锚定另一个View时，被锚定的View必须在布局中有明确的id。如果锚定的id在运行前不存在（比如动态创建的View还没add），系统会抛ClassCastException或Resources.NotFoundException。

动态添加的场景要养成两个习惯：

// 动态创建锚定目标View TextView title = new TextView(context); title.setId(View.generateViewId()); // 显式指定一个可用的id rl.addView(title); // 再创建依赖View，锚定它 TextView price = new TextView(context); RelativeLayout.LayoutParams params = new RelativeLayout.LayoutParams( RelativeLayout.LayoutParams.WRAP_CONTENT, RelativeLayout.LayoutParams.WRAP_CONTENT); params.addRule(RelativeLayout.BELOW, title.getId()); rl.addView(price, params);

View.generateViewId()是API 17引入的，如果需要兼容更低版本，手动定义id即可。顺序上，先添加锚定目标，再添加依赖View，避免measure阶段找不到锚点。

5.6 布局嵌套过深时的测量耗时问题

最后分享一个性能定位方法。如果你负责的项目里有页面明显卡顿，可以用Android Studio的Layout Inspector打开布局层级图，看最浅到最深的一条链上有多少层。

Normal标准是：首选布局层级尽量控制在三层以内。RelativeLayout在这方面天生有优势。但注意，RelativeLayout再强也架不住你在里面又套三四个RelativeLayout。扁平化是目标，不是初始状态，写完布局最好回头检查一遍，凡是能用锚点解决的嵌套，一律打开层级图确认是否真的扁平了。

6. 从RelativeLayout到ConstraintLayout，路径比想象中平滑

6.1 属性映射表：把相对布局的经验迁移过去

如果你已经仔细理解了前文所有RelativeLayout属性，现在学ConstraintLayout会非常快，因为两者的底层思路是同一个爹——都通过约束关系描述位置，只是ConstraintLayout把约束边界做得更精细、能力边界更宽。

这张表不是让你死记硬背，而是让你建立映射直觉：RelativeLayout里的align是对齐边缘，到了ConstraintLayout里就变成toStartOf依赖另一个View的边；RelativeLayout里的toRightOf是不重叠，到了ConstraintLayout就是Start_toEndOf。语义一脉相承。

6.2 什么时候迁移，什么时候保持不动

很多人跟我聊搬迁的事，其实迁移不是必须的。我的判断标准是：

• 页面逻辑简单、改动频率低：比如一个弹窗、一个页脚、一个固定结构的小部件，用RelativeLayout写着挺好，迁移收益微乎其微。
• 页面变动频繁、有大量自适应需求：比如首页、详情页、多尺寸平板适配，考虑迁移到ConstraintLayout，利用它的链、百分比、Guideline降低适配成本。
• 团队平均水平决定一切：如果团队里大部分人对ConstraintLayout不熟，写着写着就变成了"代码能跑但约束一团乱麻"，那还不如老老实实RelativeLayout。工具再强，人用不明白反而坏事。

我个人经历是，真正让我坚定选择ConstraintLayout的场景，往往是需要"把一个View放在两个View的中间偏左33%的位置"这类精确比例的约束，或者需要一行代码实现多个View的按比例分配，这些确实是RelativeLayout做不到的。

6.3 学习路线建议：别跳过RelativeLayout

我面试候选人的时候，如果对方说"只写过ConstraintLayout，不怎么了解RelativeLayout"，我通常还会多问几个关于锚点、约束、测量时机的问题。原因是我发现，RelativeLayout的每一组属性，本质上都在训练"约束建模"的思维方式。你能清楚地回答"这个View为什么在这里、换个屏幕宽度它应该怎么动"，才是真正的布局能力。

建议的学习顺序是这样的：

1. 先用RelativeLayout复习锚点概念，把前文两张属性群理解透彻。
2. 动手写三个实战页面：一个底部操作栏、一个右上角悬浮按钮、一个"图片+文字+价格"的商品卡。
3. 打开Layout Inspector看这三个页面的层级树，体会扁平化带来的性能收益。
4. 再把同样的页面用ConstraintLayout实现一遍，对照属性映射表，体会"约束"概念的演化。

这样走完一遍，你对Android布局系统的理解会是整体的，而不是零散的几个API。以后无论看老代码还是写新架构，心里都有数。

7. 关于RelativeLayout的"隐藏收益"：写布局时更容易做视觉对齐

这里写一点或许可以和单纯学布局区分开的内容——我是后来带新人才注意到的：练熟RelativeLayout之后，你对照设计稿写界面的速度会明显快于只用LinearLayout的人。因为在Sketch/Figma上，几乎所有设计元素都有明确的相对位置关系，"这个图标在文字的右边、这个标签在图片的底部"天然就是RelativeLayout的语言。

每次拿到设计稿，我习惯先在纸上画出元素的锚点关系图：中心点是谁？底部谁对齐？左边谁在谁的右边？这个过程不超过五分钟，但能避免打开编辑器后反复调坐标的无效劳动。严格说，这种"先建模再编码"的习惯，就是RelativeLayout学习赐予你的副产品，而且是挺值钱的那种。

如果只能分享一个心得，我会说：布局写不好的根源一般不是工具不会，而是没想清楚"谁在谁的哪里"这句话。RelativeLayout强迫你把这句话写明白。

最后留个实际的作业：试着用RelativeLayout重写一个你手机里最常用的App页面（比如底部导航栏、搜索框+按钮、个人中心卡片），然后打开Layout Inspector对比一下现在的层级和原来的实现，大多数时候你会看到明显的层级瘦身。做完这步，你对RelativeLayout的理解就不仅仅是"会用"，而是"用得值"。