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()。

相關部分代碼如下：

public void showEmptyView() {  listview.setVisibility(View.GONE);  if (noDataView == null) {    ViewStub noDataViewStub = (ViewStub) view.findViewById(R.id.no_data_viewstub);    noDataView = noDataViewStub.inflate();  } else {    noDataView.setVisibility(View.VISIBLE);  }}public void showListView(){  listview.setVisibility(View.VISIBLE);  if(noDataView != null){    noDataView.setVisibility(View.GONE);  }}

特別需要注意的是對ViewStub是否已經inflate的判斷。

在Listview Item中，有時候可能遇到如下場景：在不同的列表頁item的布局一部分不同，但相對于整個item布局來說又不是很多，此時最常見的有如下兩種處理：

1.對不同的部分都寫出來，放到一個item文件中，然后邏輯分別處理不同部分的顯示與否（View.VISIBLE和View.GONE）；

2.對這兩種不同的item整個部分都分別區分開，完全寫成兩個item文件，然后結合listView顯示不同布局分別做邏輯處理（通過getItemType()等方式）。

以上兩種處理方式其實都可以，第一種方式邏輯清晰，非常靈活，只是在一定程度上增加了內存和資源消耗。第二種方式是的布局文件有重復（雖然相同部分可以通過include，但是邏輯上還是有重復的），包括邏輯上處理的代碼實質上的重復。一般對于有較大不同的item布局推薦采用此種方式。

有時候結合需求，可以在第一種方式的基礎上，結合ViewStub“占位符”可以比較好的完成此類需求。也相當于是兩種方式的一種折中形式，但同時兼顧了內存和資源消耗以及不同的布局邏輯控件。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持武林網。