android自定义刷新和加载更多,Android 打造专属的下拉刷新 加载更多

最近忙成狗...

前面都有文章写怎么去实现加载下拉刷新和加载更多，这篇文章会接着讲，所以没有看的，可以先看看哟。

现在MD的设计风格逐渐在被接受，Android 对应的嵌套滑动机制下的

CoordinatorLayout  AppBarLayout  CollapsingToolbarLayout 等都在被大量使用了。

其实，我觉得 SwipeRefreshLayout  这种刷新效果就很好了，简约又不简单。一看就知道是 Android 的。但是，总会有老板或者产品要么是根本就不玩 Android 的，要么就是要标新立异的，一定要弄一个怎样怎样炫酷的下拉刷新效果。那你怎么办，吐完槽还是要撸代码咯。现在就业形势这么严峻，你还敢不老实？？哈哈，开个玩笑。

所以说，支持嵌套滑动的下拉刷新加载更多是迫在眉睫啊。

对比 iOS， Android 不是天然支持下拉刷新这种东西的，之前的文章已经讨论过，现在的下拉刷新效果其实都是先把 Header 隐藏起来，根据手势，将它有展示出来。前面说过了通过  margin，或者 translationY 的方式。今天讲讲另外一种方式，就是在 layout() 的时候控制它的摆放位置，然后通过 scroll() 的方式控制其展示。

先看 onLayout() 的方法：@Overrideprotected void onLayout(boolean changed, int l, int t, int r, int b) {    int contentHeight = 0;    int width = getMeasuredWidth();    int height = getMeasuredHeight();    int childLeft = getPaddingLeft();    int childRight = getPaddingLeft();    int childTop = getPaddingTop();    int childWidth = width - childLeft - childRight;    int childHeight;

View child;    if (header != null) {

child = header;

headerHeight = child.getMeasuredHeight();        //藏起header

child.layout(childLeft, childTop - headerHeight, childLeft + childWidth, childTop);

}    //make sure there is the target!

if (mTarget == null) {

ensureTarget();

}    if (mTarget == null) {        return;

}

child = mTarget;

childLeft = getPaddingLeft();

childTop = getPaddingTop();

childWidth = width - getPaddingLeft() - getPaddingRight();

childHeight = height - getPaddingTop() - getPaddingBottom();

child.layout(childLeft, childTop, childLeft + childWidth, childTop + childHeight);

contentHeight += child.getMeasuredHeight();    if (footer != null) {

child = footer;

footHeight = child.getMeasuredHeight();

child.layout(0, contentHeight, child.getMeasuredWidth(), contentHeight + footHeight);

}    // 滚动到bottom

bottomScroll = contentHeight - getMeasuredHeight();

}

这样之后，下拉刷新布局和加载更多的布局都隐藏起来了。因为是要打造专属的下来刷新和加载更多嘛，所以，这里的 Header 和 Footer 都是咱们自己定义然后传进去的。 mTarget 顾名思义就是需要滚动的的控件了，比如说是 RecyclerView 或者巴拉巴拉了。

嵌套滑动机制

之前都聊过这个了，大概意思就是，在这个之前， Android 的事件分发j简单来说就是从 ViewGroup 到  View，如果 View 不消费，那么又返回给 ViewGroup 让它消费。这里就存在一个问题：「饿死了爸爸，撑死了孩纸」。如果这个事件我们可以让 View 它爸消费一点，剩下的很多都自己消费，这样是不是最好了？所以，嵌套滑动的机制就出现了。

这样，在事件传递到 View 后，在 View 消费事件之前，总会关心的问问它爸爸，你到底要来一点儿不？都是一家人，千万别客气。然后父子俩就其乐融融，谁都饿不死了。

这里就有了 NestedScrollingParent , NestedScrollingChild 这两个接口。看这个名字都知道，这个就是爸爸和孩纸的关系嘛。

这里再来看我们要实现的刷新，它是 RecyclerView  NestedScrollView

的爸爸，但是有时 CoordinatorLayout 等的孩纸，所以，它就是又当爹，又是孩纸，它孩纸的事件在问它需要先消费点儿不的时候它作为孩纸也要按照惯例去问问 CoordinatorLayout 它爸爸是不是要来一点儿，嗯，满满的和谐社会啊。好了，说的这么形象了，应该没有谁不懂吧。

还是先来看看 RecyclerView 的代码吧。case MotionEvent.ACTION_MOVE: {            final int index = e.findPointerIndex(mScrollPointerId);            if (index 

Log.e(TAG, "Error processing scroll; pointer index for id " +

mScrollPointerId + " not found. Did any MotionEvents get skipped?");                return false;

}            final int x = (int) (e.getX(index) + 0.5f);            final int y = (int) (e.getY(index) + 0.5f);            int dx = mLastTouchX - x;            int dy = mLastTouchY - y;            //划重点，先问问爸爸要不要消费

if (dispatchNestedPreScroll(dx, dy, mScrollConsumed, mScrollOffset)) {

dx -= mScrollConsumed[0];

dy -= mScrollConsumed[1];

vtev.offsetLocation(mScrollOffset[0], mScrollOffset[1]);                // Updated the nested offsets

mNestedOffsets[0] += mScrollOffset[0];

mNestedOffsets[1] += mScrollOffset[1];

}

在自己消费之前，先问爸爸要不要消费。如果消费了，这个dispatchNestedPreScroll() 将会返回 true , 然后就将爸爸消费了的值减出去，剩下就是自己可以使用的了。到这里，事件是到 RecyclerView 了 ，但是它压根还没有消费任何事件。if (mScrollState == SCROLL_STATE_DRAGGING) {

mLastTouchX = x - mScrollOffset[0];

mLastTouchY = y - mScrollOffset[1];                if (scrollByInternal(

canScrollHorizontally ? dx : 0,

canScrollVertically ? dy : 0,

vtev)) {

getParent().requestDisallowInterceptTouchEvent(true);

}                if (mGapWorker != null && (dx != 0 || dy != 0)) {

mGapWorker.postFromTraversal(this, dx, dy);

}

}

到这里，RecyclerView 终于调用了 scrollByInternal() 开始消费事件啦。接着看看这个方法的详细代码。boolean scrollByInternal(int x, int y, MotionEvent ev) {    int unconsumedX = 0, unconsumedY = 0;    int consumedX = 0, consumedY = 0;

consumePendingUpdateOperations();

...    if (dispatchNestedScroll(consumedX, consumedY, unconsumedX, unconsumedY, mScrollOffset)) {        // Update the last touch co-ords, taking any scroll offset into account

mLastTouchX -= mScrollOffset[0];

mLastTouchY -= mScrollOffset[1];        if (ev != null) {

ev.offsetLocation(mScrollOffset[0], mScrollOffset[1]);

}

mNestedOffsets[0] += mScrollOffset[0];

mNestedOffsets[1] += mScrollOffset[1];

}

....    return consumedX != 0 || consumedY != 0;

}

滑动的还是，又得调用 dispatchNestedScroll() 方法来问问爸爸，我真的可以消费了哇？然后事件有传给了爸爸，爸爸如果消费了，又返回 true，那么又需要将已经消费了减掉，然后才是自己可以消费的了。

这说明了啥？ RecyclerView 真是个孝顺听话的好孩纸啊，不过也好惨啊，到嘴的肉的被会被爸爸吃了，心疼它一秒钟。

好了，到我们的下拉刷新这里，第一点，我们也要当孩纸，但是我们不能像 RecyclerView  那么听话孝顺，我们的原则是只要事件孩纸传递给我了，我要优先消费，而不是优先去问爸爸要不要消费，如果自己不能消费，或者已经吃饱了，那么这个事件才去询问爸爸要不要消费。private final int[] mParentScrollConsumed = new int[2];private final int[] mParentOffsetInWindow = new int[2];private int mTotalUnconsumed;private int mTotalUnconsumedLoadMore;@Overridepublic void onNestedPreScroll(View target, int dx, int dy, int[] consumed) {    // If we are in the middle of consuming, a scroll, then we want to move the spinner back up

// before allowing the list to scroll

if (refreshEnable && header != null && !isRefreshing && currentStatus == STATE_REFRESH && dy > 0 && mTotalUnconsumed > 0) {

mTotalUnconsumed -= dy;        if (mTotalUnconsumed <= 0) {//over

mTotalUnconsumed = 0;

dy = (int) (-getScrollY() / DRAG_RATE);

}

goToRefresh(-dy);

consumed[1] = dy;

}    if (loadEnable && !isLoading && footer != null && dy = bottomScroll && mTotalUnconsumedLoadMore > 0 && currentStatus == STATE_LOADMORE) {

mTotalUnconsumedLoadMore += dy;

goToLoad(dy);

consumed[1] = dy;

}    // 最后，我们再去问问爸爸需要消费事件不。

final int[] parentConsumed = mParentScrollConsumed;    if (dispatchNestedPreScroll(dx - consumed[0], dy - consumed[1], parentConsumed, null)) {

consumed[0] += parentConsumed[0];

consumed[1] += parentConsumed[1];

}

}

请注意，上面这个都是针对在下拉后回退的情况(onNestedPreScroll()方法中的情况。)，意思就是说，如果我现在 Header已经拉出来了，然后又向上滑动，这个时候肯定要优先先隐藏 Header，然后剩下的才让CoordinatorLayout 等爸爸去消费。

但是但是如果是在下来的过程呢？这个时候还是应该先问问爸爸要不要消费，因为你不能在下拉的头都出现完了之后再去把 AppBarLayout 等展开吧，肯定是先先展开它们，最后才是下来刷新。@Overridepublic void onNestedScroll(View target, int dxConsumed, int dyConsumed,                           int dxUnconsumed, int dyUnconsumed) {    // Dispatch up to the nested parent first

dispatchNestedScroll(dxConsumed, dyConsumed, dxUnconsumed, dyUnconsumed,

mParentOffsetInWindow);    final int dy = dyUnconsumed + mParentOffsetInWindow[1];    if (refreshEnable && header != null && dy 

mTotalUnconsumed += Math.abs(dy);        if (currentStatus == STATE_DEFAULT || mTotalUnconsumed != 0)

currentStatus = STATE_REFRESH;

goToRefresh(Math.abs(dy));

}    if (loadEnable && (isAutoLoad || footer != null) && getScrollY() >= bottomScroll && dy > 0 && !isLoading && mTotalUnconsumedLoadMore <= 4 * footHeight) {

mTotalUnconsumedLoadMore += dy;        if (currentStatus == STATE_DEFAULT || mTotalUnconsumedLoadMore != 0)

currentStatus = STATE_LOADMORE;

goToLoad(dy);

}

}

到这里，嵌套机制基本上就说完了。对于加载更多，原理类似，不在分析代码。

具体滑动

至于具体的滑动，就是上面的两个方法所示，一个 goToRefresh() 用于下拉，一个 goToLoad() 用于加载更多，最后都是调用 scrollBy() 的方法。

状态回调

因为 Header 和 Footer  都是传入的嘛，所以在滑动的过程中，需要把相关状态通知到吧，然后就可以显示出 下拉刷新、松开刷新、正在刷新等状态了吧。public interface HeaderListener {void onRefreshBefore(int scrollY, int headerHeight);void onRefreshAfter(int scrollY, int headerHeight);void onRefreshReady(int scrollY, int headerHeight);void onRefreshing(int scrollY, int headerHeight);void onRefreshComplete(int scrollY, int headerHeight, boolean isRefreshSuccess);void onRefreshCancel(int scrollY, int headerHeight);int getRefreshHeight();

}

这里来定义了 HeaderListener 的接口，这个就需要对应的 Header 来实现，然后就可以得到是是的状态回调了。 getRefreshHeight()  该方法定义什么高度就可以执行松手刷新了。系统默认的是 Header 的高度。

布局

android:id="@+id/refresh_layout"

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

>

android:id="@+id/recycler"

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

tools:context="com.lovejjfg.demo.MainActivity">

相关方法调用mRefreshLayout.setOnRefreshListener(new OnRefreshListener() {        @Override

public void onRefresh() {

mRefreshLayout.postDelayed(new Runnable() {                @Override

public void run() {                    //刷新完毕

mRefreshLayout.stopRefresh(true);

}

}, 1000);

}        @Override

public void onLoadMore() {

mRefreshLayout.postDelayed(new Runnable() {                @Override

public void run() {

mRefreshLayout.stopLoadMore(true);

List mlist = new ArrayList<>();                    for (int i = 0; i 

mlist.add("nice" + i);

}

mAdapter.appendList(mlist);                    //是否还能加载更多

mRefreshLayout.setLoadEnable(mAdapter.getList().size() 

}

}, 1000);

}

});

CircleHeaderView header = new CircleHeaderView(getContext());

FootView footView = new FootView(getContext());    //添加 header

mRefreshLayout.addHeader(header);    //添加 footer

mRefreshLayout.addFooter(footView);

如果进入页面需要显示出下拉刷新，可以调用：mRefreshLayout.setAutoRefresh(true);

如果不需要Footer，但是需要加载更多，可以调用：mRefreshLayout.setAutoLoadMore(true);

刷新完毕Header会马上隐藏上去，如果需要延迟的话，可以调用：mRefreshLayout.stopRefresh(true，5000);

一般项目的下拉刷新加载更多就是一套，每次都去调用 addHeader() 或者 addFooter() 就会很烦躁了，这时候你应该考虑继承自PowerRefreshLayout，将 Header 和 Footer 直接初始化好。

项目地址

作者：lovejjfg

链接：https://www.jianshu.com/p/e46f72ce69c4