Shulou(Shulou.com)06/03 Report--

This article focuses on "how to understand the layout optimization of Androd high-level performance optimization". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the layout optimization of Androd high-level performance optimization.

Catalogue

? Layout level management

? Draw (Measurement)

? Display (Positioning)

? Overpainting caused by background settings

? Summary

? Small experiments (multiple ways to achieve the same layout)

? LinearLayout

? Use RelativeLayout

? Layout reuse (and)

? ViewStub

? ViewStub Settin

? Display

? Summary

? Custom component optimization

? Optimize

Android's layout manager itself is a UI component, all layout managers are subclasses of ViewGroup, and ViewGroup is a subclass of View, so the layout manager can be used as a normal UI component or as a container class, multiple overloaded addView () can be called to add components to the layout manager, and layout managers can be nested with each other, of course, too much nesting is not recommended (if you want to be compatible with low-end models It is best not to exceed the fifth floor).

? Layout level management

Let's take a look at what happens every time the system draws a layout. This process is accomplished in two steps:

? Draw (Measurement)

1: the root layout measures itself.

2: the root layout requires all its internal subcomponents to measure themselves.

3: all self-layouts need to have their internal subcomponents do this until they have finished traversing all the View in the view level.

? Display (Positioning)

1: when all the View in the layout has been measured, the root layout begins to put them in place.

2: all sublayouts need to do the same thing until all the View in the view level is traversed.

? Overpainting caused by background settings

Component background: each time you set the background of each component, the area of the component will be painted with an additional layer. For example, LinearLayout sets the background color, and the TextView in it sets the background color, which will increase the transition rendering in the component area.

Theme background: the theme background of the Activity interface, which will add a GPU drawing

Do not arbitrarily set the background for the UI components in the layout. If ImageView sets up a picture, it will add one drawing, and then set the background color to the ImageView component, then it will add another drawing, then the ImageView component must have overdrawn.

? Summary

When the properties of a View change (for example, the TextView content changes or the ImageView image changes), the View itself calls the View.invalidate () method (which must be called from the UI thread) and propagates the request from the bottom up to the root layout (which calculates the areas that need to be redrawn, which in turn redraws the parts of the entire layout hierarchy that need to be redrawn). The more complex the layout level, the slower the UI loads. Therefore, when writing a layout, it is important to be as flat as possible.

FrameLayout and TableLayout have their own special uses, LinearLayout and RelativeLayout are interchangeable, ConstraintLayout and RelativeLayout are similar. That is, when writing a layout, you can choose one of them, and we can write the following simple layout in different ways.

? Small experiments (multiple ways to achieve the same layout)

? LinearLayout

The first way is to use LinearLayout, which is more readable, but the performance is poor. Because nested LinearLayout deepens the view hierarchy, each time a subcomponent is placed, it consumes more computation.

The LinearLayout view level is as follows:

? Use RelativeLayout

The second method uses RelativeLayout, in which case you do not need to nest other ViewGroup, because each child View can be equivalent to other View, or relative to the parent control.

The RelativeLayout view level is as follows:

In two ways, it is easy to see that the first method, LinearLayout, requires three view levels and six View, and the second way, RelativeLayout, requires only two view levels and five View.

Of course, although RelativeLayout is more efficient, not all cases can complete the placement of controls through relative layout. So usually, these two methods need to be used together.

Note: in order to ensure the performance of the application, when creating a layout, you need to avoid redrawing as much as possible, and the layout level should be as flat as possible, so that the system time can be reduced when the View is redrawn. If conditions permit, try to use RelativeLayout and ConstraintLayout instead of LinearLayout, or replace LinearLayout with GridLayoutl.

We most often use ViewGroup is LinearLayout, just because it is easy to understand, easy to write, so it has become the first choice of Android development. For this reason, Google has launched a brand new ViewGroup. When you use it at the right time, you can reduce redundancy, which is under the grid layout GridLayout.

? Layout reuse (and)

Android provides a very useful tag. In some cases, when you want to use some existing layout in other layouts, the tag can add one layout to another by making the relevant reference ID.

For example, if you customize a title block, you can create a reusable layout file as follows.

Next, put the label in the appropriate layout file and replace the corresponding View:

...

In this way, when you want to reuse some View, you don't have to copy / paste it, you just need to define a layout file and reference it.

But doing so may introduce a redundant ViewGroup (the root view of the reused layout file). To this end, Android provides another tag to help us reduce layout redundancy and flatten the hierarchy. We just need to replace the reusable root view with a label. As follows:

In this way, there are no redundant view controls because the system ignores the tag and places the view in the label directly in the appropriate layout file, replacing the label.

Note: there are two main limitations to keep in mind when using this tag:

1. It can only be used as a follow-up to a layout file.

2. Every time you call LayoutInflater.inflate (), you must provide a View for the layout file as its parent container: LayoutInflater.from (this) .inherate (R.layout.mergelayout.mergelayoutlayoutparent.true)

? ViewStub

ViewStub is an invisible zero-size View that can be added to the layout file as a node, but its associated layout is not drawn until the runtime calls the ViewStub.inflate () or View.setVisibility (View.VISIBLE) methods.

Take a look at the effect picture first:

? ViewStub settings? Display

The layout activity_imageview associated with the upper ViewStub will not be instantiated (do not call the controls in the layout, because a null pointer exception will be reported before loading), only the program calls the following methods during run time:

FindViewById (R.id.viewStub) .setVisibility (View.VISIBLE); ((ViewStub) findViewById (R.id.viewStub)) .inflate ()

In the meantime, do not call the controls in the associated layout, because they have not been loaded yet.

Once ViewStub becomes visible or is inflate, it is no longer available (Id:viewStub is gone) because its position in the layout level has been replaced by the layout that has been instantiated, because it cannot be accessed, and the ID in the android:inflatedId attribute should be used. As follows:

@ Override public void onClick (View v) {switch (v.getId ()) {case R.id.btn_view: break; case R.id.btn_scheme: / / load, select one. FindViewById (R.id.v_stud) .setVisibility (View.VISIBLE); / ((ViewStub) findViewById (R.id.v_stud)) .inflate (); / / ID subTree used by layout after loading = findViewById (R.id.subTree) FindViewById (R.id.btn_iv_basis) .setOnClickListener (new View.OnClickListener () {@ Override public void onClick (View v) {Toast.makeText (MainActivity.this, "I am a control loaded by ViewStud", Toast.LENGTH_SHORT) .show ();}}) Break; case R.id.btn_invisible: subTree.setVisibility (View.INVISIBLE); break; case R.id.btn_visible: subTree.setVisibility (View.VISIBLE); break Calling case R.id.btn_init: / / ViewStub again after it becomes visible will report a null pointer because id:viewStub no longer exists. View viewStub = findViewById (R.id.viewStub); viewStub.setVisibility (View.GONE); break;}}? Summary

ViewStub is very useful, and we can use ViewStub to delay the loading of some View, shorten the first load time, and reduce some unnecessary memory allocation.

? Custom component optimization

Be careful when customizing View to avoid the following performance errors:

Redraw the View when not necessary.

Draw some pixels that are not seen by the user, that is, overdraw. (covered area)

Some unnecessary operations are done during drawing, resulting in the consumption of memory resources.

? Optimize

View.invalite () is the most widely used operation because it is the fastest way to refresh and update views at any time.

Be careful not to call unnecessary methods when customizing the View, as this can lead to repeated forced painting of the entire view level, consuming valuable frame drawing cycles. Check clearly when the View.invalite () and View.requestLayout () methods are called, as this affects the entire UI, causing GPU and its frame rate to slow down.

Avoid overdrawing. To avoid overdrawing, we can use the Canvas method to draw only what is needed in the control. The whole is generally especially useful when overlapping parts or controls. The corresponding method is Canvas.clipRect () (specify the area to be drawn)

In implementing the View.onDraw () method, you should not make any object allocation within the method or in the method you call. The object is assigned in this method, and the object is created and initialized. And when the View.onDraw () method finishes executing. The garbage collector frees memory. If View leads the drawing, then View will be redrawn 60 times in a second. So avoid allocating memory in the View.onDraw () method.

Never allocate memory in the View.onDraw () method or in the method you call to avoid causing a burden. The garbage collector releases memory multiple times, which can cause stutters. The best way is to instantiate these objects when the View is first created.

Layout optimization ends here, or after that sentence, if there is a better plan will be added in time, if there is a boss has other plans can also leave a message ha, thank you!

At this point, I believe you have a deeper understanding of "how to understand the layout optimization of Androd high-level performance optimization". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.