前言

做程序開發(fā)齿风，基礎(chǔ)很重要。同樣是擰螺絲人家擰出來的可以經(jīng)久不壞绑洛，你擰出來的遇到點風(fēng)浪就開始顫抖救斑，可見基本功的重要性。此系列真屯，專門收錄一些看似基礎(chǔ)脸候，但是沒那么簡單的小細(xì)節(jié)，同時提供權(quán)威解決方案绑蔫。喜歡的同志們點個贊就是對我最大的鼓勵运沦！先行謝過！

網(wǎng)上可能有一些其他文章配深，提供了解決方案茶袒，但是要么就是沒有提供可運行demo，要么就是demo不夠純粹凉馆，讓人探索起來受到其他代碼因素的影響，無法專注于當(dāng)前這個知識點（比如，我只是想了解Activity的生命周期澜共，你把生命周期探究的過程混入到一個很復(fù)雜的大雜燴Demo中向叉，讓人一眼就沒有了閱讀Demo代碼的欲望），所以我覺得有必要做一個專題嗦董，用最純粹的方式展示一個坑的解決方案.

正文

記得有一次要使用多個ScrollView嵌套的時候母谎，需要同時讓兩層ScrollView的滑動都能生效。但是京革，當(dāng)我直接套了兩層ScrollView之后,發(fā)現(xiàn)內(nèi)層的滑動完全無效了奇唤。

研究一番之后發(fā)現(xiàn)解決方案其實非常簡單。

效果

多層ScrollView嵌套.gif

不墨跡匹摇，直接給出源碼工程github.

關(guān)鍵代碼

android的事件分發(fā)滑動沖突的基礎(chǔ)知識咬扇，這里不再贅述。
兩種解決方案：
1廊勃，自定義外層ScrollView的攔截行為. 重寫onInterceptTouchEvent,直接返回false懈贺，外層不再攔截事件。

public class OutsideScrollView extends ScrollView {

    public OutsideScrollView(Context context) {
        this(context, null);
    }

    public OutsideScrollView(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public OutsideScrollView(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
        return false;
    }

}

2坡垫、自定義內(nèi)層 ScrollView的攔截行為梭灿，調(diào)用 getParent().requestDisallowInterceptTouchEvent(true);不允許外層對它的事件進行攔截.

public class InsideScrollView extends ScrollView {
    public InsideScrollView(Context context) {
        this(context, null);
    }

    public InsideScrollView(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public InsideScrollView(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    //如果我不允許外部攔截我呢？
    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
        getParent().requestDisallowInterceptTouchEvent(true);
        return super.onInterceptTouchEvent(ev);
    }

}

原理

先來解決 第一個疑問 不進行上面的處理時內(nèi)部的ScrollView滑動不了呢冰悠？

解讀一下ScrollView的源碼堡妒，發(fā)現(xiàn)，它重寫了 View的 onInterceptTouchEvent和 onTouchEvent溉卓。

image.png

上圖中皮迟，我們能在重寫的onInterceptTouchEvent方法中找到兩處return true（true則攔截或者消費，false則放行或不消費的诵，整個事件分發(fā)機制都是這個套路万栅，記住就行了）。
第二處西疤，調(diào)用的是父類烦粒，也就是FrameLayout的攔截返回值，一般都會返回false放行代赁，不理會即可扰她。
只看第一處，首先芭碍，指定攔截ACTION_MOVE事件徒役，并且還有另一個條件。
mIsBeingDragged - 是否正在拖拽窖壕∮俏穑看看這個值什么時候會變成 true,找到下面這個地方（其實還有另一處杉女，在onTouchEvent中，但是現(xiàn)在還沒到事件回傳的時候鸳吸，所以不用看）

image.png

讓它變成true判定條件為：
if (yDiff > mTouchSlop && (getNestedScrollAxes() & SCROLL_AXIS_VERTICAL) == 0) {
yDiff > mTouchSlop的意思是熏挎，Y軸上的滑動距離，要大于設(shè)備規(guī)定的最小滑動距離.
(getNestedScrollAxes() & SCROLL_AXIS_VERTICAL) == 0 的意思是晌砾，此視圖組的嵌套滾動的當(dāng)前軸是否是縱向（看了注釋之后理解的坎拐，這里不能debug很蛋疼）. getNestedScrollAxes()的值應(yīng)該是0，因為搜索了全文养匈，發(fā)現(xiàn)針對mNestedScrollAxes值的變動哼勇，在類內(nèi)部就只有賦值為0的情況，而&是與運算呕乎，只要有0积担，就可以斷言整個都是0了，所以==0楣嘁，成立磅轻。
兩者都是true，則進入if逐虚。 進入之后：mIsBeingDragged = true; 便會執(zhí)行聋溜。
當(dāng)?shù)谝粋€move執(zhí)行之后，mIsBeingDragged 已經(jīng)是true叭爱。當(dāng)?shù)诙€move來的時候撮躁，ScrollView便會阻攔后面所有的move。 這就是內(nèi)層ScrollView不能滑動的原因买雾。

第二個疑問：為什么自定義外層 scrollView把曼，重寫 onInterceptTouchEvent 直接 return false之后，內(nèi)層就能正忱齑滑動呢嗤军，而且手指在內(nèi)層滑動時，外層是不動的晃危？

重寫了onInterceptTouchEvent 直接 return false叙赚，那原本scrollView的onInterceptTouchEvent過程則不會執(zhí)行。現(xiàn)在僚饭，所有的事件直接透傳震叮，那么內(nèi)層ScrollView就可以收到事件，自然就有了滑動效果鳍鸵。但是苇瓣，當(dāng)手指在內(nèi)層滑動時，外層不受影響偿乖。這是為何击罪。
答案在 ScrollView的onTouchEvent方法內(nèi)（代碼太長哲嘲，我就不貼全部了）

    @Override
    public boolean onTouchEvent(MotionEvent ev) {
        initVelocityTrackerIfNotExists();

        MotionEvent vtev = MotionEvent.obtain(ev);

        final int actionMasked = ev.getActionMasked();

        if (actionMasked == MotionEvent.ACTION_DOWN) {
            mNestedYOffset = 0;
        }
        vtev.offsetLocation(0, mNestedYOffset);

        switch (actionMasked) {
            case MotionEvent.ACTION_DOWN: {
                if (getChildCount() == 0) {
                    return false;
                }
                .... 省略N 行代碼
                break;
            }
            ... 省略N 行代碼
        }

        if (mVelocityTracker != null) {
            mVelocityTracker.addMovement(vtev);
        }
        vtev.recycle();
        return true;
    }

很明確，ScrollView的onTouchEvent外邓，消費掉了除DOWN之外的所有事件撤蚊。所以外層ScrollView收不到move，自然就沒有任何反應(yīng)损话。

第三個疑問：內(nèi)層攔截 getParent().requestDisallowInterceptTouchEvent(true)到底做了什么，讓外層無法攔截事件槽唾？

先看getParent, 眾所周知丧枪，View不是一個獨立個體，它是一個樹形結(jié)構(gòu)庞萍，有一個parent節(jié)點拧烦，也有N個child節(jié)點。這個getParent實際上就是得到自己的父View钝计。
看看ViewGroup的requestDisallowInterceptTouchEvent：

    @Override
    public void requestDisallowInterceptTouchEvent(boolean disallowIntercept) {

        if (disallowIntercept == ((mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0)) {
            // We're already in this state, assume our ancestors are too
            return;
        }

        if (disallowIntercept) {
            mGroupFlags |= FLAG_DISALLOW_INTERCEPT;
        } else {
            mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
        }

        // Pass it up to our parent
        if (mParent != null) {
            mParent.requestDisallowInterceptTouchEvent(disallowIntercept);
        }
    }

可以看到入?yún)ⅲ?code>disallowIntercept的值恋博，改變了全局變量mGroupFlags 的值。并且私恬，這個方法將disallowIntercept的值向父View傳遞债沮。
全局變量mGroupFlags 什么時候用到呢？
進入ViewGroup的dispatchTouchEvent方法：

image.png

可以斷定本鸣，之前傳入的disallowIntercept 入?yún)⒅狄唏茫欢梢杂绊懙竭@里的局部變量boolean disallowIntercept的值，并且如果之前傳入true荣德，這里就會得到true（你問我為什么會斷定涮瞻？因為這是在書上看到的。。。具體過程涉及到數(shù)字的位運算歹苦，賊復(fù)雜，在這里說不清楚蚪腋，以后做專題的時候再講吧）.
如果之前傳入的是true眼溶，那么這里就會執(zhí)行else 中的 intercepted = false; 也就是，不會執(zhí)行這個
intercepted = onInterceptTouchEvent(ev); 明白了吧？ 如果內(nèi)層調(diào)用了requestDisallowInterceptTouchEvent(true),在父view的dispatchTouchEvent中，就不會執(zhí)行onInterceptTouchEvent.

---

值得一提的是敞恋，requestDisallowInterceptTouchEvent(true) 方法內(nèi)部啸蜜，調(diào)用了mParent.requestDisallowInterceptTouchEvent(disallowIntercept);,讓這個bool值會一直向上傳遞裹粤，也就是說，如果一個子view調(diào)用了這個方法蜂林，那么它的父遥诉，父的父拇泣。。矮锈。節(jié)點霉翔，都不會攔截它的事件。

結(jié)語

閱讀源碼是一個痛苦的過程苞笨，隨時隨地會發(fā)現(xiàn)自己的知識盲區(qū)债朵。但是，不讀源碼猫缭，就不知道源碼的深淺葱弟，就無法進階成高級工(super)程(ma)師(nong),努力吧，騷年!