[[185980]]

關(guān)于下拉刷新這件事，無(wú)論是普通用戶還是開發(fā)者都再熟悉不過了，過去的某段時(shí)間無(wú)論下拉刷新的設(shè)計(jì)還是開源控件都異?；鸨?，火爆到驚動(dòng)了黨中央(Google)，所以黨中央就自己在支持包里面增加了一個(gè)下拉刷新的控件——SwipeRefreshLayout，這個(gè)下拉的效果非常的別致，堪稱低調(diào)的華麗，先隨便來張圖吧，相信大家都不陌生。至于SwipeRefreshLayout怎么用就不講了，不知道的自覺面壁去。 

Swiperefreshlayout.gif

那作為Material Design的堅(jiān)決擁護(hù)者，實(shí)戰(zhàn)中我也大刀闊斧的用起了SwipeRefreshLayout，簡(jiǎn)單的寫了個(gè)BaseSwipeRefreshLayout類初始化了一些基本屬性，因?yàn)楸旧砭秃芎糜?，所以也沒做太多封裝。有需要用到下拉刷新的，就直接在布局里引用這個(gè)Base類，但沒想到卻因此埋了一個(gè)坑，引發(fā)了一場(chǎng)血案。當(dāng)然并不是說Base類本身代碼有什么錯(cuò)誤，而是因?yàn)橐恍┢婷畹慕M合引起了一些狗血的bug，且聽我繼續(xù)往下八。

實(shí)際的開發(fā)中，基本上Activity、Fragment都用上了這個(gè)下拉刷新。我的首頁(yè)是一個(gè)Activity通過ViewPager維護(hù)4個(gè)Fragment的這種經(jīng)典設(shè)計(jì)，其中***頁(yè)和第二頁(yè)有用到下拉刷新，F(xiàn)ragment采用懶加載的方式，關(guān)于懶加載可以看我的另一篇文章 ViewPager+Fragment LazyLoad***解。這代碼絕壁不會(huì)有問題，一切看起來都是那么美好!飄柔，就是這么自信。然而忽然有一天發(fā)現(xiàn)了一個(gè)無(wú)法解釋的現(xiàn)象：當(dāng)我啟動(dòng)App停留在***頁(yè)的時(shí)候，即便靜止不動(dòng)，cpu利用率還是很高，而且非常線性，幾乎沒什么波動(dòng)。切到第二頁(yè)，數(shù)據(jù)加載出來后，cpu利用率立馬就下去了。我當(dāng)時(shí)就呵呵了。

于是乎開始排查優(yōu)化，經(jīng)過簡(jiǎn)單的分析，基本上可以確定問題出在第二頁(yè)上，不巧的是我的第二頁(yè)布局炒雞復(fù)雜，頂部是個(gè)自動(dòng)輪播大圖，然后是兩個(gè)橫向的RecyclerView，***還有一個(gè)縱向的RecyclerView，當(dāng)然這中間還嵌套夾雜著一些小的視圖。再來分析下問題：進(jìn)入App停在首頁(yè)，因?yàn)閼屑虞d，所以第二頁(yè)的View已經(jīng)初始化完成，但是還沒有l(wèi)oadData，這個(gè)時(shí)候cpu利用率很高，再切到第二頁(yè)loadData完成，cpu利用率馬上恢復(fù)正常。而且如果我不采用懶加載的方式去加載Fragment就不會(huì)有這個(gè)問題，那首先我就懷疑是不是我這個(gè)懶加載寫的有問題，debug跟了一遍，發(fā)現(xiàn)一切正常，并沒有發(fā)現(xiàn)不合理的地方。

根據(jù)老司機(jī)的經(jīng)驗(yàn)判斷，既然cpu一直居高不下，那很有可能是某個(gè)view一直在測(cè)量計(jì)算。那這里嫌疑***的就是RecyclerView，但是我這里有三個(gè)RecyclerView，只能通過排除法，一個(gè)一個(gè)注掉然后再觀察cpu情況，然而意外的是即便我把他們?nèi)甲⒌粢矝]有什么用，那看來并不是View反復(fù)測(cè)量引起的問題。那這個(gè)時(shí)候矛頭就直指頂部的輪播大圖了，輪播圖是可以自動(dòng)滾動(dòng)，并且***循環(huán)的，那有可能是哪里控制的不太合理，或者timer用的有問題。似乎看見曙光了，問題應(yīng)該就在這里，于是乎我把輪播圖也注釋掉再看。我去，仍然沒什么卵用。

問題似乎陷入了僵局，按照正常的劇情發(fā)展，這個(gè)時(shí)候我應(yīng)該下樓點(diǎn)根煙，邊抽煙邊和同事交流交流，然后深吸一口，吐出淡藍(lán)色的煙霧，看著青煙徐徐上升冥思苦想，忽然大喊一聲：我知道了。然后狠狠的掐滅煙頭飛奔上樓，留下同事在煙霧繚繞中凌亂不堪。但實(shí)際情況是：我并不抽煙。既然這個(gè)時(shí)候不能憑主觀經(jīng)驗(yàn)迅速定位問題，那就只能采用笨辦法了。依然是排除法，我把所有有嫌疑的代碼都一行行注釋掉，到***我?guī)缀醢颜麄€(gè)類都注釋掉了，debug進(jìn)來后已然沒有什么代碼需要執(zhí)行了，只是加載了一個(gè)布局。但是，我已經(jīng)不想再說但是了。

JAVA代碼排查個(gè)遍，依然沒有定位到問題，老司機(jī)已經(jīng)有點(diǎn)不淡定了，難道是布局的問題?OverDraw?一切都是猜測(cè)，只能硬著頭皮一個(gè)View一個(gè)View的去排除，然而讓我萬(wàn)萬(wàn)沒想到的是***揪出來元兇，居然是上面提到的我自己寫的那個(gè)BaseSwipeRefreshLayout引起的。自己挖的坑，把自己埋進(jìn)去也要給填上。

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); 
 
    } 
 
}  

上面這個(gè)類了了數(shù)行，只是做了些統(tǒng)一的初始化操作，卻引起了一些問題，給你三分鐘你能看出問題所在嗎?

問題就出在init()方法中的setRefreshing(true);這一句。寫的時(shí)候是這么想的，界面一進(jìn)去就要loading了，那我干脆把loading加在Base里了。這樣就不用每個(gè)界面再寫一遍了。但是由于我上述的場(chǎng)景里用了懶加載，所以問題就來了：雖然我停留在***個(gè)頁(yè)面，但是第二個(gè)頁(yè)面的View已經(jīng)初始化完成，那么自然SwipeRefreshLayout的那個(gè)loading的圈圈已經(jīng)在不停的轉(zhuǎn)動(dòng)了，所以cpu就開始非常線性的居高不下了，切換到第二頁(yè)，數(shù)據(jù)加載完成之后setRefreshing(false)，那個(gè)loading的圈圈消失，cpu又恢復(fù)了正常。費(fèi)了一番功夫，好在***還是把坑填上了。另外沒預(yù)料到的一點(diǎn)是，原來SwipeRefreshLayout也不怎么省油。

實(shí)際開發(fā)過程中難的不是如何解決問題，而是如何排查和定位問題。大多數(shù)情況下，我們可以憑借自己的積累和經(jīng)驗(yàn)迅速定位問題。而這次自己挖的坑著實(shí)隱蔽，費(fèi)了好大一番功夫，從JAVA代碼到Xml幾乎是一行一行去排查，***還是把坑填上了。那開發(fā)中還是要考慮的全面一些，少挖坑，那如果真的發(fā)現(xiàn)有坑，也是有套路可尋的，仔細(xì)分析問題，從JAVA代碼到xml逐步排查，總歸會(huì)豁然開朗的。