Android Redundancy Layout optimization

The system fill layout is a huge overhead, too much layout nesting and view has a great impact on the performance of the application. In order for the application to run smoothly and quickly, we should make the layout as simple as possible and avoid the situation of re-populating the layout because of the small UI changes.

1. Redundant layouts are redundant

If a linearlayout is nested in the middle of the frame, they are all set to Match_parent, which is redundant, only adding time to fill the layout. So when we add a sub-layout to a layout, we should be careful to look for redundant layouts.

Because layouts can be arbitrarily nested, so easy to create complex, multi-layered layout, which is not advocated, we should try to keep the layout simple. Although not mandatory, layout nesting is best not to exceed 10 layers.

In this example, if Framelayout is added to other layouts, it will become redundant, affecting performance, and a better option is to use the merge tag instead of the Framelayout,merge feature when it is nested in other layouts, the node is deleted, The view in the merge is then added directly to the parent class layout.

The merge tag is used with the include tag to build a more flexible, simple, reusable layout. The purpose of the include tag is to add a layout to another layout. For example:

2. Avoid excessive use of view

In reality, an application generally contains a lot of view, but not every view can be obtained, and some view may rarely be used, which creates a lot of waste of resources, to a certain extent, affect the degree of fluency in the application.

If the view is needed, loading will reduce the waste of resources due to excessive view loading.

Viewstub can achieve such a function, the view in the Viewstub is only displayed when the call inflate or is set to be visible, so as to ensure that they do not need the view when they are not loaded.

<viewstub
Android:id= "@+id/stub_import"
Android:inflatedid= "@+id/panel_import"
android:layout= "@layout/progress_overlay"
Android:layout_width= "Fill_parent"
android:layout_height= "Wrap_content"
android:layout_gravity= "Bottom"/>

In this viewstub attribute, the ID is set to be visible later and Inflate,inflateid overrides the root node of the layout file it contains id,layout is the layout file that he contains, in Viewstub, all

The Layout_* property will be applied to the top-level node of the layout file it contains.

On top of that, when you need to load the view in viewstub, you need to show the call inflate or set it to be visible, there are two different ways:

((viewstub) Findviewbyid (R.id.stub_import)). Setvisibility (view.visible);
Or
View Importpanel = ((viewstub) Findviewbyid (R.id.stub_import)). Inflate ();

The Infalte method is also triggered when it is set to visible.

However, if the call inflate method is displayed, the Infalte method can return to the view in Viewstub and delete the viewstub, because the view in Viewstub is already loaded, and viewstub has lost its meaning, There is no need to keep an unnecessary reference.

Viewstub is a very efficient label, rather than a manual inflate view and added to the view hierarchy at run time , it's better to simply use viewstub. Viewstub The only drawback is that the merge tag is not supported.

Android Redundancy Layout optimization