当你旋转手机测试屏幕时，布局会清晰地适应或崩溃。文本重新排列，按钮跳跃，模态窗口突然覆盖错误区域，或者你的视频播放器表现出预期的行为。那个小瞬间是 肖像方向 从设计术语变成产品决策。
如果你在开发移动应用，需要对 肖像方向. Not just the classroom definition, but the developer version. How it affects layout, when to support rotation, when to lock it, and how to handle it in web apps, native apps, and Capacitor projects without creating a brittle UX.
__CAPGO_KEEP_0__
理解肖像方向
用户首先注意到屏幕方向是当屏幕旋转时。开发者注意到它是当旋转破坏了他们的界面时。
肖像方向 意味着框架是 比它宽的更高. 这就是核心概念。它来自视觉艺术,其中一个人的肖像和上半身的画面通常垂直框架。同样的概念延伸到了页面设计,摄影和数字界面。一个好的参考资料是 Wikipedia的方向概述页面.
对于开发者来说，重要的是，肖像模式与一个屏幕尺寸、一个设备或一个文件格式没有直接关系。它是一种关于形状的规则。如果高度大于宽度，你就处于肖像模式。
为什么在产品工作中它很重要
肖像模式成为移动设备的实际默认值，因为垂直使用与人们自然地握持手机的方式相匹配。这会影响滚动、拇指触摸、阅读流、表单设计和导航位置。
一个feed、文章视图、设置屏幕或聊天线程通常在垂直框架中阅读得更自然。这是为什么方向选择直接与 移动应用用户体验决策而不是仅仅是视觉样式
实用规则： 将肖像模式视为布局上下文，而不是仅仅是设备位置。
初级开发者经常会混淆
方向 与 with 分辨率 或 分辨率意味着
- 方向 意味着哪一边更长
- 分辨率 意味着每个维度存在多少像素
- 宽高比 描述了宽度和高度之间的关系
在竖屏模式下，平板电脑和手机可能具有不同的尺寸，但它们仍然共享相同的方向状态。因此，响应式UI逻辑应该先问‘高度是否大于宽度？’然后再问任何更具体的问题
竖屏与横屏的基本比较
A portrait orientation的定义
在图像和UI设计中， 高度大于宽度，所以较长的边是垂直的。与水平方向相反。 SLR Lounge的词典条目 解释了技术定义以及这种形状适合于高个子和垂直结构。
在一个表格中
| 方向 | 形状 | 最佳匹配 | 上下文:Capgo Builder/原生云构建产品页面。角色:短UI标签或导航项。消息键`native_build_builder_compare_fit_feature` (原生构建构建器比较匹配特性)。 |
|---|---|---|---|
| Portrait | 高于宽 | 信息流、表单、阅读、高体积内容 | 垂直方向吸引注意力 |
| Landscape | 宽于高 | 视频、地图、仪表盘、宽景象 | 显示更多水平上下文 |
听起来很基础，但在产品评估时有用
对用户的变化
通常，垂直方向会缩小注意力。它减少了侧边内容并鼓励从上到下的流动。这就是为什么社交信息流、文章页面、引导步骤和聊天界面通常在垂直方向看起来更干净的原因。
水平方向做的相反。它暴露了更多的宽度，这有助于侧面比较、时间线、画廊、媒体播放、数据密集型表面和沉浸式视图。如果您的布局需要侧面比较，这个水平格式通常会给您更多的空间。
Portrait通常是关于焦点的。Landscape通常是关于背景的。
What对开发者来说会有变化
最大的错误是把更宽的格式当作了一个被拉伸的肖像。它不是。信息层次结构通常需要改变。
例如：
- 在肖像模式下，一个仪表板可能将卡片堆叠成一个单独的列。
- 在更宽的方向下，同样的仪表板可能会转变为多列，并显示过滤器或侧边面板。
- 在肖像模式下，一个付款表单可能优先考虑大型触摸目标和一个清晰的流程。
- 在更宽的方向下，同样的屏幕在字段变得太过垂直压缩时会感到不适。
开发者们在打造沉浸式移动界面时，也需要考虑到边缘处理、安全区域和全屏行为。如果您正在调整这些细节, Capacitor 全屏幕显示设置 是同一对话的组成部分，因为屏幕方向如何影响用户对可用空间的感知。
不同媒体的常见应用场景
竖屏方向出现在移动屏幕以外的更多地方。这很重要，因为概念并不是在软件中诞生的，也不仅仅是软件的范畴。
摄影和印刷
专业头像是最明显的例子。垂直框架更适合捕捉人脸和身体，而宽框架则不然。同样的逻辑也适用于时尚照片、书籍封面、海报和杂志封面。
印刷设计也依赖于竖屏，当阅读体验应该从上到下在窄列中移动时。这种形状有助于眼球自然地沿着页面向下移动。
文件和日常交流
大多数报告、简历、信件和内部文档都是以竖屏设计的。这不是因为竖屏总是更好，而是因为垂直页面在阅读段落、标题、列表和签名的序列时效果很好。
如果您曾经导出PDF并注意到宽表格突然变得不可读，那么您就见证了竖屏的局限性。有些内容更适合在水平格式中呈现。关键是匹配框架与内容结构。
移动产品和应用流程
在这种情况下，肖像模式成为许多团队的默认心理模型。
思考一下用户反复打开的屏幕：
- 聊天应用： 消息堆叠垂直排列。
- 社交应用： 帖子、评论和短视频在竖直方向流动。
- 零售应用： 搜索结果和产品列表向下滚动。
- 银行应用： 余额、交易和确认流程通常以垂直方式排列。
这些模式并非偶然。肖像模式支持单手操作、拇指滚动和线性任务完成。
许多移动端UI感觉很直观，因为界面假设一个直立的设备在它假设任何其他东西之前。
这并不意味着每个屏幕都应该保持竖屏。媒体播放器、地图、大的图表和基于相机的工作流程往往会从更宽的布局中受益。但是，对于日常任务流程，竖屏通常是用户开始的地方。
处理移动端屏幕旋转
一个常见的Web Bug看起来很小。您的应用程序在直立视图中清晰可读，然后用户旋转设备，图表溢出，侧边栏出现在错误的断点处，键盘覆盖提交按钮。移动端屏幕旋转实际上是关于状态的。视口形状发生了变化，您的UI需要以可预测的方式响应。
对于开发者来说，这意味着分离两个任务。CSS处理布局变化。JavaScript处理行为变化。如果您将同一个项目打包为移动端应用程序，那么这个Web层仍然很重要。 使用Capacitor将Web应用程序转换为移动端应用程序 并不消除了良好的Web屏幕旋转处理的需求。它使这个基础更为重要。
平台提供了两个主要工具。屏幕旋转API暴露了屏幕旋转类型和变化事件，Web应用程序清单允许安装的应用程序声明一个首选的直立模式，如 portrait, portrait-primary，或 portrait-secondary。MDN文档了那些清单值在其 Web应用程序清单屏幕旋转参考.
使用CSS时应适应布局
从 CSS 开始。它是最便宜、最可靠的方法来响应宽度和高度互换时的变化。
/* Default portrait-friendly layout */
.page {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.sidebar {
display: none;
}
@media (orientation: landscape) {
.page {
grid-template-columns: 280px 1fr;
}
.sidebar {
display: block;
}
}这就像对屏幕形状进行渐进增强一样。首先以窄屏、竖屏的布局作为默认值。然后在视口变宽时才添加空间来放置次要 UI。
几个实践可以节省后期的时间：
- 从主要模式开始： 如果人们主要使用竖屏应用程序，请将其作为基本布局。
- 避免使用固定高度： 旋转设备可以迅速缩小可用垂直空间，尤其是在浏览器 UI 或虚拟键盘可见时。
- 测试真实的交互状态： 表单、粘性标题和底部sheet在旋转时经常会失败，而不是在静态截图中。
使用 JavaScript 时必须有反应：
CSS 可以重新排列盒子，但无法决定何时重建图表或重置手势处理器。
使用 JavaScript 时，旋转会影响状态 UI 时：
function logOrientation() {
const type = screen.orientation?.type;
console.log('Current orientation:', type);
}
logOrientation();
screen.orientation?.addEventListener('change', () => {
logOrientation();
const isPortrait = window.innerHeight > window.innerWidth;
if (isPortrait) {
document.body.classList.remove('wide-mode');
} else {
document.body.classList.add('wide-mode');
}
});该模式对画布、媒体控制、地图视图和自定义导航壳都有用。这种思维方式简单。如果旋转改变了数据呈现或交互逻辑，JavaScript应该响应。如果旋转仅改变了间距或位置，CSS应该处理它。
一个实用的规则可以帮助初级团队避免很多复杂性。不要使用JavaScript强制CSS已经很好处理的布局决策。
设置PWA的首选方向
如果您的PWA主要用于直立使用，请在清单中声明这一点。
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}这是一种偏好，而不是响应式设计的替代品。它有助于浏览器了解如何在支持的上下文中打开和行为安装的应用程序。
您也可以在浏览器允许时在运行时请求方向锁定：
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}请谨慎使用。一个好的规则是只在旋转会破坏任务本身时锁定，例如引导式捕获流或具有严格物理对齐要求的屏幕。在其他情况下，适应界面是更好的工程选择，因为它尊重设备和用户。
在移动应用中管理方向
移动应用程序可以做得比浏览器标签更多。它们可以在应用程序级别声明默认屏幕方向，然后在任务要求时改变单个屏幕的行为。这种额外的控制很有用，但它也会导致一个常见的错误。团队限制旋转太广泛了，一个简单的应用程序开始感觉僵硬。
A个好的心理模型可以帮助你。应用级设置是你的默认策略。屏幕级code是例外层。使用策略来实现广泛的意图，使用例外仅在旋转设备会干扰用户正在尝试完成的工作时。
原生平台控制
开启 Android,屏幕方向通常在 AndroidManifest.xml for一个活动:
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />这就像一个顶级配置标志。它简单、可预测、易于在整个活动中实施。然而，这个方法的缺点是范围。如果只有一屏幕需要竖直模式，应用这个规则全球通常太过笨拙。
开启 iOS,支持的屏幕方向在Xcode中通过目标设置和应用元数据来设置。你可以定义应用支持的总体屏幕方向，然后在特定的视图控制器中细化行为，当屏幕有更严格的要求时。
这个分离对于跨平台团队来说很重要。原生配置回答，“这个应用应该允许什么？”运行时code回答，“这个屏幕应该做什么？”
程序化控制在Capacitor应用中
如果您使用Capacitor构建应用，动态控制通常应该放在code中，靠近需要它的路由或视图。登录屏幕可能更容易在横屏下使用。媒体屏幕或摄像头流可能需要根据设备的握持方式允许旋转。
一个插件可以让该逻辑保持可读性，并避免自定义原生管道。 Capacitor横屏插件为Capacitor应用提供了读取当前屏幕方向、为特定模式（如横屏）应用限制，并在用户返回到灵活屏幕时移除该限制的功能。 __CAPGO_KEEP_0__横屏插件为__CAPGO_KEEP_1__应用提供了读取当前屏幕方向、为特定模式（如横屏）应用限制，并在用户返回到灵活屏幕时移除该限制的功能。
import { ScreenOrientation } from '@capgo/capacitor-screen-orientation';
async function lockLoginScreen() {
await ScreenOrientation.lock({ orientation: 'portrait' });
}
async function unlockForMedia() {
await ScreenOrientation.unlock();
}
async function checkCurrentOrientation() {
const result = await ScreenOrientation.orientation();
console.log(result);
}模式很简单。应用限制时屏幕激活，移除限制时屏幕不再激活。在基于路由器的应用中，这通常意味着将屏幕方向变化与页面生命周期钩子相关联，而不是在随机组件中散布调用。
选择屏幕特定的限制时要谨慎
在旋转会干扰输入、对齐或用户焦点的情况下，使用固定直立模式。
常见的例子包括：
- 认证屏幕： 用户输入时输入保持稳定。
- 支付和确认步骤： 在高注意力任务期间减少布局变化。
- 屏幕方向 或导向型工作流程：
当额外宽度或不同握持方式显著改善任务时，允许设备自由旋转。
典型例子包括媒体播放、地图、游戏、相机视图和密集数据屏幕。
对于初级团队来说，一个有用的规则很简单。如果改变设备方向只会改变间距，让布局系统来处理。如果改变设备方向会改变任务的工作方式，那么屏幕方向code可能是合理的。
Capgo在这里提及的原因是实用。 在Capacitor项目中，方向控制是那些从小的UI细节开始，迅速成为应用行为的平台功能之一。将其视为行为。保持默认值灵活，适度限制，随着屏幕不再需要时移除。
屏幕方向最佳实践
屏幕方向处理是一个用户体验决策，技术决策是第二位。code通常很简单。困难的是选择一种感觉自然的行为。
设计一个简短的检查清单帮助：
- 为主要上下文设计： 如果大多数用户以直立姿势开始，设定肖像为界面最强大的版本。
- 支持一个更广泛的显示模式，仅在它添加价值时才支持： 不要在需要额外宽度的屏幕上阻止旋转。
- 只有在有明确理由的情况下才锁定屏幕: 表单、结帐或安全流程可能会合理化它。内容屏幕通常不会。
- 在旋转时保留状态: 用户不应丢失输入、滚动位置或选定的标签。
- 在真实设备上测试两种方向: 模拟器会错过不适合的过渡、键盘重叠和安全区域问题。
对于更广泛的布局决策 适用于Capacitor应用的跨平台UI和UX指南 与方向测试相符，因为同一屏幕通常需要在不同设备大小和平台约定下感觉像本地应用一样。
主要的收获很简单。如果你在问什么是竖屏方向，答案不仅仅是“垂直”。它是一个框架规则、一个布局状态和一个用户期望。好的应用会这样处理它。
如果你正在发布Capacitor应用并需要控制方向行为以及快速发布修复 Capgo 值得一看。它为CapacitorJS和Electron应用提供实时更新，并且它还维护了屏幕方向等应用能力的插件，帮助您在不重建整个发布流程的情况下锁定或启用特定的视图。
