案例2——hprof文件顯示出Fragment內存泄漏

接下來我們來看fragment內存泄漏，老規矩查看fields和references，確保它符合內存泄漏的情形；我們點擊jump to source查看泄漏的位置

Fragment#MZBannerView#內部類Runnbale

/*** Banner 切換時間間隔*/
private int mDelayedTime = 5000;
private final Runnable mLoopRunnable = new Runnable() {@Overridepublic void run() {if (mIsAutoPlay) {mCurrentItem = mViewPager.getCurrentItem();mCurrentItem++;if (mCurrentItem > mAdapter.getCount() - 1) {mCurrentItem = 0;mViewPager.setCurrentItem(mCurrentItem, false);mHandler.postDelayed(this, mDelayedTime);} else {mViewPager.setCurrentItem(mCurrentItem);mHandler.postDelayed(this, mDelayedTime);}} else {mHandler.postDelayed(this, mDelayedTime);}}};

可以看到Fragment內存泄漏的第一個原因，內部類runnable持有了view的實例，每個Runnbale會發送一個延時5秒的消息，消息發送期間，有可能view、fragment已經結束了生命周期，此時產生了內存泄漏。
解決辦法也很簡單，view離開窗口的時候，釋放Handler中消息，釋放Runnbale對view 的引用。

1. 靜態Runnbale內部類+對view的弱引用(此部分代碼與前面的示例很相似，不重復貼代碼了)
2. 離開窗口remove#handler消息
   view對Activity暴露了pause方法，在Activity銷毀時，強制清空handler的任務；

// view代碼
/*** 停止輪播*/public void pause() {mIsAutoPlay = false;mHandler.removeCallbacks(mLoopRunnable);mBannerPageClickListener = null;}
// Activity代碼：@Overridepublic void onDestroy() {super.onDestroy();dataBing.homeBanner.pause();}