hehonghui / ptr-comparison

Performance comparison of android "pull to refresh" repos in github.

#下拉刷新开源库对比 目前仅比对github上star数>1500的下拉刷新开源库，在比较完成之后可能会加入其它有代表性的库.

##Repo

Repo	Owner	Star (2015.12.5)	version	Snap shot
Android-PullToRefresh (作者已停止维护)	chrisbanes	6014	latest
android-Ultra-Pull-To-Refresh	liaohuqiu	3413	1.0.11
android-pulltorefresh (作者已停止维护)	johannilsson	2414	latest
Phoenix	Yalantis	1897	1.2.3
FlyRefresh	race604	1843	2.0.0

##拓展性

|Repo|自定义顶部视图|支持的内容布局| |:--:|:--:|:--:|:---:|:--:|:--:| |Android-PullToRefresh|不支持，只能改代码。
由于仅支持其中实现的LoadingLayout作为顶视图，改代码实现自定义工作量较大。|任意视图，内置:GridView
ListView,HorizontalScrollView
ScrollView ,WebView| |android-Ultra-Pull-To-Refresh|任意视图。
通过继承PtrUIHandler并调用
PtrFrameLayout.addPtrUIHandler()得到最大支持。|任意视图|| |android-pulltorefresh|不支持，只能改代码。
代码仅一个ListView，耦合度太高，改动工作量较大。|无法扩展，自身为ListView| |Phoenix|不支持，此控件特点就是顶部视图及动画。|任意视图| |FlyRefresh|不支持，此控件特点就是顶部视图及动画。|任意视图|

##易用性

|Repo|gradle配置|上拉加载|自动加载|滑动阻尼配置| |:--:|:--:|:------:|:---:|:--:|:--:|:--:| |Android-PullToRefresh|×|√|×|移动比固定1/2| |android-Ultra-Pull-To-Refresh|√|×|√|√| |android-pulltorefresh|×|×|×|移动比固定1/1.7| |Phoenix|√|×|×|×| |FlyRefresh|√|×|×|×|

##性能分析

通过捕捉如下图中的操作持续1秒钟的systrace进行性能分析：

注：由于开源库Header大多无法直接放自定义视图，头部视图复杂程度不同，数据对比结果会有所偏差。

###1. Chris Banes's Ptr

滑动实现方式：View.post(Runnable) + View.scrollTo()

trace snapshot:

作为Github上星星数最多的Android下拉刷新控件，从性能上看（渲染时间构成）几乎没有什么明显的缺点。可惜的是作者已经不再维护，并且gradle中也无法使用。在本次demo这类层级比较简单的环境中，几乎都达到了60fps，可以与后面的trace对比。

###2. liaohuqiu's Ptr

滑动实现方式：Scroller + View.post(Runnable) + View.offsetTopAndBottom()

trace snapshot:

这套开源库可以说是自定义功能最强的组件了，美中不足的就是在下拉状态变化的时候会有一阵measure时间。我查看了一下代码，发现是PtrClassicFrameLayout的顶部视图出了问题：

看！都是wrap_content，那么当里面的内容变化的时候，是会触发View.requestLayout()的。不要小看这一个子视图的小操作，一个requestLayout()大概是这么一个流程：View.requestLayout()->ViewParent.requestLayout()->...->ViewRootImpl.requestLayout()->ViewRootImpl.doTraversal()=>MEASURE(ViewGroup)=>MEASURE(ChildView of ViewGroup)

在层级复杂的时候（大部分互联网产品由于复杂的产品需求嵌套都会比较多），它会层层向上调用，将measure时间放大至一个可观的层级。下拉刷新界面的卡顿由此而来。

我修改了一下，将其全部变为固定高度、宽度，之后的trace如下：

measure时间神奇的没掉了吧:P

###3. johannilsson's Ptr

滑动实现方式：View.setPadding()

trace snapshot:

分析：

通过顶视图调用View.setPadding()来实现的滑动，是会造成不断的requestLayout()!这就解释了为什么图中UI线程的蓝色块时间(measure时间)很明显。当你在视图层级比较复杂的app中使用它时，下拉动作所造成的开销会非常明显，卡顿是必然结果。

###4. Yalantis's Ptr

滑动实现方式：Animation + View.topAndBottomOffset()

顶部动效实现方式：Drawable的Canvas中设置偏移量及缩放。

trace snapshot:

分析：此开源库动画效果非常柔和，且顶部视图全部是通过draw去更新，不会造成第三个开源库那样的大开销问题。可惜的是比较难以去自定义顶部视图，不好在大型线上产品中使用，不过这个开源库是一个好的练手与学习的对象。由于顶部动效实现开销不大，它的性能同样非常好。

###5. race604's Ptr

滑动实现方式：View.topAndBottomOffset()

顶部动效实现方式：

• 飞机滑动 ObjectAnimator.
• 背景缩放 通过放大系数计算Path后进行draw.

trace snapshot:

分析：每次拖动都会重新计算背景"山体"与"树木"的Path，造成了draw时间过长。效果不错，也是一个好的学习对象，相比Yalantis的下拉刷新性能上就差一些了，它的draw中计算量太多。使用起来疑似bug。