"Turn" Android layout optimization viewstub

Viewstub is a good tag/control in Android layout optimization, directly inheriting from view. Although Android developers have largely heard of it, the actual use may not be much.

Viewstub can be understood as a very lightweight view, like other controls, with its own attributes and specific methods. When Viewstub is used in a layout file, when the program inflate the layout file, the viewstub itself is parsed and occupies the memory control, but the main difference compared to other controls is the following:

1. While the layout file inflate, the Viewstub control also occupies memory, but compared to other controls, the viewstub occupies little memory;

2. When the layout file is inflate, the viewstub is primarily a "placeholder" character, placed in the view tree, and viewstub itself is not visible. There is a layout property in Viewstub, which points to the viewstub itself that may be replaced by the layouts file, and at a certain time, through Viewstub.inflate () to complete the process;

3.ViewStub itself is not visible to viewstub setvisibility (..) Unlike other controls, Viewstub's setvisibility into view.visible or invisible if it is used for the first time, it automatically inflate its point to the layout file and replaces the viewstub itself, which is the equivalent of setting the visibility to the layout file it points to.

It is important to note that:

1.ViewStub is often referred to as "lazy loading," because in most cases, the program does not need to display the layout file pointed to by Viewstub, only under certain few conditions, the layout file pointed at this time viewstub need to be inflate, And this layout file will directly replace the current viewstub, specifically through Viewstub.infalte () or viewstub.setvisibility (view.visible) to complete;

2. It is important to correctly hold the Viewstub application scenario, as described in 1, where the use of viewstub can optimize the layout;

3. The inflate operation on the viewstub can only be performed once, because the inflate is to parse the layout file that it points to inflate and replace the current viewstub itself (thus embodying the viewstub "placeholder" nature), once replaced, There is no viewstub control in the original layout file, so if you infalte the viewstub multiple times, an error message appears: Viewstub must has a non-null viewgroup viewparent.

In 4.3, viewstub points to the layout file resolution inflate and replace the current viewstub itself, not the full meaning of the replacement (and not the same as the include tag), when replaced, layout file layouts The params is based on viewstub, and other layout attributes are based on the layout file itself.

Take a look at the simple requirements scenario: When the ListView displays list data, there may be a situation where there is no data on the service side, and a emptyview is displayed, prompting the user to temporarily have no data. Considering that the chances of Emptyview display in the actual application are quite small, you can use the viewstub stance in the layout file and then Viewstub.infalte () when there is no data.

The relevant section code is as follows:

1 public void Showemptyview () {2     listview.setvisibility (View.gone); 3     if (Nodataview = = null) {4         viewstub No Dataviewstub = (viewstub) View.findviewbyid (r.id.no_data_viewstub); 5         Nodataview = Nodataviewstub.inflate (); 6     } else {7         nodataview.setvisibility (view.visible); 8     } 9}10 One public void Showlistview () {     listview.setvisibility (view.visible);     if (nodataview! = null) {         Nodataview.setvisibility (View.gone);     }16}

It is particularly important to note whether the viewstub has inflate judgment.

In the ListView item, it is sometimes possible to encounter the following scenario: The layout of item on different list pages is different, but not much compared to the entire item layout, at this time the most common are the following two kinds of processing:

1. Write out the different parts, put them in an item file, and then logically handle the display of the different parts (view.visible and View.gone) respectively;

2. The entire part of the two different item is separated, completely written into two item files, and then combined with the ListView to show the different layouts are logically processed (via Getitemtype (), etc.).

The above two processing methods can actually be, the first way of logic clear, very flexible, but to a certain extent increased memory and resource consumption. The second way is that the layout files are duplicated (although the same parts can be included, but logically there are duplicates), including essentially repetitive code that is handled logically. This approach is generally recommended for larger, different item layouts.

Sometimes the combination of demand, can be based on the first way, combined with viewstub "placeholder" can be better to complete such requirements. It is also quite a compromise between the two approaches, but it also takes into account both memory and resource consumption as well as different layout logic controls.

Original: http://www.cnblogs.com/lwbqqyumidi/p/4047108.html

"Turn" Android layout optimization viewstub