ViewStub是Android布局優化中一個很不錯的標簽/控件，直接繼承自View。雖然Android開發人員基本上都聽說過，但是真正用的可能不多。
ViewStub可以理解成一個非常輕量級的View，與其他的控件一樣，有着自己的屬性及特定的方法。當ViewStub使用在布局文件中時，當程序inflate布局文件時，ViewStub本身也會被解析，且占據內存控件，但是與其他控件相比，主要區別體現在以下幾點：
1.當布局文件inflate時，ViewStub控件雖然也占據內存，但是相相比於其他控件，ViewStub所占內存很小；
2.布局文件inflate時，ViewStub主要是作為一個“占位符”的性質，放置於view tree中，且ViewStub本身是不可見的。ViewStub中有一個layout屬性，指向ViewStub本身可能被替換掉的布局文件，在一定時機時，通過viewStub.inflate()完成此過程；
3.ViewStub本身是不可見的，對ViewStub setVisibility(..)與其他控件不一樣，ViewStub的setVisibility 成View.VISIBLE或INVISIBLE如果是首次使用，都會自動inflate其指向的布局文件，並替換ViewStub本身，再次使用則是相當於對其指向的布局文件設置可見性。
這里需要注意的是：
1.ViewStub之所以常稱之為“延遲化加載”，是因為在教多數情況下，程序無需顯示ViewStub所指向的布局文件，只有在特定的某些較少條件下，此時ViewStub所指向的布局文件才需要被inflate，且此布局文件直接將當前ViewStub替換掉，具體是通過viewStub.infalte()或viewStub.setVisibility(View.VISIBLE)來完成；
2.正確把握住ViewStub的應用場景非常重要，正如如1中所描述需求場景下，使用ViewStub可以優化布局；
3.對ViewStub的inflate操作只能進行一次，因為inflate的時候是將其指向的布局文件解析inflate並替換掉當前ViewStub本身（由此體現出了ViewStub“占位符”性質），一旦替換后，此時原來的布局文件中就沒有ViewStub控件了，因此，如果多次對ViewStub進行infalte，會出現錯誤信息：ViewStub must have a non-null ViewGroup viewParent。
4.3中所講到的ViewStub指向的布局文件解析inflate並替換掉當前ViewStub本身，並不是完全意義上的替換（與include標簽還不太一樣），替換時，布局文件的layout params是以ViewStub為准，其他布局屬性是以布局文件自身為准。
下面看一下簡單的需求場景：在listview顯示列表數據時，可能會出現服務端一條數據都沒有的情況，此時顯示一個EmptyView，提示用戶暫無數據。此時考慮到實際應用中EmptyView顯示出來的機會相當小，因此，可以在布局文件中使用ViewStub站位，然后確實沒有數據時才viewStub.infalte()。
相關部分代碼如下：
1 public void showEmptyView() { 2 listview.setVisibility(View.GONE); 3 if (noDataView == null) { 4 ViewStub noDataViewStub = (ViewStub) view.findViewById(R.id.no_data_viewstub); 5 noDataView = noDataViewStub.inflate(); 6 } else { 7 noDataView.setVisibility(View.VISIBLE); 8 } 9 } 10
11 public void showListView(){ 12 listview.setVisibility(View.VISIBLE); 13 if(noDataView != null){ 14 noDataView.setVisibility(View.GONE); 15 } 16 }
特別需要注意的是對ViewStub是否已經inflate的判斷。
在Listview Item中，有時候可能遇到如下場景：在不同的列表頁item的布局一部分不同，但相對於整個item布局來說又不是很多，此時最常見的有如下兩種處理：
1.對不同的部分都寫出來，放到一個item文件中，然后邏輯分別處理不同部分的顯示與否（View.VISIBLE和View.GONE）；
2.對這兩種不同的item整個部分都分別區分開，完全寫成兩個item文件，然后結合listView顯示不同布局分別做邏輯處理（通過getItemType()等方式）。
以上兩種處理方式其實都可以，第一種方式邏輯清晰，非常靈活，只是在一定程度上增加了內存和資源消耗。第二種方式是的布局文件有重復（雖然相同部分可以通過include，但是邏輯上還是有重復的），包括邏輯上處理的代碼實質上的重復。一般對於有較大不同的item布局推薦采用此種方式。
有時候結合需求，可以在第一種方式的基礎上，結合ViewStub“占位符”可以比較好的完成此類需求。也相當於是兩種方式的一種折中形式，但同時兼顧了內存和資源消耗以及不同的布局邏輯控件。