Android 嵌套滑动总结，开发移动app公司

手动重写事件分发的缺点

• 只适合比较简单的嵌套滑动情况

这一点很好理解。因为你需要自己手动编写拦截逻辑，嵌套滑动的布局一旦复杂，那么就需要大量的代码和逻辑来实现嵌套滑动，增大维护的成本。所以不适合复杂的嵌套滑动布局，实际上也很难实现复杂的嵌套滑动。

• 难以支持 fling

fling 指的是滑动松手后，视图继续依靠惯性滑动的过程。一般来说，考虑到用户体验，嵌套滑动是需要支持 fling 的。那么对于手动编写事件分发来说，除了需要重写 onInterceptTouchEvent 之外，还需要针对 ACTION_UP 事件进行特定的处理，因为 fling 源于 ACTION_UP 事件时产生的 Velocity。然而事件分发机制并没有提供像 onInterceptTouchEvent 的那样的对外暴露的接口让开发者来处理 ACITON_UP 事件。只能通过复写 onTouchEvent 等方法来处理，而这样做的限制太大，因为你需要调用 super.onTouchEvent，但是你又不能修改其中的代码。

• 没有办法实现连贯的吸顶嵌套滑动

还是以之前的例子来说，当 tab 吸顶后，我们希望的是手指不松开继续往上滑可以使 RecyclerView 往上滑，然而手动拦截事件的做法是做不到的，必须先抬起手指然后再次滑动。为什么会这样？看看 dispatchTouchEvent 中的代码：

if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) {

…

} else {

// 当 MotionEvent 为 ACTION_MOVE 且 mFirstTouchTarget == null 时，仍然拦截事件

intercepted = true;

}

当 ViewGroup 在分发事件时，如果 mFirstTouchTarget == null 则说明 ViewGroup 中没有子 View 来消费事件，该事件由 ViewGroup 自己处理。而当 ViewGroup 拦截事件后，恰恰会将 mFirstTouchTarget 置空。回到之前的例子，当外层滑动父布局拦截了 ACTION_MOVE 事件后，会将 mFirstTouchTarget 置空。接下来即使吸顶后不拦截事件，由于 mFirstTouchTarget 已经为 null，所以事件不会传递到子 RecyclerView，而是继续由父布局消费。这样就没有达到连贯的吸顶嵌套滑动的效果。

2、CoordinatorLayout + AppBar + Behavior + scrollFlag

CoordinatorLayout 是 google 提供的一套可以实现复杂交互效果的布局，和 AppBar 、Behavior、scrollFlag 配合使用，可以解耦地定制多种效果，这些效果由 Behavior 和 scrollFlag指定。并且 Behavior 可以自定义。

要用 CoordinatorLayout 实现嵌套滑动非常简单，只要按如下编写布局文件：

<?xml version="1.0" encoding="utf-8"?>

<androidx.coordinatorlayout.widget.CoordinatorLayout

xmlns:android=“http://schemas.android.com/apk/res/android”

xmlns:app=“http://schemas.android.com/apk/res-auto”

xmlns:tools=“http://schemas.android.com/tools”

android:layout_width=“match_parent”

android:layout_height=“match_parent”>

<com.google.android.material.appbar.AppBarLayout

android:layout_height=“300dp”

androi