企业官网建设流程全解析

1. 项目概述：先搞清楚这个"悬浮"到底该怎么实现

接了个需求，某App的信息流列表要加一个分类筛选条，要求列表往上滚的时候，这个筛选条滚到顶部之后就被"钉"在屏幕顶端，下面的内容继续从它底下滚过去。这个效果在业界叫"吸顶"或者"Sticky Header"，说白了就是RecyclerView实现顶部悬浮。

可能很多人第一反应是：这不简单吗，给那个View加个addOnScrollListener，监听dy，然后translationY跟着挪不就完事了？真做起来你会发现一堆细节：悬浮条要哪些内容、滚动边界怎么判断、挡住内容的布局错位怎么处理、和下拉刷新怎么共存，每一项都能让你改到怀疑人生。

这篇文章我直接给出一套完整可落地的方案，基于ItemDecoration + RecyclerView.addOnScrollListener实现，读取源码级联动的关键判断逻辑，整篇不左侧滑、不嵌套ScrollView、不动LayoutManager，一份代码通吃LinearLayoutManager和GridLayoutManager。适合正在做信息流、筛选列表、购物分类页的Android开发，尤其是那种列表头需要悬停但是不希望引入重型第三方库的场景。

先说结论，方案就一句话：重写ItemDecoration.onDrawOver()去绘制那个吸顶条，再用滚动监听告诉它"现在该钉在哪、悬停条下面压住的item是谁、要不要切换状态"。听起来是不是有点像自定义View那套？其实核心工作量就在一个类里，我拆开讲。

2. 方案选型：三种悬浮方案，我为什么只推荐ItemDecoration

2.1 先看三种主流实现路径的优劣对比

网上聊RecyclerView吸顶效果，你搜一圈基本绕不开下面三条路：

方案一：ItemDecoration + 滚动监听

思路是每个item的顶部留出一块高度，专门给吸顶条腾位置，滚动到一定条件时把吸顶条画上去。优点是对item自身侵入性很小，不需要改item布局结构，性能也够好，因为onDrawOver本来就是RecyclerView绘制体系里天然的口子。缺点是逻辑判断要自己写，尤其分组列表场景下要把"当前悬停位置属于哪一组"算清楚。

方案二：CoordinatorLayout + AppBarLayout

这是很多人想到的第一套"官方方案"，把吸顶条放进AppBarLayout的app:layout_scrollFlags="scroll|exitUntilCollapsed"里。优点是配合系统自带behavior，折叠动画、标题栏联动都能省很多事。但它有个硬伤：AppBarLayout只能作用于整个RecyclerView的顶部区域，它做的是"整体滚出+折叠"，而不是"所有item滚动时某一个条子钉在屏幕顶端"。如果你要的悬浮条是跟着数据走的（比如列表里有多个分组，滚到哪个分组，吸顶条就显示哪个分组的名字），这套方案就完全不对路了。

方案三：自定义LayoutManager

通过重写LayoutManager.scrollVerticallyBy()，在滚动时手动挪动那些"锚定"的item位置。这套方案最灵活，悬浮item还可以是真View而不只是画出来的，点击交互随便加。但代价是LayoutManager本身就是很底层的API，你要处理测量、布局、回收复用一整条链路，没有把RecyclerView摸透的人建议不要碰。正常业务开发选这个，维护成本会非常痛苦。

我这份方案走的是第一条路，因为它的适用范围最广：普通列表、分组列表、网格列表，都能吃得住，而且实现还是集中在"一个自定义类"的粒度，你扔项目里改改回调就能用。

2.2 ItemDecoration方案的核心洞察：onDraw和onDrawOver的区别

可能有同学要问，为什么偏偏用onDrawOver而不是onDraw？这里有个很多人写RecyclerView自定义装饰都会踩的坑。

RecyclerView的绘制顺序是：item内容先画，然后是ItemDecoration.onDraw()，最后是ItemDecoration.onDrawOver()。也就是说，onDraw画在item的下面，会被item遮盖；onDrawOver画在item的上面，会盖住item。

吸顶条悬浮在列表上方，它必须压住正在滚过它底下的item，所以必须用onDrawOver。你要是用onDraw，画出来的条子直接沉到item后面去了，效果就是"这吸顶条跟shi一样被内容盖住"，这是原理层面的第一课。

另外还有个细节：getItemOffsets()不是给你搞吸顶用的，它的职责是给item腾出外边距空间。但我们会用到它来做"内容顶部占位"。比如列表第一条数据本身是个Header，吸顶条要悬停的话，最开始下面那个item不能被吸顶条挡住，所以要给第一个item单独留出吸顶条的高度作为偏移。很多人忽略这一步，结果做出来的列表"顶上总像是被啃掉了一块"，其实就是这个占位逻辑没写对。

2.3 为什么不推荐引入第三方StickyHeader库

StickyHeader相关的开源库也不少，用起来一行依赖就接入。但你自己接一次就知道，通用库最大的问题是"通用的代价"。它要兼容不同布局结构、不同分组模型、不同点击事件，就会有一大堆配置项和回调，光是理解它内部的"分组状态转移"就要花半天。而很多时候我们要的效果比库的能力简单得多，比如我的需求就一个悬浮条、一个跟手联动，这种场景自己实现30分钟搞定，引个库反而要为它多余的逻辑买单。

而且第三方库普遍都依赖RecyclerView的addOnItemTouchListener那套去拦截点击和悬停判断，这种监听方式在快速滚动时偶尔会有"点击错位"的奇怪问题。我们自己写addOnScrollListener的话，悬停状态跟着滚动手势实时走，行为干净很多。

3. 上手实操：先搭建悬浮条的"绘制底座"

接下来我直接进入代码，每一步说清楚"我为什么这么写"。整个方案的模块划分是这样：

• 自定义StickyHeaderDecoration extends RecyclerView.ItemDecoration
• 内部维护一个StickyHeaderAdapter接口，让我们的列表Adapter实现getHeaderData()去返回当前分组信息
• 用addOnScrollListener驱动状态刷新

先用一个最小Demo把架子搭起来，后面再扩展成多分组版本。

3.1 定义吸顶条数据接口

interface StickyHeaderAdapter { /** * 返回当前position所在分组的header数据 * 如果这个位置不需要吸顶条，返回null */ fun getHeaderData(position: Int): StickyHeaderData? } class StickyHeaderData( val title: String, val iconRes: Int = 0 )

这里有个设计细节：getHeaderData(position)不是返回"这个item是不是分组头"，而是返回"这个position的item所属的分组头"。因为吸顶条一直显示的是当前滚到顶部的那个item所属分组的信息，可能这个item本身并不是分组头，只是它所属的分组头在它上方的某处。这个抽象一旦想清楚，后面所有判断都好写。

3.2 自定义Decoration核心实现

class StickyHeaderDecoration( private val adapter: StickyHeaderAdapter ) : RecyclerView.ItemDecoration() { private val headerRect = Rect() private val tmpRect = Rect() override fun getItemOffsets( outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State ) { super.getItemOffsets(outRect, view, parent, state) val position = parent.getChildAdapterPosition(view) if (position == 0) { val headerData = adapter.getHeaderData(position) if (headerData != null) { // 第一条数据所在的分组需要占位，防止顶部的东西被吸顶条盖住 outRect.top = headerHeight } } } override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { super.onDrawOver(c, parent, state) val layoutManager = parent.layoutManager ?: return // 找到当前可见的第一个item val firstVisiblePosition = layoutManager.findFirstVisibleItemPosition() if (firstVisiblePosition == RecyclerView.NO_POSITION) return val headerData = adapter.getHeaderData(firstVisiblePosition) ?: return // 绘制吸顶条 drawStickyHeader(c, parent, headerData) } private fun drawStickyHeader(c: Canvas, parent: RecyclerView, data: StickyHeaderData) { // 这里预留接口，具体绘制逻辑由子类或回调决定 // 一般做法是inflate一个View，测量布局后draw(c) // 也可以直接用Canvas drawText、drawRect，看你的悬浮条复杂程度 } }

这里我先留了个drawStickyHeader的空壳，等一下完整实现里我会专门说"吸顶条本身怎么画"两个流派：Canvas直绘 vs 真View绘制。先把骨架代码跑通，再纠结绘制细节。

3.3 为什么第一条item要做额外占位偏移

getItemOffsets里我只给position == 0且该位置有headerData时加了顶部偏移，这个其实要展开讲：

当RecyclerView还没滚动时，整个列表从顶部开始，吸顶条悬在屏幕顶端，此时列表的第一条内容不应该被吸顶条压住，因为吸顶条只是"悬浮"而"内容本身还在正常位置"。但是如果第一条item和吸顶条显示的是同一个分组的头，那么视觉上会出现"分组头在地面，吸顶条也在顶部"这种重叠，看着特别乱。

解决办法是给第一个item的顶部留出headerHeight的偏移，让第一条内容整体往下挪出一个吸顶条的高度。等用户开始滚动，吸顶条下的item切换成第二条、第三条时，这个偏移就不需要了，但是因为只有position 0才做这个偏移，后面所有item都正常。

提示：这里有个很常见的隐蔽坑。如果你给所有item都加了outRect.top = headerHeight，那整个列表看起来就像被什么东西顶下去了一截，滚动的时候下面也会出现大段空白。占位偏移只加在第一个位置，其他位置别动。

4. 核心细节：滚动监听与吸顶条的"贴顶压底"逻辑

上面只是画了静态的吸顶条，真正难的是滚动过程中的三种状态切换，这也是网上很多实现写不好的地方。

我把状态归纳成三种：

• 状态A：吸顶条不动，位于RecyclerView顶部
• 状态B：吸顶条被下一个分组的头"顶上去"
• 状态C：吸顶条跟随一个分组滚动到顶后，停住不动

关键就在于状态B，处理它的时候很多人直接写崩。正确的做法是：除了要绘制吸顶条，还要找到"下一个分组头"的View，判断它距离屏幕顶部多近，距离小于吸顶条高度时，让吸顶条跟着往上推。

4.1 找到下一个分组头并计算推移距离

override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { super.onDrawOver(c, parent, state) val layoutManager = parent.layoutManager ?: return val firstVisiblePosition = layoutManager.findFirstVisibleItemPosition() if (firstVisiblePosition == RecyclerView.NO_POSITION) return val currentHeader = adapter.getHeaderData(firstVisiblePosition) ?: return // 找下一个和当前分组不同的位置 val nextHeaderPosition = findNextHeaderPosition(firstVisiblePosition) val nextHeader = if (nextHeaderPosition != RecyclerView.NO_POSITION) { adapter.getHeaderData(nextHeaderPosition) } else null if (nextHeader != null) { // 拿到下一个分组头对应的View val nextHeaderView = layoutManager.findViewByPosition(nextHeaderPosition) if (nextHeaderView != null) { val top = nextHeaderView.top if (top < headerHeight) { // 下一个分组头快顶到吸顶条了，吸顶条开始往上让位 // 同时这里还要处理"被遮挡的item"透明度变化 } } } }

这里有一个普通实现不太会考虑到的细节：当第一个可见分组和下一个分组的头之间，可能隔着一个或者多个item。比如当前第一个可见item是第5条，它属于分组A，而分组B的第一个item在第9条。分组B的头部View可能已经滚到屏幕里了，也可能还在屏幕外。

判断"下一个分组头是否顶到吸顶条"，得靠findViewByPosition(nextHeaderPosition)返回View的状态来区分：如果返回null，说明下一个分组头还没进到屏幕可见范围，吸顶条保持静止；如果View存在，就用view.top去和吸顶条的高度做比较。注意这里比较的不是view.top == 0，因为吸顶条是有高度的，分组头必须等滚到"触碰到吸顶条下边缘"才开始推它走。

4.2 滑动监听的四个判断条件

单纯在onDrawOver里做逻辑有一个问题：onDrawOver是随着RecyclerView的绘制被调用的，如果RecyclerView没有触发重绘，吸顶条的状态就不会更新。所以必须要配合addOnScrollListener来强制刷新。

parent.addOnScrollListener(object : RecyclerView.OnScrollListener() { override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) { // 状态A → B → C的切换判定 val firstVisible = layoutManager.findFirstVisibleItemPosition() val headerData = adapter.getHeaderData(firstVisible) // 更新内部缓存数据后invalidate recyclerView.invalidate() } override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { // 快速滑动停下来后，吸顶条要立刻回到正确状态 // 这里仍然需要 invalidate recyclerView.invalidate() } })

很多人写滚动监听只写onScrolled，忘了onScrollStateChanged，快速划到底再松手，吸顶条经常卡在错误的位置。原因就是惯性滚动过程中onDrawOver被频繁调用，但DataSet变化和布局状态没有及时对齐。在onScrollStateChanged里无论如何补一次invalidate，基本就能解决99%的"状态残留"问题。

4.3 完整实现吸顶条绘制（Canvas直绘流派）

如果悬浮条只是"色块 + 一行文字 + 角标"，我建议直接Canvas画，不inflate布局，性能更好，代码也干净。下面是一个示例：

class StickyHeaderDecoration( private val adapter: StickyHeaderAdapter, private val headerHeight: Int, private val headerBgColor: Int, private val titleColor: Int ) : RecyclerView.ItemDecoration() { private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { textSize = 14.sp() } override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { super.onDrawOver(c, parent, state) val layoutManager = parent.layoutManager ?: return val firstVisiblePosition = layoutManager.findFirstVisibleItemPosition() if (firstVisiblePosition == RecyclerView.NO_POSITION) return val headerData = adapter.getHeaderData(firstVisiblePosition) ?: return // 吸顶条默认在屏幕顶部 var headerTop = 0 // 寻找下一个分组头并计算推挤距离 val nextHeaderPosition = findNextHeaderPosition(firstVisiblePosition) if (nextHeaderPosition != RecyclerView.NO_POSITION) { val view = layoutManager.findViewByPosition(nextHeaderPosition) if (view != null && view.top < headerHeight) { headerTop = view.top - headerHeight } } // 绘制吸顶条背景 val headerBottom = headerTop + headerHeight c.drawRect(0f, headerTop.toFloat(), parent.width.toFloat(), headerBottom.toFloat(), paint.apply { color = headerBgColor }) // 绘制标题文字 paint.color = titleColor val baseline = headerTop + (headerHeight - paint.textSize) / 2 - paint.fontMetrics.top c.drawText(headerData.title, 16f, baseline, paint) } private fun findNextHeaderPosition(startPosition: Int): Int { for (i in startPosition + 1 until startPosition + 100) { val data = adapter.getHeaderData(i) ?: continue // 当前startPosition的headerData和i的headerData如果不同，说明i是新分组的头 val current = adapter.getHeaderData(startPosition) if (data.title != current?.title) { return i } } return RecyclerView.NO_POSITION } }

这个写法有个小瑕疵：findNextHeaderPosition里用"标题不同"判断分组是否切换，如果你的分组有多个字段（比如ID+标题+副标题），建议比较一个唯一ID，不然标题一样就当同一组，那就错得离谱了。我的实际建议是给StickyHeaderData加一个groupKey: String字段，用它做比较，不要用title。

4.4 真View绘制流派：什么时候值得用

如果你的吸顶条需要包含图片、多按钮、复杂布局，Canvas流就很难受了，这时候用真View来画。核心思路：在Decoration里面定义一个View headerView，每次onDrawOver时对它做measure和layout，然后draw(c)。

private var headerView: View? = null private fun getHeaderView(parent: RecyclerView, data: StickyHeaderData): View { if (headerView == null) { headerView = LayoutInflater.from(parent.context) .inflate(R.layout.item_sticky_header, parent, false) } headerView!!.findViewById<TextView>(R.id.tvTitle).text = data.title return headerView!! } override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { val view = getHeaderView(parent, headerData) val widthSpec = View.MeasureSpec.makeMeasureSpec(parent.width, View.MeasureSpec.EXACTLY) val heightSpec = View.MeasureSpec.makeMeasureSpec(headerHeight, View.MeasureSpec.EXACTLY) view.measure(widthSpec, heightSpec) view.layout(0, headerTop, parent.width, headerTop + headerHeight) c.save() c.clipRect(0, headerTop, parent.width, headerTop + headerHeight) view.draw(c) c.restore() }

注意这里不能用View.GONE或者动态add/remove这种常规View操作，因为Decoration里没有ViewGroup容器，它只能负责draw。这个View相当于一个"离屏渲染"的模板，每次draw到Canvas上，所以你需要保证它的宽高测量正确，不要在它上面做太频繁的动画。

这种真View流派最适合的场景就是吸顶条上带图片加载（比如Glide加载头像）、带可点击按钮的复杂交互。但是要注意：你真View绘制后，Canvas上点击事件是点不到这个View的，因为RecyclerView的事件分发不会自动把触摸传给Decoration里的View，你得手动拦截或者到外面套一层TouchDelegate。这也是为什么很多库不搞复杂吸顶条交互的原因。交互逻辑尽量放在列表item内部或者吸顶条之外的区域，这是这套方案的实际边界。

5. 多分组滚动联动：吸顶状态和item替换的完整实战

上面的Demo只展示了"单组列表只有一个吸顶条"的骨架，但实际业务几乎都是多分组列表。这里我给一个完整的、可以直接抄的多分组场景实现，里面包含了最关键的状态判断。

5.1 分组Adapter的关键实现

class GroupListAdapter( private val items: List<ItemData> ) : RecyclerView.Adapter<GroupListAdapter.VH>(), StickyHeaderAdapter { override fun getHeaderData(position: Int): StickyHeaderData? { return items[position].groupInfo } // ... 常规Adapter方法 } data class ItemData( val title: String, val groupInfo: StickyHeaderData )

这里想强调一点：getHeaderData返回的是每个position对应的分组信息，而不是"这个position是组头"。也就是说，你不需要在数据里给每个分组单独加一条header item，而是让列表里的每个普通item都带一个groupKey字段，然后getHeaderData(position)直接返回这个item所属的分组。这样Adapter的position数和数据条数严格一一对应，完全不需要额外的"header type item"。

好处是显而易见的：代码里不存在"Header View"和"Content View"两种viewType的切换，也就不存在漏改viewType导致崩溃的问题，也不会出现实时数据更新时分页拼接错乱的问题。这个设计是"视图层吸顶"和"数据层分组"完全解耦的，最优雅。

5.2 组合后的完整工具类

class StickyHeaderDecoration( private val adapter: StickyHeaderAdapter, private val headerHeight: Int, private val inflater: LayoutInflater? = null ) : RecyclerView.ItemDecoration() { private val tmpRect = Rect() override fun getItemOffsets( outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State ) { val position = parent.getChildAdapterPosition(view) if (position == 0) { val headerData = adapter.getHeaderData(0) if (headerData != null) { outRect.top = headerHeight } } } override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { super.onDrawOver(c, parent, state) val layoutManager = parent.layoutManager ?: return val firstVisiblePosition = layoutManager.findFirstVisibleItemPosition() if (firstVisiblePosition == RecyclerView.NO_POSITION) return val headerData = adapter.getHeaderData(firstVisiblePosition) ?: return var top = 0 var nextHeaderView: View? = null val nextHeaderPosition = findNextHeaderPosition(firstVisiblePosition) if (nextHeaderPosition != RecyclerView.NO_POSITION) { nextHeaderView = layoutManager.findViewByPosition(nextHeaderPosition) } if (nextHeaderView != null && nextHeaderView.top < headerHeight) { top = nextHeaderView.top - headerHeight } // 吸顶条相关Rect，供外部使用 tmpRect.set(0, top, parent.width, top + headerHeight) // 回调出去，让使用者自己绘制或做其他逻辑 onDrawStickyHeader(c, parent, headerData, tmpRect) } private fun findNextHeaderPosition(startPosition: Int): Int { val currentKey = adapter.getHeaderData(startPosition)?.groupKey ?: return RecyclerView.NO_POSITION for (i in startPosition + 1 until startPosition + Int.MAX_VALUE) { val data = adapter.getHeaderData(i) ?: continue if (data.groupKey != currentKey) { return i } } return RecyclerView.NO_POSITION } // 子类或者外部set回调 var onDrawStickyHeader: ((Canvas, RecyclerView, StickyHeaderData?, Rect) -> Unit)? = null }

这段代码的关键价值在findNextHeaderPosition：它只需要知道当前第一个可见item的分组key，然后一直往后面找，直到遇到第一个和当前分组key不同的item。这个位置的item一旦被滚动到顶部附近，就意味着新分组要来了，吸顶条就要"让位"了。

这个"从当前位置往后找分组边界"的实现，在数据量几千上万条时也别担心性能问题，因为正常情况下分组切换往往是几十条以内就出结果，而且它只在绘制时执行，每次绘制一帧就跑一次，几乎可以忽略。

5.3 GridLayoutManager和LinearLayoutManager的兼容

ItemDecoration方案天然兼容GridLayoutManager。不需要为Grid场景写额外逻辑，因为findFirstVisibleItemPosition()对两种LayoutManager都成立，findViewByPosition()也一样。唯一要注意的是Grid下如果跨行合并单元格的情况比较特殊，吸顶条的宽度依然以RecyclerView宽度为准，不会跟着item的span走。

如果是StaggeredGridLayoutManager瀑布流场景，findFirstVisibleItemPosition()返回的不一定是视觉上最靠上的item，因为瀑布流有两列，可能左列第3条比右列第1条还高。这时候吸顶条逻辑会不稳定，需要换思路：遍历所有可见position，找到top最小的那个作为"第一个可见item"。这块比较进阶，一般项目也用不太到，我这里就不展开了，有需要的同学可以自己扩展。

提示：如果你的列表是横向滚动、纵向悬浮，那完全是另一个维度的需求了。上面这套是"纵向滚动+顶部悬浮"，方向别搞混。

6. 踩坑总结：悬浮条做完了，真正让人头大的从来不是绘制

6.1 上半部分被遮挡：setPadding和setClipToPadding的坑

这个坑是公约级问题。很多人在布局里为了配合吸顶条，给RecyclerView加一个android:paddingTop="?attr/statusBarSize"或者为了边缘效果加clipToPadding="false"。一旦有padding，findFirstVisibleItemPosition()返回的位置和视觉上的顶部就错位了：吸顶条以为下面第一个可见item是position 5，但实际上因为padding，position 4还露着一截。结果就是吸顶条状态切换时机总是不对，忽闪忽闪的。

我的建议是：整个吸顶方案的RecyclerView不要加paddingTop，优先保证findFirstVisibleItemPosition()的语义是"占据视觉最顶部的item"。要处理状态栏高度，在Activity/Fragment外面套一层占位View，然后RecyclerView自身保持干净的顶部；要处理边缘渐变效果，尽量用clipToPadding="false"但别加padding，或者在外部包一层FrameLayout处理渐变遮罩。

6.2 快速滚动时吸顶条闪烁或错位

你会遇到这种情况：手指快速往下甩，列表飞速往上滚动，吸顶条显示的分组切换和item内容显示不同步，甚至偶尔会闪一下旧分组的内容。这其实是RecyclerView的回收复用机制在作祟：你推测的"下一个分组头View"可能已经被回收了，findViewByPosition返回null，于是走到了"吸顶条静止"的那个分支。

处理办法是状态缓存。我建议在addOnScrollListener.onScrolled()里实时更新"当前吸顶条显示的分组key"，缓存成成员变量，然后在onDrawOver里优先使用这个缓存。因为滚动监听里的位置信息比绘制时更及时，用监听里的数据做"决策"，再用invalidate让绘制去"执行"，这种数据驱动的方式比在onDrawOver里临时从LayoutManager取值要稳定很多。

6.3 吸顶条高度和item顶部间距的抖动问题

如果你的列表item本身带了marginTop或Decoration给item之间加了间距，吸顶条压住下面那条item时，会看到间距变化，视觉上就是"跳一下"。本质原因：吸顶条的底部和下一个item的顶部之间没有建立"视觉粘连"的关系。

解决思路有两条：一是吸顶条高度做成和分组头item的高度完全一致，这样贴合感最好；二是如果悬浮条只是分类标签，不需要和分组头一样高，那就接受"悬浮条下面露出间距"的事实，这是正常的，不要试图通过给每个item设置负margin去强行贴合，那会把布局搞乱。

6.4 下拉刷新和吸顶条共存的一个坑

现在主流的下拉刷新组件（比如各种SwipeRefreshLayout、SmartRefreshLayout）一般都在RecyclerView外包一层。吸顶条是画在RecyclerView的onDrawOver里，所以它不会挡住下拉刷新的触发区域。但有个情况要注意：如果下拉刷新布局里自带了"淘宝二楼"、吸顶占位这种效果，它内部可能已经自己对RecyclerView做了translationY平移。一旦有外部移动了RecyclerView的坐标，onDrawOver里绘制的吸顶条还在原点位置，就会和列表"脱离"。

这个问题的处理很简单：吸顶条的Top计算不能写死为0，要动态读取RecyclerView在父容器中的位置作为原点：

val location = IntArray(2) parent.getLocationOnScreen(location) val viewTopOnScreen = location[1]

然后吸顶条的y坐标等于viewTopOnScreen相关的偏移。我自己踩过一次这个坑，所以写在这儿提醒你们：如果你的页面有外部容器对RecyclerView做y轴位移，吸顶条绘制原点一定要动态取，不能用0。

6.5 常用问题速查表

6.6 关于"隐藏/吸附"一个容易被忽略的交互细节

需求方可能会说"吸顶条要平滑地滑下来、滑上去"。这个平滑的效果，很多人会去搞动画插值器、贝塞尔曲线，其实没必要。加了滚动监听之后做差值计算就行：

val offset = (view.top - headerHeight).coerceIn(-headerHeight, 0) val alpha = 1f - abs(offset) / headerHeight.toFloat()

用线性关系让吸顶条随滚动手势渐变透明度，视觉上就是"被顶下去"的效果，不需要额外动画。而且这样不会和RecyclerView的滚动产生脱节——因为它在每一帧都由onDrawOver驱动，天然跟随手势。

7. 踩坑之外的延伸：把吸顶条做成点击可交互的正确姿势

前面提到Canvas绘制的吸顶条点击不到，很多需求里其实是要点击吸顶条的（比如点击悬浮的分类标签直接跳转）。这里我给出两个亲测稳定的方案。

方案一：LayoutManager外挂View

RecyclerView外面套一个FrameLayout，在FrameLayout里面、RecyclerView的上面放一个真正可点击的吸顶条View。滚动的时候，根据吸顶状态去动态控制这个View的显示和内容。这样点击事件天然支持，但需要维护两个数据来源：一个是Decoration里绘制的"视觉吸顶条"（用于滚动态），一个是外挂View（用于点击态）。

我这个建议是：当吸顶条需要点击时，放弃Decoration"绘制"路线，直接用外挂View方案，但外挂View的移动逻辑仍然沿用onDrawOver的坐标计算。也就是说，我把"绘制吸顶条"这步换成"更新外挂View的坐标"，其他判断逻辑完全复用，一举两得。

// 伪代码：在onScrolled中更新外挂View的位置 fun onScrolled(recyclerView: RecyclerView) { val firstVisible = layoutManager.findFirstVisibleItemPosition() val headerData = adapter.getHeaderData(firstVisible) ?: return val top = calculateHeaderTop(firstVisible) externalHeaderView.translationY = top.toFloat() externalHeaderView.tvTitle.text = headerData.title }

方案二：通过ItemDecoration里的TrueView配合点击事件转发

这个方案稍微hack一点，就是让那个离屏View真正布局到一个隐藏的FrameLayout里，然后监听整个RecyclerView的touch事件手工命中测试。不推荐，太绕。

我这里明确建议：复杂的吸顶交互就直接上外挂View方案。成本只多了一个xml布局和一个外部容器，换来的是点击事件、动画、状态切换全部自由，不需要自己实现触摸命中测试。代码量也多不了多少。

8. 最后再分享一点关于吸顶效果的实现心得

这个需求做完之后我复盘了一下，觉得整件事真正的难点根本不在于"把条子画到顶部"，而是在于你要能清晰定义出"当前处于哪个分组"这个状态。很多代码写混乱，都是因为状态定义不清晰：到底什么时候吸顶条属于上一个分组的头？什么时候应该属于下一个分组？什么时候应该处于过渡期？想清楚这三个问题，代码就是顺理成章的事。

我个人的经验是：在设计阶段先把groupKey抽象到位，数据层无论如何分组，UI层只依赖一个纯函数getHeaderData(position)拿到当前分组信息。这样不管是下拉刷新、分页加载还是局部更新，吸顶条状态都会跟着数据集的变化自然刷新，不需要你做额外同步。

另外，建议你在开发时把吸顶条的顶部位置、下一个分组头的View位置，先打印出来或者用日志工具可视化确认一遍，再去写绘制细节。我看到太多人一上来就闷头写Canvas绘制代码，结果半天都在调"为什么画出来偏了、为什么闪了"，其实稍微加几个日志就能秒破案。

最后，如果你用的是Compose，这套经验也能迁移过去，核心思想完全一致：先定义groupKey，然后在LazyColumn的item组合里通过Modifier和滚动状态计算悬停位置，本质还是"数据分组驱动、状态绘制分离"那一套。

这个悬浮条方案从画第一条线到最终稳定上线，我没用任何第三方库，所有逻辑都集中在一个文件里，后续维护的同学也都说好改。希望这篇文章能帮你在遇到同样需求的时候少走几步弯路。