Android: an efficient UI is a popular UI (1)

Android: an efficient UI is a popular UI (1)

Opening

Android is an operating system running on mobile terminals. The biggest difference with traditional PCs is the shortage of resources on mobile terminals, it should be described as "very" to be reliable. Therefore, it is often the case that some software is terminated abnormally on an old machine that lacks youthful vigor. However, as an Internet manufacturer, the vast majority of silk machine users must be a large user resource. Can this be a market that can be abandoned ?! Of course, it is not "o", so we should try our best to improve the efficiency of the software to win the customer's smile, and the diaosi is also the customer!

This blog mainly introduces how to improve the efficiency of uidesign and reduce the use of resources. After all, in today's end-to-end resource shortage, efficiency is always king. We judge how complicated a UI is, or how dazzling a UI is. A simple and extraordinary efficient UI is an awesome interface design.

Introduction

In android applications, writing interfaces using hard encoding is not an advocate method. Of course, the hard coding interface is more efficient and flexible than the soft encoding Interface Based on XML files, but it is not easy to maintain. The complicated code will make the program more complicated, maybe the application may be terrible someday. Therefore, if it is necessary, you must use the code to write the hard-coding interface. In other cases, it is better to use the easy-to-maintain XML for writing.

Therefore, the UI optimization design comes down to the optimization design of the XML layout file.

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

Downstairs:

Hello, everyone. I am a figure ~

This analyzes the XML interface with only one TextView component in a layout. The figure shows that four components are used to construct this interface, that is, four components need to be drawn, naturally, every time a component is drawn, resources are required.

Next we will step into the theme part of the crazy cool sky ....

Complete layout with the least steps possible

I am a good social youth, and I am a national and provincial resource. Of course, as a component, I also need this awareness. Every component will be drawn more or less consuming terminal resources. So here we can't listen to our ancestor's words: Han Xin dianbing is more and more helpful, and jianzheng is the only way out for uidesign. Don't believe it? OK! The following is an example of comparison.

Isn't that easy? Isn't several lines of code a minute?

 
 

  
  
<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 read the code. If you get tired and hurt your eyes, just look at the figure in hierarchyviewer.

A small button is drawn using three components, which is the complexity of the 3N. If there are five such buttons, 15 components are required, if there are 10 buttons, there will be 30. If there are N + + buttons, you can't imagine it. In this case, we should consider the optimization and optimization. After turning over the information, we found that we could not use so many components to implement this button.

 
 

  
  
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" 
  
  
    /> 

 
 

Still the original button, or the original taste, complexity reduced from 3N to N !!! You dare say you don't want to improve this efficiency ????

Conclusion 1: when designing the UI layout, we should start with using as few components as possible, because the system components are well encapsulated, by assigning multiple simple components to a complex component, you can achieve better efficiency. Because every component has to be drawn by itself, it is a waste of resources to draw multiple components that not only harm our applications, it is even more deeply affected by the self-esteem of high-end machine-"Fuck, this software is useless! ".

Don't you work? Quit.

Do we still remember a chart we just gave? We only use a TextView in the layout, and RelativeLayout seems to be useless ......

We have never advocated that we do not do anything without work. This is also the implicit rule in the software field. Out of the sense of justice in building a harmonious society, we certainly cannot sit down and look at the rogue behavior like RelativeLayout, so we need a solution -- <merge> label, it can help us eliminate unnecessary root nodes. In order to have a better visual sense, I used a more complex layout, which is actually not complicated at all ),,

XML file of the main layout:

 
 

  
  
<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> 
 
 

Widget 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 ugly and can't bear to look directly at it:

Ugly, we still need to use the hierarchyviewer to look at the interface structure generated by the XML to explore the rich and colorful world of the ugly girl ~~~~~~~

I rely on .... The layout of the three components actually uses a six-layer nested layout. In an instant, there is a deep sense of waste for the big girl to marry the old bachelor. We started to look at the figure. The components on the first and second layers are automatically generated by the system. This is something that cannot be discussed on the Board unless you talk to them at the bottom layer. But ~ However, FrameLayout on the third layer and LinearLayout on the fifth layer are completely in the sense of presence, so we have to work hard on them. How can we come? Use the <merge> label.

Because the <merge> label can only be used as the root element, We Can slightly modify these two root elements, as shown below:

XML file of the main layout:

 
 

  
  
<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> 
 
 

Widget 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 setOrientation (LinearLayout. HORIZONTAL) to the class of the composite control to ensure HORIZONTAL arrangement of the Self-component.

Continue to look at the structure with an artifact:

Call ~~ Is it from the sixth layer to the fourth layer structure? I feel like a little fresh, and I feel like a float. The improvement in natural efficiency is beyond doubt .....

Conclusion 1:<Merge> labels can replace <FrameLayout> with labels. For other complex layout components, such as linear layout, you can set its attributes in the inherited subclass, or use the <merge> label. <merge> label does not occupy resources. Naturally, no corresponding component is generated when the interface is generated. Note that <merge> can only be used as the root element. When you need to use inflate to generate a layout file, you must specify a ViewGroup as the parent element and set the attachToRoot parameter of inflate to true. Refer to inflate (int, ViewGroup, boolean )).

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