企业官网建设流程全解析

最近有朋友在群里问，RecyclerView的LayoutManager到底怎么自定义，说网上教程一看就会、一写就废。我第一反应是让他去看看android-pile-layout这个项目——仿Dribbble卡片堆叠效果的那个开源库，把滑动卡片堆叠这种视觉效果玩明白了，基本就摸清了自定义LayoutManager的套路。

正好我之前为项目需求，把android-pile-layout从源码到原理完整过了一遍，还顺手改了一版配合ViewPager2用的。这篇就借着这个标题，把从效果拆解到LayoutManager重写的完整链路理一遍，想说的是：卡片堆叠看起来花哨，落地到RecyclerView体系里，本质上就是一个“根据滚动偏移量动态调整子View位置和变换”的数学问题。

1. 整体设计与实现思路拆解

1.1 效果到底长什么样

先说清楚目标效果。不是那种类似ViewPager整页切换，也不是那种简单的列表错位，而是卡片在垂直方向上一个压一个，越往下露出的部分越少，顶部那张卡片完全展开、最大、最清晰，后面每张卡片依次缩小、往下错开，滚动的时候手指往上一推，当前顶部的卡片往后退去、让位给下一位，整个视觉像一副牌被从上面一张张抽走。

细节上通常还伴随几个视觉特征：每张卡片有圆角、有阴影；后面的卡片只露出头部一小截（比如30dp左右）；层级越靠后的卡片缩放比例越小，透明度也可能略降；滑动过程中动画要有一定的跟手性，松手后要么回弹到最近的稳定位置，要么直接滑到下一个状态。

android-pile-layout这个名字里的“pile”就是“堆叠、摞起来”的意思，开发者早期在Dribbble上看到类似的概念稿后在Android上落地，核心不靠自定义View，而是靠RecyclerView的自定义LayoutManager来实现。这个选型本身就很有代表性：RecyclerView天然处理了ViewHolder复用、回收、滚动事件分发，LayoutManager只负责“把item摆在哪里”，所以只要把摆放逻辑写清楚，剩余的复用和性能问题框架全都兜住了。

1.2 为什么选择自定义LayoutManager而不是别的方案

其实要实现卡片堆叠，有几种路可以走，我分别试过，说下对比。

第一种：用ScrollView + LinearLayout全量加载。简单是简单，但卡片一多就不行了，所有View常驻内存，每次滑动还要自己监听touchEvent做位移变换，复杂的手势冲突更是要命。

第二种：RecyclerView + ItemAnimator/ItemDecoration做障眼法。ItemDecoration只能在绘制阶段加装饰，比如画背景、加间距，它改变不了item的绘制顺序和层级关系，也拿不到滚动过程中的插值状态来做缩放偏移，基本做不了这种连续联动效果。

第三种：RecyclerView的LayoutManager，也就是android-pile-layout选用的方案。LayoutManager决定了RecyclerView的子View怎么测量、怎么布局、什么时候回收，更重要的是它天然感知RecyclerView的滚动状态，scrollVerticallyBy方法会在每次滚动时回调。这意味着卡片堆叠的位移、缩放、透明度完全可以在LayoutManager的布局阶段计算出来，数据驱动清晰，回收复用交给RecyclerView内部机制，性能和代码结构都最优。

还有个不大不小的问题：RecyclerView的绘制顺序里，后addView的child会绘制在上层，LayoutManager可以自己控制addView的先后顺序，因此“哪张卡片在上、哪张在下”是完全可控的。这一点如果不自己实现LayoutManager，用其他方案想做到层级正确会非常别扭。

1.3 视觉参数与状态机拆解

动手写代码之前，先把效果拆成可量化参数。我做了一个小的状态模型，卡片在任意滚动位置只有三种状态。

初始状态（未滑动）：第0个item在最上面，完全展开；第1、2、3…个item依次向下错开，每张卡片露出固定高度。该固定高度我通常叫它pileHeight或者mPileDistance，控制的是堆叠的紧密程度，一般取30dp到48dp之间，太密了层级感弱，太疏了屏幕放不了几张卡片。

滑动中状态：手指拖动时，顶部卡片随滚动上移，下面的卡片跟随上浮，但是上浮节奏不是线性等距的，而是后面卡片逐渐减速靠近，形成一种“追赶但不超越”的错落感。这里要抽象出一个核心参数：偏移比例，也就是当前卡片位置与其目标稳定位置之间的归一化距离。

稳定状态（松手或fling结束）：每张卡片必须停在“目标槽位”上，槽位间距就是mPileDistance，顶层卡片的槽位在屏幕内的固定区域（一般稍微往上预留一部分空间，避免与状态栏冲突）。

这三个状态本质上不需要搞复杂状态机，因为布局算法本身就是基于连续滚动offset计算的，每个item根据当前位置算出进度值，再映射到位移和缩放。真正的状态控制主要发生在滑动结束后的回弹逻辑里，需要判断当前滚动offset离哪个槽位最近，然后滚动到对应的目标位置。

2. LayoutManager核心原理与重写要点

2.1 从线性布局讲起：重新认识onLayoutChildren

自定义LayoutManager的起点，是明白RecyclerView.LayoutManager这个抽象类给你留了哪些口子。最常见、也最重要的就是onLayoutChildren方法，它负责在RecyclerView需要重新布局子View时被调用，比如数据源变化、首次布局、notifyDataSetChanged。你在这个方法里决定“哪些item可见、每个item摆在什么坐标”。

我把onLayoutChildren理解成一个“快照布局”方法：只关心当前应该展示哪些view，以及它们此刻的静态位置和属性。至于后续滚动，则通过scrollVerticallyBy方法不断微调，再配合requestLayout重新触发布局刷新。

android-pile-layout正是沿着这个思路：onLayoutChildren先把当前offset对应的可见卡片都摆放出来，每张卡片的坐标、缩放、层级都算好；用户手指一滚动，scrollVerticallyBy更新偏移量并请求重布局，onLayoutChildren再次执行，重新摆放新一轮位置。这种写法简单直观，但有个隐患——每次滚动都触发一次全量布局，性能会有损耗。不过实测下来RecyclerView内部有复用机制，加上布局计算不复杂、卡片数量有限，对大多数场景影响不大。

2.2 测量机制：不要让每个item都占满屏幕

刚开始写LayoutManager容易踩一个坑：给每个item设置的LayoutParams高度和实际测量高度混淆。LayoutManager里有一个关键差异，即getMeasuredHeight与getDecoratedMeasuredHeight的区别。前者是View测量后的尺寸，后者额外包含了ItemDecoration的偏移。正确做法是用getDecoratedMeasuredHeight来计算布局位置，用layoutDecoratedWithMargins摆放，避免卡片在装饰边上错位。

由于我们的布局是垂直方向、每行一个item，卡片宽度我固定为RecyclerView宽度减去左右内边距，高度用默认的wrap_content。此时measureChildWithMargins会自动做measure，但需要注意一点：如果希望卡片不占满整个RecyclerView高度（通常我们只希望屏幕顶部显示一张卡，下面露出其余卡片的头部），就不能简单地让每个item把整个高度占满，而是要让item高度自适应内容，再由LayoutManager在垂直方向上按mPileDistance逐张往下摆放。

这里还要留意RecyclerView的缓存机制，在onLayoutChildren里每张卡片的复用位置是变化的，但LayoutManager要保证getViewForPosition返回的view在addView之前先detachAndScrapAttachedViews，否则会出现“同一个view同时挂到两个父容器”的崩溃或者显示错乱。

2.3 滚动边界与手势处理的取舍

RecyclerView的滚动事件由系统框架接管，LayoutManager只负责实现scrollVerticallyBy方法并返回实际消费的位移。这是最微妙的地方：你返回的数值可以比手指滑动的dy小，这样就是“阻尼”效果；如果你完全消费掉了dy，会表现为页面跟手滑动。android-pile-layout的做法是基本全量消费，但要在边界处截断。

滚动边界分上界和下界。上界是顶部卡片已经到达最顶端，不能继续向上推出；下界是最后一张卡片已经到达顶部槽位，不能继续向下拉。这里我用了一个比较关键的计算：

maxScrollOffset = (itemCount - visibleCount) * mPileDistance

其中visibleCount代表屏幕内最多同时展示的卡片数。举个例子，一个RecyclerView高度800dp，mPileDistance取40dp，一屏最多展示的卡片数量大约是20张（考虑缩放后略微少一些，但取固定安全值即可）。如果itemCount有25张，最大可滚动距离就是(25-20)*40dp=200dp。这样保证滚到最后，最后一张卡片正好停在顶部槽位。

手势处理不需要自己接管MotionEvent，RecyclerView已经封装好了。但fling的初速度、回弹动画需要依靠smoothScrollToPosition或者自定义的smoothScroller来完成。如果偷懒，也可以不处理fling，直接让RecyclerView默认的fling生效，但因为我们的滚动不是线性列表的常规滚动，默认fling的targetPosition计算会不准确，容易出现“滚动过头”或者“停不住”的情况。后面第4节我会讲一个比较稳的滑动手感方案。

2.4 LayoutParams复用与ItemAnimator的坑

默认情况下，RecyclerView会为你设置的item布局inflate一个RecyclerView.LayoutParams，但如果你用默认的generateDefaultLayoutParams，返回的是MATCH_PARENT + WRAP_CONTENT，在某些自适应高度场景会出问题。更稳的做法是，在构造LayoutManager时明确生成LayoutParams，并且复写checkLayoutParams与generateLayoutParams，确保传进来的params是自定义类型。

另一个坑是ItemAnimator。RecyclerView默认的DefaultItemAnimator喜欢对child做translation动画来实现add/remove/change效果，但我们的LayoutManager在每次布局时都改动了view的translationY、scaleX、scaleY，动画一旦介入，会出现视觉“闪烁”或变换错乱。做这个效果时，一般建议布局容器设置itemAnimator = null，或者至少关掉change动画。

3. 实操过程与核心环节实现

3.1 定义一个PileLayoutManager骨架

写代码永远是学LayoutManager最直接的方式。下面给出一个简化但可运行的PileLayoutManager核心骨架，使用Kotlin实现。这里略去完整的XML、Adapter等外围代码，聚焦LayoutManager本身。

class PileLayoutManager( private val pileDistance: Int = 30.dp, private val scaleRatio: Float = 0.05f ) : RecyclerView.LayoutManager() { private var scrollOffset = 0 private var itemHeight = 0 private var visibleCount = 4 override fun generateDefaultLayoutParams(): RecyclerView.LayoutParams { return RecyclerView.LayoutParams( ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.WRAP_CONTENT ) } override fun onLayoutChildren(recycler: RecyclerView.Recycler, state: RecyclerView.State) { if (itemCount == 0) return // 先清空所有已挂载的view detachAndScrapAttachedViews(recycler) // 计算可见数量，至少为1 if (itemHeight <= 0 && childCount > 0) { itemHeight = getDecoratedMeasuredHeight(getChildAt(0)) } val totalHeight = height - paddingTop - paddingBottom visibleCount = maxOf(1, totalHeight / pileDistance + 1) visibleCount = minOf(visibleCount, itemCount) // 当前滚动的槽位索引 val topVisibleIndex = (scrollOffset / pileDistance).toInt() val partialOffset = scrollOffset % pileDistance for (i in 0 until visibleCount) { val realIndex = topVisibleIndex + i if (realIndex < 0 || realIndex >= itemCount) continue val child = recycler.getViewForPosition(realIndex) addView(child) measureChildWithMargins(child, 0, 0) val childWidth = getDecoratedMeasuredWidth(child) val childHeight = getDecoratedMeasuredHeight(child) val left = (width - childWidth) / 2 val top = paddingTop + i * pileDistance - partialOffset layoutDecoratedWithMargins( child, left, top, left + childWidth, top + childHeight ) // 计算缩放：越后面的卡片越小 val progress = i.toFloat() / (visibleCount - 1).coerceAtLeast(1) val scale = 1f - progress * scaleRatio child.scaleX = scale child.scaleY = scale child.pivotX = childWidth / 2f child.pivotY = 0f // 可选：透明度随层级递减 child.alpha = 1f - progress * 0.3f } } override fun scrollVerticallyBy( dy: Int, recycler: RecyclerView.Recycler, state: RecyclerView.State ): Int { if (childCount == 0 || itemCount == 0) return 0 val maxOffset = maxScrollOffset() var target = scrollOffset + dy if (target < 0) target = 0 if (target > maxOffset) target = maxOffset val consumed = target - scrollOffset if (consumed == 0) return 0 scrollOffset = target // 方式一：直接整体偏移已有child offsetChildrenVertical(-consumed) // 方式二：重新布局刷新变换，保证新增/回收正确 requestLayout() return consumed } private fun maxScrollOffset(): Int { if (itemCount <= visibleCount) return 0 return (itemCount - visibleCount) * pileDistance } override fun canScrollVertically(): Boolean = true }

这段代码能跑出最基本的卡片堆叠效果，但有几点需要解释。

3.2 参数计算与视觉调优

上面代码里pileDistance决定了卡片错开的距离，我实测建议在24dp到48dp之间。小于24dp的话，底下的卡片露得太少，用户很难意识到下面还有内容；大于48dp，屏幕能放下的卡片数量变少，卡片堆叠的“厚度感”就弱了，卡片之间的遮挡关系也不明显，视觉比较零散。

scaleRatio控制的是堆叠后端卡片的缩小幅度，0.05f表示每往后一张缩小5%。如果visibleCount是5，那么第5张卡片大概是0.75倍大小，对比度够但不会觉得太小。

alpha衰减不是必须的。如果不做透明度变化，堆叠效果已经很有层次；加上透明度衰减会让后面的卡片更像“远景”，但衰减过猛会让人看不清卡片内容。我一般把alpha最小限制在0.6f，衰减系数0.3f比较稳。

另外，缩放的原点pivotX、pivotY非常关键。大多数情况下我们希望卡片从中心缩放，但如果所有卡片都从中心缩放，堆叠时底部露出的部分反而会错位。经过反复试，pivotX设在宽度一半（水平居中缩放），pivotY设为0（从顶部往下缩小）比较符合视觉直觉：顶部卡片是基准，下面的卡片像是在底部被压缩了，整个堆叠有一种纵深往下延伸的感觉。

3.3 滑动回弹与fling处理

基础版LayoutManager虽然能滑动，但有一个问题：手指松开后RecyclerView的fling会让scrollVerticallyBy收到一段惯性位移，滚动的最终位置不一定是mPileDistance的整数倍，卡片会停在半空。要解决这个问题，需要监听滑动状态。RecyclerView提供了addOnScrollListener，里面有SCROLL_STATE_IDLE、SCROLL_STATE_DRAGGING、SCROLL_STATE_SETTLING三种状态。

在SCROLL_STATE_IDLE时，判断当前scrollOffset离哪个槽位最近，然后主动smoothScrollToPosition到合适位置。这里的“合适位置”不是item的position，而是scrollOffset的目标值，但RecyclerView的smoothScrollToPosition只能滚动到position，如果自定义LayoutManager不做处理，滚动位置会由LinearSmoothScroller计算，不一定是我们想要的offset。

更直接的方案是自定义SmoothScroller，或者干脆自己写一个ValueAnimator驱动scrollVerticallyBy。后者会更可控，因为动画插值完全由你决定：

fun settleToNearestPosition() { val targetOffset = (scrollOffset.toFloat() / pileDistance).roundToInt() * pileDistance val target = targetOffset.coerceIn(0, maxScrollOffset()) if (target != scrollOffset) { recyclerView.smoothScrollBy(0, target - scrollOffset) } }

上面这个方法有一个坑，smoothScrollBy传入的是位移增量，但在滚动过程中，scrollOffset一直在变，直接传target - scrollOffset有可能在途中有偏差。稳妥办法是记录一个固定目标值，每次在scrollVerticallyBy中判断当前offset是否到达，如果超出就截断。这里不再展开代码，核心思路就是：把目标偏移量作为成员变量存起来，在scrollVerticallyBy里比较并且截断返回。

3.4 轨道外卡片的回收与复用

回收逻辑是衡量一个LayoutManager是否合格的关键。LayoutManager不需要你手动移除每个不可见child，但要在合适的时机把不可见的view标记为scrap或直接回收。最常用的模式是：

• 布局时先detachAndScrapAttachedViews(recycler)把所有child转为scrap状态。
• 重新规划可见item后，通过recycler.getViewForPosition拿到复用的view。
• 布局结束后，可以再遍历一遍child，把仍在屏幕外的child用removeAndRecycleView移除。

上面骨架里为了简洁，没有做显式越界回收。这在卡片数量不多的时候问题不大，因为每次布局时getViewForPosition会优先复用scrap缓存。但如果卡片数量多，滚动跨越多个槽位，旧的不可见view没有被正确回收，会造成内存中的view数量持续增多（虽然RecyclerView底层有限制，但布局会越来越慢）。

建议加上一个fill逻辑，在onLayoutChildren里循环获取及摆放view，并判断child的bottom是否已经超出RecyclerView底部，若超出则停止并进入回收循环。这一步实际Android官方的一些LayoutManager示例也有类似写法，经典代码模式如下：

var lastBottom = paddingTop var nextIndex = topVisibleIndex while (nextIndex < itemCount && lastBottom < height - paddingBottom) { val child = recycler.getViewForPosition(nextIndex) addView(child) measureChildWithMargins(child, 0, 0) layoutDecoratedWithMargins(child, left, lastBottom, left + childWidth, lastBottom + childHeight) lastBottom += pileDistance nextIndex++ } // 回收超出边界的 for (i in childCount - 1 downTo 0) { val child = getChildAt(i) if (getDecoratedBottom(child) < 0 || getDecoratedTop(child) > height) { removeAndRecycleView(child, recycler) } }

注意，这里用getDecoratedBottom而不是getBottom，因为前者考虑了ItemDecoration，后者只是View的实际坐标，容易在带凹槽/分割线的情况下把还可见的view误回收。

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

4.1 卡片全部挤在屏幕顶部，不堆叠

这是最常被问的问题。原因通常是onLayoutChildren里没有为每个child设置不同的top，或者top的计算公式写错导致每个卡片都被摆到了同一个y坐标。检查方式很简单，在layoutDecoratedWithMargins之前打印每个child的实际position和layout坐标，看top是否按预期递增。另一种可能原因：item本身高度为MATCH_PARENT，每张卡片占满RecyclerView高度，后面的卡片虽然往下摆了但超出屏幕不可见，看起来就像只有一张。

解决办法：item根布局的height用wrap_content，并且内部内容不要设置固定全屏高度。如果实在需要固定高度，比如电话拨号卡片、名片卡片，那就在LayoutManager里计算出统一itemHeight，然后layout时用这个高度去布局，同时累积top递增pileDistance而不是递增itemHeight。

4.2 滚动时卡片闪烁，或者出现“闪现”

这类问题基本都和ItemAnimator有关。RecyclerView默认的ItemAnimator会在child的layout params或者translation属性变化时执行动画，而自定义LayoutManager里为了堆叠效果，每次布局都会修改scale、alpha、translationY，动画和手写变换叠加，视觉上就成了闪烁。

解法有几种：

• 最简单：在RecyclerView上设置itemAnimator = null，生效最直接。
• 如果需要item动画（比如notifyItemRemoved的渐隐），可以保留itemAnimator，但要让自定义LayoutManager实现supportsPredictiveItemAnimations()返回false。这个返回值告诉RecyclerView当前LayoutManager不支持预测性动画，因此change类的动画就不会执行。
• 还有一种隐蔽情况：notifyDataSetChanged后，旧的view在detach时由于RecyclerView的scrap缓存策略，早期状态残留导致闪烁。可以在onLayoutChildren开头调用detachAndScrapAttachedViews时对view做一次“复位”，重置scale与alpha到默认值。

4.3 fling停不准，位置歪在半空

默认RecyclerView的fling速度很大，scrollVerticallyBy一旦接收了大dy，LayoutManager截断只会在到达边界时生效，中间过程不会自动对齐卡片槽。所以松手后的停止位置完全取决于RecyclerView的物理衰减，歪是大概率事件。

最推荐的做法是：监听RecyclerView的OnScrollListener，在SCROLL_STATE_IDLE时判断targetOffset。但如果用户在大惯性下滚动，到IDLE之前SCROLL_STATE_SETTLING阶段可能已经持续很久，此时不要立即打断滚动。我习惯在SCROLL_STATE_IDLE后post一个小延迟（比如50ms），等物理动画彻底稳定后，再smoothScroll到最近槽位，这样体感最自然。

另一种方案是禁用默认fling，自己接管。做法是addOnItemTouchListener拦截ACTION_UP，计算手指滑动速度，然后用自定义Animator驱动scrollVerticallyBy，实现“速度越快滑越多、但最终一定会落到最近的稳定槽位”。这个方案控制力最强，但代码量也上去了，适合对跟手度有极致要求的场景。

4.4 item复用导致卡片变换错乱

布局复用发生在recycler.getViewForPosition返回一个旧view时，它身上还带着上一次位置的scale、alpha、translationX/Y。一旦复用到新位置，没有做复位处理，会出现某张卡片突然很大或者很小，甚至透明到看不见。

解决办法：在getViewForPosition拿到child后、addView之前，统一做一次状态重置：

child.scaleX = 1f child.scaleY = 1f child.alpha = 1f child.translationX = 0f child.translationY = 0f child.pivotX = 0f child.pivotY = 0f

不要小看这几行，漏了就会看到各种“抽搐”卡顿。我在第一次实现时，卡片从底部滑上来直接放大到1倍，再跳变回缩放值，视觉极其廉价。复位后再重新设置变换，才平滑。

4.5 fling后出现空白区域

滚动到末尾时，如果RecyclerView底部已经没有卡片，但手指还能滑，就会露出背景色，显得很空。本质原因是maxScrollOffset的计算偏小了或者偏大了。

我之前犯过一个错：visibleCount取值不准。因为visibleCount是动态计算的，但onLayoutChildren里会因为itemHeight还没测量而暂时低估数量，导致maxScrollOffset偏大，用户能一直拖到卡片全部离开屏幕。后来我在onLayoutChildren里每次先measure第一张卡片并更新itemHeight，再计算visibleCount，并把maxScrollOffset的公式固定为(itemCount - visibleCount) * pileDistance - partialOffsetCompensation，才彻底解决。

还有一个边界坑：RecyclerView内部默认会为smoothScrollbar设置track，但如果canScrollVertically返回true而maxScrollOffset为0（比如itemCount小于等于visibleCount），滚动条会闪现消失，这是正常现象，不需要处理。

4.6 性能优化：卡片阴影与圆角别写太重

堆叠卡片通常带圆角与阴影，如果给每张卡片根布局加上高成本的shadow、elevation或复杂背景，滑动时会反复触发绘制。实测在低端机上，卡片超过6层时掉帧非常明显。

推荐的优化：使用ShapeDrawable画圆角背景，避免用CardView自带elevation；阴影尽量用LayerDrawable或者RecyclerView外面的整体阴影层模拟，而不是每张卡片都开启硬件加速阴影。另外，LayoutManager布局阶段的计算本身都是轻量的整数运算，真正的性能瓶颈在draw和onMeasure里的自定义子View——所以卡片内部不要放那种每次measure都要走复杂计算的重量级自定义View。

5. 扩展玩法：这套思路还能做什么

android-pile-layout这种自定义LayoutManager的魅力在于，掌握核心逻辑后，可以轻松扩展出很多变体。

比如改成横向滑动。只需要把vertical方向的方法换成horizontal，scrollHorizontallyBy对应实现，layoutMovement方向改成横向，即可实现左右滑动的卡片叠放。很多音乐播放器、短视频沉浸页的卡片切换就是类似逻辑。

再比如结合ViewPager2。ViewPager2内部也基于RecyclerView，只要你自定义一个可以“一次展示多页”的LayoutManager，就能在一个ViewPager2里实现多卡片堆叠预览。我实际项目中就是用这个方法做“首页焦点卡片”的，两个层叠卡片，下层是内容摘要，上层是主卡片，滑动时上层的向右上角缩放消失，下层的补位成为新的主卡片。

如果想让视觉更流畅，还可以引入实时插值：scrollVerticallyBy里不直接全部消费dy，而是对上面的卡片使用时序插值函数（比如overshoot或decelerate插值），下面的卡片用线性插值，这样堆叠位移会产生轻微“差速”感，整体更有弹性。android-pile-layout原版并没有做差速，改起来也很容易。

关于“差速”再补充一点：具体做法是不要对每个child都统一使用offsetChildrenVertical(-consumed)，而是先布局时把卡片放在各自理想位置，再根据它们离顶部槽位的距离，分别计算各自的translationY。这样滑起来，前排卡片走得快，后排卡片起步慢，堆叠的纵深感就成了。不过这个方案对回收逻辑要求更高，建议在基础版本跑通后再优化。

6. 写在最后的调试心得

自定义LayoutManager这个东西，看十篇文章不如动手踩一次坑。我第一次实现android-pile-layout类似效果时，光“onLayoutChildren重复调用导致重复添加view”就卡了两个晚上，后来才理解到RecyclerView的执行流程是“先scrap、再布局、再回收”三段式。把这三段背后的意图搞明白，LayoutManager基本就没有秘密了。

实际写的过程中，我强烈建议在onLayoutChildren里养成分段打印的习惯，把每个child的position、top坐标、scale值都打出来。打印几轮之后，布局算法的逻辑会变得非常清晰，问题定位速度翻倍。等效果跑通，再回头删日志，加上注释，这份代码就是团队里别人借鉴自定义LayoutManager的最佳参考。

卡片堆叠的视觉核心是“错落有致”，但工程核心永远是无懈可击的复用和回收。理解了android-pile-layout，你收获的不只是一个炫酷的UI效果，更是对RecyclerView整个渲染管线的深度理解。之后再看LinearLayoutManager、GridLayoutManager的源码，会觉得清晰很多，再遇到各种自定义布局需求，也就不会再觉得无从下手了。