ViewStub is a very good label/control in Android layout optimization, and it is directly inherited from View. Although Android developers have basically heard of it, they may not be able to use it.
ViewStub can be understood as a very lightweight View, like other controls, it has its own properties and specific methods. When ViewStub is used in the layout file, when the program inflates the layout file, ViewStub itself will be parsed and occupy memory controls, but compared with other controls,The main differences are reflected in the following points:
1. When layout file inflate, although the ViewStub control also occupies memory, compared with other controls, ViewStub takes up very little memory;
2. When laying out the file inflate, ViewStub is mainly used as a "placeholder" and is placed in the view tree, and ViewStub itself is invisible. There is a layout attribute in ViewStub that points to the layout file that ViewStub itself may be replaced. At a certain time, this process is completed through ();
It is invisible itself. The setVisability(..) for ViewStub is different from other controls. If it is used for the first time, it will automatically inflate the layout file it points to and replace the ViewStub itself. Using it again is equivalent to setting visibility to the layout file it points to.
What needs to be noted here is:
The reason why it is often called "delayed loading" is that in most cases, the program does not need to display the layout file pointed to by ViewStub. Only under certain fewer conditions, the layout file pointed to by ViewStub needs to be inflate, and this layout file will directly replace the current ViewStub, which is specifically done through () or ();
2. It is very important to correctly grasp the application scenario of ViewStub. As described in 1, using ViewStub can optimize the layout;
3. The inflate operation of ViewStub can only be performed once, because when inflate, the layout file it points to is parsed inflate and replaced the current ViewStub itself (this reflects the "placeholder" nature of ViewStub). Once replaced, there is no ViewStub control in the original layout file. Therefore, if you infalte ViewStub multiple times, an error message will appear: ViewStub must have a non-null ViewGroup viewParent.
The layout file pointed to by ViewStub mentioned in 4.3 is not a complete replacement (not quite the same as the include tag). When replacing, the layout params of the layout file are based on ViewStub, and other layout attributes are based on the layout file themselves.
Let’s take a look at a simple demand scenario: when the listview displays the list data, there may be no data on the server. At this time, an EmptyView is displayed, prompting the user to have no data yet. At this time, considering that the chance of displaying the EmptyView in actual applications is quite small, you can use the ViewStub site in the layout file, and then () when there is really no data.
The relevant codes are as follows:
public void showEmptyView() {
();
if (noDataView == null) {
ViewStub noDataViewStub = (ViewStub) (.no_data_viewstub);
noDataView = ();
} else {
();
}
}
public void showListView(){
();
if(noDataView != null){
();
}
}
What is particularly important to note is the judgment of whether ViewStub has been inflate.
In Listview Item, sometimes you may encounter the following scenario: the layout of items on different list pages is different, but it is not many compared to the entire item layout. At this time, the most common ones are as followsTwo treatments:
1. Write down all the different parts, put them in an item file, and then logically handle the display (and) of different parts respectively;
2. The entire part of these two different items is distinguished separately, and written into two item files completely. Then, the different layouts are displayed in combination with the listView and the logical processing is performed separately (by getItemType() and other methods).
Both of the above processing methods are actually OK. The first method is clear and very flexible, but it only increases memory and resource consumption to a certain extent. The second way is that the layout file has duplications (although the same part can be included, there are still logical repetitions), including the substantial duplication of the code processed logically. Generally, this method is recommended for larger different item layouts.
Sometimes, based on the first method, combined with the ViewStub "placeholder" can achieve this kind of requirement better. It is also equivalent to a compromise between the two methods, but it takes into account both memory and resource consumption and different layout logic controls.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.