企业官网建设流程全解析

Impeccable Android 平台设计指南：以 Material 3 为准绳的原生 Android 界面审查与验证实践

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

Android 原生界面（Jetpack Compose、Android Views、React Native、Expo、Flutter）如何在保持品牌表达的同时获得“像原生一样”的信任感？本指南以 Impeccable 设计技能库中的 Android 平台参考文档 为骨架，系统讲解 Material Design 3 框架下的布局、触控、排版、色彩、动效规范，以及基于 adb 的真机/模拟器截图验证流程。读完本文，你将掌握一套可直接执行的 Android 平台设计检查清单与命令行验证方案，并了解它在 Impeccable 审计、适配工作流中的具体落点。

适用范围与核心原则：访客模式下 Material 3 是唯一规则书

该参考文档面向所有最终运行在 Android 硬件上的原生应用：Jetpack Compose、Android Views、React Native、Expo、Flutter 均在其列。它的核心前提是一个贯穿 Impeccable 设计体系的“访客模式”（visitor mode）概念：访客模式收窄了表达层可以覆盖的范围——即结构、导航与交互在每种模式下都必须由 Material Design 3 管辖，品牌只能通过 Material 的主题化机制（color roles 色彩角色、type scale 字体阶梯、shape 形状、motion 动效）来表达自己，而不是绕过平台规范另起炉灶。

这里有一个容易被忽视的边界：一个“处处 Material”的跨平台应用如果同时发布到 iPhone，那么在 iOS 硬件上它仍然欠 iOS 一份操作系统级的保证——安全区 insets、Reduce Motion（减弱动态效果）、边缘滑动返回（edge-swipe back）。这正是 iOS 平台参考 所管辖的范围。从仓库中可以看到，Impeccable 将这类平台知识组织成“参考文档”（reference）体系：init命令在记录到平台为ios、android或adaptive时会自行加载对应的原生平台参考（见 skill/SKILL.src.md），audit.native与adapt.native也都会在开始前读取目标平台参考文档作为评分与规划依据（见 skill/reference/audit.native.md 与 skill/reference/adapt.native.md）。

The Android slop test：一眼识破“披着 Android 皮的 iOS 应用”

“Android slop test”（Android 廉价移植测试）是该参考文档的验收门槛：一个熟练的 Android 用户会信任这个应用，还是在偏离规格的组件上绊倒？

最常见的失败信号恰恰是“披着 Android 皮肤的 iOS 应用”：

• 照抄 iPhone 的仅底部导航（bottom-only navigation）；
• 存在无视系统返回手势的后退箭头（back arrow that ignores the system Back gesture）；
• 出现Cupertino 形状的开关和对话框（Cupertino-shaped switches and dialogs）。

结论很明确：Material 3 是规则书，跟随它的组件，并通过它来主题化品牌。在 audit.native.md 的“Platform Conformance（CRITICAL）”维度中，这一测试被操作化为具体扣分项——预测性返回被劫持（predictive Back hijacked）、Web 形状控件（web-shaped controls）、图标漂移（混合图标集而非 Material Symbols）、iOS 模式出现在 Android 上等。而在 adapt.native.md 的“平台到平台”迁移表中，iOS ↔ Android 惯用法被一一翻译而不是移植：Tab bar ↔ Navigation bar / rail / drawer，边缘滑动返回 ↔ 预测性 Back 手势/按钮，Switch/segmented control ↔ Material switch/chips/Material pickers，Action sheet ↔ Bottom sheet/Material dialog，SF Symbols/SF Pro/Dynamic Type ↔ Material Symbols/Roboto/sp 缩放，语义系统色/material ↔ Material color roles/tonal elevation，系统 push/sheet 转场 ↔ container transform/shared-axis/fade-through。

布局与结构：从导航形态到窗口 insets 的四个硬性要求

布局层面的规则在文档中以带规则 ID 的检查项呈现（这些 ID 同时是审计时可直接引用的规则标识）：

• Material 导航需与屏幕尺寸匹配（android-layout-adaptive-nav）：窄屏（compact width）使用底部导航栏（navigation bar，3–5 个目的地）；宽屏（expanded width）切换为导航栏抽屉（navigation rail）或抽屉（drawer）。绝不允许把手机的底部栏原封不动地搬到平板上。
• 系统返回必须始终可用（android-layout-system-back）：尊重预测性 Back 手势与返回按钮，绝不困住用户或劫持该手势。
• 边到边渲染配合窗口 insets（android-layout-window-insets）：应用状态栏、导航栏、刘海/挖孔（display cutout）与 IME（输入法）insets，确保内容永远不会藏在系统栏或键盘后面。
• 顶部应用栏（top app bar）提供屏幕上下文；当屏幕只有一个主操作时，搭配一个 FAB。

值得强调的是adapt.native.md的补充视角：平板适配的关键是从window size classes（窗口尺寸类）驱动结构而非机型判断，并且“多窗口（multi-window）是一种尺寸，不是边缘情况”——Android 多窗口可以把手机宽度的窗口放到平板上，尺寸类驱动的布局可以免费处理这一切（skill/reference/adapt.native.md）。

触控目标：48×48 dp 与 8 dp 间距底线

文档给出单一但明确的标准（规则 IDandroid-touch-target-48dp）：

每个触控目标最小48×48 dp，目标之间至少8 dp间距。

对比 iOS 参考文档的 44×44 pt，可看出平台差异被严格区分。在audit.native.md的“Accessibility”维度中，触控目标低于 48 dp（Android）或 44 pt（iOS）、以及目标拥挤无间距，都是明确的扣分项（skill/reference/audit.native.md）。

排版：Material 字体阶梯、系统字体与 sp 可缩放单位

排版规则对应三个规则 ID：

• Material 字体阶梯（android-typo-type-scale）：使用 Display、Headline、Title、Body、Label 五类角色（每类各有 large/medium/small）。把文本映射到角色，绝不为每个屏幕手挑字号。
• Roboto 是系统字体（android-typo-system-font）：通过字体阶梯主题化品牌字体，保证正文、标签与控件清晰一致。
• sp 单位而非固定 px（android-typo-scalable-sp）：让字号跟随系统字体大小设置。

后者直接呼应audit.native.md的可访问性检查项“固定 point 大小破坏了 Dynamic Type（iOS）或使用 px 而非 sp（Android）的布局在放大字号时被裁剪或重叠”（skill/reference/audit.native.md）。这也是后续验证环节中font_scale 1.3检查的意义所在。

色彩与主题化：从角色 token 到 Dynamic Color 与色调高度

• Material 色彩角色（android-color-role-tokens）：primary、on-primary、surface、surface-variant、secondary-container、outline、error。角色 token 会自动解析亮色/暗色与对比度变体；裸 hex 色值在这些场景下会失效。
• Dynamic Color（Material You）（android-color-dynamic-color）：在合适的场景下，从 Android 12+ 的用户壁纸派生配色方案，并提供静态回退方案。
• 深色主题是一等方案（android-color-dark-theme）：要真正设计与测试深色主题，绝不做快速的取反。
• 色调高度（android-color-tonal-elevation）：通过标准的 surface 色调等级传达高度感（必要时辅以阴影），不用任意的投影。

audit.native.md的 “Appearance & Theming” 维度逐条对应：裸 hex 代替 Material 色彩角色/设计 token、缺少深色变体、无静态回退的 Dynamic Color、以及用手搓的视觉材质代替系统材质或 tonal elevation，均属于硬编码与主题化缺陷（skill/reference/audit.native.md）。

组件与动效：Material 组件、单一 FAB、Snackbar 与四种动效模式

• Material 组件（android-components-material）：filled / tonal / outlined / text 四类按钮、FAB、开关、chips、Snackbar、底部弹层（bottom sheets）、Material 对话框、导航栏/抽屉。绝不复刻 iOS 控件，也不自行发明等价物。
• 单一 FAB 单一主操作（android-components-single-fab）：绝不堆叠 FAB，也不把 FAB 花在次要任务上。
• Snackbar 用于瞬时反馈（android-components-snackbar）：需要时携带操作项，但绝不用 toast 替代；只有必须打断的决策才用对话框。
• Material 动效模式（android-motion-material-and-reduce）：container transform、shared-axis、fade-through，配标准缓动与时长；当系统开启“移除动画”（Remove animations）设置时，降级为交叉淡化或瞬时切换。

动效的可访问性在audit.native.md中同样被列为检查点：“忽略 Reduce Motion——视差和大幅滑动没有交叉淡化替代”（skill/reference/audit.native.md）。

验证构建：adb 驱动的截图取证流程

这是本参考文档最具实操价值的部分：Android 的验证截图必须来自模拟器或连接的真机，绝不允许来自浏览器。完整流程如下：

1. 构建并安装，然后用adb exec-out screencap -p > <path>截图；多台设备连接时用adb -s <serial>指定设备。
2. 覆盖所有发布目标设备类别：至少一台手机；若平板是发布目标，再截一台平板。截图文件写入审查流程（review flow）期望的路径。

深色主题与字体缩放属于必测项，这是固定布局最常见的翻车点：

# 切换深色主题 adb shell cmd uimode night yes # 放大字体到 1.3 倍，捕获固定布局隐藏的裁剪标签 adb shell settings put system font_scale 1.3 # 验证完毕后恢复 adb shell settings put system font_scale 1.0

多台目标设备连接时，上述命令同样需要带上-s <serial>。

最后一条原则关乎证据诚实性（android-verify-hardware-honesty）：模拟器能提供覆盖面，但手势、刷新率与性能需要真实硬件——审查产出物必须说明证据来自哪一种。

参考文档在 Impeccable 工作流中的落点

该 Android 参考不是孤立的规范文本，而是被 Impeccable 的命令体系直接引用的裁决依据：

• 上下文加载：impeccable context会在适用时加载原生平台指南（见 skill/SKILL.src.md）；init在平台被记录为ios/android/adaptive时会自行加载对应的原生平台参考（skill/SKILL.src.md）。
• 原生审计：audit.native从源码（SwiftUI / UIKit / Compose / React Native / Flutter）评分，并明确“针对平台参考评分（ios.md / android.md），adaptive 两者都要读”(skill/reference/audit.native.md)；其“Platform Conformance”维度直接内置了 slop test 的操作化版本。
• 原生适配：adapt.native在规划前读取目标平台参考，并要求“当适配在每个上下文里都显得原生时，交给 impeccable polish 做最终打磨”（skill/reference/adapt.native.md）。
• 测试证据：仓库的 oracle 黄金夹具中可见平台字段如何被解析——Platform: Android解析为platform: "android"，ios, android解析为adaptive（参见 tests/oracle/golden/context-android.json 与 tests/oracle/golden/context-adaptive.json），说明“原生平台 vs 自适应平台”的分流在引擎层是真实生效的。

结语：把 Material 3 当规则书，而不是建议

总结这份 Android 平台参考的核心主张：在 Android 硬件上，Material Design 3 是结构、导航与交互的唯一规则书，品牌通过它的主题化层表达；slop test 是验收门槛，48 dp 触控目标、sp 字号、色彩角色、tonal elevation、Material 组件与动效是具体落点；而验证必须回到模拟器/真机，用adb exec-out screencap取证，并把深色主题与 1.3 倍字体缩放纳入每个通过（pass）。这套规范与验证闭环，构成了 Impeccable 在 Android 原生面上“让设计经得起推敲”的底线。

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