在了解ViewPager的工作原理之前，先回顧ListView的工作原理：

ListView只有在需要顯示某些列表項(xiàng)時(shí)，它才會(huì)去申請(qǐng)可用的視圖對(duì)象；如果為所有的列表項(xiàng)數(shù)據(jù)創(chuàng)建視圖對(duì)象，會(huì)浪費(fèi)內(nèi)存；
ListView找誰(shuí)去申請(qǐng)視圖對(duì)象呢？ 答案是adapter。adapter是一個(gè)控制器對(duì)象，負(fù)責(zé)從模型層獲取數(shù)據(jù)，創(chuàng)建并填充必要的視圖對(duì)象，將準(zhǔn)備好的視圖對(duì)象返回給ListView；
首先，通過(guò)調(diào)用adapter的getCount()方法，ListView詢問(wèn)數(shù)組列表中包含多少個(gè)對(duì)象（為避免出現(xiàn)數(shù)組越界的錯(cuò)誤)；緊接著ListView就調(diào)用adapter的getView(int, View, ViewGroup)方法。
ViewPager某種程度上類似于ListView，區(qū)別在于：ListView通過(guò)ArrayAdapter.getView(int position, View convertView, ViewGroup parent)填充視圖；ViewPager通過(guò)FragmentPagerAdapter.getItem(int position)生成指定位置的fragment.

而我們需要關(guān)注的是:
ViewPager和它的adapter是如何配合工作的？
聲明：本文內(nèi)容針對(duì)android.support.v4.app.*
繼承自android.support.v4.view.PagerAdapter，每頁(yè)都是一個(gè)Fragment，并且所有的Fragment實(shí)例一直保存在Fragment manager中。所以它適用于少量固定的fragment，比如一組用于分頁(yè)顯示的標(biāo)簽。除了當(dāng)Fragment不可見(jiàn)時(shí)，它的視圖層（view hierarchy）有可能被銷毀外，每頁(yè)的Fragment都會(huì)被保存在內(nèi)存中。（翻譯自代碼文件的注釋部分）
繼承自android.support.v4.view.PagerAdapter，每頁(yè)都是一個(gè)Fragment，當(dāng)Fragment不被需要時(shí)（比如不可見(jiàn)），整個(gè)Fragment都會(huì)被銷毀，除了saved state被保存外（保存下來(lái)的bundle用于恢復(fù)Fragment實(shí)例）。所以它適用于很多頁(yè)的情況。（翻譯自代碼文件的注釋部分）
它倆的子類，需要實(shí)現(xiàn)getItem(int) 和 android.support.v4.view.PagerAdapter.getCount().

先通過(guò)一段代碼了解ViewPager和FragmentPagerAdapter的典型用法
稍后做詳細(xì)分析：

 // Set a PagerAdapter to supply views for this pager.
 ViewPager viewPager = (ViewPager) findViewById(R.id.my_viewpager_id);
 viewPager.setAdapter(mMyFragmentPagerAdapter);
 
 private FragmentPagerAdapter mMyFragmentPagerAdapter = new FragmentPagerAdapter(getSupportFragmentManager()) {
  @Override
  public int getCount() {
   return 2; // Return the number of views available.
  }
 
  @Override
  public Fragment getItem(int position) {
   return new MyFragment(); // Return the Fragment associated with a specified position.
  }
 
  // Called when the host view is attempting to determine if an item's position has changed.
  @Override
  public int getItemPosition(Object object) {
   if (object instanceof MyFragment) {
    ((MyFragment)object).updateView();
   }
   return super.getItemPosition(object);
  }
 };
 
 private class MyFragment extends Fragment {
  @Override
  public void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   // do something such as init data
  }
 
  @Override
  public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
   View view = inflater.inflate(R.layout.fragment_my, container, false);
   // init view in the fragment
   return view;
  }
 
  public void updateView() {
   // do something to update the fragment
  }
 }

FragmentPagerAdapter和FragmentStatePagerAdapter對(duì)Fragment的管理略有不同，在詳細(xì)考察二者區(qū)別之前，我們通過(guò)兩種較為直觀的方式先感受下：

通過(guò)兩張圖片直觀的對(duì)比FragmentPagerAdapter和FragmentStatePagerAdapter的區(qū)別
說(shuō)明：這兩張圖片來(lái)自于《Android權(quán)威編程指南》，原圖有3個(gè)Fragment，我增加了1個(gè)Fragment，以及被調(diào)到的方法。
FragmentPagerAdapter的Fragment管理：

FragmentStatePageAdapter的Fragment管理：

詳細(xì)分析 adapter method和fragment lifecycle method 的調(diào)用情況
好啦，感受完畢，我們需要探究其詳情，梳理adapter創(chuàng)建、銷毀Fragment的過(guò)程，過(guò)程中adapter method和fragment lifecycle method哪些被調(diào)到，有哪些一樣，有哪些不一樣。

最開(kāi)始處于第0頁(yè)時(shí)，adapter不僅為第0頁(yè)創(chuàng)建Fragment實(shí)例，還為相鄰的第1頁(yè)創(chuàng)建了Fragment實(shí)例：

// 剛開(kāi)始處在page0
D/Adapter (25946): getItem(0)
D/Fragment0(25946): newInstance(2015-09-10) // 注釋：newInstance()調(diào)用了Fragment的構(gòu)造器方法，下同。
D/Adapter (25946): getItem(1)
D/Fragment1(25946): newInstance(Hello World, I'm li2.)
D/Fragment0(25946): onAttach()
D/Fragment0(25946): onCreate()
D/Fragment0(25946): onCreateView()
D/Fragment1(25946): onAttach()
D/Fragment1(25946): onCreate()
D/Fragment1(25946): onCreateView()

第1次從第0頁(yè)滑到第1頁(yè)，adapter同樣會(huì)為相鄰的第2頁(yè)創(chuàng)建Fragment實(shí)例；

// 第1次滑到page1
D/Adapter (25946): onPageSelected(1)
D/Adapter (25946): getItem(2)
D/Fragment2(25946): newInstance(true)
D/Fragment2(25946): onAttach()
D/Fragment2(25946): onCreate()
D/Fragment2(25946): onCreateView()

FragmentPagerAdapter和FragmentStatePagerAdapter齊聲說(shuō)：吶，請(qǐng)主公貳放心，屬下定會(huì)為您準(zhǔn)備好相鄰的下一頁(yè)視圖噠！么么噠！
它倆對(duì)待下一頁(yè)的態(tài)度是相同的，但對(duì)于上上頁(yè)，它倆做出了不一樣的事情：

FragmentPagerAdapter說(shuō)：上上頁(yè)的實(shí)例還保留著，只是銷毀了它的視圖：

// 第N次（N不等于1）向右滑動(dòng)選中page2
D/Adapter (25946): onPageSelected(2)
D/Adapter (25946): destroyItem(0) // 銷毀page0的視圖
D/Fragment0(25946): onDestroyView()
D/Fragment3(25946): onCreateView() // page3的Fragment實(shí)例仍保存在FragmentManager中，所以只需創(chuàng)建它的視圖
FragmentStatePagerAdapter說(shuō)：上上頁(yè)的實(shí)例和視圖都被俺銷毀啦：
// 第N次（N不等于1）向右滑選中page2
D/Adapter (27880): onPageSelected(2)
D/Adapter (27880): destroyItem(0) // 銷毀page0的實(shí)例和視圖
D/Adapter (27880): getItem(3) // 創(chuàng)建page3的Fragment
D/Fragment3(27880): newInstance()
D/Fragment0(27880): onDestroyView()
D/Fragment0(27880): onDestroy()
D/Fragment0(27880): onDetach()
D/Fragment3(27880): onAttach()
D/Fragment3(27880): onCreate()
D/Fragment3(27880): onCreateView()
Fragment getItem(int position)

// Return the Fragment associated with a specified position.
public abstract Fragment getItem(int position);

當(dāng)adapter需要一個(gè)指定位置的Fragment，并且這個(gè)Fragment不存在時(shí)，getItem就被調(diào)到，返回一個(gè)Fragment實(shí)例給adapter。
所以，有必要再次強(qiáng)調(diào)，getItem是創(chuàng)建一個(gè)新的Fragment，但是這個(gè)方法名可能會(huì)被誤認(rèn)為是返回一個(gè)已經(jīng)存在的Fragment。
對(duì)于FragmentPagerAdapter，當(dāng)每頁(yè)的Fragment被創(chuàng)建后，這個(gè)函數(shù)就不會(huì)被調(diào)到了。對(duì)于FragmentStatePagerAdapter，由于Fragment會(huì)被銷毀，所以它仍會(huì)被調(diào)到。
由于我們必須在getItem中實(shí)例化一個(gè)Fragment，所以當(dāng)getItem()被調(diào)用后，F(xiàn)ragment相應(yīng)的生命周期函數(shù)也就被調(diào)到了：

D/Adapter (25946): getItem(1)
D/Fragment1(25946): newInstance(Hello World, I'm li2.) // newInstance()調(diào)用了Fragment的構(gòu)造器方法；
D/Fragment1(25946): onAttach()
D/Fragment1(25946): onCreate()
D/Fragment1(25946): onCreateView()

void destroyItem(ViewGroup container, int position, Object object)
// Remove a page for the given position. 
public void FragmentPagerAdapter.destroyItem(ViewGroup container, int position, Object object) {
  mCurTransaction.detach((Fragment)object);
}

public void FragmentStatePagerAdapter.destroyItem(ViewGroup container, int position, Object object) {
  mSavedState.set(position, mFragmentManager.saveFragmentInstanceState(fragment));
  mFragments.set(position, null);
  mCurTransaction.remove(fragment);
}

銷毀指定位置的Fragment。從源碼中可以看出二者的區(qū)別，一個(gè)detach，一個(gè)remove，這將調(diào)用到不同的Fragment生命周期函數(shù)：

// 對(duì)于FragmentPagerAdapter
D/Adapter (25946): onPageSelected(2)
D/Adapter (25946): destroyItem(0)
D/Fragment0(25946): onDestroyView() // 銷毀視圖

// 對(duì)于FragmentStatePagerAdapter
D/Adapter (27880): onPageSelected(2)
D/Adapter (27880): destroyItem(0)
D/Fragment0(27880): onDestroyView() // 銷毀視圖
D/Fragment0(27880): onDestroy() // 銷毀實(shí)例
D/Fragment0(27880): onDetach()
FragmentPagerAdapter和FragmentStatePagerAdapter對(duì)比總結(jié)

二者使用方法基本相同，唯一的區(qū)別就在卸載不再需要的fragment時(shí)，采用的處理方式不同：

使用FragmentStatePagerAdapter會(huì)銷毀掉不需要的fragment。事務(wù)提交后，可將fragment從activity的FragmentManager中徹底移除。類名中的“state”表明：在銷毀fragment時(shí)，它會(huì)將其onSaveInstanceState(Bundle) 方法中的Bundle信息保存下來(lái)。用戶切換回原來(lái)的頁(yè)面后，保存的實(shí)例狀態(tài)可用于恢復(fù)生成新的fragment.
FragmentPagerAdapter的做法大不相同。對(duì)于不再需要的fragment，F(xiàn)ragmentPagerAdapter則選擇調(diào)用事務(wù)的detach(Fragment) 方法，而非remove(Fragment)方法來(lái)處理它。也就是說(shuō)，F(xiàn)ragmentPagerAdapter只是銷毀了fragment的視圖，但仍將fragment實(shí)例保留在FragmentManager中。因此， FragmentPagerAdapter創(chuàng)建的fragment永遠(yuǎn)不會(huì)被銷毀。
更新ViewPager中的Fragment
調(diào)用notifyDataSetChanged()時(shí)，2個(gè)adapter的方法的調(diào)用情況相同，當(dāng)前頁(yè)和相鄰的兩頁(yè)的getItemPosition都會(huì)被調(diào)用到。

// Called when the host view is attempting to determine if an item's position has changed. Returns POSITION_UNCHANGED if the position of the given item has not changed or POSITION_NONE if the item is no longer present in the adapter.
public int getItemPosition(Object object) {
  return POSITION_UNCHANGED;
}

從網(wǎng)上找到的解決辦法是，覆寫getItemPosition使其返POSITION_NONE，以觸發(fā)Fragment的銷毀和重建?？墒沁@將導(dǎo)致Fragment頻繁的銷毀和重建，并不是最佳的方法。
后來(lái)我把注意力放在了入口參數(shù)object上，"representing an item", 實(shí)際上就是Fragment，只需要為Fragment提供一個(gè)更新view的public方法：

@Override
// To update fragment in ViewPager, we should override getItemPosition() method,
// in this method, we call the fragment's public updating method.
public int getItemPosition(Object object) {
  Log.d(TAG, "getItemPosition(" + object.getClass().getSimpleName() + ")");
  if (object instanceof Page0Fragment) {
    ((Page0Fragment) object).updateDate(mDate);
  } else if (object instanceof Page1Fragment) {
    ((Page1Fragment) object).updateContent(mContent);
  } else if (object instanceof Page2Fragment) {
    ((Page2Fragment) object).updateCheckedStatus(mChecked);
  } else if (...) {
  }
  return super.getItemPosition(object);
};

// 更新界面時(shí)方法的調(diào)用情況
// 當(dāng)前頁(yè)為0時(shí)
D/Adapter (21517): notifyDataSetChanged(+0)
D/Adapter (21517): getItemPosition(Page0Fragment)
D/Fragment0(21517): updateDate(2015-09-12)
D/Adapter (21517): getItemPosition(Page1Fragment)
D/Fragment1(21517): updateContent(Hello World, I am li2.)

// 當(dāng)前頁(yè)為1時(shí)
D/Adapter (21517): notifyDataSetChanged(+1)
D/Adapter (21517): getItemPosition(Page0Fragment)
D/Fragment0(21517): updateDate(2015-09-13)
D/Adapter (21517): getItemPosition(Page1Fragment)
D/Fragment1(21517): updateContent(Hello World, I am li2.)
D/Adapter (21517): getItemPosition(Page2Fragment)
D/Fragment2(21517): updateCheckedStatus(true)

在最開(kāi)始調(diào)用notifyDataSetChanged試圖更新Fragment時(shí)，我是這樣做的：用arraylist保存所有的Fragment，當(dāng)需要更新時(shí)，就從arraylist中取出Fragment，然后調(diào)用該Fragment的update方法。這種做法非常魚(yú)唇，當(dāng)時(shí)完全不懂得adapter的Fragment manager在替我管理所有的Fragment。而我只需要：

• 覆寫getCount告訴adapter有幾個(gè)Fragment；
• 覆寫getItem以實(shí)例化一個(gè)指定位置的Fragment返回給adapter；
• 覆寫getItemPosition，把入口參數(shù)強(qiáng)制轉(zhuǎn)型成自定義的Fragment，然后調(diào)用該Fragment的update方法以完成更新。

只需要覆寫這幾個(gè)adapter的方法，adapter會(huì)為你完成所有的管理工作，不需要自己保存、維護(hù)Fragment。

替換ViewPager中的Fragment
應(yīng)用場(chǎng)景可能是這樣，比如有一組按鈕，Day/Month/Year，有一個(gè)包含幾個(gè)Fragment的ViewPager。點(diǎn)擊不同的按鈕，需要秀出不同的Fragment。
具體怎么實(shí)現(xiàn)，請(qǐng)參考下面的代碼：
github.com/li2/Update_Replace_Fragment_In_ViewPager/ContainerFragment.java

一些誤區(qū)
ViewPager.getChildCount() 返回的是當(dāng)前ViewPager所管理的沒(méi)有被銷毀視圖的Fragment，并不是所有的Fragment。想要獲取所有的Fragment數(shù)量，應(yīng)該調(diào)用ViewPager.getAdapter().getCount().

ViewPager中使用Fragment+ListView，多次切換后造成ListView沒(méi)有數(shù)據(jù)顯示？

ViewPager+Fragment動(dòng)態(tài)增刪緩存問(wèn)題
產(chǎn)生原因：

我們?cè)陂_(kāi)發(fā)中會(huì)常常用到ViewPager+Fragment，有時(shí)候可能會(huì)有這樣的需求，需要對(duì)ViewPager中的內(nèi)容進(jìn)行動(dòng)態(tài)的增刪管理，但是我們都知道ViewPager為了保證滑動(dòng)的流暢性，viewpager在加載當(dāng)前頁(yè)的時(shí)候已經(jīng)將pager頁(yè)左右頁(yè)的內(nèi)容加載進(jìn)內(nèi)存里了，所以此時(shí)我們不進(jìn)行任何處理的話，是我發(fā)達(dá)到我們預(yù)期的效果的。
解決方案：

一、將FragmentPagerAdapter 替換成FragmentStatePagerAdapter， 因?yàn)榍罢咧灰虞d過(guò)，fragment中的視圖就一直在內(nèi)存中，在這個(gè)過(guò) 程中無(wú)論你怎么刷新，清除都是無(wú)用的，直至程序退出； 后者可以滿足我們的需求。 2.我們可以重寫Adapter的方法–getItemPosition()，讓其返回PagerAdapter.POSITION_NONE即可。 以下為引用內(nèi)容：

@Override  

  public int getItemPosition(Object object) { 

  return PagerAdapter.POSITION_NONE;  

 }

到這一步我們就可以真正的實(shí)現(xiàn)隨意、徹底刪除viewpager中的fragment，隨意增刪。
二、善用Dialog 一些交互簡(jiǎn)單、或者只是展示功能的頁(yè)面，如果使用一個(gè)Activity來(lái)顯示的話，過(guò)于繁瑣，開(kāi)銷也很大，使用Fragment的話，蛋疼的生命周期也不好處理，此時(shí)使用一個(gè)全屏的Dialog來(lái)模擬一個(gè)Activity就是一個(gè)不錯(cuò)的選擇。
三、Splash頁(yè)面那點(diǎn)事 ：幾乎每個(gè)頁(yè)面都會(huì)有一個(gè)Spalsh頁(yè)，通常我們會(huì)用一個(gè)Activity加載一張全屏的背景圖，或者放一個(gè)app的logo，展示2秒之后，跳轉(zhuǎn)到登錄或者主頁(yè)面，期間可能會(huì)做一些數(shù)據(jù)初始化，檢查更新等操作。相信大多數(shù)小伙伴也是這么干的，但是，你不覺(jué)得一個(gè)Activity只顯示2秒就殺掉有點(diǎn)浪費(fèi)？個(gè)人覺(jué)得這樣的開(kāi)銷是非常之不劃算的，我們可以借用上面一條，利用一個(gè)Dialog模擬一個(gè)Splash頁(yè)面，2秒之后dismiss掉這個(gè)Dialog，而檢查更新，初始化數(shù)據(jù)等操作就放到MainActivity中?；蛘呤褂肍ragment替代SplashActivity等等方法， 都可以達(dá)到Splash頁(yè)的相同效果。
四、善待內(nèi)部類 在開(kāi)發(fā)中，我們會(huì)經(jīng)常用到內(nèi)部類，內(nèi)部類的出現(xiàn)，解決了Java只能單繼承的局限性，使得開(kāi)發(fā)能更加靈活。但如果內(nèi)部類用的不好，就會(huì)出現(xiàn)Android Developer的噩夢(mèng)，OOM!。為什么呢？底子稍微好點(diǎn)的同學(xué)，應(yīng)該都知道內(nèi)部類可以訪問(wèn)外部類的成員變量和方法，因?yàn)閮?nèi)部類持有了外部類的引用，當(dāng)你在一個(gè)Activity中使用的內(nèi)部類，當(dāng)Activity銷毀時(shí)，你的內(nèi)部類沒(méi)有釋放，就會(huì)造成這個(gè)Activity無(wú)法被GC回收，因?yàn)閮?nèi)部類中持有了Activity的應(yīng)用。
五、library那些事 library中的switch中不能使用id來(lái)case，這個(gè)在我的上一篇博文中已經(jīng)講過(guò)。這里我們?cè)僦v一個(gè)library的坑，當(dāng)我們引入一個(gè)依賴庫(kù)時(shí)，依賴庫(kù)中一般都會(huì)自帶一個(gè)support v4的包，這個(gè)v4包的版本，和我們創(chuàng)建工程時(shí)的版本一般情況下是一致的，但是一旦我們自己工程的v4包的依賴庫(kù)中的v4包中的版本不一致時(shí)，一大推莫名其妙的錯(cuò)誤日志就會(huì)接踵而來(lái)。此時(shí)的處理方法也很簡(jiǎn)單，由于v4包都是向下兼容的，只需要保持依賴庫(kù)的版本和我們自身項(xiàng)目的版本一致即可。 今天暫時(shí)先總結(jié)到這里，如果上述言論有錯(cuò)誤的地方，希望各位小伙伴們及時(shí)指出。

最新評(píng)論