SwipeRefreshLayout引發(fā)的一場血案
關(guān)于下拉刷新這件事，無論是普通用戶還是開發(fā)者都再熟悉不過了，過去的某段時間無論下拉刷新的設(shè)計還是開源控件都異常火爆，火爆到驚動了黨中央(Google)，所以黨中央就自己在支持包里面增加了一個下拉刷新的控件——SwipeRefreshLayout，這個下拉的效果非常的別致，堪稱低調(diào)的華麗，先隨便來張圖吧，相信大家都不陌生。至于SwipeRefreshLayout怎么用就不講了，不知道的自覺面壁去。
Swiperefreshlayout.gif
那作為Material Design的堅決擁護者，實戰(zhàn)中我也大刀闊斧的用起了SwipeRefreshLayout，簡單的寫了個BaseSwipeRefreshLayout類初始化了一些基本屬性，因為本身就很好用，所以也沒做太多封裝。有需要用到下拉刷新的，就直接在布局里引用這個Base類，但沒想到卻因此埋了一個坑，引發(fā)了一場血案。當然并不是說Base類本身代碼有什么錯誤，而是因為一些奇妙的組合引起了一些狗血的bug，且聽我繼續(xù)往下八。
實際的開發(fā)中，基本上Activity、Fragment都用上了這個下拉刷新。我的首頁是一個Activity通過ViewPager維護4個Fragment的這種經(jīng)典設(shè)計，其中***頁和第二頁有用到下拉刷新，F(xiàn)ragment采用懶加載的方式，關(guān)于懶加載可以看我的另一篇文章 ViewPager+Fragment LazyLoad***解。這代碼絕壁不會有問題，一切看起來都是那么美好!飄柔，就是這么自信。然而忽然有一天發(fā)現(xiàn)了一個無法解釋的現(xiàn)象：當我啟動App停留在***頁的時候，即便靜止不動，cpu利用率還是很高，而且非常線性，幾乎沒什么波動。切到第二頁，數(shù)據(jù)加載出來后，cpu利用率立馬就下去了。我當時就呵呵了。
于是乎開始排查優(yōu)化，經(jīng)過簡單的分析，基本上可以確定問題出在第二頁上，不巧的是我的第二頁布局炒雞復(fù)雜，頂部是個自動輪播大圖，然后是兩個橫向的RecyclerView，***還有一個縱向的RecyclerView，當然這中間還嵌套夾雜著一些小的視圖。再來分析下問題：進入App停在首頁，因為懶加載，所以第二頁的View已經(jīng)初始化完成，但是還沒有l(wèi)oadData，這個時候cpu利用率很高，再切到第二頁loadData完成，cpu利用率馬上恢復(fù)正常。而且如果我不采用懶加載的方式去加載Fragment就不會有這個問題，那首先我就懷疑是不是我這個懶加載寫的有問題，debug跟了一遍，發(fā)現(xiàn)一切正常，并沒有發(fā)現(xiàn)不合理的地方。
根據(jù)老司機的經(jīng)驗判斷，既然cpu一直居高不下，那很有可能是某個view一直在測量計算。那這里嫌疑***的就是RecyclerView，但是我這里有三個RecyclerView，只能通過排除法，一個一個注掉然后再觀察cpu情況，然而意外的是即便我把他們?nèi)甲⒌粢矝]有什么用，那看來并不是View反復(fù)測量引起的問題。那這個時候矛頭就直指頂部的輪播大圖了，輪播圖是可以自動滾動，并且***循環(huán)的，那有可能是哪里控制的不太合理，或者timer用的有問題。似乎看見曙光了，問題應(yīng)該就在這里，于是乎我把輪播圖也注釋掉再看。我去，仍然沒什么卵用。
問題似乎陷入了僵局，按照正常的劇情發(fā)展，這個時候我應(yīng)該下樓點根煙，邊抽煙邊和同事交流交流，然后深吸一口，吐出淡藍色的煙霧，看著青煙徐徐上升冥思苦想，忽然大喊一聲：我知道了。然后狠狠的掐滅煙頭飛奔上樓，留下同事在煙霧繚繞中凌亂不堪。但實際情況是：我并不抽煙。既然這個時候不能憑主觀經(jīng)驗迅速定位問題，那就只能采用笨辦法了。依然是排除法，我把所有有嫌疑的代碼都一行行注釋掉，到***我?guī)缀醢颜麄€類都注釋掉了，debug進來后已然沒有什么代碼需要執(zhí)行了，只是加載了一個布局。但是，我已經(jīng)不想再說但是了。
JAVA代碼排查個遍，依然沒有定位到問題，老司機已經(jīng)有點不淡定了，難道是布局的問題?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);
- }
- }
上面這個類了了數(shù)行，只是做了些統(tǒng)一的初始化操作，卻引起了一些問題，給你三分鐘你能看出問題所在嗎?
問題就出在init()方法中的setRefreshing(true);這一句。寫的時候是這么想的，界面一進去就要loading了，那我干脆把loading加在Base里了。這樣就不用每個界面再寫一遍了。但是由于我上述的場景里用了懶加載，所以問題就來了：雖然我停留在***個頁面，但是第二個頁面的View已經(jīng)初始化完成，那么自然SwipeRefreshLayout的那個loading的圈圈已經(jīng)在不停的轉(zhuǎn)動了，所以cpu就開始非常線性的居高不下了，切換到第二頁，數(shù)據(jù)加載完成之后setRefreshing(false)，那個loading的圈圈消失，cpu又恢復(fù)了正常。費了一番功夫，好在***還是把坑填上了。另外沒預(yù)料到的一點是，原來SwipeRefreshLayout也不怎么省油。
實際開發(fā)過程中難的不是如何解決問題，而是如何排查和定位問題。大多數(shù)情況下，我們可以憑借自己的積累和經(jīng)驗迅速定位問題。而這次自己挖的坑著實隱蔽，費了好大一番功夫，從JAVA代碼到Xml幾乎是一行一行去排查，***還是把坑填上了。那開發(fā)中還是要考慮的全面一些，少挖坑，那如果真的發(fā)現(xiàn)有坑，也是有套路可尋的，仔細分析問題，從JAVA代碼到xml逐步排查，總歸會豁然開朗的。
