關于下拉重新整理這件事，無論是普通使用者還是開發者都再熟悉不過了，過去的某段時間無論下拉重新整理的設計還是開源控件都異常火爆，火爆到驚動了黨中央(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);
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逐漸排查，總歸會豁然開朗的。
本文作者：佚名
來源：51cto