Fragment是Android3.0之後加入的新特性，需要API11以上的SDK版本才能兼容，然而市面上有很多手機依然是3.0以下的系統，谷歌爲了兼容低版本，於是開發了Android support v4包，裏面的Fragment能夠在最低API4的版本下運行,而且v4裏面的Fragment還能嵌在一個名叫ViewPager的控件中，形成多頁側滑的效果。
我們一般的APP中，主要的界面有很多都是底部多標籤切換的形式，這種形式我們很自然的想到通過ViewPager來構建一個多頁面側滑的效果，並可以和底部的RadioGroup實現聯動。我的確一直都是這麼做的，當時也並未想到有什麼不妥，直到今天在一個包含五個Fragment的Activity上做操作時，發現視圖的加載很不流暢，尤其是我加入了一個下拉刷新的功能之後，發現下拉刷新的下拉動作變得非常困難。如何解釋這種困難，大約就是當我費盡心思用手指在屏幕上滑動時，根本看不到下拉的效果，或者是手指滑過整個屏幕，但是卻僅僅把視圖下拉了非常微小和距離，而且在下拉動畫一點都不流暢，有明顯的掉幀和卡頓現象。
我百思不得其解，最初認爲是在主線程中執行了太多的操作導致的，於是將所有加載數據的動作全部禁用，僅保留基本視圖的加載，經過這樣處理，結果收效甚微，幾乎看不到明顯的改善。我越發疑惑，僅僅是加載幾個空的佈局而已，況且佈局並不複雜，爲什麼視覺效果上還是這麼卡頓？於是換一種方式來檢測原因，保留所有的數據加載，但是不使用Fragment，全部在Activity中執行，將這5個Fragment中的內容全部遷移到Activity中來。先不說結果，估且設想一下，沒有了Fragment分攤Activity的工作，視圖的加載理應變得更慢纔是。
結果自然出乎我的意料，Activity的加載雖然沒有變得十分之快，但較之5個Fragment時期卻反而流暢了一些。我想可能是Activity主線程加載佈局太多，畢竟我之前的5個Fragment每個都有整屏幕的內容，5合1,各種重疊，我幾乎看不清它們之中的任何一個，慢也是正常的，但比5個Fragment的時候快，我於是想到可能是ViewPager的原因了。
ViewPager下的Fragment是v4包中的Fragment，爲了兼容低版本而存在，則必然要犧牲某些性能以實現兼容，另外我認爲自己並不是很需要ViewPager的側滑效果，甚至是需要取消這種效果，基於這些原因，我刪除了項目中的ViewPager，並使用普通的app包中的Fragment，其他和之前完全一樣，僅僅是v4中的Fragment換成了API11以上才能使用的普通app包中的Fragment，令人振奮的是，下拉的動畫變得流暢許多，從叫人完全不能接受的卡頓變成了完全可以接受的流暢度。
具體原因暫時沒有仔細研究源碼，猜想原因大約有以下幾點：
1.普通的Fragment比v4包中的Fragment性能要好，畢竟按常理來說，兼容性必然是以犧牲某些性能作爲代價的。
使用普通的Fragment之後再對其生命週期進行管控，適當的銷燬和重用某些視圖，就能實現較爲流暢的視覺效果了。2.ViewPager有頁面緩存，在使用ViewPager管理Fragment的時候往往容易忽略對Fragment本身的管理，而且ViewPager管理下的Fragment生命週期和普通的Fragment的生命週期有區別。
3.ViewPager+Fragment，如果每個Fragment都佔一屏的話，根據ViewPager的緩存，它實際上會同時加載左右兩邊緩存的頁面，除了數據，視圖也會同時加載，等於是一個Activity承擔幾個Activity面積的視圖加載任務，這種緩存不可取消，最少也得有左右相鄰各一個同時加載，或許這一點纔是視圖卡頓的真正原因。