用 Material Design 3 打造原生 Android 设计：impeccable 的 Android 平台规则参考指南-平芜编程栈

用 Material Design 3 打造原生 Android 设计：impeccable 的 Android 平台规则参考指南

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

本文基于开源项目 impeccable 的 Android 平台参考文档 android.md（源码维护版本见 skill/reference/android.md）展开。impeccable 是一套面向 AI 编码助手的设计技能（skill），当工作区的 PRODUCT.md 将平台记录为android时，这套规则会在每次设计、评审与打磨任务中被注入上下文，约束 AI 在 Jetpack Compose、Android Views、React Native、Expo、Flutter 等原生 Android 交付物上的设计决策。读完本文，你将掌握：Android "slop"（贴错平台皮肤）的识别方法、Material 3 在布局/触控/排版/色彩/动效上的落地清单，以及用 adb 在模拟器或真机上完成可复核截图证据的完整验证流程。

impeccable 用一个与 Mode（Persuade / Operate / Read / Experience）正交的 Platform 轴（web / ios / android / adaptive）来回答"交付目标是什么、该遵守哪套原生约定"。android平台自动加载本参考文件，adaptive（同一套代码同时发往 iOS 与 Android，如 Flutter、React Native、KMP）则同时加载 ios 与 android 两份参考。对"两端一套皮"的 Material-everywhere Flutter/RN 应用，项目不将其判定为 adaptive，而是只取对应单一平台的规则（见 CLAUDE.md 的 Platform 段）。

原生场景下的核心立场：模式收窄，表达让位于规范

参考文档开篇即给出 Android 平台的最高原则：在原生平台上，访问者模式（visitor mode）进一步收窄了"什么可以被表达覆盖"的空间。无论当前任务处于哪种模式，Material Design 3 都统治结构、导航与交互；品牌只能通过 Material 允许的通道来表达——色彩角色（color roles）、字体尺度（type scale）、形状（shape）与动效（motion）。反过来说，一个既发往 Android 又发往 iPhone 的 Material-everywhere 跨平台应用，只要运行在 Apple 硬件上，就仍欠 iOS 以该操作系统的保证项（安全区、Reduce Motion、边缘右滑返回），这正是 ios.md 的管辖范围。

从工程组织上可以印证这套"按平台内联规则"的设计：impeccable 的 Setup 流程会读取 PRODUCT.md 中的## Platform字段（缺省为 web），当值为android、ios或adaptive时，把对应原生参考文件直接内联进上下文，避免模型二次跳读（参见 CLAUDE.md Platform 段）；同时init命令在访谈确认平台后、进入任何设计工作前也会加载对应参考。而audit.native.md则明确要求评审者对照平台参考文件打分，而非使用任何浏览器工具链。

Android slop 测试：先识别"穿了 Android 皮"的 iOS 应用

文档用一个高度可操作的检验锚定了最常见的失败模式——The Android slop test：

一个熟练的 Android 用户会信任这个应用吗，还是会被不合规格的组件绊倒？

最典型的穿帮是"给 iOS 应用穿上 Android 皮肤"：

从 iPhone 照搬的底部导航独占（没有侧边导航、没有抽屉）；
忽略系统返回手势的自绘返回箭头（Back 箭头不响应系统 Back 手势）；
Cupertino 形状的开关与对话框（iOS 风格控件直接移植）。

结论很干脆：Material 3 就是规则书，跟随它的组件体系，然后通过它去主题化品牌，而不是反向造一套"仿 iOS"控件。这项判断与 impeccable 对跨文件 slop 的检出思路一脉相承（web 侧由detect.mjs/ 反模式规则引擎在 HTML/CSS 层检测，原生侧则由本参考约束源码评审，live 模式与 HTML 规则引擎对原生项目不生效，见 CLAUDE.md）。

布局与结构：导航、返回、边到边与系统栏

规则	要点
Material 导航随尺寸匹配	窄屏用底部导航栏（3–5 个目的地）；宽屏切换为导航 rail 或抽屉。绝不允许把手机版底部栏原样搬到平板上
系统 Back 永远可用	尊重 predictive Back 手势与 Back 键；绝不困住用户或劫持手势
Edge-to-edge 配合窗口 insets	处理状态栏、导航栏、刘海/挖孔（display cutout）与 IME insets，让内容永不躲在系统栏或键盘后面
顶部应用栏提供屏幕语境	当屏幕只有一个主操作时，与 FAB 成对出现

其中"导航匹配尺寸"呼应了 Material 3 的 adaptive 布局思想：同样的目的地集合在不同宽度下应切换不同的容器形态（bottom nav → rail → drawer），而不是让手机竖屏的视觉直接等比放大。系统 Back 永远可用在 Android 13+ 尤其关键——预测性返回（predictive Back）是系统级动画与手势，任何自绘返回栈都会与它冲突。

触控目标：48×48 dp 是硬下限

每个触控目标至少48×48 dp，相邻目标之间至少留8 dp间距。

这是 Material 3 无障碍与误触的双重底线。与 ios.md 的 44×44 pt 相比，Android 触控目标更大，因为 dp 与密度无关的语义与实际物理尺寸在目标人群上存在差异；实现时不应为视觉紧凑感而缩水，也不应让目标仅靠 padding 撑大而可点区域仍停留在文字上。

排版：用 Material 类型尺度，而不是手挑字号

Material type scale：Display、Headline、Title、Body、Label 五类角色，每类又分 large / medium / small。把文本映射到角色上，绝不逐屏手挑字号。
Roboto 是系统字体：品牌字体应通过类型尺度注入主题，同时保证正文、标签与控件可读且一致。
一律使用 sp 而非固定 px：让文字跟随系统字体大小设置。

类型尺度是可编程的 token 集合（在 Compose 中对应Typography/TextStyle，在 RN/Flutter 中对应各自的 TextTheme）。之所以禁止手挑字号，是因为 Material 3 的类型系统在字体缩放（系统 font_scale）与无障碍放大下需要协同伸缩——这正是后文验证环节里"把字号拉到 1.3 再截图"能抓出截断文案的原因。

色彩与主题：角色 token、动态取色与明暗一等公民

Material 色彩角色：primary、on-primary、surface、surface-variant、secondary-container、outline、error。角色 token 会自动解析 light/dark 与对比度变体；裸 hex 在这些场景下会失联。
Dynamic Color（Material You）：合适时从 Android 12+ 用户的壁纸派生配色方案（scheme），并必须有静态兜底（static fallback）。
深色主题是一等公民方案：设计与测试都要做，绝不允许"快速反相"充数。
Tonal elevation：用标准 surface 色调层级传达高度（必要时加阴影），不要任意投影。

语义角色的价值在于"换肤免改码"：同一套 primary 在 light 与 dark 下自动产生可用的 on-primary，深色下自动提升 surface 的色调；一旦写成 hex 直填，深浅两套与动态取色就全部失效。Material You 的落地路径是：用户壁纸 → 系统生成动态 scheme → 应用读取；因此测试时应同时覆盖"动态色可用"与"静态兜底路径"两种设备状态。

组件与动效：Material 组件 + 受约束的动效语汇

只用 Material 组件：按钮（filled / tonal / outlined / text）、FAB、开关、chip、snackbar、bottom sheet、Material 对话框、navigation bar/rail/drawer。绝不移植 iOS 控件或自造等价物。
一个 FAB 对应一个主操作：不堆叠 FAB，也不把 FAB 花在次要任务上。
Snackbar 负责瞬时反馈（有用时带操作项，但不用它替代 toast 的位置语义）；对话框只留给必须打断用户的决策。
Material 动效模式：container transform、shared-axis、fade-through，配合标准缓动与时长；并遵守系统的"移除动画"设置——检测到时应退化为交叉淡入或直接硬切。

最后一条与 iOS 参考的 Reduce Motion 是同一哲学在两家平台的落地：动效是表达层，但不能凌驾于系统无障碍偏好之上。impeccable 的 animate 命令参考对原生平台即明确"跟随平台参考的 Motion 段处理动效，不套用 web 工具链"，而 layout、typeset 等命令在原生场景同样回指本文件而非 web 规则。

验证构建：截图证据必须来自模拟器或真机

参考文档的收官章节给出了原生 Android 上"用证据说话"的完整流程，这也是 impeccable 有界评审（bounded passes）纪律在原生平台的落点——一次批量截图、一轮修复、至多再确认一轮，然后停止打磨。

① 截图永不来自浏览器

构建安装完成后，用 adb 截屏：

adb exec-out screencap -p > <path> # 多台设备同时连接时，用序列号锁定目标 adb -s <serial> exec-out screencap -p > <path>

覆盖应用要发布的每一种设备形态：至少一部手机；当平板是交付目标时再补一部平板。文件要写到评审流程期望的位置（web 评审是desktop.png/mobile.png，原生评审使用phone.png/tablet.png这类按设备形态命名的截图，详见 plugin/agents/impeccable-finish-reviewer.md 中关于.impeccable/review/目录的约定）。

② 深色主题与字体缩放必须进验证清单

# 切到深色模式（结束后用 uimode night no 恢复） adb shell cmd uimode night yes # 把系统字体缩放到 1.3，抓出固定布局藏起来的截断文案（验完恢复 1.0） adb shell settings put system font_scale 1.3 adb shell settings put system font_scale 1.0

如果同时挂着多台目标设备，上述命令同样要带上截图所用的-s <serial>，保证主题与字号的切换作用在正确的设备上。font_scale 1.3 相当于系统级"大字模式"，是验证 sp 单位是否真正生效、文案是否会被固定高度裁掉的最高性价比手段。

③ 证据来源要诚实

模拟器给出广度（多种设备形态、系统版本覆盖）；而手势、刷新率与真实性能表现必须依赖硬件真机。产出证据时必须说明它来自哪一种载体——模拟器结论不能冒充真机性能证据。

这套"截图入评审流、深浅/字重入验证、模拟器与真机分工并披露来源"的纪律，与 impeccable 其它原生入口（polish 参考要求按平台参考的 Verifying the build 章节在目标设备形态上验证、new-work 参考要求按该章节批量截图一轮定稿）保持一致，共同构成闭环的质量证据链。

资料来源与延伸阅读

本文主体规则源：.hermes/skills/impeccable/reference/android.md（内容带 machine-readable 规则锚点注释的源码版本为 skill/reference/android.md）
iOS 平台对照规则：skill/reference/ios.md
Platform 轴与规则路由设计：CLAUDE.md
原生评审与截图契约：skill/agents/impeccable-finish-reviewer.md、plugin/skills/impeccable/reference/audit.native.md
设计理念与命令总表：README.md、plugin/skills/impeccable/SKILL.md
归属声明：ios.md/android.md由 MIT 许可的 ehmo/platform-design-skills 提炼改写，署名详见 NOTICE.md