Android: An efficient UI is a cool UI (Part 1)

Introduction

Android is an operating system that runs on mobile terminals. The biggest difference from traditional PCs is that the resource shortage problem on mobile terminals is "relatively" obvious. Of course, for some Diaosi models, it should be described as "very" reliable. Therefore, it is often the case that some software is abnormally terminated when running on some old models that lack youthful vitality; however, as an Internet manufacturer, the vast number of Diaosi machine users must be a large amount of user resources. Is this a market that can be abandoned? ! Of course not o(╯□╰)o, so we must improve the efficiency of the software as much as possible to win the customer's smile, Diaosi is also a customer!

This blog mainly introduces how to improve efficiency and reduce resource utilization in UI design. After all, in today's world of terminal resource shortage, efficiency is always king. We don't judge a UI interface by how complex it is, or how flashy it is. A simple but extraordinary and efficient UI interface is a very awesome interface design.

Introduction

In Android applications, it is not a recommended method to write interfaces in a hard-coded way. Of course, hard-coded interfaces are more efficient and flexible than soft-coded interfaces based on XML files, but they are very difficult to maintain. The complicated code will make the program full of landmines, and the application may be destroyed one day. Therefore, unless it is absolutely necessary to use code to write hard-coded interfaces, it is better to use easy-to-maintain XML for other situations.

Therefore, the UI optimization design in this article ultimately boils down to the optimization design of XML layout files.

In the development environment provided by Google, there is a very useful tool - hierarchyviewer. It is estimated that many people have never paid attention to this small tool hidden in a remote corner; it can easily help us analyze the structure and construction efficiency of the UI interface. The location of this tool is in the sdk/tools/ folder.

Downstairs picture:

Hello everyone, I am Tu~

This is an analysis of an XML interface with only one TextView component in its layout. The figure tells us that a total of four components are used to construct this interface, which means that the components need to be drawn four times. Naturally, each drawing of a component consumes resources.

Now let’s move on to the crazy, cool and awesome theme section. . . .

Try to complete the layout in the fewest steps possible

I am a good youth in society, I save resources for the country; of course, as a component, this awareness is also needed. The drawing of each component will consume more or less terminal resources. So we can't listen to our ancestors here: Han Xin selected the more soldiers, the better. The only way out for UI design is to streamline the army and simplify the government. Don't believe it? OK! Let's start with a comparative example.

[[121125]]

Isn't this simple? Isn't it a matter of minutes with a few lines of code?

 <RelativeLayout
    android:layout_width= "wrap_content"  
    android:layout_height= "wrap_content"  
    android:gravity= "center" >
 <Button
        android:id= "@+id/button1"  
        android:layout_width= "wrap_content"  
        android:layout_height= "wrap_content"  
        android:background= "@drawable/btn_backgroup"  
 />
 <ImageView
        android:id= "@+id/imageView1"  
        android:layout_width= "wrap_content"  
        android:layout_height= "wrap_content"  
        android:layout_alignParentLeft= "true"  
        android:layout_centerVertical= "true"  
        android:src= "@drawable/header_back" />
 </RelativeLayout>

Don't rush to look at the code, it's tiring and hurts your eyes. Just look at the picture in the hierarchyviewer.

A small button uses 3 components to draw, which is 3N complexity. If there are 5 such buttons, 15 components are needed. If there are 10 buttons, 30 components are needed. If there are N++, oh my god, I dare not imagine it. In this case, should we consider optimization? After looking through the data, we found that this button can be realized without so many components.

 Button
    android:id= "@+id/button1"  
    android:layout_width= "wrap_content"  
    android:layout_height= "wrap_content"  
    android:background= "@drawable/btn_backgroup"  
    android:drawableLeft= "@drawable/header_back"  
 android:gravity= "center"  
 android:padding= "10dp"  
 />

It’s still the same button, still the same taste, and the complexity is reduced from 3N to N!!! Do you dare to say that you don’t want to improve this efficiency???

Summary: When designing UI layout, we should start with the premise of using as few components as possible. Since the system components are well encapsulated, it is possible to achieve better efficiency by implementing multiple simple components in a more complex component. Because each component needs to be drawn independently, the resources wasted by drawing multiple components not only harm our application, but also deeply hit the self-esteem of the users who cannot afford high-end machines - "Fuck, this software is not usable again!"

You don't work? I'll fire you.

Do we still remember the picture given at the beginning? All we used in the layout was a TextView, and RelativeLayout seemed to have done nothing. . . . . .

We never advocate working without doing anything, and this is also the unspoken rule in the software industry. Out of a sense of justice in building a harmonious society, we certainly cannot sit idly by and watch RelativeLayout's rogue behavior of standing in the toilet without doing anything, so we need to use a solution - the <merge> tag, which can help us get rid of some unnecessary root nodes. In order to have a better visual experience, I used a more complex layout (actually not complex at all),,

Main layout XML file:

 < FrameLayout   xmlns:android = "http://schemas.android.com/apk/res/android"  
 android:id = "@+id/layout1"  
 android:layout_width = "match_parent"  
 android:layout_height = "match_parent"  
 >  
 < ImageView   android:id = "@+id/image1"  
 android:layout_width = "match_parent"  
 android:layout_height = "wrap_content"  
 android:src = "@drawable/bg"  
 />  
 < com.net168.text.MyLayout   
 android:id = "@+id/layout2"  
 android:layout_width = "match_parent"  
 android:layout_height = "match_parent"  
 >  
 < /com.net168.text.MyLayout >  
 </ FrameLayout >  

Combined control layout XML file:

 < LinearLayout   xmlns:android = "http://schemas.android.com/apk/res/android"  
 android:layout_width = "wrap_content"  
 android:layout_height = "wrap_content"  
 android:orientation = "horizontal"  
 >  
 < Button   android:id = "@+id/button2"  
 android:layout_width = "wrap_content"  
 android:layout_height = "wrap_content"  
 android:text = "button2"  
 />  
 < TextView   android:id = "@+id/text1"  
 android:layout_width = "wrap_content"  
 android:layout_height = "wrap_content"  
 android:text = "text1"  
 android:textColor = "#ff0000"  
 />  
 </LinearLayout>​​  

This interface is so ugly that I can’t bear to look at it:

Ugly as it is, we still need to continue to use the artifact hierarchyviewer to look at this XML-generated interface structure diagram to explore the colorful world inside the ugly girl~~~~~~~

Damn... The layout of the three components actually uses six layers of nested layouts. I suddenly felt a deep sense of waste, like a young lady marrying an old bachelor. Let's start with the pictures. The first and second layers of components are automatically generated by the system. This is a done deal and cannot be negotiated unless you go to the bottom layer and have a good talk with them. But~but the third layer FrameLayout and the fifth layer LinearLayout are just showing off their presence , so we have to be ruthless and get rid of them. How? Use the <merge> tag.

Since the <merge> tag can only be used as a root element, we can modify both root elements slightly as follows:

Main layout XML file:

 < merge   xmlns:android = "http://schemas.android.com/apk/res/android"  
 android:id = "@+id/layout1"  
 android:layout_width = "match_parent"  
 android:layout_height = "match_parent"  
 >  
 < ImageView   android:id = "@+id/image1"  
 android:layout_width = "match_parent"  
 android:layout_height = "wrap_content"  
 android:src = "@drawable/bg"  
 />  
 < com.net168.text.MyLayout   
 android:id = "@+id/layout2"  
 android:layout_width = "match_parent"  
 android:layout_height = "match_parent"  
 >  
 < /com.net168.text.MyLayout >  
 </ merge >  

Combined control layout XML file:

 <merge xmlns:android= "http://schemas.android.com/apk/res/android"  
    android:layout_width= "wrap_content"  
    android:layout_height= "wrap_content"  
 >
    <Button android:id= "@+id/button2"  
        android:layout_width= "wrap_content"  
        android:layout_height= "wrap_content"  
        android:text= "button2"  
 />
    <TextView android:id= "@+id/text1"  
        android:layout_width= "wrap_content"  
        android:layout_height= "wrap_content"  
 android:text= "text1"  
        android:textColor= "#ff0000"  
 />
 </merge>

PS: Note that you need to add a setOrientation(LinearLayout.HORIZONTAL) statement in the composite control class to ensure the horizontal arrangement of the components.

Continue to use the artifact to look at the structure:

Huhuhu~~ Has the structure been reduced from six layers to four layers? What a refreshing feeling! I feel like I’m floating on the surface. The improvement in efficiency is unquestionable. . . .

Summary: The <merge> tag can completely replace the <FrameLayout> layout component. For other uncomplicated layout components such as linear layout and other composite components, you can use the <merge> tag after setting its properties in the inherited subclass . The <merge> tag does not occupy resources, and naturally no corresponding components will be generated when the interface is generated . Another point to note is that <merge> can only be used as a root element . When you need to use inflate to generate a layout file, you must specify a ViewGroup as its parent element, and set the attachToRoot parameter of inflate to true. (Refer to inflate(int, ViewGroup, boolean)).

Link to this article: http://www.cnblogs.com/net168/archive/2014/10/09/4004950.html