关于下拉刷新这件事，无论是普通用户还是开发者都再熟悉不过了，过去的某段时间无论下拉刷新的设计还是开源控件都异常火爆，火爆到惊动了党中央(Google)，所以党中央就自己在支持包里面增加了一个下拉刷新的控件——SwipeRefreshLayout，这个下拉的效果非常的别致，堪称低调的华丽，先随便来张图吧，相信大家都不陌生。至于SwipeRefreshLayout怎么用就不讲了，不知道的自觉面壁去。
Swiperefreshlayout.gif
那作为Material Design的坚决拥护者，实战中我也大刀阔斧的用起了SwipeRefreshLayout，简单的写了个BaseSwipeRefreshLayout类初始化了一些基本属性，因为本身就很好用，所以也没做太多封装。有需要用到下拉刷新的，就直接在布局里引用这个Base类，但没想到却因此埋了一个坑，引发了一场血案。当然并不是说Base类本身代码有什么错误，而是因为一些奇妙的组合引起了一些狗血的bug，且听我继续往下八。
实际的开发中，基本上Activity、Fragment都用上了这个下拉刷新。我的首页是一个Activity通过ViewPager维护4个Fragment的这种经典设计，其中第一页和第二页有用到下拉刷新，Fragment采用懒加载的方式，关于懒加载可以看我的另一篇文章 ViewPager+Fragment LazyLoad最优解。这代码绝壁不会有问题，一切看起来都是那么美好!飘柔，就是这么自信。然而忽然有一天发现了一个无法解释的现象：当我启动App停留在第一页的时候，即便静止不动，cpu利用率还是很高，而且非常线性，几乎没什么波动。切到第二页，数据加载出来后，cpu利用率立马就下去了。我当时就呵呵了。
于是乎开始排查优化，经过简单的分析，基本上可以确定问题出在第二页上，不巧的是我的第二页布局炒鸡复杂，顶部是个自动轮播大图，然后是两个横向的RecyclerView，最后还有一个纵向的RecyclerView，当然这中间还嵌套夹杂着一些小的视图。再来分析下问题：进入App停在首页，因为懒加载，所以第二页的View已经初始化完成，但是还没有loadData，这个时候cpu利用率很高，再切到第二页loadData完成，cpu利用率马上恢复正常。而且如果我不采用懒加载的方式去加载Fragment就不会有这个问题，那首先我就怀疑是不是我这个懒加载写的有问题，debug跟了一遍，发现一切正常，并没有发现不合理的地方。
根据老司机的经验判断，既然cpu一直居高不下，那很有可能是某个view一直在测量计算。那这里嫌疑最大的就是RecyclerView，但是我这里有三个RecyclerView，只能通过排除法，一个一个注掉然后再观察cpu情况，然而意外的是即便我把他们全都注掉也没有什么用，那看来并不是View反复测量引起的问题。那这个时候矛头就直指顶部的轮播大图了，轮播图是可以自动滚动，并且无限循环的，那有可能是哪里控制的不太合理，或者timer用的有问题。似乎看见曙光了，问题应该就在这里，于是乎我把轮播图也注释掉再看。我去，仍然没什么卵用。
问题似乎陷入了僵局，按照正常的剧情发展，这个时候我应该下楼点根烟，边抽烟边和同事交流交流，然后深吸一口，吐出淡蓝色的烟雾，看着青烟徐徐上升冥思苦想，忽然大喊一声：我知道了。然后狠狠的掐灭烟头飞奔上楼，留下同事在烟雾缭绕中凌乱不堪。但实际情况是：我并不抽烟。既然这个时候不能凭主观经验迅速定位问题，那就只能采用笨办法了。依然是排除法，我把所有有嫌疑的代码都一行行注释掉，到最后我几乎把整个类都注释掉了，debug进来后已然没有什么代码需要执行了，只是加载了一个布局。但是，我已经不想再说但是了。
JAVA代码排查个遍，依然没有定位到问题，老司机已经有点不淡定了，难道是布局的问题?OverDraw?一切都是猜测，只能硬着头皮一个View一个View的去排除，然而让我万万没想到的是最后揪出来元凶，居然是上面提到的我自己写的那个BaseSwipeRefreshLayout引起的。自己挖的坑，把自己埋进去也要给填上。
- public class BaseSwipeRefreshLayout extends SwipeRefreshLayout {
- public BaseSwipeRefreshLayout(Context context) {
- super(context);
- init();
- }
- public BaseSwipeRefreshLayout(Context context, AttributeSet attrs) {
- super(context, attrs);
- init();
- }
- private void init() {
- this.setProgressViewOffset(false, DensityUtil.dip2px(getContext(), -50), DensityUtil.dip2px(getContext(), 30));
- this.setColorSchemeColors(getContext().getResources().getColor(R.color.primary_green));
- setRefreshing(true);
- }
- @Override
- public boolean onStartNestedScroll(View child, View target, int nestedScrollAxes) {
- return !isRefreshing() && super.onStartNestedScroll(child, target, nestedScrollAxes);
- }
- }
上面这个类了了数行，只是做了些统一的初始化操作，却引起了一些问题，给你三分钟你能看出问题所在吗?
问题就出在init()方法中的setRefreshing(true);这一句。写的时候是这么想的，界面一进去就要loading了，那我干脆把loading加在Base里了。这样就不用每个界面再写一遍了。但是由于我上述的场景里用了懒加载，所以问题就来了：虽然我停留在第一个页面，但是第二个页面的View已经初始化完成，那么自然SwipeRefreshLayout的那个loading的圈圈已经在不停的转动了，所以cpu就开始非常线性的居高不下了，切换到第二页，数据加载完成之后setRefreshing(false)，那个loading的圈圈消失，cpu又恢复了正常。费了一番功夫，好在最后还是把坑填上了。另外没预料到的一点是，原来SwipeRefreshLayout也不怎么省油。
实际开发过程中难的不是如何解决问题，而是如何排查和定位问题。大多数情况下，我们可以凭借自己的积累和经验迅速定位问题。而这次自己挖的坑着实隐蔽，费了好大一番功夫，从JAVA代码到Xml几乎是一行一行去排查，最后还是把坑填上了。那开发中还是要考虑的全面一些，少挖坑，那如果真的发现有坑，也是有套路可寻的，仔细分析问题，从JAVA代码到xml逐步排查，总归会豁然开朗的。
