先把结论放在前面：View 的滑动只有三条路——改 translationX/Y（重绘）、改 scrollX/scrollY（重绘）、改 left/top 也就是 LayoutParams（重排）。 前两条不改布局，走重绘；后一条触发 requestLayout，进入测量布局流程。这个分类是这题的骨架，后面所有的性能结论、动画选型、坑位都从这里推出来。
这题的特点是"人人都写过，但说不清代价"。面试里常见的两种丢分：一种是只答 scrollTo/scrollBy，被问"那和 translationX 有什么区别"就卡住；另一种是把 scrollTo 当成动画来用，结果手指一停内容就跳回去——因为 scrollTo 是瞬时赋值，不产生插值。
三条路各自的机制与代价
第一条：translationX/translationY。 它是 Matrix 变换的一部分，View 绘制时通过 canvas.translate(-mScrollX + mTranslationX, ...) 参与坐标计算，它不影响 getLeft/getTop/getRight/getBottom 返回的布局位置。因此改它不触发布局，只触发重绘（invalidate）。这条路的代价有两个：一是父容器的触摸分发与边界裁剪仍按布局位置判断（比如 ViewPager、ScrollView 的可滚动范围按布局宽高算，translation 超出会被裁掉或点到空白）；二是动画结束后 translation 不会被"消费"，它会一直停在那儿，后续逻辑读 getLeft() 会拿到和视觉位置不一致的坐标。
第二条：scrollX/scrollY。 它直接参与 getHitRect、裁剪与滚动容器的范围计算，同时影响事件命中与内容偏移。代价是：改它同样只重绘，但它会被父容器的裁剪规则约束（出界的部分不绘制），且和 ScrollView/RecyclerView 父容器同时改 scroll 时会互相覆盖。
第三条：改 left/top（即 LayoutParams）。 这是真正改变布局位置，每帧都改会触发完整的 measure → layout → draw 流程，父容器还要重新计算所有子 View 的位置，代价是数量级的差别。它在两种场景是必须的：子 View 的兄弟顺序需要跟随变化（比如交换位置）、需要在布局阶段就被后续兄弟感知到（比如 LinearLayout 中的 layout_weight 分配、以及需要撑开父容器的场景）。
判断该走哪条路，一句话：视觉位移走 translation，滚动偏移走 scroll，影响兄弟排布才动 LayoutParams。
最常见的坑是
第一层坑：scrollBy 的方向与手指方向相反。
scrollBy(dx, dy) 的语义是"内容往哪个方向移动"，而不是"手指往哪个方向划"。手指向左划（dx 为负）想让内容向左走，需要 scrollBy(+distance, 0)。这个符号关系在 Scroller 的自定义实现里更隐蔽——Scroller.startScroll 的 dx/dy 同样是对内容的位移量，很多人在 computeScroll 里传反了，表现为"反向加速"或"回弹到起点"。
第二层坑：用 ValueAnimator 每帧改 LayoutParams。
// 错误示范：每帧触发 requestLayout
ValueAnimator.ofFloat(0f, target).apply {
duration = 300
addUpdateListener {
anim ->
val lp = view.layoutParams as? LinearLayout.LayoutParams
lp?.marginStart = (anim.animatedValue as Float).toInt()
lp?.let {
view.layoutParams = it } // 每帧 measure + layout
}
start()
}
这段代码在小规模页面上"看不出问题"，放进 RecyclerView 的 item 或长列表里就会掉帧。setLayoutParams 会 requestLayout()，沿着 View 树向上冒泡，父容器要重新测量所有子 View（包括 0 尺寸的）。规范的替代方案有三种：改 translationX（首选）；改 MarginLayoutParams 但把动画挪到动画结束后的 layout 阶段（post 一次，而不是每帧）；或者让 View 自己预留空间、在 onDraw 里做偏移。
第三层坑：把 scrollTo 当动画用，导致松手回跳。
scrollTo 是"瞬间设置"，没有任何插值。把它写在 onTouchEvent 的 MOVE 里，手指一停赋值就停；一旦抬手或者事件被父容器以 CANCEL 结束，scroll 就永久停在最后那个不完整的位置。要跟手就必须有插值来源——Scroller/OverScroller 提供距离插值，ValueAnimator 提供时间插值，两者选其一。
还有一个更隐蔽的坑：translation 残留导致后续逻辑全错。 动画用 translationX 做完，没有在 onAnimationEnd 里 translationX = 0f 并把值写回 left/top。于是这个 View 视觉上在 A 位置，布局上还在 B 位置。后果是：点击区域按布局位置判定（视觉上点空处）、getHitRect 判错、后续 RecyclerView item 动画起点错位。规范是"动画结束即归位"——把最终值写回布局属性，然后把 translation 清零。
代码里见真章
先看一个完整的跟手拖拽 + 松手吸附实现，它把三条路的边界都演示了：
class DragLayout @JvmOverloads constructor(
context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr) {
private val touchSlop = ViewConfiguration.get(context).scaledTouchSlop
private var downX = 0f
private var downY = 0f
private var dragging = false
// 吸附目标：0 或 maxOffset
private var maxOffset = 0
private val animator = ValueAnimator()
override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {
// 把"实际偏移"写进布局，避免 translation 残留
val lp = layoutParams as? LayoutParams
val target = if (lp != null) lp.leftMargin else 0
for (i in 0 until childCount) {
val child = getChildAt(i)
val childLp = child.layoutParams as LayoutParams
val left = if (i == 0) target else 0
child.layout(
left, 0,
left + child.measuredWidth,
child.measuredHeight
)
// childLp 变量保留引用，便于扩展按类型排布
if (childLp !== child.layoutParams) child.layoutParams = childLp
}
}
override fun onTouchEvent(event: MotionEvent): Boolean {
when (event.actionMasked) {
MotionEvent.ACTION_DOWN -> {
downX = event.x; downY = event.y
dragging = false
animator.cancel() // 打断进行中的吸附动画
return true
}
MotionEvent.ACTION_MOVE -> {
val dx = event.x - downX
if (!dragging && kotlin.math.abs(dx) > touchSlop) dragging = true
if (dragging) {
// 跟手走 translation：不触发布局，且松手后统一归位
child.translationX = dx
}
return true
}
MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL -> {
if (!dragging) {
performClick(); return true }
val dx = event.x - downX
settleTo(if (dx > maxOffset / 2f) maxOffset else 0)
return true
}
}
return super.onTouchEvent(event)
}
private fun settleTo(target: Int) {
val start = child.translationX
animator.cancel()
animator.duration = 260
ValueAnimator.ofFloat(start, target.toFloat()).apply {
addUpdateListener {
anim ->
child.translationX = anim.animatedValue as Float
}
addListener(object : AnimatorListenerAdapter() {
override fun onAnimationEnd(animation: Animator) {
// 关键：动画结束把值写回布局，再清 translation
val lp = child.layoutParams as LayoutParams
lp.leftMargin = target
child.layoutParams = lp
child.translationX = 0f
}
})
start()
}
}
override fun performClick(): Boolean {
super.performClick()
return true
}
}
这段代码值得盯三处：第一处，ACTION_DOWN 里 animator.cancel()，避免"动画还没停就又开始拖"的抖动；第二处，MOVE 用 translationX = dx 而不是反复改 leftMargin，全程不触发布局；第三处，onAnimationEnd 里把最终值写回 leftMargin 再清零 translationX，从根本上杜绝了 translation 残留。
再看 OverScroller 的 fling 版本，适用于"只关心惯性"的场景：
// 惯性滚动：Scroller 负责时间插值，computeScroll 里逐帧消费
private val scroller = OverScroller(context, FastOutSlowInInterpolator())
fun flingFrom(dx: Int) {
scroller.fling(
child.scrollX, 0, // 当前起点
dx, 0, // 初始速度
0, maxOffset, // 边界
0, 0 // 结束时位置占位
)
postInvalidateOnAnimation() // 关键：安排下一帧
}
override fun computeScroll() {
if (scroller.computeScrollOffset()) {
// computeScrollOffset 每次返回 true 表示还有下一帧
child.scrollX = scroller.currX // 符号语义：对内容的位移量
postInvalidateOnAnimation()
} else {
// 滚动结束，归位到精确边界，避免停在半像素
child.scrollX = maxOffset
}
}
这段代码值得盯两处：第一处，postInvalidateOnAnimation() 而不是 invalidate()——前者按帧对齐到 vsync，且按需合并，后者可能在同一帧内被多次触发或错过渲染时机；第二处，computeScrollOffset() 返回 false 时把 scrollX 收束到精确边界，避免像素取整导致的"停在对齐不准的中间位"。
关于 ScrollView 内部的滑动，需要理解 overScrollBy 的契约：它是 ScrollView 留给子类扩展的唯一入口，父类已经算好了 scroll 变化量，子类只需在 overScrollBy 结束时同步 scrollTo(scrollX, scrollY) 并返回 true，不要自己再 scrollTo 一次——重复设置会让 View 的 mScrollX 与实际绘制位置短暂不一致。
class ElasticScrollView : ScrollView(context) {
override fun overScrollBy(
dx: Int, dy: Int,
scrollX: Int, scrollY: Int,
scrollRangeX: Int, scrollRangeY: Int,
maxOverScrollX: Int, maxOverScrollY: Int
): Boolean {
val consumedY = dy.coerceIn(-maxOverScrollY, maxOverScrollY)
// 父类已把 scrollX/scrollY 参数算成新值，这里同步即可
scrollTo(scrollX, scrollY)
return consumedY != 0
}
}
面试中的经典考点
问：scrollTo 和 translationX 的区别是什么？什么时候必须用哪个？
答：scrollX/Y 参与事件命中与内容裁剪，是"内容偏移"；translationX/Y 只参与绘制变换，不改布局。需要被父容器裁剪、不希望内容跑到容器外（比如抽屉滑出一半要被裁掉）时用 scroll；需要视觉位移但仍算"同一个位置"（比如下拉刷新下移）时用 translation。规律是：scroll 管"内容的位置"，translation 管"视觉的偏移"。
问：为什么 Scroller 需要配 computeScroll()？
答：因为 Scroller 本身不驱动绘制，它只做时间 → 距离的插值计算。必须由 View 在每帧的 computeScroll() 里主动问一次"还有下一帧吗"，有就把 currX/currY 应用到 scrollX/scrollY 并 postInvalidateOnAnimation() 请求下一帧，这是一个由 View 生命周期驱动的循环。少了 computeScroll 覆写，动画就只走一帧不动；少了 postInvalidateOnAnimation 就会"停在半路"。
问：属性动画和 Scroller 怎么选？
答：选型看驱动量。时间驱动、要精确控制时长与曲线（淡入、旋转、进度条）用属性动画；速度驱动、要处理惯性衰减与边界减速（列表惯性滚动）用 Scroller/OverScroller。还可看是否需要插值器之外的信息——惯性滚动需要摩擦系数与边界回弹，Scroller 的 fling 已经把这些封装好了，属性动画得自己算。
问：为什么改 translationX 的动画在 RecyclerView 里的 item 上"位置会跳"？
答：因为 item 被复用。onViewAttachedToWindow / onBindViewHolder 时旧 item 的 translationX 可能还残留，而 translationX 属于View 实例状态而非数据状态，复用时不会被自动重置。规范做法是在 onBindViewHolder（或 onViewRecycled 后重新取出时）显式 itemView.translationX = 0f，把动画起点绑定到数据而不是绑定到 View 实例。
问：View 的滑动会影响点击吗？
答：会。触摸命中按 getHitRect 判定，而 getHitRect 受 scrollX/Y 影响、不受 translation 影响。 所以 translationX 位移后，视觉位置与命中区域不一致（点到别处去了），而 scroll 位移后命中跟着变。若用 translation 做可点击控件的位移，必须同步扩大 TouchDelegate 或改用 scroll。 这是这题最容易被忽略但最出实际价值的一条。
落到项目里怎么做
一条能写进规范的红线：位移动画优先 translation/scroll，改布局只在动画结束时做一次。 判断标准是"动画过程中兄弟 View 的位置是否需要跟着变"——需要，才动 LayoutParams。
配套实践三条：① 所有位移动画统一封装一个 settle 工具，内部保证"动画结束写回布局 + 清 translation"这条不变量；② 滑动相关代码中 scrollBy/Scroller 的符号写注释，这类 bug 视觉上完全反了，肉眼极易漏过；③ 惯性滚动统一基于 OverScroller，自己手写摩擦系数时应对齐 Android 原版的 mFlingFriction 量级，否则和系统列表手感不一致。
给正在准备面试的你
这题的答法要落到"三条路 + 各自的代价与适用边界"。推荐这条线：先分类（translation / scroll / LayoutParams，分别是重绘、重绘、重排）→ 讲清 scroll 影响命中与裁剪、translation 只影响绘制 → 讲三个坑：符号写反、每帧改 LayoutParams、translation 残留与命中错位 → 补 Scroller 与属性动画的选型判据（速度驱动 vs 时间驱动）。能被追问到"translation 位移后点击为什么点不到"，说明真的在项目里踩过；能讲清 postInvalidateOnAnimation 与 invalidate 的差别，说明调试过掉帧。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：滑动冲突解决：外部拦截与内部拦截
下一篇预告：RecyclerView-缓存机制：四层缓存各自干什么
有任何问题欢迎在评论区留言交流。
