ViewStub Control for Android Layout Optimization

ViewStub is a very good tag/control in Android layout optimization, directly inherited from View. Although Android developers have basically heard of it, they may not really use it much.

ViewStub can be understood as a very lightweight View, like other controls, with its own properties and specific methods. When ViewStub is used in a layout file, when the program inflate lays out the file, ViewStub itself will be parsed and occupy memory controls, but compared with other controls, the main differences are as follows:

1. When laying out the file inflate, ViewStub control also occupies memory, but compared with other controls, ViewStub occupies very small memory;

2. When laying out the file inflate, ViewStub is mainly used as a "placeholder", which is placed in view tree, and ViewStub itself is invisible. There is an layout attribute in ViewStub, which points to the layout file that ViewStub itself may be replaced. When the time is 1, this process is completed through viewStub. inflate ();

3. ViewStub itself is invisible. ViewStub setVisibility (...) is different from other controls. If setVisibility of ViewStub becomes View. VISIBLE or INVISIBLE is used for the first time, it will automatically replace the layout file pointed by inflate and replace ViewStub itself. If it is used again, it is equivalent to setting visibility for the layout file pointed by inflate.

What should be noted here is:

1. The reason why ViewStub is often called "delayed loading" is that in most cases, the program does not need to display the layout file pointed by ViewStub, and only under certain few conditions, the layout file pointed by ViewStub needs to be replaced by inflate, and this layout file directly replaces the current ViewStub, specifically through viewStub. infalte () or viewStub. setVisibility (View. VISIBLE).

2. It is very important to correctly grasp the application scenario of ViewStub. As in the demand scenario described in 1, the layout can be optimized by using ViewStub;

3. The inflate operation of ViewStub can only be carried out once, because when inflate is carried out, the layout file it points to is parsed to inflate and the current ViewStub itself is replaced (which reflects the "placeholder" nature of ViewStub). After one replacement, there is no ViewStub control in the original layout file at this time. Therefore, if infalte is carried out on ViewStub many times, an error message will appear: ViewStub must a non-null ViewGroup viewParent.

The layout file pointed to by ViewStub mentioned in 4.3 parses inflate and replaces the current ViewStub itself, which is not a complete replacement (not quite the same as include tag). When replacing, layout params of the layout file is subject to ViewStub, and other layout attributes are subject to the layout file itself.

Let's look at a simple requirement scenario: When listview displays list data, there may be no data on the server side. At this time, an EmptyView is displayed, prompting the user that there is no data at present. At this point, considering that the chance of EmptyView being displayed in practical applications is rather small, you can use the ViewStub station in the layout file, and then only use viewStub. infalte () when there is really no data.

The relevant parts of the code are as follows:

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);
  }
}

Special attention should be paid to the judgment of whether ViewStub has already been inflate.

In Listview Item, you may sometimes encounter the following scenarios: the layout 1 part of item is different in different list pages, but it is not much relative to the overall layout of item. At this time, the most common treatments are as follows:

1. Write out different parts and put them into an item file, and then logically process whether different parts are displayed or not (View. VISIBLE and View. GONE);

2. Distinguish the whole part of these two different item, write them into two item files completely, and then do logical processing according to different layouts displayed by listView (through getItemType (), etc.).

In fact, the above two processing methods can be used. The first method has clear logic and is very flexible, but it only increases memory and resource consumption to a certain extent. The second way is that there are duplicates in the layout file (although the same part can be passed through include, there are duplicates logically), including the duplication of logically processed code in essence. 1 This method is generally recommended for item layouts that are quite different.

Sometimes, combined with requirements, such requirements can be well completed on the basis of the first way and combined with ViewStub "placeholders". It is also equivalent to a compromise between the two methods, but it also takes into account memory and resource consumption and different layout logic controls.