本文算是對(duì)之前的一篇博文《自個(gè)兒寫(xiě)Android的下拉刷新/上拉加載控件》的續(xù)章，如果有興趣了解更多的朋友可以先看一看之前的這篇博客。

事實(shí)上之所以會(huì)有之前的那篇博文的出現(xiàn)鹉动，是起因于前段時(shí)間自己在寫(xiě)一個(gè)練手的App時(shí)很快就遇到這種需求。其實(shí)我們可以發(fā)現(xiàn)類(lèi)似這樣下拉刷新、上拉加載的功能正在變得越來(lái)越普遍懈玻，可以說(shuō)如今基本上絕大多數(shù)的應(yīng)用里面都會(huì)使用到。當(dāng)然乾颁，隨著Android的發(fā)展涂乌，已經(jīng)有不少現(xiàn)成的可以實(shí)現(xiàn)這種需求的“輪子”供我們使用了。

但轉(zhuǎn)過(guò)頭想一下想钮孵，既然本來(lái)就是自己練手之作骂倘。為什么還要去用別人的“輪子”呢？何不自己也試著造一造“輪子”巴席？其實(shí)以上拉刷新历涝、下拉加載這種需求來(lái)說(shuō)，以前基本上都是應(yīng)用在ListView上面的。所以回想一下：可以說(shuō)前兩年P(guān)ullToRefreshListView還依然是很多應(yīng)用里都會(huì)使用到的開(kāi)源庫(kù)荧库。但是隨著Android的飛速發(fā)展堰塌，比如RecyclerView的出現(xiàn)等等。這時(shí)候分衫，像PullToRefreshListView這種對(duì)于ListView所做的擴(kuò)展场刑，就顯得不夠了。

所以蚪战，我首先很快決定：自己要定義的是一個(gè)可以通用這種功能的ViewGroup牵现，而不是針對(duì)某種特定的View來(lái)做擴(kuò)展。（當(dāng)然了邀桑，這兩種做法顯然各自有利也有弊瞎疼，關(guān)鍵還是看實(shí)際的需求采用哪種方式更合適以及自己的取舍了）至于接下來(lái)的工作，自然就是整理思路壁畸，并逐步加以實(shí)現(xiàn)了贼急。

當(dāng)最后完成后，當(dāng)然免不了記錄一下這個(gè)過(guò)程中的思路捏萍、收獲等來(lái)進(jìn)行鞏固太抓。于是，就有了之前的博文令杈。在這之后走敌，有收到了不少朋友的鼓勵(lì)；當(dāng)然也有朋友提出了很多不足的地方和很多有用的建議这揣。衷心感謝；诔！！给赞！其實(shí)因?yàn)樗交颉r(shí)間以及精力等緣故，對(duì)于最初的實(shí)現(xiàn)方式片迅，之后我自己有空時(shí)再回過(guò)頭去看的時(shí)候残邀，也發(fā)現(xiàn)很多地方不太滿(mǎn)意，很多地方可以改進(jìn)柑蛇。也正是基于這些原因芥挣，就有了之后的優(yōu)化改良工作。于是耻台，最終對(duì)應(yīng)的又有了這篇博客的誕生空免，在這里總結(jié)一下這次優(yōu)化的思路以及收獲。

一盆耽、上拉蹋砚、下拉動(dòng)畫(huà)效果的修改

實(shí)際上扼菠，在之前的實(shí)現(xiàn)里，自己選擇了如下的下拉刷新以及上拉加載的動(dòng)畫(huà)效果：

這是因?yàn)橹坝X(jué)著反正也是自己寫(xiě)著爽爽坝咐，不如就搞點(diǎn)比較有意思的Loading效果循榆。但后來(lái)有朋友告訴我，如果我感興趣墨坚，想要使用一下你的控件秧饮，那么這種動(dòng)畫(huà)卻有點(diǎn)不太實(shí)用。自己想想也是泽篮，比如假設(shè)我打算把自己的應(yīng)用發(fā)布到應(yīng)用市場(chǎng)盗尸，那這種效果確實(shí)有點(diǎn)不太嚴(yán)肅。正好自己比較喜歡簡(jiǎn)書(shū)IOS版以及新浪微博的下拉動(dòng)畫(huà)帽撑，給人的感覺(jué)是簡(jiǎn)練振劳，并且提示清晰。所以這次自己也采用了這種動(dòng)畫(huà)∮涂瘢現(xiàn)在的效果如下：

這里的改動(dòng)并沒(méi)有什么難度，主要的思路仍然是根據(jù)滑動(dòng)的距離讓ViewGroup進(jìn)入不同的狀態(tài)（當(dāng)然自己這次優(yōu)化了onTouchEvent中根據(jù)滑動(dòng)舉例切換視圖狀態(tài)的實(shí)現(xiàn)細(xì)節(jié)）寸癌，而后根據(jù)不同的狀態(tài)來(lái)顯示不同的提示信息专筷。而對(duì)于旋轉(zhuǎn)的提示箭頭，只需要一張向下的箭頭素材 + 屬性動(dòng)畫(huà)就可以搞定了蒸苇。

二磷蛹、onMeasure和onLayout的思路優(yōu)化

在自己最初的實(shí)現(xiàn)里，onMeasure和onLayout這里就一直是自己不太滿(mǎn)意的溪烤。我最初的思路是味咳，既然是一個(gè)可上拉、下拉的ViewGroup檬嘀，所以考慮選擇將ViewGroup里的child view按照定義的先后順序由上至下進(jìn)行排列槽驶。導(dǎo)致后來(lái)只要稍微一回想，就會(huì)覺(jué)得這種方式實(shí)在是非常的想當(dāng)然和糟糕鸳兽。

這種方式直接導(dǎo)致我對(duì)于ViewGroup中的child view的measure工作以及后續(xù)的一系列滑動(dòng)邏輯變得非常的十分缺乏邏輯嚴(yán)密性和合理性掂铐。舉例來(lái)說(shuō)，我不得不在進(jìn)行滑動(dòng)沖突的處理的時(shí)候選擇：如果是處理下拉的滑動(dòng)沖突的時(shí)候揍异，只能通過(guò)getChildAt（firstChildIndex）這樣的方式來(lái)判斷位于最上方的子View是否需要處理滑動(dòng)沖突全陨；同理，在處理上拉時(shí)衷掷，則需要判斷getChildAt（lastChildIndex）是否存在滑動(dòng)沖突辱姨。

這樣的處理方式時(shí)候讓我越看代碼，越有一種要犯尷尬癌的沖動(dòng)戚嗅。于是雨涛，這也成了自己著重想要進(jìn)行優(yōu)化和改變的地方枢舶。為此，自己抽空去閱讀了SwipeRefreshLayout的源碼镜悉。而最終也是選擇借鑒了SwipeRefreshLayout的實(shí)現(xiàn)方式祟辟。從而不得不感嘆：佩服！至于為什么這么說(shuō)侣肄，我們先來(lái)看這樣的一個(gè)布局文件旧困。并且，思考一下其最終呈現(xiàn)出來(lái)的效果應(yīng)該是怎么樣的稼锅？

<android.support.v4.widget.SwipeRefreshLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="300dp"
        android:orientation="vertical">

        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="button" />

        <ImageView
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:background="@mipmap/ic_launcher" />
    </LinearLayout>

    <View
        android:layout_width="match_parent"
        android:layout_height="1200dp"
        android:background="#000000"/>
</android.support.v4.widget.SwipeRefreshLayout>

在這個(gè)布局文件的最終效果呈現(xiàn)到屏幕上之前吼具，不知道你對(duì)它最終效果的猜想是如何的呢？如果你和我之前一樣無(wú)法確定矩距，那這里可以一起來(lái)看一下：

沒(méi)錯(cuò)最終的效果就是這樣拗盒，可以發(fā)現(xiàn)：

• 雖然我們?cè)诓季治募袑wipeRefreshLayout內(nèi)的LinearLayout的高度設(shè)置為300dp，但其實(shí)最終的效果看上去是match_parent锥债。
• 雖然我們已經(jīng)明確將這之后的一個(gè)View的高度設(shè)置為了1200dp陡蝇，但其實(shí)然并卵，這個(gè)View最終是無(wú)法顯示到屏幕上的哮肚。

形成這種效果的原因登夫，顯然我們應(yīng)該到SwipeRefreshLayout的onMeasure和onLayout中去尋找答案。首先允趟，我們截取部分onMeasure的代碼：

public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
        if (mTarget == null) {
            ensureTarget();
        }
        if (mTarget == null) {
            return;
        }
        mTarget.measure(MeasureSpec.makeMeasureSpec(
                getMeasuredWidth() - getPaddingLeft() - getPaddingRight(),
                MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(
                getMeasuredHeight() - getPaddingTop() - getPaddingBottom(), MeasureSpec.EXACTLY));
        // 省略若干...
        }

可以看到這里首先會(huì)進(jìn)行一個(gè)mTarget是否為空的判斷恼策。如果為空，則會(huì)調(diào)用叫做ensureTarget()的方法潮剪。顧名思義涣楷，該方法就是用來(lái)確認(rèn)mTarget的。

    private void ensureTarget() {
        // Don't bother getting the parent height if the parent hasn't been laid
        // out yet.
        if (mTarget == null) {
            for (int i = 0; i < getChildCount(); i++) {
                View child = getChildAt(i);
                if (!child.equals(mCircleView)) {
                    mTarget = child;
                    break;
                }
            }
        }
    }

其實(shí)這個(gè)方法的實(shí)現(xiàn)抗碰，非常簡(jiǎn)單狮斗，就是遍歷SwipeRefreshLayout中的child view，遍歷到的第一個(gè)不為mCircleView的child就將作為mTarget弧蝇。
那么情龄，mCircleView這個(gè)東西究竟是什么鬼呢？其實(shí)就是SwipeRefreshLayout在進(jìn)行下拉的時(shí)候的那個(gè)圈圈了捍壤，這是SwipeRefreshLayout默認(rèn)添加的骤视。
然后，讓我們回到onMeasure方法當(dāng)中鹃觉，就會(huì)看到對(duì)mTarget進(jìn)行測(cè)量的代碼专酗。從源碼中可以看到，其實(shí)無(wú)論我們對(duì)mTarget的寬高進(jìn)行如何的設(shè)置盗扇，其實(shí)其最后的寬高都是EXACTLY模式的SwipeRefreshLayout的寬高減去內(nèi)邊距祷肯。這就解釋了為什么對(duì)LinearLayout設(shè)置300dp的高度最終卻占滿(mǎn)了窗口沉填。

最后，我們?cè)倏匆豢碨wipeRefreshLayout的源碼中onLayout方法的實(shí)現(xiàn)：

    @Override
    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
        final int width = getMeasuredWidth();
        final int height = getMeasuredHeight();
        if (getChildCount() == 0) {
            return;
        }
        if (mTarget == null) {
            ensureTarget();
        }
        if (mTarget == null) {
            return;
        }
        final View child = mTarget;
        final int childLeft = getPaddingLeft();
        final int childTop = getPaddingTop();
        final int childWidth = width - getPaddingLeft() - getPaddingRight();
        final int childHeight = height - getPaddingTop() - getPaddingBottom();
        child.layout(childLeft, childTop, childLeft + childWidth, childTop + childHeight);
        int circleWidth = mCircleView.getMeasuredWidth();
        int circleHeight = mCircleView.getMeasuredHeight();
        mCircleView.layout((width / 2 - circleWidth / 2), mCurrentTargetOffsetTop,
                (width / 2 + circleWidth / 2), mCurrentTargetOffsetTop + circleHeight);
    }

由此佑笋，我們可以發(fā)現(xiàn)對(duì)于SwipeRefreshLayout來(lái)說(shuō)：其實(shí)不論是measure和layout工作翼闹，都只會(huì)針對(duì)于mTarget，即第一個(gè)child進(jìn)行的蒋纬。那么就可以解釋為什么之前我們放置在LinearLayout之后的高度設(shè)置為1200dp的View根本就不會(huì)顯示的原因了猎荠。

現(xiàn)在，了解了其中秘密蜀备。我們來(lái)分析一下為什么說(shuō)這種方式更為的優(yōu)秀呢关摇？很簡(jiǎn)單，因?yàn)槲覀兏镜男枨笫嵌x一個(gè)支持下拉（上拉）的ViewGroup碾阁。
那么注意了输虱！我們要明確在這里：支持下拉、上拉才是重點(diǎn)脂凶。所以說(shuō)宪睹，這時(shí)我們其實(shí)根本不用去過(guò)多的考慮child view的measure和layout工作。

對(duì)于onMeasure來(lái)說(shuō)蚕钦，對(duì)于mTarget的寬横堡、高的測(cè)量，其實(shí)就是需要與我們自定義的ViewGroup保持一致才對(duì)（當(dāng)然需要計(jì)算內(nèi)邊距）冠桃。因?yàn)樵囅胍幌拢?/p>

• 假設(shè)SwipeRefreshLayout的寬度是200，里面的child內(nèi)容卻是50道宅，那么看上去不是很奇怪嗎食听？
• 同理，假設(shè)SwipeRefreshLayout的高度是500污茵，而其中的child高度卻是1000樱报，那不是又很尷尬了嗎？

而對(duì)于child的置位工作來(lái)說(shuō)泞当，Android本身就已經(jīng)就為我們提供了足夠的ViewGroup（Layout）類(lèi)型迹蛤，如果有復(fù)雜的置位需求，使用這些ViewGroup不就行了嗎襟士？而拋開(kāi)了這些后顧之憂(yōu)盗飒，有一個(gè)最大的好處就是：我們之后對(duì)于滑動(dòng)沖突等事物的處理將變得明確，只需要針對(duì)于mTarget就可以了陋桂。

所以逆趣，最終我也選擇借鑒SwipeRefreshLayout的方式。之前的文字描述可能表達(dá)并不清晰嗜历，為了更加直觀看到我想描述的效果宣渗，看這樣一個(gè)布局文件：

<me.hwang.widgets.SmartPullableLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:library="http://schemas.android.com/apk/res-auto"
    android:id="@+id/layout_pullable"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    library:smart_ui_enable_pull_up="false">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical"
        android:padding="20dp">

        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="按鈕一"/>

        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="按鈕二"/>

        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="按鈕三"/>

        <ImageView
            android:id="@+id/iv_content"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:background="@mipmap/ic_launcher"/>
    </LinearLayout>
</me.hwang.widgets.SmartPullableLayout>

其最終的運(yùn)行效果如下：

也就說(shuō)抖所，這里我的布局里其實(shí)并不止一個(gè)單獨(dú)的View，其包括3個(gè)Button以及1個(gè)ImageView痕囱。但是田轧，對(duì)于它們的測(cè)量與置位工作，顯然不應(yīng)該是我們這里定義的ViewGroup應(yīng)該關(guān)心的鞍恢。對(duì)于此類(lèi)邏輯傻粘，讓它交給LinearLayout，RelativeLayout這類(lèi)ViewGroup不就OK了嗎有序？當(dāng)然了抹腿，是不是說(shuō)這種方式就能做到萬(wàn)無(wú)一失了呢？顯然不是旭寿，以SwipeRefreshLayout為例警绩。假設(shè)寫(xiě)出了類(lèi)似下面這樣的布局的話(huà)，它也是會(huì)很糾結(jié)的：

<android.support.v4.widget.SwipeRefreshLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <Button
        android:layout_width="match_parent"
        android:layout_height="0dp"
        android:layout_weight="1" />
  
        <ListView
            android:id="@+id/lv_content"
            android:layout_width="match_parent"
            android:layout_height="0dp"
            android:layout_weight="1"/>

        <Button
            android:layout_width="match_parent"
            android:layout_height="0dp"
            android:layout_weight="1" />
    </LinearLayout>
</android.support.v4.widget.SwipeRefreshLayout>

這種寫(xiě)法顯然就會(huì)造成需求不明的情況盅称，因?yàn)榭丶淖髡咴诙xViewGroup的時(shí)候肯定猜不到你的目的到底是針對(duì)于整個(gè)LinearLayout進(jìn)行下拉刷新肩祥，還是針對(duì)于里面局部的ListView進(jìn)行刷新。那么缩膝，顯然這時(shí)就無(wú)法避免的會(huì)出現(xiàn)滑動(dòng)bug混狠。所以如果你的需求是后者，那顯然應(yīng)該使用如下的方式才對(duì)：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <Button
        android:layout_width="match_parent"
        android:layout_height="0dp"
        android:layout_weight="1" />
  
    <android.support.v4.widget.SwipeRefreshLayout
        android:layout_width="match_parent"
        android:layout_height="0dp"
        android:layout_weight="1">
        
        <ListView
            android:id="@+id/lv_content"
            android:layout_width="match_parent"
            android:layout_height="match_parent" />

    </android.support.v4.widget.SwipeRefreshLayout>

    <Button
        android:layout_width="match_parent"
        android:layout_height="0dp"
        android:layout_weight="1" />
</LinearLayout>

三疾层、添加滑動(dòng)阻力

這一點(diǎn)是寫(xiě)了之前一篇博客之后将饺，有一個(gè)朋友提出來(lái)的，我自己也覺(jué)得非常需要痛黎。同樣為了有一個(gè)比較直觀的印象予弧，來(lái)看一看是否添加阻力的效果對(duì)比：

這里可以看到，最初沒(méi)有添加滑動(dòng)阻力的時(shí)候湖饱，當(dāng)我們快速的向下滑動(dòng)屏幕掖蛤，會(huì)發(fā)現(xiàn)整個(gè)視圖飛快的下滑。這種體驗(yàn)顯然不是很好井厌。并且蚓庭，在這里我是做了判斷，當(dāng)滑動(dòng)的距離達(dá)到一定數(shù)值仅仆，就不再允許滑動(dòng)器赞。否則，當(dāng)我們快速的滑動(dòng)一段舉例墓拜，可能會(huì)出現(xiàn)視圖滑動(dòng)了十萬(wàn)八千里的情況拳魁。與之對(duì)比：

可以看到加入了滑動(dòng)阻力過(guò)后，整個(gè)滑動(dòng)給人的體驗(yàn)確實(shí)要舒服不少撮弧。并且潘懊，這時(shí)我們也不再需要加入滑動(dòng)達(dá)到一定距離后姚糊，便不再允許滑動(dòng)的判斷了。因?yàn)榧尤肓嘶瑒?dòng)阻力之后授舟，當(dāng)滑動(dòng)達(dá)到一定距離之后救恨，就很難再讓view繼續(xù)產(chǎn)生滑動(dòng)了。

要為滑動(dòng)添加上這種所謂的阻力其實(shí)也非常簡(jiǎn)單释树，我們可以設(shè)置一個(gè)常量作為阻力因子肠槽，比如說(shuō)0.5。那么奢啥，我們每次讓滑動(dòng)的實(shí)際距離乘以阻力因子秸仙，不就是所謂的阻力了嗎？進(jìn)一步來(lái)說(shuō)桩盲，我們還可以在滑動(dòng)距離達(dá)到可以進(jìn)行釋放刷新的距離之后寂纪，再乘以一次阻力因子，這樣阻力就進(jìn)一步的加大了赌结。由此就會(huì)給人一種越往下越拉不動(dòng)的感覺(jué)捞蛋。

四、滑動(dòng)沖突與事件攔截處理

在之前的實(shí)現(xiàn)當(dāng)中柬姚，針對(duì)于滑動(dòng)沖突拟杉。比如說(shuō)與ListView配合使用，我的思路是覆寫(xiě)onInterceptTouchEvent量承，在這里進(jìn)行邏輯處理搬设。比如如果是下拉的操作，則首先判斷ListView是否已經(jīng)滑動(dòng)到頂部撕捍。如果是拿穴，則將攔截事件滑動(dòng)事件，自己處理滑動(dòng)卦洽。否則則不攔截，讓ListView自身進(jìn)行滑動(dòng)斜棚。這里的邏輯其實(shí)是沒(méi)有問(wèn)題的阀蒂。但是，之前因?yàn)閷?duì)ListView弟蚀，具體來(lái)說(shuō)應(yīng)該是AbsListView了解不夠深入蚤霞。最后發(fā)現(xiàn)會(huì)有很讓人不爽的一點(diǎn)：

我在上述截圖中的操作是先讓ListView向下滑動(dòng)一點(diǎn)距離，然后又接著向上滑動(dòng)义钉。這時(shí)可以看到昧绣，雖然當(dāng)我已經(jīng)把ListView滑動(dòng)到最頂端，然后再繼續(xù)下拉的時(shí)候捶闸，實(shí)際是不起作用的夜畴。這是為什么呢拖刃？原因在于AbsListView內(nèi)部在處理觸摸事件的時(shí)候，會(huì)有類(lèi)似如下的代碼處理：

            final ViewParent parent = getParent();
            if (parent != null) {
                parent.requestDisallowInterceptTouchEvent(true);
            }

也就是說(shuō)贪绘，當(dāng)AbsListView決定自己開(kāi)始處理滑動(dòng)的時(shí)候兑牡，則會(huì)通過(guò)調(diào)用父視圖的requestDisallowInterceptTouchEvent禁止父視圖攔截事件。簡(jiǎn)單來(lái)說(shuō)税灌，就是這時(shí)候AbsListView已經(jīng)開(kāi)始耍流氓了均函，導(dǎo)致后續(xù)的觸摸事件根本就不會(huì)再經(jīng)過(guò)我們自定義的ViewGroup內(nèi)的onInterceptTouchEvent。這就意味著菱涤，這個(gè)時(shí)候我們對(duì)于滑動(dòng)沖突的邏輯判斷根本就不會(huì)執(zhí)行苞也，最終自然也就無(wú)法處理觸摸事件了。這個(gè)問(wèn)題的解決方法其實(shí)說(shuō)難也不難粘秆，靈感同樣來(lái)自于SwipeRefreshLayout如迟。查看SwipeRefreshLayout的源碼，可以看到如下代碼：

    public void requestDisallowInterceptTouchEvent(boolean b) {
        // if this is a List < L or another view that doesn't support nested
        // scrolling, ignore this request so that the vertical scroll event
        // isn't stolen
        if ((android.os.Build.VERSION.SDK_INT < 21 && mTarget instanceof AbsListView)
                || (mTarget != null && !ViewCompat.isNestedScrollingEnabled(mTarget))) {
            // Nope.
        } else {
            super.requestDisallowInterceptTouchEvent(b);
        }
    }

這段代碼的作用就和注釋中描述的一樣翻擒，防止在child view同樣具有垂直滑動(dòng)能力的時(shí)候“偷”走滑動(dòng)事件氓涣。在這之后，就可以解決上面談到的問(wèn)題了：

五陋气、NestedScroll 加入嵌套滑動(dòng)機(jī)制

當(dāng)完成了之前談到的一點(diǎn)的改造之后劳吠，是否還有繼續(xù)改進(jìn)的余地呢？顯然時(shí)候有的巩趁。因?yàn)橐灾罢劦降腖istView的改進(jìn)來(lái)說(shuō)：雖然相對(duì)最初的效果體驗(yàn)好了不少痒玩。但是，歸根結(jié)底议慰，仍然沒(méi)有脫離通過(guò)事件攔截機(jī)制來(lái)處理滑動(dòng)沖突的原理蠢古。這樣有一個(gè)非常顯著的問(wèn)題就是，只要當(dāng)我們自定義的作為Parent View的ViewGroup決定攔截事件過(guò)后：那么别凹，很遺憾的草讶，本次的一系列TouchEvent就不會(huì)再有機(jī)會(huì)傳遞給下面的childView（比如說(shuō)ListView）了。

但對(duì)于RecyclerView這類(lèi)更為“年輕”的控件來(lái)說(shuō)炉菲，這個(gè)問(wèn)題就不再是無(wú)解的了堕战。因?yàn)锳ndroid在Lollipop版本之后，加入了一個(gè)牛逼的機(jī)制叫做Nested Scroll拍霜，即嵌套滑動(dòng)嘱丢。而RecyclerView自身就是支持這種機(jī)制的。于是祠饺，這次我也決定為自定義的ViewGroup加上這種玩意兒越驻。

可以看到在加入嵌套滑動(dòng)的處理后，這種體驗(yàn)效果顯然是最好的。因?yàn)槲覀冏远x的ViewGroup與作為child view的RecyclerView之間完成了非常默契的滑動(dòng)配合缀旁。這里不會(huì)對(duì)NestedScroll做詳細(xì)的介紹记劈，因?yàn)槟芰推加邢蓿信d趣的朋友可以自己查閱相關(guān)資料诵棵。

簡(jiǎn)單的介紹一下核心的實(shí)現(xiàn)思路抠蚣，總的來(lái)說(shuō)，我們只需要知道：

• 首先履澳，RecyclerView作為NestedScrollingChild嘶窄，其在每次處理滑動(dòng)之前會(huì)先通知NestedScrollingParent是否需要進(jìn)行嵌套滑動(dòng)。
• 這時(shí)距贷，如果Parent決定進(jìn)行嵌套滑動(dòng)柄冲。那么，在Child處理滑動(dòng)之前忠蝗，Parent可以首先在onNestedPreScroll預(yù)先進(jìn)行滑動(dòng)现横。
• 最后，當(dāng)Child在處理過(guò)滑動(dòng)之后阁最，還會(huì)通知parent執(zhí)行onNestedScroll戒祠。在這里，Child沒(méi)有消耗的y軸滑動(dòng)舉例將作為參數(shù)dyUnconsumed傳入速种。

有了這些基礎(chǔ)姜盈，我們可以做的工作是：

• 在onNestedPreScroll中，如果我們自定義的ViewGroup已經(jīng)發(fā)生過(guò)滑動(dòng)配阵，那么我們需要先進(jìn)行滑動(dòng)馏颂，直到ViewGroup恢復(fù)到初始的位置。
• 反之棋傍，如果在onNestedPreScroll時(shí)救拉，ViewGroup沒(méi)有發(fā)生過(guò)滑動(dòng)，那么就沒(méi)有必要進(jìn)行預(yù)消耗瘫拣。直接讓NestedScrollingChild處理滑動(dòng)就行了亿絮。
• 最后，我們說(shuō)到在onNestedScroll中麸拄，NestedScrollingChild沒(méi)有消耗掉的滑動(dòng)距離將會(huì)通過(guò)參數(shù)dyUnconsumed傳入派昧。那么，我們要做的就是在這里把這些NestedScrollingChild沒(méi)有消耗完的距離給消耗掉感帅。

總結(jié)

好了斗锭，以上差不多就是這次對(duì)于自定義上拉加載地淀、下拉刷新控件的優(yōu)化工作的思路總結(jié)以及收獲失球。再次感嘆，閱讀源碼可能真的是一件有些藍(lán)瘦但卻又最能帶來(lái)收獲的事情了，真是叫做有苦有甜实苞。像以上談到的種種改動(dòng)豺撑，很多的啟發(fā)都來(lái)自于SwipeRefreshLayout當(dāng)中。除此之外黔牵，像當(dāng)時(shí)在閱讀當(dāng)中onMeasure的實(shí)現(xiàn)方式時(shí)聪轿，因?yàn)橐恍┘?xì)節(jié)上的困惑，同時(shí)又逼迫自己重新走了一遍Android中View的繪制流程猾浦，從而又有不少以前自己忽略掉的收獲陆错。至于本文中項(xiàng)目的源碼已經(jīng)上傳到github，如果感興趣的朋友金赦，具體的實(shí)現(xiàn)細(xì)節(jié)都可以參照源碼音瓷，多多指教。

https://github.com/RawnHwang/SmartAndroidWidgets