android-mobile-frontend-design

Name: android-mobile-frontend-design
Author: krutikjain

github.com/krutikjain设计与 UI1499 次安装31 周前更新

代码仓库

关于 android-mobile-frontend-design

用于创建、改进和修复 Android 移动界面的设计技能，适合使用 Compose 或 Views 的设计与开发工作。它围绕任务层级和视觉方向开展设计，并在实现前检查本地化、RTL、溢出及设备限制。

主要功能

01创建、改进和修复屏幕设计
02规划信息层级与导航框架
03适配翻译文本与 RTL 布局
04检查溢出、内边距和触控目标
05将工作交接给实现技能

适用场景

01设计新的 Android 屏幕
02改造杂乱或缺乏特色的界面
03修复文字裁切与操作不可达问题
04为本地化和折叠设备准备布局

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/krutikjain/android-agent-skills --skill android-mobile-frontend-design

安装后在 Claude Code 中输入/android-mobile-frontend-design确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

agents/

openai.yaml

references/

official-links.md

patterns.md

scenarios.md

scripts/

run_examples.sh

详细介绍

Android 移动端前端设计

适用场景

当请求涉及以下内容时使用此技能：Android 移动端前端设计、从零设计 Android 屏幕、重新设计 Android 移动端屏幕。
主要目标：从零设计 Android 移动端前端体验、改进现有屏幕，并修复 UI 问题；针对 Compose 和 Views 提供突出品牌、安全适配本地化且避免内容溢出的指导。
当工作以设计意图为先时使用此技能：层级、节奏、屏幕结构、导航栏、间距、表面模型、视觉方向、防溢出或适配本地化的移动端 UX。
当用户希望屏幕更有质感、更现代、更精致、更清晰、更平和、更具品牌特色或更符合移动端原生体验时，应在讨论实现细节之前使用此技能。
需要创建／改进／修复路由矩阵、Compose 与 Views 的交接规则，或本地化与溢出压力检查清单时，请阅读 references/patterns.md。
需要仅限文档的演练，了解新屏幕设计简报、OrbitTasks 重新设计评审或溢出／本地化修复流程时，请阅读 references/scenarios.md。
范围扩大时，转交给以下技能：
android-compose-foundations
android-material3-design-system
android-compose-accessibility
android-viewsystem-foundations
android-testing-ui

工作模式

`create`

屏幕尚不存在或只有粗略构想时使用。
从用户目标、主要任务、状态模型和移动端层级着手，而不是直接跳到颜色或组件。
尽早确定屏幕的主导模式：列表-详情、信息流、表单、仪表板、引导流程、确认流程或设置界面。

`improve`

屏幕功能正常，但显得平庸、杂乱、过时、令人困惑或视觉效果薄弱时使用。
先审查需要保留的内容：任务顺序、用户心智模型、品牌限制，以及已有的有效信息元素。
重新设计层级、间距、操作提示和操作重点；除非请求明确要求，否则不要改变产品意图。

`fix`

屏幕已经存在，且有明确的 UX 缺陷时使用：文字被裁切、间距不自然、操作无法触及、层级不佳、内边距异常、RTL 支持有误、加载状态薄弱或控件拥挤。
先修复最少量的布局和交互决策，以恢复清晰度，再考虑全面的视觉改版。
将“cut”视为 UI 被裁切、截断、缩短、遮挡或以其他方式出现视觉损坏，并将其作为首要故障模式处理。

工作流

首先选择操作模式：create、improve 或 fix。
用移动端视角定义屏幕的任务：谁在使用、他们必须快速完成什么、必须一眼看懂什么，以及哪些内容需要让人安心或放心。
在设计样式之前确定信息层级：主要操作、主导内容区块、次要操作、辅助元数据和恢复状态。
根据设备尺寸和任务频率，为任务选择合适的移动端框架：顶部应用栏、底部栏、侧边栏、底部弹层、FAB、分段控件、标签页或列表-详情分栏。
构建有意突出品牌、同时仍适用于 Android 的界面模型：密度、圆角风格、层次感、色彩基调和字体强调应体现产品特质，同时不妨碍触控操作。
根据真实移动端限制检验布局：长字符串、翻译后的标签、多行文本、RTL、窄屏、宽屏、键盘、系统栏、屏幕开孔、分屏、平板和折叠屏。
在交接给实现技能之前，验证操作可达性、触控目标、层级、对比度和浏览速度。
正确分配实现工作：

设计方案已确定，工作涉及 Compose 结构或布局时，使用 android-compose-foundations。
工作涉及令牌化、主题设置或自定义设计系统转换时，使用 android-material3-design-system。
语义、焦点或辅助功能行为需要专门处理时，使用 android-compose-accessibility。
所属界面使用 XML/ViewBinding/Fragment UI 时，使用 android-viewsystem-foundations。
设计已就绪，需要进行截图或交互验证时，使用 android-testing-ui。

出色 UI 的质量标准

移动端 Android UI 中的“出色”意味着什么

首屏立即回答三个问题：这个屏幕的用途是什么、什么最重要，以及用户接下来应该做什么。
屏幕看起来经过精心设计，而不是由默认组件拼凑而成：间距、字体比例、色彩强调、层次感和动效都强化同一种产品个性。
主要操作一目了然，同时不会显得喧闹。
UI 在压力下依然美观：翻译、字体缩放、键盘、手势导航、分屏和大屏调整都不会破坏使用体验。
产品的高级感来自自信且充分考虑使用阻力，而不是堆砌渐变、玻璃效果或装饰性元素。

实用设计规则

采用基于 Android 4dp 网格的一致间距节奏；在增加留白有助于清晰表达的地方，也要让屏幕充分舒展。
让排版各司其职：眉题/引导语、主标题、分区标签、正文、元数据和操作文本应层次分明。
每个视口区域都应有一个主导元素。如果主标题、筛选栏、卡片和 CTA 都同样抢眼，设计就失去了主次。
优先使用数量更少、表现力更强的表面，而不是堆叠许多弱化的卡片和分隔线。
用颜色明确状态、操作和可信度。不要把强调色当作壁纸。
动效应呈现结构、保持上下文或确认状态变化。如果动效只是装饰，就删掉。

常见屏幕类型的最佳实践

列表和信息流：让用户能在不到一秒内浏览并理解条目层级，有意识地控制行密度，并让次要元数据弱于影响决策的内容。
表单：保持标签始终可见，明确标示验证状态和必填项，并确保键盘上的焦点移动不会遮挡当前任务。
仪表盘：不要默认照搬桌面端的信息密度；应将内容组织成清晰的叙事结构：概览、决策和深入查看。
引导流程和空状态：每屏只讲一个要点，只设置一个主要操作，并在介绍细节之前先说明价值。
底部弹层和对话框：用于聚焦决策或上下文流程，不要用它们藏起整屏内容，导致导航失效。

设计方向

从移动端使用意图出发，而不是装饰

判断用户必须单手完成什么、哪些内容可以放在首屏以下，以及在动效、键盘和窄屏布局下哪些内容必须始终可见。
移动端 UI 应该给人精心设计的感觉，而不是被挤窄的桌面端 UI。小屏幕会比任何设计评审都更快暴露层级不清的问题。
品牌鲜明不意味着默认要更张扬，而是要让界面显得经过深思熟虑、令人难忘，并且有别于产品本身，而非泛泛的 Material 脚手架。

选择清晰的视觉基调

为每类屏幕选定一种主导基调：
自信实用：信息密集、清晰、快速、易读，并克制地使用颜色。
平和引导：留白更多、分区节奏更鲜明、强调更柔和，适用于友好的引导流程和空状态。
高端可信：层次丰富的表面、克制的动效、更精致的字体，在金钱、健康或不可逆操作相关场景中营造更强的信任感。
鲜明品牌：更大胆的色彩、令人难忘的形状和标志性的布局方式，同时确保触控安全且易读。
在相关屏幕间保持基调一致。高端仪表盘搭配扁平、普通的详情页，通常意味着设计系统尚未统一。

创建模式要点

从以下事项着手：
屏幕目标
用户状态和紧迫程度
主要操作的位置
内容顺序
加载、空、错误、离线和成功状态的规划
围绕主要操作选择页面框架：
用于完成流程的底部操作区域
仅在其为主要的可重复操作时才使用悬浮操作
用于上下文相关、可中断操作的表单
仅当切换内容类别是屏幕核心功能时，才使用标签页或分段控件
每个屏幕优先突出一个明确的主要操作。如果所有内容都在大声呼喊，就没有任何内容能引导用户。

改进模式要点

检查：
用户首先会注意到什么
主要操作目前位于何处
间距是否能体现内容分组
表面效果是显得平淡、杂乱，还是分隔过度
屏幕是否要求用户在操作前阅读过多内容
是否因为每个组件的视觉权重都相同，让屏幕显得平庸
动效、颜色和字体是在帮助用户定位，还是只是在增加干扰
保留：
产品逻辑
仍有帮助的用户操作习惯
现有良好的组件约定
已经发挥作用的设计令牌投入
通过调整强调顺序、合并薄弱分区、明确标签、增加留白，以及让行动号召醒目易见来改进，同时避免增加杂乱。

修复模式要点

诊断：
被裁切或截断的文本
无法适应较长文本的按钮、标签、选项卡和提示条
被键盘或系统栏遮挡的操作
表单高度异常或固定高度不安全的问题
对比度不足或触控目标过小
让密集屏幕更难浏览的间距问题
没有说明下一步该怎么做的空、加载或错误状态
所有内容尺寸、权重和紧迫程度都相同造成的视觉失衡
节奏感不足、圆角不一致、层级不统一或颜色使用不当导致的“廉价感”界面
先解决布局问题，再处理美观问题。一个在英语中看起来很高端、却在德语或阿拉伯语中出现布局问题的屏幕，还没有完成。

本地化与内容溢出最佳实践

面向本地化的设计

默认预期文本会变长，而不是将其视为边缘情况。
设计标签、筛选标签和 CTA 文本时，不要依赖英文字符串长度，确保翻译后也能适用。
对于必须明确表达内容的按钮、筛选器、横幅、引导文案和空状态，优先考虑多行布局。
将伪本地化视为设计工具，而不只是 QA 工具。如果伪本地化字符串导致视觉层级崩塌，说明设计不够稳健。
支持按应用设置语言及区域设置切换，不要假设所有界面都采用统一的密度或格式。
设计窄单元格和摘要行时，应考虑特定区域的数字、日期/时间格式、货币所需宽度和阅读节奏。
确保视觉强调不依赖于翻译后会消失的特定词序。

面向 RTL 的设计

安全地镜像方向性布局，不要将左右假设硬编码。
确保图标、尖括号、进度提示和文本对齐在 RTL 环境中显示正确。
不要依赖不对称内边距或镜像后会出问题的左侧锚定视觉技巧。
同一屏幕中出现混合方向内容时，应以可读性为设计目标，而不要假设整个界面都采用同一阅读方向。

溢出与截断安全性

除非已验证设计在长字符串、字体缩放和多行内容下都能正常显示，否则不要使用固定高度的文本容器。
不要因装饰性布局决策而裁切 CTA 标签、筛选标签、标签页、底部弹层、Snackbar、工具栏标题或底部弹层拉手。
优先采用安全换行和自适应重排，而不是静默截断。
只有在隐藏内容确实不重要，或提供了明确的恢复方式（例如展开、详情视图或等效于工具提示的帮助）时，才使用省略号。
确保键盘、IME 内边距、屏幕开孔、任务栏和系统栏不会遮挡主要操作或当前输入框。
在大屏设备和折叠设备上，避免将关键内容放在铰链、折叠区域或不便使用的空白区域。
在全面屏布局中，不要将依赖点击或拖动的关键 UI 放在与手势内边距冲突的区域。

自适应与全面屏最佳实践

默认采用全面屏设计：滚动内容和背景内容可以延伸至系统栏下方，但关键的可点击 UI 必须避开内边距和手势冲突区域。
对于目标 SDK 35+ 和更新的设备，应将全面屏视为 Android 常规体验的一部分，而不是可有可无的点缀。
使用窗口尺寸类别和自适应结构，让布局能够重组为侧边导航栏、多列区块或列表-详情布局，而不会变成拉伸后的手机 UI。
大屏至少应达到 Android 大屏设备「优化」质量的预期：不要采用黑边填充的思路、不要浪费空白空间，也不要假设只能使用手机导航方式。
折叠设备和多窗口状态应作为布局测试场景，而不是发布后的意外情况。

Compose 与 View 系统指南

Compose

如果重新设计需要灵活的层级、自适应结构、灵活的间距和可复用的 UI 基础组件，Compose 是理想选择。
如果屏幕适合采用组合式区块、更轻松地实现自适应分支，以及更现代的动效和视觉效果，请使用 Compose。
设计意图确定后，如果剩余工作是组件架构和布局实现，请交接给 android-compose-foundations。

Views 和 XML

View 系统屏幕同样值得精心设计；不要认为只有 Compose 屏幕才能呈现高品质体验。
规划改进时，应考虑 Fragment、RecyclerView、ViewBinding 和 ConstraintLayout 的实际情况。
优先采用响应式/自适应的 View 系统布局，而不是只能在一种设备配置上显示正常的静态、尺寸锁定型 XML。
屏幕设计方向明确后，如果剩余工作是 XML/Fragment 实现，请交接给 android-viewsystem-foundations。

设计准则

始终优先考虑移动端，不要将仪表盘网页的密集布局或依赖指针操作的假设带入手机屏幕，除非有充分理由。
以品牌为核心的样式必须兼顾本地化适配、防溢出和无障碍访问。
确保触控目标易于触达且清晰可见；视觉上的简约不能成为交互区域过小的借口。
从一开始就按边缘到边缘的布局和实际边缘内边距进行设计，而不是事后再补上。
通过自适应结构支持手机、平板、折叠屏和多窗口状态，而不是使用单一的硬编码画布。
改进现有屏幕时，保留产品的心智模型；除非需求明确要求，否则不要重新设计工作流。
优先考虑清晰的层次结构和便于恢复的用户体验，而非装饰性动效、表面装饰或额外的界面元素。
间距、字体排版、层次深度或色彩强调中至少有一项应让屏幕令人印象深刻；本技能的目标不是“安全但平庸”。

反模式

将手机屏幕设计成压缩版网页仪表盘，使用微小控件和密集的顶层导航。
使用固定宽度或高度，导致文本长度变化时立即出现裁切、截断或重叠。
将仅有英文的截图视为设计已完成的证明。
将主要操作藏在首屏以下、键盘后面，或弱化的界面元素中。
把每个区块都做成卡片、分隔线或带边框的表面，导致屏幕杂乱且难以快速浏览。
依赖在从右向左布局或窄屏上会失效的对称性技巧。
通过缩短文案来修复布局问题，而不是让设计具备结构上的适应能力。
明明针对问题进行修复就能解决，却在视觉上重做所有内容。
将视觉上的繁杂误认为高端品质。
交付的屏幕静态看起来不错，但在输入法编辑器、字体缩放或长篇内容下变得脆弱。

示例

顺利路径

场景：从头开始创建一个全新的 Android 移动屏幕，具备鲜明的层次结构、清晰的主要操作、自适应外壳和鲜明的品牌视觉风格。
命令：bash skills/android-mobile-frontend-design/scripts/run_examples.sh

边缘情况

场景：改进现有的 OrbitTasks Compose 屏幕，使其能够应对较长的本地化字符串、键盘边缘内边距和 RTL 镜像，而不会裁切控件。
命令：cd examples/orbittasks-compose && ./gradlew :app:assembleDebug

故障恢复

场景：在升级为全面重新设计之前，先修复现有 XML 屏幕中的截断、间距拥挤以及空状态和错误状态薄弱的问题。
命令：cd examples/orbittasks-xml && ./gradlew :app:assembleDebug

完成检查清单

已明确操作模式：create、improve 或 fix。
在开始实现细节之前，已明确视觉信息层次和主要操作的位置。
设计方向鲜明地体现品牌，同时仍符合移动端原生体验和平台使用习惯。
已明确考虑本地化、RTL、内容溢出、键盘和边缘内边距等压力场景。
已明确 Compose 与 Views 的分工，并将实现工作交接给相邻的正确技能。
最终指南可用于从头创建屏幕、改进现有屏幕或修复故障屏幕，且没有留下未解决的重大设计决策。

Official References

支持 Markdown

登录后评论