开发笔记之打造通用下拉刷新（介绍篇）
开发笔记之打造通用下拉刷新（细节篇）
开发笔记之打造通用下拉刷新（重难点篇）
在开始写代码前，我们要明白它的基本需求是什么，既然是打造通用的下拉刷新，那就要看看平时常见的刷新是怎样的。从大方面说（当然不包括所有的情况，这里只是列举最常见的几种）。
- 按位置变化分类：固定头部、固定内容、刷新时隐藏头部
- 按触发条件分类：下拉触发和释放触发
但是从一些细节的体验上，其实有很多方面可以考虑。比如，刷新时是否可以拖动、刷新完成是否强制上升、还有手指移动的连贯性和动画与滑动的冲突处理等。而代码里的各种布尔变量和条件判断就是为了处理这些细节
开始前先讲清两个概念
- 触发线，在下拉刷新模式下，刷新触发时头部的高度，ThresholdHeight
- 刷新线，松开手后的正在刷新高度，RefreshingHeight
刷新时是否可以拖动
我发现，绝大部分的应用在刷新时都是继续可以拖动头部的， 但是也有例外，比如安卓自带的SwipeRefreshLayout，在PullToRefreshLayout（下简称Prtlayout）中对应的是pinContent模式。既然要打造通用下拉刷新，那么就要考虑这两种情况。
- 刷新时不可以拖动
这意味着，开始刷新后，ptrLayout就不再处理任何触摸事件，而是直接交给下层去处理，直到刷新完成头部完全隐藏，实际上SwipeRefreshLayout也是这么做的，它的刷新模式为释放刷新。但是当刷新模式为下拉刷新时（达到触发线立即刷新），会出现小问题：下拉刚达到触发线，立即开始刷新，如果ptrLayout从此不再处理任何事件，那头部将一直停在触发线刷新而不是在刷新线刷新，这里就又多出了两个选择：
1.开始刷新后强制回到刷新线;
2.ptrLayout并不是不处理任何事件，而是要处理action_up事件，在松开手后判断是否要回到刷新线。
在ptrLayout里两种方案都有实现，这也是为什么会有mCanScrollWhenRefreshing 和mUpToRefredshingImmediately这两个布尔成员变量和对应的接口
- 刷新时可以拖动
这通常是大部分的应用的做法。刷新时可以拖动，意味着我们时时都要监控着MotionEvent，在拖动的时候将其拦截。具体表现为：头部处于正在刷新状态时，头部依然会随着手指下拉而向下移动，（关键点）这时候头部会再次超过刷新线，如果当前是下拉刷新的话，我们就不能重复触发刷新，所以就会有一个isRefreshing变量，代表当前是否正在刷新，在触发下拉刷新时作判断。另外，在下拉之后，（关键点）松开手后Header要回到刷新线，如果在松开手之前刷新已经完成怎么办？
我们又面临两个选择:
1.不等松手，头部强制升回顶部（我个人觉得这是一种不太好的体验，但确实有应用是这么做的，比如网易新闻）
2.在松手之后再回到顶部
(这两种情况ptrLayout都有实现，强制上升对应mForceToTopWhenFinish成员。)
先说第一种情况，既然是强制，意味着上升动画执行过程中ptrLayout不再处理触摸事件，所以我们应该在触摸事件响应中判断如果开启”强制返回“****且****强制上升的动画正在执行,则不拦截事件。
再说松手之后再回到顶部的情况，当我们松手的时候，怎么知道要升回到刷新线还是升回顶部呢？自然而然就要有一个IsFinish的变量去表示当前是否已经刷新完成，来决定松手后的上升位置。接着，现在手指松开了，header开始上升，那么又会引出一个问题：上升的时候手指又拖动怎么办？无非又是两种情况，****强制与不强制****，因为之前已经有强制与不强制的选择了，所以在ptrLayout实现中，这里是选择不强制，意味着****手指再次按下时上升的动画要取消****（真是纠结-_-#）
如果不取消，上升动画和手指拖动同时进行的话，就会出现画面抖动，是个糟糕的体验。
下拉事件与子view滑动的衔接
这是另外一个小细节，标题可能比较说得比较抽象，看下面两个例子就知道了。
这两个的区别并不是十分影响体验，不过实现总比不实现强，要实现这种衔接的效果，意味着在一次手指按下、拖动再松开的动作中，父布局需要动态判断事件的消费者并灵活控制事件的传递，父布局可能会拦截部分事件，然后向下传递部分事件，再拦截部分事件，由于篇幅原因，具体逻辑留到下一篇再讨论。
最后
即使是简单的下拉也会有很多小细节，为了实现所谓的通用刷新，我把一些细节都写成了可配置的项。当然还有更多可以考虑的地方，不过从技术上来说都是增加判断而已，所以就没必要扯太多了，下一篇文章（也是最后一篇）将讲一下代码实现的过程中遇到的一些问题与难点。
