Android布局最佳化之ViewStub控制項_Android

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“預留位置”可以比較好的完成此類需求。也相當於是兩種方式的一種折中形式，但同時兼顧了記憶體和資源消耗以及不同的布局邏輯控制項。

以上就是本文的全部內容，希望對大家的學習有所協助，也希望大家多多支援雲棲社區。