企业官网建设流程全解析

“我的app界面越来越好看了”——这话最近常在我这边出现。不是自夸，是用户主动发来的反馈。我负责的这款工具类app，上一版还被吐槽“像上个时代的产物”，到现在有人私信说“界面挺精致”，中间隔了大概两个多月。今天想把整个视觉升级的过程拆开讲一讲。我不聊玄学审美，只说能落地的方法、参数、代码，还有那些踩过的坑。如果你正在优化自己的app，或者刚接手一个界面老旧的存量项目，这篇文章应该能帮你少走不少弯路。

1. 改版前先想清楚：界面变好看的底层逻辑

很多人在优化界面时容易一上来就换皮肤、找新图、调颜色，结果改完一看更乱了。界面越来越好看这件事，本质上不是“画更多”，而是“删更准”。在动手之前，我花了三天时间做了一件事：把整个app按页面截屏，然后贴在白板上，用分类的方式标出每个页面的问题。

1.1 旧界面到底输在哪里

旧版界面有几个非常典型的问题，我相信很多存量app都有：

• 颜色太多。一屏里出现五六种高饱和颜色，按钮是蓝色的，标题是橙色的，标签是绿色的，连分割线都带颜色。
• 层级靠边框，不加border就不知道哪儿是哪儿。
• 间距随意，有的页面边距16dp，有的24dp，同一个页面里的元素间隔也忽大忽小。
• 字体只有两种大小，重要信息靠加粗硬撑，但字重和层级完全对不上。
• 缺乏状态反馈，点击按钮没有按压效果，加载转圈转得毫无灵魂。

把这些问题列出来之后，我非常清楚：这次改版不是“重新设计”，而是“建立秩序”。秩序感才是用户感知到“界面好看了”的真正原因。人对复杂界面好不好看的第一感知，往往来自统一性，而不是某个元素单独多惊艳。

1.2 确立一套可执行的设计原则

我给自己定了三条硬性设计原则，后续所有改动都必须靠拢这三条。

第一，内容优先。界面是用来承载内容的，不是用来展示设计技巧的。任何装饰元素，如果不能让用户更快扫到核心信息，就砍掉。

第二，层级靠深浅，不靠边框。两个卡片区块之间用背景色和阴影区分，而不是靠一条明显的描边线。这样整个页面会干净很多，视觉重量也更集中。

第三，动效有目的。每个动画要么解释空间关系（比如页面如何进入），要么反馈操作状态（比如按钮按下），绝不为了炫技而添加无效动效。

这三条原则看起来简单，但真正执行起来非常考验定力。因为总会有各种“临时需求”想往界面上塞东西，而原则就是用来挡住这些干扰的。

1.3 自建设计规范：数字化的间距与字号

我做的第一件具体工作，不是画图，而是建一套设计规范，并且把它写进代码里。

间距方面，我只保留了4个档位：4dp、8dp、16dp、24dp。别小看这个决定，之前界面乱，很大程度就是间距随手来的。统一成这几个档位后，无论页面内容怎么组合，视觉节奏都是稳定的。

字号方面，我定了一套基础规则：

这套规范看起来死板，但正是它让整个app在后续改版中保持了高度一致。你可能觉得“好看”和“规范”是两回事，但在工程化的app里，规范才是好看的地基。没有规范，今天你调好的界面，过两个月别人改一处逻辑，视觉就会崩掉。

2. 视觉细节逐个击破：真正让界面变好看的关键

有了规范和原则，接下来就是具体执行。这一部分我挑几个改动效果最明显的点展开讲，每一个都配了参数和代码，方便你直接抄。

2.1 色彩：从“五颜六色”到“主色+中性色”

色彩是视觉升级里见效最快的一步。旧版的问题在于颜色太多，而且每个颜色饱和度都很高。改版时我做了一个大胆的收缩：整个app的彩色只保留一个主色和一个辅助色，其余全部用中性色。

主色我用的是品牌蓝，色值是#2563EB，辅助色是暖橙#F59E0B，主要用于“警示”“强调”这类场景。剩下的灰阶从浅到深一共五档：#F8FAFC、#F1F5F9、#E2E8F0、#94A3B8、#334155。背景统一用最浅的两档，正文用最深的#334155，辅助文字用#94A3B8。

这个配色方案的好处是：页面一旦大面积使用中性色，用户的眼睛就会自动聚焦到少数有颜色的元素上，比如主按钮、链接、角标。优先级一下子就出来了。在Android里，我直接在colors.xml里定义好这些值，然后严格规定：任何页面不得使用规范之外的色值。

<color name="brand_primary">#2563EB</color> <color name="brand_accent">#F59E0B</color> <color name="bg_default">#F8FAFC</color> <color name="bg_card">#FFFFFF</color> <color name="text_primary">#334155</color> <color name="text_secondary">#94A3B8</color> <color name="divider">#E2E8F0</color>

你可能会担心这样会不会太素。其实不会，中性色不等于廉价，关键是层次是否拉得开。背景、卡片、文字三者的明度对比一旦拉开，页面自然会显得干净又精致。反而是那些处处都想“有点颜色”的界面，最容易让人疲劳。

2.2 字体：层级和字重比换字体更重要

很多朋友喜欢折腾字体，总觉得换个字体界面就能变好看。但对我来说，字体层级比字体本身重要得多。系统默认字体其实完全够用，我们要做的是让它“有秩序”。

改版时我给整个app重新定义了文本样式（TextStyle），而不是继续在布局里一个控件一个控件地设字号。在Jetpack Compose里是这样的：

val Typography = Typography( titleLarge = TextStyle( fontSize = 22.sp, fontWeight = FontWeight.Bold, lineHeight = 28.sp ), titleMedium = TextStyle( fontSize = 16.sp, fontWeight = FontWeight.Medium, lineHeight = 22.sp ), bodyMedium = TextStyle( fontSize = 14.sp, fontWeight = FontWeight.Normal, lineHeight = 20.sp ), labelSmall = TextStyle( fontSize = 12.sp, fontWeight = FontWeight.Normal, lineHeight = 16.sp ) )

注意lineHeight这个参数，很多人会忽略。字号14sp时，行高20sp是最舒服的阅读节奏，太紧会挤，太松会散。行高对界面精致度的影响远超你想象，尤其是列表类页面，行高统一之后，整个屏幕的“呼吸感”一下子就出来了。

另外一个小技巧：正文和标题的字重区分。以前我喜欢用“字号变大”来区分标题和正文，但后来发现，字号差距不够大的时候，只靠字重变化也能做出非常清晰的信息层级。比如区块标题用16sp Medium，正文用14sp Regular，视觉上能明显感觉到区块标题更“稳”，但整体又不会显得字号跳脱。

2.3 圆角、阴影与卡片层级

卡片化是现在app界面的大趋势，但卡片做不好最容易显low。我总结的经验有三点：圆角统一、阴影克制、留白够。

圆角方面，我定了一套统一规格：小卡片圆角12dp，大容器圆角16dp，按钮圆角10dp，头像圆角50%。以前项目里圆角各种值都有，4dp、8dp、20dp混在一起，看起来非常散。统一之后视觉一致性立马上来。

阴影方面，我踩过一个坑：一开始为了突出卡片，给每个卡片都加了很重的阴影，结果整个页面灰蒙蒙的，像蒙了一层雾。后来我改用“轻阴影+浅背景”的组合：卡片背景用#FFFFFF，页面背景用#F1F5F9，阴影只用非常浅的一层来勾勒轮廓。

android:elevation="2dp"

在XML布局里，elevation="2dp"就够用了。如果非要更明显的层级感，我会优先用背景色变化，而不是继续加阴影。记住：阴影是锦上添花，不是用来区分层级的唯一手段。把层级交给背景明度，画面会干净得多。

2.4 底部一级导航栏：一级入口的精细打磨

底部导航栏是每个用户每天都要看的组件，它的精细程度直接影响整个app的质感。我这次改版在nav bar上下的功夫，可能比首页还多。

首先是高度。很多app底部栏做得太高或者太矮，底栏高度我是这样算的：系统导航安全区高度 + 56dp的内容区。Android里要适配手势导航，必须给底栏留出安全区，否则会跟系统手势条重叠。

然后是图标与文字的交互。未选中状态用线性图标，选中状态用填充图标，这个变化本身就能传达“已选中”的含义。颜色上，未选中#94A3B8，选中用主色#2563EB。这个对比够强烈，用户一眼就能看出当前所在页。

还有一个小细节：切换时的动效。旧版底部栏切换页面是瞬间跳转，十分生硬。我加了两个东西，一个是图标切换时的轻微缩放动画，另一个是页面切换的淡入淡出。别小看这点动效，用户的“流畅感”很大程度上就来自这些过渡细节。

scaleIn + fadeIn

在Component Activity中，用Crossfade或者AnimatedContent来切换主页面，比直接setContent要自然得多。视觉升级到这一步，整个app已经初步有了“精致”的底子。但真正让它“活”起来的，是下一部分的动效和状态反馈。

3. 动效与状态反馈：从“不丑”到“好用好看”

界面的“好看”分两层。第一层是静态的好看，就是颜色、字体、间距这些东西，一眼看上去舒服。第二层是动态的好看，是手指触摸时、页面跳转时、加载等待时，app给你的反馈是否跟手、是否自然。第二层往往是区分普通app和优秀app的分水岭。

3.1 转场动效：300ms规则

我给所有页面转场定了一个统一的规则：标准时长300ms，快进快出。页面进入时用一个轻微的从右往左滑动+淡入，退出时反向。滑动距离我控制在屏幕宽度的1/4左右，不要来一个从屏幕外面整体滑入的“大动作”，那种动效太抢戏。

为什么是300ms？这是众多设计系统验证过的一个中间值。少于200ms会感觉生硬，多于400ms会明显觉得拖沓。300ms配合FastOutSlowIn这类缓动曲线，既有速度感，又不会让人觉得急促。

在Android的ActivityOptions里可以这么写：

ActivityOptions options = ActivityOptions.makeCustomAnimation( context, R.anim.slide_in_right, R.anim.slide_out_left );

如果你的app页面较多，强烈建议所有转场统一使用同一套动画资源，避免有些页面有动画、有些页面没有的割裂感。割裂感是“高品质感”的头号杀手。

3.2 按压反馈：每一次点击都要有回应

一个我见过很多app忽略的细节：点击按钮没有任何按压反馈，手指点下去屏幕毫无反应，用户会怀疑自己是不是没点中。这次的改版里，我给所有可点击控件都加了按压态。

按钮按压态最便宜也最有效的实现方式是改变透明度，或者叠加一层半透明遮罩。在Android中，使用RippleDrawable就能做出比较标准的波纹反馈：

<ripple android:color="#332563EB"> <item android:id="@android:id/content"> <shape> <solid android:color="@color/brand_primary"/> <corners android:radius="10dp"/> </shape> </item> </ripple>

这里#332563EB是主色加20%透明度，按压时会在按钮上扩散一层淡淡的蓝色波纹，松手后消失。比简单改背景色柔和很多，配合RippleDrawable的原生反馈，手感会明显“跟手”。

列表项的点击也要有反馈。整个item是点击区域时，直接在背景上加ripple即可。这里有一个容易踩的坑：如果你给item背景直接设置了普通色值，ripple会被背景挡住，点上去没有波纹反馈。解决方案是把ripple作为背景，item本身的颜色放到ripple的content里去。

3.3 空状态、加载状态与错误状态

很多app好看是好看，但一旦遇到加载失败、列表为空，就原形毕露——一个孤零零的灰色文字“加载失败”，配上毫无美感的按钮，前面积累的好感全没了。状态页也是界面的一部分，必须一起改。

空状态我统一用“主题插画+文案+行动按钮”的结构。插画不是随便找一张图，而是和主色呼应的简单线性插图，文案说明“这里还没有内容”，按钮引导用户去操作。错误状态多一个“重试”按钮，点击后重新请求。

加载状态这里有个细节：不要只放一个转圈。最好在转圈下面配一句文案，比如“正在加载XXX”，让用户知道系统在工作。如果是列表加载更多，底部放一个小型加载指示器就好，不要整个页面弹转圈，那样会打断用户浏览。

3.4 暗黑模式不能只顾一半

说实话，暗黑模式第一次做的时候我差点翻车。因为只把背景改成黑色、文字改成白色，结果是：卡片和背景都黑成一团，层次感全没了。

暗黑模式做好的关键在于：不能简单反色，要重新设计一套暗色下的灰阶层次。我的做法是，暗色下背景用#0F172A（近黑深蓝），卡片用#1E293B，分割线用#334155，正文用#E2E8F0，辅助文字用#94A3B8。注意，暗色模式下文字不能是纯白，纯白在暗背景下会显得刺眼，稍微带一点灰反而更舒适。

还有阴影。暗色模式下阴影基本没用，因为黑背景上看不到黑影子。这时就需要用“提亮卡片背景”来区分层级，而不是继续依赖阴影。这也是我前面说“层级靠背景明度”的原因，暗黑模式下这套逻辑依然成立，只是明度方向反过来了。

如果项目时间紧张，我建议先用isLightTheme做好基础适配，至少保证暗黑模式下所有页面可读、无刺眼对比。尽量别出现“半边亮半边暗”的情况，那种割裂感对用户体验伤害非常大。

4. 从设计到代码的落地细节：界面好看的最后一步

设计和视觉稿只是第一步。真正让界面“越来越好看”的，是前端和客户端把这些规范一丝不苟地落到代码里。很多改版项目失败，不是设计不好，而是落地时走了样。这一节我整理几个最关键的落地细节。

4.1 用设计令牌统一管理样式

前面我提到在colors.xml里统一色值，这只是第一步。更进一步的做法是引入“设计令牌（Design Token）”的概念：不直接在任何控件里写死#2563EB，而是先定义一个语义化的名字，比如brand_primary，然后再由它去控制各个组件。

为什么这样做？因为后续如果你想调整主色，只需要改令牌的值，整个app所有用到这个令牌的地方会自动更新。我就在一次品牌色微调时吃过没做令牌的亏：全局搜#2563EB搜出20多处，改的时候漏了两处，结果页面上出现了两个接近但不一样的蓝色，用户一眼就看出来了。

如果你用的是Jetpack Compose，可以定义一组MaterialTheme的颜色：

private val LightColors = lightColorScheme( primary = BrandPrimary, background = BgDefault, surface = BgCard, onSurface = TextPrimary, onSurfaceVariant = TextSecondary )

用的时候只引用MaterialTheme.colorScheme.primary，不直接引用具体色值。间距、圆角、字号也都可以做成类似的令牌。这是一次性的投入，但对后续维护的价值是长期的。

4.2 Android 与 iOS 双端还原差异

两端还原同一个设计稿时，总会有一些细微出入。这里说两个最常见的坑。

第一个是字体渲染差异。Android的默认中文字体是思源黑体（HarmonyOS Sans/Roboto），iOS是苹方，同样是14sp，苹方看起来会稍大一点点。别纠结于像素级一致，重要的是两端的字号缩放比例关系保持一致，也就是“标题大于正文、正文大于辅助文字”这个层级关系不能乱。

第二个是安全区。iPhone底部有Home Indicator，Android有手势导航条，底部固定按钮、底部导航栏都必须适配各自的安全区。我见过很多app，Android上底栏被手势条遮住一部分，或者iOS上按钮贴到了Home Indicator上。这个细节非常影响“精致感”，适配方法两端各有API，但记住一条原则：底部交互元素的下边距 = 安全区高度 + 固定间距。

4.3 几个高频控件的实现要点

这里不讲大架构，只讲几个改版中我反复用到的、对质感影响最大的控件实现细节：

圆角卡片列表

列表页面我会用CardView或 Compose 的Card，背景白色、圆角12dp、高度2dp，列表项与项之间留16dp间距。整个页面背景用浅灰色#F1F5F9，这样卡片会非常突出，又不依赖重阴影。

主按钮（Primary Button）

按钮高度统一48dp，圆角10dp，文字16sp Medium，背景主色，按压态用ripple。禁用态改成#94A3B8加40%透明度，不能只是把颜色改灰，那样会显得很脏。

输入框（TextInput）

输入框聚焦时边框颜色切到主色，未聚焦时用分隔线色#E2E8F0。这个交互细节对表单类页面尤其重要，能让用户明确知道当前输入的位置。

Toolbar/标题栏

标题栏文字不居中，靠左对齐，字号22sp Bold。标题栏背景跟页面背景一致，不要单独给一条明显的标题栏颜色，让内容自然地延伸到顶部，会更现代。

4.4 发布前的视觉验收清单

在提测和发布之前，我会拿着设计稿，一台一台真机做视觉验收。这一步我总结了一个简洁的自查清单：

• 字体层级是否清晰？每个页面的标题、正文、辅助文字是否都用了对应字号和字重？
• 页面背景、卡片背景、分割线是否都来自设计令牌？有没有出现“野生色值”？
• 底部导航栏图标在选中/未选中状态是否正确？颜色是否符合规范？
• 暗黑模式下是否所有页面都适配了？有没有刺眼对比或不可读文字？
• 点击按钮、列表项是否有按压反馈？
• 键盘弹出、拉起相册这类系统交互出现时，界面是否错位？

这张清单每次提测前我都会过一遍。别嫌麻烦，界面“精致感”就是靠这一项一项抠出来的。有一次我在验收时发现某个二级页面的空状态还是旧版灰字样式，就是因为清单没走全，漏掉了它。

5. 常见问题与排查技巧实录

这一部分换一种方式聊。我按照真实开发中踩过的坑，整理成了一组“症状+诊断+解法”的速查表，希望对你有帮助。

5.1 色值偏色的原因与排查

症状：真机上的颜色跟设计稿不一样，明显偏黄或者偏暗。

诊断方向：先看是不是屏幕色域问题，P3和sRGB在红色上差异明显；再看布局文件里有没有二次叠加透明度；最后检查有没有night mode资源干扰了日间的颜色。

解决思路：团队里统一使用sRGB色值，切图导出时注意色彩配置文件。代码里尽量使用规范的色值定义，不要直接在控件上叠加多层透明度，容易产生不可预期的混色结果。我在做暗黑模式时遇到过，日间模式页面突然出现了暗色背景，排查半天发现是日间资源里漏了一段values-night的覆盖。

5.2 真机与设计稿尺寸不一致

症状：设计稿上完美的间距，真机上一看要么太挤，要么空荡荡。

诊断方向：原因基本有两个：一是没有考虑屏幕密度，设计稿标注的px值直接用到了dp；二是使用了比例适配但临界值没处理好。

解决思路：Android端一律用dp和sp，iOS用pt，严格禁止用px写布局。设计稿标注多少dp，代码里就是多少dp，但要注意在极小屏和折叠屏上做上下限保护，比如maxWidth限制内容宽度，防止在大屏上文字拉得过长。

5.3 动效卡顿的优化

症状：加了动效之后界面反而显得“卡”，掉帧明显，特别是列表滑动时。

诊断方向：优先检查动画作用的属性。如果直接改了布局的layout_margin或者width/height，很容易触发整页重新测量和布局，这种开销是很高的。还有阴影层叠和多层半透明叠加，也会拖慢渲染。

解决思路：动效尽量作用于alpha、translationX/Y、scaleX/Y这类只触发重绘不触发布局的属性。用ViewPropertyAnimator或者Jetpack Compose的animateDpAsState，都会自动选择高效路径。列表滑动时，避免在onScroll里直接控制大量视图属性，尽量用组合的方式合并动画。

5.4 我的最终自查清单

除了前面发布前的视觉验收清单，我再分享一份自己长期维护用的“健康自查表”。它不是一次性检查项，而是每次迭代都要对照的标准。

这套清单执行下来，就算中途有新人接手，界面风格也不容易跑偏。视觉升级从来不是一次性的“改版发布”，而是一套规则体系的建立和长期执行。

个人经验：界面好看是一个持续迭代的过程

文章写到这里，最后分享一点我的真实体会。很多朋友觉得“界面变好看”是一次改版冲刺，做完就完了。实际上不是。上线才是开始，后面还有各种新需求、新页面加进来，如果之前定下的规范没有贯彻到位，界面会一点一点变回去，这就是所谓“慢慢看腻了”的真相。

我自己现在固定做两件事。第一，每次需求评审时，凡是涉及界面的，都拿设计规范核对一遍，宁可多开一次会，也不放不合格的样式进代码仓库。第二，每两周花半小时把app的线上版本全部点一遍，重点看状态页、暗黑模式这些“边角”有没有退化。

这样维持了几个月之后，我最大的感受不是“界面好看”，而是“界面很稳”。用户也许说不出具体哪里变了，但他们会觉得这个app越来越可靠、越来越高级。界面好看的本质是可信赖，这个道理，做产品的人越早明白越好。