關於下拉重新整理這件事，無論是普通使用者還是開發者都再熟悉不過了，過去的某段時間無論下拉重新整理的設計還是開源控制元件都異常火爆，火爆到驚動了黨中央（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引起的。自己挖的坑，把自己埋進去也要給填上。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
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逐步排查，總歸會豁然開朗的。