一、亮点概述

这是设计师 @raul_dronca 在 X 上发布了一个利用 iPhone 灵动岛显示阅读进度的交互方案。

用户在浏览一篇长内容时，页面处于顶部，灵动岛保持默认的药丸形态，不做任何额外显示。当用户开始向下滚动页面，灵动岛从药丸形态过渡为一个进度条，进度条右侧显示当前阅读位置对应的百分比数字。滚到页面中部，进度条填充到一半，继续向下滚动，进度条持续增长，直到页面到达底部，进度条填满，右侧出现一个绿色的勾号图标。如果用户向上回滚页面，进度条会随之缩短，百分比数字同步减小，直到页面回到顶部，灵动岛恢复成最初的药丸形态。

这个设计方案，没有用到弹窗，没有浮层控件，进度信息完全依附在灵动岛的位置上。滚动触发显示，停止滚动后进度条保持当前状态，回到顶部则一切复原。

二、设计拆解

1. 用灵动岛承载进度，不占用内容区域

传统的阅读进度指示通常是出现在页面右侧的滚动条、页面顶部的进度条、或者浮动在页面边缘的百分比数字。这些方案都不得不在内容区域的边缘或内部划出一块单独的空间来放置进度信息，尤其在手机屏幕上，任何出现的额外元素，都会和正文内容争夺注意力。

而目前这个方案，换了一个思路——把进度信息放在了灵动岛上。灵动岛位于屏幕顶部居中的位置，在用户阅读内容时，这块区域同样也处于视线范围之外，用户的注意力集中在屏幕中部和下方的正文区域。进度条不会干扰阅读，但当用户想要了解自己读到哪里时，抬眼就能看到进度信息。进度信息和阅读内容在空间上完全分离，一个在屏幕顶部的硬件区域，一个在屏幕中下方的内容区域，互不干扰。

2. 滚动行为触发状态变化，不需要用户主动操作

灵动岛从药丸形态变成进度条，不需要用户点击任何按钮或进入任何模式。滚动页面这个动作本身就是触发条件。用户无需做任何"查看进度"的额外操作，进度信息作为滚动行为的附属反馈会一直出现。

这种设计让进度显示和阅读行为合并成一件事。用户不需要中断阅读去寻找"我读到哪了"的信息，也不需要调出某个面板来查看进度。滚动本身就是在持续更新进度，进度条的长度与百分比数字，与页面位置实时对应。

3. 完成状态有明确的终点标识

进度条填满 100% 时，右侧会出现一个绿色勾号。这个勾号不只是装饰，它在视觉上把"已经读完"和"还在读"的状态区分开开来。进度条从 10% 到 90%，用户看到的都是一个正在增长的条形加一个变化的数字，形态没有区别。但到达 100% 时，绿色勾号的出现打破了这种连续性，给出了一个"读完了"的明确信号。

5. 药丸形态和进度条形态之间的过渡是连续的

灵动岛从默认药丸形态转化为进度条时，不是突然切换的。药丸的外轮廓逐渐拉长，内部开始出现填充色，百分比数字从右侧浮现。这个过渡在视觉上是一个形变动画，用户不会产生"突然多了一个东西"的感觉。

回到顶部时也是同样的逻辑，进度条逐渐缩短，填充色退去，百分比数字消失，灵动岛回到药丸形态。整个过程没有生硬的出现和消失，进度条像是从灵动岛里长出来的，阅读结束后又自动缩回去。这会让你认为进度条不是一个独立的新元素，而是灵动岛在特定情境下的另一种新形态，这种连续过渡保持了两者之间的视觉因果性。

三、给设计师的启发

1. 硬件特征可以成为信息载体，前提是场景匹配

灵动岛是一块被手机硬件被挖孔后，定义出来的屏幕区域，它的位置和形状是固定的。而这个方案把它当作一个信息显示的容器来使用，非常创新，但这种用法能够成立，是因为阅读场景和灵动岛的特性恰好匹配——阅读时用户视线集中在屏幕中下方，灵动岛所在的顶部区域处于视觉边缘，放置不紧急但随时可查的信息刚好合适。

如果换成实时通知，可能就不一定合适了，实时通知需要立即响应，放在用户不会频繁看向的屏幕顶部，反而容易被忽略。硬件特征能不能用来承载信息，取决于具体场景需求。阅读场景里灵动岛刚好在视觉边缘，放进度信息匹配；换个场景，同样的位置可能就不太合适了。

2. 最好的进度反馈是不需要用户主动查看的

这个方案里，滚动本身就在更新进度，用户不需要主动触发任何东西。进度反馈附着在用户已有的行为上，而不是作为一个独立功能单独存在。

设计师在给长内容、长流程加入进度指示时，可以先想一下用户在当前场景里主要动作是什么。如果这个动作能被映射成进度信息，就不需要额外的交互入口。滚动对应阅读进度，逐步提交对应流程进度，拖动对应调节进度——用户已经在做的事情本身就能产出位置信息，设计师要做的，只是把它转译并展示出来即可。

四、设计局限

灵动岛是系统级的硬件区域，iOS 对它的使用有严格的 API 限制。目前只有系统功能和通过 Live Activities 授权的应用可以控制灵动岛区域的显示内容，普通的网页浏览场景无法直接调用灵动岛的显示能力。这意味着这个方案如果要落地，要么需要在原生应用内实现，要么需要 Apple 开放更多的灵动岛接口权限。

灵动岛和系统通知存在冲突的可能。当用户在阅读过程中收到电话、计时器到期、或者其他会占用灵动岛的系统事件时，进度条需要让位给系统功能。通知结束后进度条如何恢复、恢复过程中的动画衔接是否流畅，这些过渡状态在方案中没有表现。

进度条的视觉形态本身带有"完成度"的含义。用户看到一个从左往右填充的条形加百分比数字，默认理解是"我完成了多少"。但这个方案里，用户往上回滚时进度会倒退，从 60% 退回 30%，这和进度条建立的心理预期冲突。它实际映射的是滚动位置而不是阅读完成度，但视觉上用的却是进度条的语言。如果用户把它理解为阅读进度，回翻时看到数字倒退会感到困惑。