CoordinatorLayout滑动问题
最近发现个问题，在CoordinatorLayout多tab的情况下，若一开始滑动tab下的ViewPager2，切换tab后，滑动AppBarLayout区域，没有任何反应。
理清逻辑
第一反应是view属性配置导致的？仔细检查了下布局文件，并没有一些特殊的属性在作怪，又去有着相似布局的其他页面查看了下，发现了同样的问题。查看了stackoverflow上一些问答，都未能找到答案。CoordinatorLayout并不是一个新的控件，这么严重的bug不可能遗留到今天。issuetracker中也没有得到答案。只有查看源码，分析问题了。
滑动ViewPage2时，整个布局正常滚动，说明嵌套滑动机制是生效的。唯独AppBarLayout上滑动时失效，那就先定位到AppBarLayout的源码中。AppBarLayout中并没有处理事件分发，响应事件的方法。那入口就得去父级找找看了。果不其然CoordinatorLayout.onInterceptTouchEvent中发现了performIntercept方法，循环调用childView，并获取childView的Behavior，调用onInterceptTouchEvent。
AppBarLayout的Behavior.onInterceptTouchEvent实现为HeaderBehavior.onInterceptTouchEvent
@Override
public boolean onInterceptTouchEvent(
@NonNull CoordinatorLayout parent, @NonNull V child, @NonNull MotionEvent ev) {
if (touchSlop < 0) {
touchSlop = ViewConfiguration.get(parent.getContext()).getScaledTouchSlop();
}
// Shortcut since we're being dragged
if (ev.getActionMasked() == MotionEvent.ACTION_MOVE && isBeingDragged) {
if (activePointerId == INVALID_POINTER) {
// If we don't have a valid id, the touch down wasn't on content.
return false;
}
int pointerIndex = ev.findPointerIndex(activePointerId);
if (pointerIndex == -1) {
return false;
}
int y = (int) ev.getY(pointerIndex);
int yDiff = Math.abs(y - lastMotionY);
if (yDiff > touchSlop) {
lastMotionY = y;
return true;
}
}
if (ev.getActionMasked() == MotionEvent.ACTION_DOWN) {
activePointerId = INVALID_POINTER;
int x = (int) ev.getX();
int y = (int) ev.getY();
isBeingDragged = canDragView(child) && parent.isPointInChildBounds(child, x, y);
if (isBeingDragged) {
lastMotionY = y;
activePointerId = ev.getPointerId(0);
ensureVelocityTracker();
// There is an animation in progress. Stop it and catch the view.
if (scroller != null && !scroller.isFinished()) {
scroller.abortAnimation();
return true;
}
}
}
if (velocityTracker != null) {
velocityTracker.addMovement(ev);
}
return false;
}
通过我们的案例可知，滑动AppBarLayout区域无效果，事件可能是没有被拦截的，那么可能就是onInterceptTouchEvent返回false导致的。为了验证这以猜想，查看canDragView中的代码，具体实现是BaseBehavior.canDragView。
@Override
boolean canDragView(T view) {
if (onDragCallback != null) {
// If there is a drag callback set, it's in control
return onDragCallback.canDrag(view);
}
// Else we'll use the default behaviour of seeing if it can scroll down
if (lastNestedScrollingChildRef != null) {
// If we have a reference to a scrolling view, check it
final View scrollingView = lastNestedScrollingChildRef.get();
return scrollingView != null
&& scrollingView.isShown()
&& !scrollingView.canScrollVertically(-1);
} else {
// Otherwise we assume that the scrolling view hasn't been scrolled and can drag.
return true;
}
}
默认是返回true，那么问题就出在lastNestedScrollingChildRef身上。为了测试是否是因为这个对象导致的，我在执行canDragView之前，反射将lastNestedScrollingChildRef置null，通过测试，发现问题被成功解决了。但谷歌这样设计是有道理的，不应该违背这套机制，将其值null。
问题的根源在哪？
lastNestedScrollingChildRef在onStartNestedScroll被置null，在onStopNestedScroll被赋值。滑动ViewPager2，其本身内部由RecyclerView实现，RecyclerView的事件机制内，会触发onStartNestedScroll，lastNestedScrollingChildRef会被置null，这也是为啥滑动底部ViewPager2，能够正常响应的原因。滑动AppBarLayout区域则不会触发这一流程，既然不能通过默认机制来解决问题，那还是得回到lastNestedScrollingChildRef本身。
更简单的解决方案
三个条件scrollingView != null&& scrollingView.isShown()&& !scrollingView.canScrollVertically(-1);重点就在第二个isShown，通过打印scrollingView对象，可以清楚的看见，当切换到第二个tab时，scrollingView就是ViewPager2中的第一个RecyclerView，因为其不可见导致滑动无法被响应。ViewPager2默认offscreenPageLimit为1，这也就意味这缓存空间只有1个屏幕宽度，所以第一个RecyclerView会不可见，通过调整offscreenPageLimit即可解决。
