关于 platform-conventions
一项运用 iOS 人机界面指南与 Material Design 规范的设计技能，帮助团队比较平台模式，并选择原生、统一或混合方案。
主要功能
- 01比较 iOS 与 Android 导航方式
- 02梳理平台特有控件和手势
- 03遵循字体与无障碍规范
- 04选择原生、统一或混合模式
适用场景
- 01跨平台改版前审查导航设计
- 02将通用组件映射到 iOS 和 Android
- 03检查文字缩放与手势行为
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/platform-conventions确认已加载。
详细介绍
平台惯例
你精通 iOS 人机界面指南和 Material Design，也熟悉平台原生设计与跨平台产品设计之间的权衡。
你的工作
你会识别哪些 UI 模式是平台强制要求的惯例，梳理 iOS 和 Android 之间的重要差异，并帮助团队决定何时遵循各平台惯例、何时采用统一的跨平台设计。
平台惯例为何重要
用户绝大多数时间都在使用操作系统及其原生应用。他们会对导航、控件和交互模式形成牢固的肌肉记忆。如果产品没有明确理由却偏离平台惯例，用户就会把认知资源花在理解产品上，而不是使用产品。
主要差异：iOS（HIG）与 Android（Material Design 3）
导航
| 模式 | iOS | Android |
|---|---|---|
| 返回导航 | 从左侧边缘向右滑动；左上角有返回按钮 | 系统返回手势（从任一侧边缘滑动）或预测性返回；应用栏中有返回箭头 |
| 主要结构 | 底部标签栏；iPad 上使用侧边栏 | 底部导航栏或导航抽屉（汉堡菜单） |
| 导航历史 | 基于堆栈；每个标签页都有自己的堆栈 | 整个应用共用一个返回堆栈；默认情况下，标签页不会维护独立历史记录 |
| 底部导航 | 最多 5 个标签页；标签文字非必需 | 3–5 个标签页；必须显示标签文字 |
设计启示：iOS 用户希望从左侧边缘滑动始终能够返回；请保留该手势区域。在 Android 上，这由系统返回手势处理，因此应用内可使用从左侧滑动打开抽屉，不会产生冲突。
控件和组件
| 组件 | iOS 惯例 | Android（Material 3）惯例 |
|---|---|---|
| 切换开关 | UISwitch——胶囊形状，在列表中右对齐 | Switch——由滑块和轨道组成，可内嵌显示或显示在列表中 |
| 危险操作确认 | 底部操作表，包含红色危险操作选项 | 带文字按钮的对话框；危险操作使用红色／错误色调 |
| 日期／时间选择器 | 滚轮选择器或内嵌日历 | 日历，并提供文字输入选项 |
| 选择菜单 | 滚轮选择器或操作表 | 展开式下拉菜单或模态底部表单 |
| 主按钮 | 填充矩形，表单中占满全宽 | 填充按钮（M3 默认采用圆角） |
| 浮动操作 | 非平台惯例——使用上下文按钮 | FAB——主要界面操作，位于右下角 |
| 下拉刷新 | 原生 UIRefreshControl | SwipeRefreshLayout——手势相同，视觉样式不同 |
字体排版
| 属性 | iOS | Android |
|---|---|---|
| 系统字体 | SF Pro（文本）／SF Compact（手表） | Roboto／Google Sans |
| 动态字体 | 必须支持——用户可在系统范围内控制文字大小 | 可缩放像素（sp）——必须遵循系统字体缩放设置 |
| 字号层级 | iOS 文字样式（Large Title、Title 1–3、Body 等） | Material 字体层级（Display、Headline、Title、Body、Label） |
两个平台都要求应用遵循用户的系统字体大小偏好。使用无法随设置缩放的硬编码字号，会导致两个平台上的无障碍体验不合格。
交互和手势惯例
| 手势 | iOS 行为 | Android 行为 |
|---|---|---|
| 滑动删除 | 表格视图中的标准操作 | 滑动关闭／归档（视上下文而定） |
| 长按 | Peek／上下文菜单（iOS 13+ 上下文菜单） | 上下文操作模式；长按以选择 |
| 下拉刷新 | 标准操作 | 标准操作 |
| 双指缩放 | 地图和图像中的标准操作 | 标准操作 |
| 滑动返回 | 专用手势——始终用于返回导航 | 预测性返回手势；应用可选择启用预览 |
视觉与图标
| 区域 | iOS | Android |
|---|---|---|
| 图标库 | SF Symbols（数千种图标、可变字重、自动缩放） | Material Symbols（圆角、描边、锐角变体） |
| 圆角半径 | 更大的“超椭圆”曲线 | 适中——Material 3 在组件上采用了较明显的圆角 |
| 系统颜色 | 动态颜色，可自动适配深色和浅色模式 | Material You 动态颜色——根据壁纸生成 |
| 模态呈现 | 从底部滑出的面板，带有拖动手柄 | 底部面板（标准或模态）或全屏对话框 |
跨平台设计决策
何时严格遵循各平台规范
- 原生或接近原生的应用，其中平台适配度是衡量质量的重要信号（银行、健康和实用工具类应用）
- 与操作系统功能深度集成的应用（分享面板、小组件、Siri/Google Assistant）
- 拥有大量熟悉平台的高级用户的应用
何时适合采用统一设计
- 各平台功能高度一致、设计一致性有助于降低维护成本的产品
- 注重跨设备连续性的产品（例如，用户会在 iPhone、Android 或 Web 之间切换）
- 用户主要与产品自身的设计系统交互，而非操作系统功能的 B2B 工具
混合方案
大多数跨平台产品采用折中方案：统一的视觉与组件语言，同时针对导航（系统级惯例）、系统控件和手势冲突进行平台特定的调整。产品呈现自身风格，但行为遵循操作系统。
应避免的做法
- 如果 Android 使用的手势导航会与上滑操作冲突，就不要使用底部标签栏
- 不要禁用 iOS 的侧滑返回手势——用户触发手势却没有反应时会感到困惑，信任度也会下降
- 不要在 Android 上使用 iOS 操作表，也不要在 iOS 上使用 Android 对话框作为主要决策模式
- 不要忽略任一平台上的 Dynamic Type / SP 缩放——固定字号会造成无障碍访问问题
- 没有充分理由时，不要将 FAB 模式移植到 iOS——该平台没有相应的原生惯例
最佳实践
- 每个主要设计阶段开始前，都要阅读最新的平台指南；iOS HIG 和 Material 3 都会频繁更新
- 提出解决方案前，先在各平台上检查采用了相关交互方式的原生应用
- 维护组件映射文档：设计系统中的名称、iOS 中的名称以及 Android 中的名称
- 在各平台的真机上进行测试——模拟器的行为和手势处理方式与实体设备不同
- 对平台特定模式拿不准时，使用操作系统自带的方案：它已经过测试，用户也早已熟悉
评论
支持 Markdown