底部 20% 是死亡区：交互按钮和时长角标遮挡，文字别放底部和右下角

1. 问题的提出：为什么偏偏是"底部 20%"

先看一个几乎所有短视频产品都会遇到的现场：一条 15 秒的竖屏视频，底部左侧是作者昵称与文案，底部右侧是头像、点赞、评论、分享四个竖排按钮，右下角还压着一个"00:15"的时长角标。当文案稍长、或者用户开启了大字号无障碍模式，文字就会钻到按钮下面，被头像和角标切掉半行。用户想读完整，只能等它滚动，或者干脆放弃。

这不是个别产品的疏忽，而是竖屏视频这一形态的结构性矛盾。竖屏把宽度压缩到 9:16，横向可用的"安全文字带"本来就窄；而底部又恰好是拇指最容易触达、产品最想放交互按钮的位置。于是"想放文字的地方"和"想放按钮的地方"在物理上重叠了。

1.1 底部 20% 的三重身份

把屏幕按高度切成 100 份，底部 20 份（即 20%）在主流竖屏视频 App 中同时是：

• 交互按钮区：点赞、评论、分享、收藏、关注，绝大多数产品把它们放在右下角竖排，因为这是单手拇指的自然落点。
• 角标与进度区：时长角标、进度条、倍速提示、清晰度标签，习惯性贴在右下或底部通栏。
• 系统手势区：iOS 的 Home Indicator、Android 的手势导航条，都会从底部向上"吃掉"一段不可用高度。

三重身份叠加，意味着底部 20% 是一个高竞争、低容错的区域。任何放进去的信息，都要先问一句：它会不会被按钮压住？会不会被角标盖住？会不会和系统手势打架？

1.2 一个被反复验证的经验法则

在移动端可用性研究中，拇指自然扫过的区域被称为"拇指热区"（thumb zone）。Steven Hoober 在 2013 年对 1333 名用户的观察研究（How Do Users Really Hold Mobile Devices?, UXmatters）指出，约 49% 的用户单手持机，拇指可舒适触及的区域集中在屏幕中下部，但最底部恰恰是拇指"够得到却看不清"的盲区——因为手指本身会遮住屏幕。

本文评述：Hoober 的数据常被简化为"按钮要放底部"，但原文强调的是"可触达"与"可视"的分离。底部按钮好按，不等于底部文字好看。把这两件事混为一谈，正是"死亡区"的认知起点。

所以，"底部 20% 是死亡区"并不是说底部不能用，而是说底部是一个"交互优先、信息靠后"的区域。文字、字幕、关键提示这类需要被"读"的内容，应该尽量避开它。

2. 三区错位模型：视觉热区、交互热区与安全热区

要系统解释"死亡区"，需要一个能同时描述"人怎么看""手怎么点""系统怎么限制"的模型。本文提出三区错位模型，作为全文的分析主线。

2.1 三个区的定义

区域	定义	决定因素	典型位置
视觉热区	用户视线停留最久、最容易读取信息的区域	眼动规律、内容重心、F/Z 型阅读	屏幕中上部、画面主体附近
交互热区	拇指最容易触达、产品放置按钮的区域	持机姿势、手部尺寸、点击热图	屏幕中下部、右下角竖排
安全热区	系统允许内容稳定显示、不被裁切的区域	安全区（safe area）、手势条、刘海/挖孔	屏幕中部矩形，底部需上抬

三个区各自合理，但它们的交集并不在底部。视觉热区偏上，交互热区偏下，安全热区要求底部留白。底部 20% 恰好是"交互热区 ∩ 安全热区边缘"，却常常被误当成"视觉热区"来用——这就是错位的根源。

2.2 错位的三种典型形态

• 形态 A：文字压按钮。文案、字幕被放进右下角，与竖排按钮重叠，造成遮挡。
• 形态 B：角标压文字。时长角标固定在右下，长文案换行后正好被角标切掉。
• 形态 C：手势吃内容。底部内容没有上抬安全区，被 Home Indicator 或手势条覆盖。

这三种形态在真实产品中往往同时出现。本文后续章节将逐一拆解，并给出对齐三区的工程方法。

3. 遮挡的量化：文字损耗率与误触率如何测量

"被遮挡"不能停留在感觉层面，必须量化，否则无法做 A/B 实验，也无法说服设计评审。本节给出两个核心指标：文字损耗率与误触率。

3.1 文字损耗率（Text Loss Rate, TLR）

定义：在某一布局下，被其他元素（按钮、角标、进度条、系统手势条）覆盖的文字像素面积，占该文字总渲染面积的比例。

TLR = Σ(被遮挡文字像素面积) / Σ(文字总渲染面积)

工程近似算法（前端可实时计算）：
1. 用 getBoundingClientRect() 拿到文字块与遮挡元素的矩形；
2. 求两矩形交集面积 intersectionArea；
3. TLR = intersectionArea / textRect.area；
4. 对多行文字逐行计算后加权求和。

TLR 的优点是可自动化、可回归。把它接入 UI 自动化测试，每次改版都能跑一遍，防止新按钮把老文案压住。

3.2 误触率（Mis-tap Rate, MTR）

定义：用户本意是"阅读/滑动"，却触发了按钮点击的比例。它反映的是交互热区与视觉热区的冲突。

测量方法：在按钮上埋点，记录点击时的按压时长、滑动速度、点击后 500ms 内的返回/取消行为。如果一次点击后用户立刻返回、或紧接着滑动，往往说明这是一次误触。

笔者认为：误触率比点击率更能说明布局问题。点击率高可能是按钮位置好，也可能是用户"被迫"点到；只有把误触率一起看，才能判断这个位置到底是"好按"还是"碍事"。

3.3 一组模拟数据示例

以下为模拟数据（用于说明指标计算方式，非真实产品数据）：

布局方案	TLR	MTR	说明
文案贴右下角	18%–32%	6%–11%	与竖排按钮、角标重叠
文案左下、按钮右下	8%–15%	3%–6%	横向分离，但长文案仍会撞角标
文案上抬至安全区上方	<3%	<2%	三区基本对齐

模拟数据的方向性结论与工程直觉一致：横向分离只能缓解，纵向抬升才能根治。这也解释了为什么"文字别放底部和右下角"是一条经验上非常稳的规则。

4. 时长角标：被低估的"永久遮挡物"

在所有遮挡物里，时长角标最特殊：它几乎永远存在、位置固定、尺寸不大但足够致命。按钮还可以通过交互隐藏，角标却往往全程显示。

4.1 角标为什么总在右下角

角标放右下，是历史惯性：早期视频播放器把时间码放在右下，后来短视频沿用。但从三区模型看，右下角恰恰是交互热区与视觉热区的双重冲突点——按钮在这里，用户视线也常扫过这里。

4.2 角标的三种处理策略

• 策略一：挪。把角标移到左下或底部居中，避开按钮竖排。代价是与进度条位置习惯冲突。
• 策略二：融。把时长信息并入进度条，用进度条上的气泡或刻度表达，取消独立角标。
• 策略三：让。角标保留右下，但文字布局主动避让，预留角标宽度。

本文评述：三种策略没有绝对优劣，取决于产品形态。信息流视频适合"融"，因为进度条本就存在；直播适合"让"，因为直播没有总时长；点播长视频适合"挪"，因为角标信息密度高、需要独立可读。

4.3 一个可复用的避让尺寸

以 1080×1920 的竖屏为基准，时长角标常见尺寸约为 120×48 px（含内边距）。若采用"让"策略，文字容器的右侧内边距应至少预留 140 px，底部内边距应至少预留 角标高度 + 安全区高度。这两个数值可以直接写进设计规范。

5. 系统手势与安全区：不可协商的硬约束

如果说按钮和角标是"产品自己制造的遮挡"，那么系统手势与安全区就是"平台规定的硬约束"。它们不可协商，只能适配。

5.1 iOS 安全区与 Home Indicator

自 iPhone X 起，iOS 引入安全区（Safe Area）概念。底部 Home Indicator 区域高度约为 34 pt（不同机型略有差异），系统建议交互控件不要贴底，内容不要进入该区域。Apple 的《Human Interface Guidelines》明确要求为底部手势预留空间。

5.2 Android 手势导航

Android 10 之后，手势导航逐步取代三键导航。底部手势条同样占据一段高度，且不同厂商 ROM 的默认高度不一致。Google 的 Material Design 文档建议使用 WindowInsets 动态获取系统栏高度，而不是写死数值。

5.3 安全区的工程读取

/* Web：使用 env() 读取安全区 */
.bottom-safe {
  padding-bottom: env(safe-area-inset-bottom, 0px);
}

/* Android：使用 WindowInsets */
ViewCompat.setOnApplyWindowInsetsListener(view, (v, insets) -> {
    int bottom = insets.getInsets(WindowInsetsCompat.Type.systemBars()).bottom;
    v.setPadding(0, 0, 0, bottom);
    return insets;
});

把安全区高度作为布局的"底线"，再在其上方叠加按钮区与文字区，是避免"形态 C"的标准做法。

6. 分区栅格：把底部 20% 拆成可计算的三层

前面讲的是"为什么不能放"，这一节讲"到底怎么放"。核心思路是把底部 20% 从"一个模糊区域"变成"三个可计算的层"。

6.1 三层结构

层	高度占比	内容	规则
系统层	底部约 3%–5%	Home Indicator / 手势条	禁止放任何文字与按钮
交互层	系统层之上约 8%–10%	点赞、评论、分享、角标	只放可点击元素，不放长文本
信息层	交互层之上	标题、文案、字幕	必须完整落在安全区内

三层叠加，正好覆盖底部 20%。信息层永远在交互层之上，这是"文字别放底部和右下角"的工程化表达。

6.2 横向分区：右下角单独留白

纵向分层之后，横向还要再切一刀。由于按钮竖排在右侧，文字容器应设置右侧内边距，形成"右下角留白区"。一个可用的经验值是：右侧留白宽度 = 按钮宽度 + 16 dp。

6.3 栅格落地示例

.video-overlay {
  position: absolute;
  left: 16px;
  right: calc(var(--action-bar-width) + 16px); /* 右下角留白 */
  bottom: calc(var(--safe-bottom) + var(--action-bar-height) + 12px);
  /* 信息层：位于交互层之上 */
}

.action-bar {
  position: absolute;
  right: 16px;
  bottom: calc(var(--safe-bottom) + 12px);
}

这段 CSS 的关键在于 bottom 的计算：安全区 + 按钮区高度 + 间距。只要这三个变量来自同一套设计令牌（design token），三区就自动对齐。

7. 避让算法：让文字与按钮自动错位

栅格是静态的，但真实内容长度是动态的。文案可能一行，也可能五行；角标可能是"00:15"，也可能是"01:23:45"。因此需要一套运行时避让算法。

7.1 算法目标

在给定文字内容、按钮布局、角标尺寸、安全区高度的条件下，找到一个文字容器位置，使得 TLR 最小、且不超出屏幕。

7.2 简化算法步骤

1. 测量文字实际高度 textHeight（可用离屏渲染或 measureText）。
2. 计算交互层顶部坐标 actionTop = 屏高 − 安全区 − 按钮区高度。
3. 计算文字容器底部坐标 textBottom = actionTop − 间距。
4. 若 textBottom − textHeight < 顶部安全线，则折叠文字（最多 N 行 + 展开按钮）。
5. 若角标在右下，且文字容器右边界与角标矩形相交，则进一步收窄文字右边界。

function layoutOverlay({ screenH, safeBottom, actionH, gap, textH, badgeRect }) {
  const actionTop = screenH - safeBottom - actionH;
  let textBottom = actionTop - gap;
  let maxLines = Infinity;

  // 角标避让：若文字底部进入角标纵向范围，则上抬
  if (badgeRect && textBottom > badgeRect.top) {
    textBottom = badgeRect.top - gap;
  }

  // 空间不足则限制行数
  const available = textBottom - /* topSafeLine */ 0;
  if (textH > available) {
    maxLines = Math.max(1, Math.floor(available / lineHeight));
  }
  return { textBottom, maxLines };
}

本文评述：避让算法的价值不在"算得多准"，而在把经验规则变成可测试的代码。一旦算法化，就可以写单元测试、可以回归、可以在 CI 里拦截"新按钮压住老文案"的提交。

8. 工程落地：从设计规范到代码与埋点

模型和算法要落地，需要三件套：设计令牌、组件约束、埋点验证。

8.1 设计令牌

把安全区、按钮区高度、角标尺寸、间距统一为令牌，避免各页面各写各的。

:root {
  --safe-bottom: env(safe-area-inset-bottom, 0px);
  --action-bar-height: 220px;   /* 竖排四按钮 */
  --action-bar-width: 72px;
  --badge-height: 48px;
  --overlay-gap: 12px;
}

8.2 组件约束

在组件库层面，给"视频浮层文字"组件加一条硬约束：其底部不得低于交互层顶部。这条约束可以用 Storybook 的可视化测试或截图对比来守护。

8.3 埋点验证

上线后需要持续监控 TLR 与 MTR。建议埋点字段：

• text_loss_rate：前端实时计算的 TLR。
• mis_tap_flag：点击后 500ms 内返回/滑动的标记。
• badge_overlap：文字与角标是否相交。

这些字段可以按机型、系统版本、字号设置分组，快速定位"哪些设备上死亡区最严重"。

9. 验证方法：A/B 实验与眼动数据

任何布局改动都需要验证。本节给出两类方法：线上 A/B 与线下眼动。

9.1 线上 A/B 实验设计

组别	布局	核心指标
对照组	文案贴右下角	完读率、误触率
实验组 A	文案左下、按钮右下	同上
实验组 B	文案上抬至交互层之上	同上

预期方向：实验组 B 的完读率提升、误触率下降。若数据不显著，需检查是否文案本身太短、或用户根本不读文案。

9.2 眼动与视线热图

眼动仪可以给出真实的视觉热区。Nielsen Norman Group 的诸多研究指出，用户对视频页面的注意力集中在画面主体与中上部文字，底部按钮区更多是"扫视"而非"阅读"。这与三区模型的预测一致。

本文评述：眼动数据最大的价值是打破"设计者视角"。设计者盯着自己的文案看，用户却盯着画面看。把两者放在同一张热图上，错位一目了然。

9.3 可参考的教程与工具

• Apple Human Interface Guidelines（布局与安全区）：developer.apple.com/design/human-interface-guidelines/layout
• Android WindowInsets 官方文档：developer.android.com/develop/ui/views/layout/edge-to-edge
• MDN CSS env() 安全区：developer.mozilla.org/en-US/docs/Web/CSS/env
• Nielsen Norman Group 眼动研究合集：nngroup.com/topic/eye-tracking
• Web.dev 视频浮层与安全区实践：web.dev/learn/design

10. 前沿预判：自适应布局与多模态感知

"死亡区"问题不会永远靠人工规范解决。未来三到五年，三个方向值得关注。

10.1 基于设备与持机姿势的自适应布局

手机陀螺仪、握持传感器可以推断用户是单手还是双手、左手还是右手，从而动态调整按钮与文字位置。已有学术工作探索用 IMU 数据做持机姿势分类，准确率在受控实验中可达较高水平（具体数值因数据集与模型而异，此处不引用单一来源）。

10.2 内容感知的自动避让

用轻量视觉模型检测画面主体位置，把文字放到"画面空白且不被按钮遮挡"的区域。这本质上是把 TLR 最小化问题交给模型求解。

10.3 无障碍与大字号的强制约束

随着无障碍要求提高，系统字号可能放大到 200%。此时底部 20% 的可用空间进一步压缩，"文字别放底部"将从最佳实践变成合规要求。产品应提前把大字号场景纳入测试矩阵。

11. 结论与操作清单

回到主线：底部 20% 之所以是死亡区，是因为视觉热区、交互热区、安全热区在这里错位。解决思路不是"少放东西"，而是"把三区重新对齐"。

可直接执行的操作清单：

1. 把底部 20% 拆成系统层、交互层、信息层三层，信息层永远在交互层之上。
2. 文字容器右侧预留按钮宽度 + 16 dp，底部预留安全区 + 按钮区高度 + 间距。
3. 时长角标优先"融"进进度条，其次"挪"到左下，最后才"让"。
4. 用 env(safe-area-inset-bottom) 与 WindowInsets 动态读取安全区，禁止写死。
5. 实现 TLR 与 MTR 埋点，接入 CI 与 A/B 实验。
6. 把"文字不得进入交互层"写进组件库约束与设计评审清单。

最后强调一句："文字别放底部和右下角"不是审美偏好，而是三区错位模型下的工程结论。理解了这个模型，就能在不同产品形态中自行推导出合适的布局，而不是死记一条规则。

主要参考文献