SwipeRefreshLayout 引发的一场血案

关于下拉刷新这件事,无论是普通用户还是开发者都再熟悉不过了,过去的某段时间无论下拉刷新的设计还是开源控件都异常火爆,火爆到惊动了党中央(Google),所以党中央就自己在支持包里面增加了一个下拉刷新的控件——SwipeRefreshLayout,这个下拉的效果非常的别致,堪称低调的华丽,先随便来张图吧,相信大家都不陌生。至于SwipeRefreshLayout怎么用就不讲了,不知道的自觉面壁去。

1187237-1cf88590c313fa04

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引起的。自己挖的坑,把自己埋进去也要给填上。

上面这个类了了数行,只是做了些统一的初始化操作,却引起了一些问题,给你三分钟你能看出问题所在吗?

问题就出在init()方法中的setRefreshing(true);这一句。写的时候是这么想的,界面一进去就要loading了,那我干脆把loading加在Base里了。这样就不用每个界面再写一遍了。但是由于我上述的场景里用了懒加载,所以问题就来了:虽然我停留在第一个页面,但是第二个页面的View已经初始化完成,那么自然SwipeRefreshLayout的那个loading的圈圈已经在不停的转动了,所以cpu就开始非常线性的居高不下了,切换到第二页,数据加载完成之后setRefreshing(false),那个loading的圈圈消失,cpu又恢复了正常。费了一番功夫,好在最后还是把坑填上了。另外没预料到的一点是,原来SwipeRefreshLayout也不怎么省油。

实际开发过程中难的不是如何解决问题,而是如何排查和定位问题。大多数情况下,我们可以凭借自己的积累和经验迅速定位问题。而这次自己挖的坑着实隐蔽,费了好大一番功夫,从JAVA代码到Xml几乎是一行一行去排查,最后还是把坑填上了。那开发中还是要考虑的全面一些,少挖坑,那如果真的发现有坑,也是有套路可寻的,仔细分析问题,从JAVA代码到xml逐步排查,总归会豁然开朗的。

1 1 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部