UI Tuning for Android

For an app's UI, the improvement goal in fluency is to reduce the delay in screen drawing, creating a smooth and stable frame rate to avoid stalling.

Ideally, the overall measurement, layout and drawing time is best within 16ms, in order to ensure the smoothness of the screen running. And how to evaluate and analyze screen rendering and UI performance, there are tools in the Android SDK that are used to render performance issues for policy apps.

First, the hierarchical analysis of views:

There are three steps required for each view: measurement, layout, and rendering. How the app draws the view, which needs to be measured from the top node, is rendered one at a time along the layout tree, the more the hierarchy of the view tree, the more the number of nested measurements, the longer the measurement. Once the measurement is complete, the layout is laid out, each view lays out its own sub-view, the child views are laid back to the parent view, and then to the root view, and each view is drawn on the screen when the layout is completed.

Obviously, the more views the app has, the longer it takes to measure, layout, and draw the deeper the hierarchy, in order to reduce these times, you need to flatten the view level as much as possible and delete any views that are not necessarily rendered.

While you can view the layout's node view in an XML layout file, it's hard to find redundant views, and in order to find these extra views, you can use the Hierarchy Viewer tool in Android Studio to analyze the views in the Android app.

The Hierarchy Viewer (Hierarchy Viewer) provides a convenient way to visually view the various view nesting relationships that can be used to study the XML view structure. (Requires a device running Android app)

This tool allows you to view the level of our view, so that we can modify our layout using it.

General recommendations:

The use of abstract layout labels (include, viewstub, merge) is primarily intended to optimize the layout, removing unnecessary nesting and view nodes.

1. View Reuse

More for list forms such as ListView and Recylerview

1. Using the include nested layout to implement the modular design of the layout, it is necessary to consider the use of the merge tag as discussed below.
2. <merge> tags

The use of include may result in too many layouts nesting, unnecessary layout nodes, resulting in slow parsing, unnecessary nodes and nesting can be viewed through the hierarchy Viewer or settings--developer options, display layout boundaries. The merge tag plays a very important role in the structure optimization of the UI, and it can prune unnecessary layers and optimize the UI.
Merge is used to replace framelayout or when one layout contains another, the Merge tab eliminates the extra view groups in the view hierarchy.

The Merge tab can be used in two typical cases:
A. the top node of the layout is framelayout and does not need to set properties such as background or padding, which can be replaced with merge because the parent view of the activity content view is a framelayout. So you can use merge to eliminate only one left.
B. when a layout is used as a sub-layout by another layout include, use merge as the top node of the layout, so that the top nodes are automatically ignored when they are introduced, and all of their child nodes are merged into the main layout.

1. <ViewStub>

The viewstub tag can be used to introduce an external layout as well as an include tag, but the layout introduced by Viewstub does not expand by default, which saves both the display and the location, saving CPU and memory when parsing layout.
Viewstub is often used to introduce layouts that are not displayed by default, only in special cases, such as progress layouts, refresh layouts for network failures, prompt layouts for information errors, and so on.

For example, suppose Network_error.xml is a layout that needs to be displayed only in the case of a network error and is not resolved by default.
When we want to use, there are two ways to use, the effect is the same:

((viewstub) Findviewbyid (R.id.layout_error)). Setvisibility (view.visible);

Or

View Importpanel = ((viewstub) Findviewbyid (R.id.layout_error)). Inflate ();

Ii. Reduction of resources

The 1th is to flatten the app's view structure and reduce the number of views, but we can also try to reduce the amount of resources used in each view. (such as referencing a resource at load time, coloring at run time)

Three Excessive drawing of the screen

The concept of screen over-rendering is somewhat similar to the concept of layers in Photoshop, where the layers above cover the layers below, making the layers below invisible. When the Android system draws the screen, the parent view is first drawn and then the child view, and the child view is on its parent view.

The behavior of redrawing the screen is called over-drawn, and multiple screen draws increase latency and can cause the layout to stutter.

Since the impact of over-drawing is so great, how should we detect it?

Android offers some great tools to detect over-rendering, but typically in the debug GPU overdraw menu, choose "Show overdraw area" (In my phone for the debug GPU in developer options), The selection will then overwrite different colors in different areas of the app to indicate the number of times the drawing is over. Compare these different colors on the screen to quickly locate the problem.

White: Not Over-drawn

Blue: 1 times over-drawn (screen drawn 2 times)

Green: 2 times over-drawn

Light red: 3 times over-drawn

Dark red: Over-drawn 4 or more times

Another way to look at this is to save the view hierarchy as a Photoshop document with the Hierarchy Viewer tool mentioned earlier, and open the views to see different levels of over-rendering.

Iv. analysis of the lag (strategy GPU rendering capabilities)

After optimizing the hierarchy and over-drawing of the view, the app also has dropped frames or is not fluent, in order to obtain more comprehensive lag detection information, the Android system has a profile GPU rendering developer option, it can detect each frame on the screen for how long, The policy data can be saved to the log file or displayed in real time on the device. In general, it is more intuitive to show the GPU's rendering data directly on the screen.

In my phone, find the "GPU Rendering mode Analysis" in the developer options, select "Show as bar on screen", then open a mobile phone QQ, find the situation as shown

Need to pay attention to the bottom of the horizontal Green Line, which means that the device renders a frame to 16ms, each frame is a horizontal bar, if there are many frames above the green line indicates that the device has a lag situation.

Five, make it look faster

As mentioned earlier, if you find the problem by testing to optimize the layout to make the UI drawing smoother, there is actually a way to make the UI draw faster: Make it look faster.

1. Progress bar
2. Animation
3. Instant Update: When a user updates a page, the data on the page changes immediately, even if the data does not reach the server (where it is necessary to determine that the data will eventually be updated to the server) (offline upload, send network requests offline)

Or another way of thinking, when users add text about a picture post, upload images to the server in advance.

UI Tuning for Android