企业官网建设流程全解析

1. 从"我的应用"这个页面说起：为什么值得单独仿一遍

支付宝的"我的"页面看起来平平无奇，但如果你真正动手去仿，会发现它是整个App里信息密度最高、交互层级最深、状态管理最复杂的页面之一。顶部是用户信息区，往下是资产总览卡片，再往下是功能宫格、服务卡片、列表入口，底部还有一层悬浮的运营位。每一块都有自己的数据来源、自己的刷新逻辑、自己的点击跳转规则。

我之所以挑这个页面来做仿写练习，原因很直接：它几乎覆盖了Android日常开发中80%的UI场景。网格布局、卡片圆角阴影、多类型列表、分组标题、图标文字混排、状态栏沉浸、下拉刷新、局部数据更新，这些东西你在这个页面里都能碰到。而且它的视觉规范相对克制，没有太多花哨的动效，适合把注意力放在"结构怎么搭、数据怎么管"上面。

这篇内容适合谁看？如果你已经写过几个Activity、用过RecyclerView、对Fragment有一点概念，但一遇到"多类型列表怎么组织""嵌套滚动怎么处理""数据怎么分层"就犯怵，那这篇就是写给你的。我不会只丢一堆代码出来，而是会把每个模块为什么这样设计、当时踩过什么坑、有哪些看起来能用但实际会出问题的做法，都摊开讲清楚。

Demo的整体技术选型走的是"原生+轻量"路线：Kotlin + RecyclerView多类型 + 自定义组合控件 + 本地Mock数据。没有引入任何重型框架，目的是让你能把注意力放在UI结构和数据流本身，而不是被框架的API淹没。等你把这套结构吃透了，换成任何MVVM框架都是顺手的事。

2. 页面骨架拆解：先想清楚"谁管谁"，再动手写布局

2.1 为什么不用ScrollView一把梭

新手最容易犯的错误，就是看到"整页可以滚动"就条件反射地套一个ScrollView，里面塞LinearLayout，然后往里面一个个addView。这个做法在页面简单的时候确实快，但放到"我的"这种页面上，问题会一个接一个冒出来。

首先是性能。ScrollView会把所有子View一次性全部测量、布局、绘制，哪怕它还在屏幕外面。这个页面往下拉有几十个图标和入口，全部一次性inflate的代价是启动时明显的卡顿。其次是复用。ScrollView没有复用机制，每个条目都是独立的对象，内存占用随条目数量线性增长。最后是嵌套滚动。页面里如果有横向滚动的运营位、有可以左右滑的卡片，ScrollView和它们的滑动冲突处理起来非常难受。

所以正确的做法是：整个页面用一个RecyclerView承载，把不同区块抽象成不同的Item类型。顶部用户信息是一种类型，资产卡片是一种类型，功能宫格是一种类型，分组标题是一种类型，普通列表项是一种类型。RecyclerView只负责按顺序把它们摆出来，复用和回收交给它自己处理。

提示：用RecyclerView做整页容器时，记得把嵌套的横向RecyclerView的nestedScrollingEnabled处理好，否则会出现滑动方向判断混乱的问题。

2.2 多类型列表的Adapter该怎么组织

多类型列表的核心在于getItemViewType。很多人写多类型Adapter时喜欢用一个巨大的when分支把所有逻辑堆在onBindViewHolder里，结果就是几百行的巨型方法，改一处牵一发而动全身。

我的做法是引入"Item模型+委托"的思路。先定义一个密封类表示所有可能的条目类型：

sealed class MineItem { data class UserHeader(val avatar: String, val name: String, val phone: String) : MineItem() data class AssetCard(val totalAsset: String, val yesterdayEarning: String) : MineItem() data class GridSection(val title: String, val items: List<GridItem>) : MineItem() data class ListEntry(val iconRes: Int, val title: String, val subtitle: String?) : MineItem() data class SectionTitle(val title: String) : MineItem() }

然后为每种类型定义一个独立的绑定器，Adapter只负责根据类型分发。这样做的好处是：新增一种条目只需要加一个密封类子类和对应的绑定器，不用动已有的代码；每种条目的布局逻辑独立，测试和调试都方便；类型安全，编译期就能发现漏处理的分支。

2.3 顶部用户信息区的沉浸式处理

顶部用户信息区通常是带背景图的，背景要延伸到状态栏下面，但文字内容要避开状态栏。这个效果靠fitsSystemWindows是搞不定的，正确做法是手动处理WindowInsets。

具体来说，在Activity的onCreate里设置WindowCompat.setDecorFitsSystemWindows(window, false)，让内容延伸到系统栏区域。然后在用户信息区的布局里，给容器设置一个top padding，值等于状态栏高度。状态栏高度通过ViewCompat.getRootWindowInsets获取，注意要在视图attach之后才能拿到准确值。

这里有个容易忽略的细节：如果页面顶部有渐变背景，状态栏区域的颜色要和背景自然衔接，不能出现明显的色块断层。我的处理方式是在背景图上叠一层从透明到目标色的渐变，渐变高度设为状态栏高度加上一段过渡距离，这样视觉上就平滑了。

3. 资产卡片与功能宫格：视觉还原背后的计算逻辑

3.1 卡片圆角、阴影与层级关系的还原

支付宝的资产卡片有几个视觉特征：大圆角、轻微的投影、卡片之间有明确的间距、卡片内部有主次分明的文字层级。这些看起来是设计师的事，但落到代码里全是计算。

圆角用CardView或者MaterialCardView都能实现，但我更推荐直接用ShapeableImageView配合ShapeAppearanceModel，或者干脆在背景drawable里写<corners>。原因是CardView自带一层阴影实现，在某些机型上阴影渲染会有性能开销，而且阴影颜色不好精确控制。如果设计稿的阴影很淡，用elevation往往还原不到位，这时候用一层半透明的渐变drawable模拟阴影反而更准。

卡片之间的间距，我建议用ItemDecoration统一处理，而不是在每个item布局里写margin。原因是margin会让item的边界变得不直观，做点击涟漪效果时涟漪范围会包含margin区域，看起来很奇怪。用ItemDecoration在item之间插入间距，item本身的边界就是内容边界，点击反馈和视觉边界一致。

3.2 功能宫格的列数计算与自适应

功能宫格通常是4列或者5列，但不同屏幕宽度下如果写死dp值，在大屏手机上会出现图标挤在一起或者间距过大的问题。正确的做法是让列宽自适应。

我的实现方式是：在自定义ViewGroup的onMeasure里，先拿到可用宽度，减去左右padding和列间距总和，除以列数得到每个格子的宽度，然后按这个宽度去测量每个子View。行高方面，如果设计稿给的是固定宽高比，就按宽度乘以比例算出行高；如果是固定高度，就直接用固定值。

这里有个细节：图标和文字的组合，文字可能是两行，也可能是一行。如果按固定高度测量，两行文字可能被截断。我的处理是给文字区域设置最大行数，同时在测量时用measureText预估文字高度，取图标高度和文字高度中的较大值作为格子高度。这样无论文字长短，格子高度都能自适应。

3.3 宫格点击的涟漪范围与触摸反馈

宫格的点击反馈，默认的foreground涟漪会覆盖整个格子区域，包括图标和文字之间的空白。如果设计稿希望涟漪只覆盖图标区域，就需要自定义。做法是给图标单独设置一个rippledrawable作为背景，文字区域不参与点击反馈。

另外，宫格的点击事件不要在每个子View上单独设置，而是在父容器里统一处理。父容器在onTouchEvent里判断落点在哪个格子上，然后回调对应的位置。这样做的好处是点击区域的计算逻辑集中在一处，调整起来方便，也避免了子View抢占触摸事件导致滑动冲突。

4. 数据分层：Mock数据也要有正经的结构

4.1 为什么数据层不能直接写在Adapter里

我见过太多Demo把数据直接硬编码在Adapter或者Activity里，一开始跑得挺欢，等到要加一个"下拉刷新"或者"局部更新"的需求，就发现代码改不动了。原因很简单：数据和UI耦合在一起，任何数据变化都要手动去通知UI，通知的逻辑又散落在各处。

正确的做法是至少分三层：数据源层负责提供数据，仓库层负责聚合和缓存，ViewModel层负责把数据转换成UI需要的状态。哪怕数据是Mock的，这个结构也要搭起来。因为Mock数据迟早要换成真实网络请求，结构搭好了，替换的时候只动数据源层就行。

4.2 用密封类描述页面状态

页面的状态无非几种：加载中、加载成功、加载失败、空数据。用密封类把这几种状态描述清楚，UI层根据状态决定显示什么。

sealed class MineUiState { object Loading : MineUiState() data class Success(val items: List<MineItem>) : MineUiState() data class Error(val message: String) : MineUiState() object Empty : MineUiState() }

这样做的好处是，UI层不需要去判断"数据是不是null""列表是不是空"这些边界情况，状态类已经帮你区分好了。加载中的时候显示骨架屏，成功的时候显示列表，失败的时候显示重试按钮，逻辑清晰，不会出现"数据还没回来但列表已经渲染了"这种时序问题。

4.3 局部刷新与DiffUtil的正确用法

页面里有些数据是独立变化的，比如资产金额会定时刷新，但其他部分不变。如果每次金额变化都调notifyDataSetChanged，整个列表会重新绑定，不仅性能差，还会导致正在进行的动画被打断、滚动位置跳动。

正确的做法是用DiffUtil计算新旧列表的差异，只刷新变化的部分。使用DiffUtil的关键是实现好areItemsTheSame和areContentsTheSame两个方法。前者判断是不是同一个条目（通常比较唯一ID），后者判断内容是否相同。如果条目类型里有嵌套列表，还要注意嵌套列表的内容比较，否则会出现"外层没变但内层变了"导致不刷新的问题。

注意：DiffUtil的比较是在后台线程做的，areItemsTheSame和areContentsTheSame里不要做耗时操作，也不要访问UI。

5. 那些只有真正动手才会遇到的坑

5.1 嵌套横向列表的滑动冲突

页面里如果有横向滚动的运营位，放在纵向RecyclerView里，默认情况下横向滑动是可以正常工作的，因为两个方向的滑动不冲突。但如果你在横向列表的item里又放了可以点击的元素，快速滑动时容易误触发点击。解决办法是在横向列表的触摸事件里判断滑动距离，超过阈值就拦截事件，不传递给子View。

还有一种情况是横向列表嵌套在可以纵向滚动的父容器里，当手指斜着滑动时，两个方向都可能响应。这时候需要根据滑动的初始方向来决定由谁处理。可以在父容器的onInterceptTouchEvent里记录初始的x和y位移，如果x位移大于y位移，就把事件交给横向列表处理，否则父容器自己处理。

5.2 图标资源在不同分辨率下的适配

Demo里用的图标如果是固定尺寸的png，在不同dpi的设备上会出现模糊或者拉伸。正确的做法是使用矢量图（VectorDrawable），或者至少提供多套分辨率的位图。矢量图的优势是任意缩放不失真，而且体积小。但矢量图也有代价：复杂的路径在低端机上渲染会慢，而且不支持某些高级特性。

我的建议是：简单的图标（箭头、加号、勾选）用矢量图，复杂的插画或者带渐变的图标用位图并做好多分辨率适配。另外，图标的颜色如果需要在不同状态下变化（比如选中和未选中），用矢量图的tint属性比准备两套图要方便得多。

5.3 文字大小与系统字体缩放的兼容

用户在系统设置里调整了字体大小后，App里的文字会跟着缩放。如果布局里用的是固定高度，文字放大后可能被截断。解决办法是：文字容器的高度用wrap_content，不要写死；如果必须固定高度，就在文字上设置maxLines和ellipsize，保证超出时显示省略号而不是直接截断。

另外，sp和dp的区别要搞清楚。文字大小用sp，这样会跟随系统字体缩放；其他尺寸用dp，不跟随缩放。如果某个文字你希望它不跟随系统缩放（比如图标上的角标数字），可以用dp来设置文字大小，但这是特殊情况，大部分文字还是应该用sp。

5.4 点击事件的防抖处理

用户快速点击一个入口，可能会连续触发多次跳转，导致打开多个相同的页面。这个问题在真机上特别明显，因为手指的抖动会产生多次点击事件。

解决办法是在点击处理里加一个时间判断，两次点击间隔小于某个阈值（比如500毫秒）就忽略后一次。可以写一个扩展函数统一处理：

fun View.setDebouncedClickListener(interval: Long = 500L, action: (View) -> Unit) { var lastClickTime = 0L setOnClickListener { val now = System.currentTimeMillis() if (now - lastClickTime > interval) { lastClickTime = now action(it) } } }

这个防抖逻辑要加在所有会触发页面跳转或者网络请求的点击上，不然用户手快一点就会出问题。

6. 从Demo到可用：还能往哪些方向打磨

6.1 骨架屏与加载体验

Demo里的加载状态如果只显示一个转圈，体验是比较粗糙的。更好的做法是显示骨架屏：用灰色的占位块模拟真实内容的布局，让用户在等待时就能感知到页面的结构。骨架屏的实现可以用一个和真实布局结构相同的灰色版本，加载完成后切换过去。

骨架屏的动画通常是闪烁效果，用一个从透明到半透明的渐变循环播放。实现方式可以用ValueAnimator配合alpha属性，或者用shimmer效果。注意动画的帧率要控制好，不要用太复杂的绘制导致掉帧。

6.2 数据缓存与离线展示

真实场景下，用户打开页面时可能网络不好，这时候如果直接显示空白或者错误页，体验很差。合理的做法是缓存上一次成功加载的数据，打开页面时先展示缓存，同时发起网络请求，请求成功后再更新。

缓存的存储可以用SharedPreferences存简单的JSON，也可以用Room存结构化数据。如果数据量不大、结构简单，SharedPreferences就够了；如果数据量大、需要查询和排序，Room更合适。缓存要设置过期时间，过期后仍然展示但标记为"可能不是最新"，同时后台刷新。

6.3 无障碍与深色模式

无障碍方面，每个可点击的元素都要有contentDescription，让读屏软件能正确朗读。图标按钮的contentDescription要描述功能而不是图标本身，比如"设置"而不是"齿轮图标"。文字和背景的对比度要符合规范，保证视力不佳的用户也能看清。

深色模式方面，颜色不要写死在布局里，要用主题属性或者资源限定符。深色模式下，卡片的背景色、文字颜色、图标颜色都要有对应的深色版本。测试的时候要把系统切换到深色模式，逐个页面检查有没有颜色不对的地方。

6.4 性能监控与优化方向

页面做出来之后，可以用Layout Inspector检查布局层级，看看有没有不必要的嵌套。用Profiler看渲染时间，找出耗时长的帧。用StrictMode检测主线程的磁盘读写和网络操作。

常见的优化点包括：减少布局层级（用ConstraintLayout替代多层嵌套的LinearLayout）、避免在onBindViewHolder里做耗时操作、图片加载用缓存和采样、减少过度绘制（去掉不必要的背景）。这些优化不需要一次做完，但要有意识地去检查和改进。

7. 一些个人体会

仿写这个页面最大的收获，不是学会了某个API怎么用，而是理解了"结构比技巧重要"这件事。同样一个页面，结构搭得好，后面加需求就是顺水推舟；结构搭得乱，每加一个功能都像在拆炸弹。

另外一点体会是，不要怕在Demo里写"多余"的代码。分层、状态管理、防抖这些在Demo阶段看起来是过度设计，但正是这些"多余"的代码，让你在把Demo变成真实项目的时候，不会推倒重来。Mock数据换成网络请求、本地状态换成数据库，这些替换之所以能平滑进行，靠的就是前期把边界划清楚了。

最后一个建议：动手之前先把页面截图打印出来，用笔在上面画一画区块划分，标一标哪些是列表、哪些是独立模块、哪些需要复用。这个纸上的过程花不了十分钟，但能帮你省下后面几个小时的返工。