Android: an efficient UI is a popular UI (2). androidui

Android: an efficient UI is a popular UI (2). androidui

While the boss is not secretly leaving work early tonight, he has time to continue to talk about the pain of uidesign. This is also an example of the previous article "Android: an efficient UI is a great UI (I) complete supplement. If it is not well written, everyone will make a brick ~ (Come! ~)

Preface

In the previous blog, I explained two methods to optimize the UI design. The first one is to use as few components as possible to implement the layout function, the second is to use the <meger> label to reduce unnecessary root nodes. Both methods can improve the running efficiency of the application UI, but is it enough? It is far from enough. There will never be too many methods, just like money. So I will not introduce more methods for uidesign optimization. can I say this?

It's almost four years old and running the old android 2.2 machine in my pocket. For me, any application larger than 10 MB has the super power to crash several times. But for a certain letter, it is 24 MB in size and still runs on the dying hardware resources of the diaosi machine (at least never crashed ), I have to lament that application optimization is doing quite well, and it also meets our emotional needs to shake off on a deep lonely night. Therefore, an application can win the market, not only to win the lead, but also to do better functions with the same requirements. The same features are simpler than yours, it runs faster than you with the same simple design!

---------------------------------- I am a split line ------------------------------------- Tianwang gaitihu -------------------------------------------------------------

Queuing, one by one

When ActivityA said hello to ActivityB, "I'm going to go home. You'll come to the top ". It means that the system will be quickly slipped away without a trace. In this case, ActivityB will hurry to measure, layout, and draw to create an interface to deal with the audience first; what's even worse, they need to have a handover ceremony-the super-amazing switching animation! However, in the root contradiction between the increasingly infinite desire and the increasingly dry resources, the machine took hundreds of milliseconds without hesitation. This choppy beat the obsessive-compulsive patients on the phone, and naturally said, "This software is really scum! You will have to wait for a while before you break the picture ". The user experience instantly drops to 0 ~

What are the solutions? Of course, it is very easy to cancel the cool switching animation, but if your product manager does not agree, you cannot find another way. Without giving up the animation, we can delay some steps such as measure, layout, and draw after the animation. We can queue them one by one. How can we do this? We need to introduce a lightweight component <ViewStub>, that is, the dynamic loading method.

We usually use it for pre-loading to improve page loading speed and smoothness. ViewStub itself does not occupy the level and will eventually be replaced by the level it specifies. Sometimes we also need complex views with less use. We can load them as needed to reduce memory and improve the experience. In the past, we used to set the layout and used the View. GONE attribute to hide components. However, resource consumption affects performance. In general, this is a lightweight View. It is an invisible control that occupies a very small resource and does not occupy the layout.

The code below:

ActivityB layout to be loaded (ignore complicated animation code)

<meger xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="match_parent"    >    <ViewStub          android:id="@+id/mystub"          android:layout_width="match_parent"        android:layout_height="match_parent"        />    <ImageView        android:id="@+id/loading_image"          android:layout_width="match_parent"        android:layout_height="match_parent"        android:src="@drawable/loading_image"        /></meger>

In this UI, when we switch ActivityB, the animation effect is taken into account. So we let ViewStub temporarily load the complicated layout, and first load the relatively simple display loading screen loading_image. Then we will start loading the layout in the code later, see the following code:

@ Overrideprotected void onCreate (Bundle savedInstanceState) {super. onCreate (savedInstanceState); setContentView (R. layout. layout_loading); LoadHandler = new Handler (); myStub = (ViewStub) findViewById (R. id. mystub); loadingView = (ImageView) findViewById (R. id. loading_image); myStub. setLayoutResource (R. layout. layout_main); // sets LoadHandler to load resources. postDelayed (new Runnable () {@ Override public void run () {myStub. inflate (); // starts loading the complex interface loadingView. setVisibility (View. GONE); // hide the simple interface for temporary loading }}, 500 );

The code above implements complex animation first. When the interface is switched to Ms, handler starts to execute and load complex interface sub-threads, thus opening the centralized utilization of resources by mistake, the method of dynamically adding ViewStub to point to the layout resource is simple and practical. For a user, loading the interface with a delay of half a second is much easier to accept than freezing the switching screen.

When using ViewStub, You need:

1. ViewStub can only be set to Inflate once. After Inflate, The ViewStub object is set to null. To put it more commonly, when ViewStub is placed in Inflate, viewStub cannot be used to control it, because it has been retired. visibility is recommended for situations where it needs to be hidden in different scenarios.

2. ViewStub can only be used to Inflate a layout file. It is powerless for a single specific View. Of course, it is acceptable to include the View in a layout file.

3. The merge tag cannot be nested in VIewStub.

Reuse layout is a good habit

Reuse is a good habit. Since everyone is always talking about it, there is no picture and no truth.No picture you say a jb~ For this type of reply, I 'd better figure it out.

This interface consists of three parts: the title bar, content display, and bottom buttons. If you don't have to worry about it, just click it and you will find that the style of each interface is surprisingly similar! It is not only reflected in this software, but also in most applications on the market! To put it bluntly, this is a style issue.

So, since there are so many duplicates, can we endure this waste as a norm farmer in the 21st century? Therefore, we need to use the <include> label-modular layout.

The layout is as follows: simple layout reuse. Do you still say that you do not like to use the <include> label?

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="fill_parent"    android:layout_height="fill_parent"    android:orientation="vertical"    > <include android:id="@+id/head_menu" layout="@layout/head_menu" /> <include android:id="@+id/content" layout="@layout/content_showweibo" /> <include android:id="@+id/bottom_menu" layout="@layout/bottom_menu" /></LinearLayout>

Advantages of using <include>:

1. modular layout to improve the Reuse Rate and facilitate future maintenance and expansion.

2. Reduce the weight of the generated app. The user traffic is very expensive!

Briefly Talk About the remaining points

1. Reduce Unnecessary inflate

(1) The layout of inflate can be directly cached. replace local variables with all the variables to avoid inflate again next time.

if (loadingView != null) {    loadingView.setVisibility(View.VISIBLE);}else{    loadingView =LayoutInflater.from(context).inflate(R.layout.loadingView, this, true);}

(2) convertView Cache Usage of items in BaseAdapter. For details, refer to "usage and optimization of BaseAdapter".

PS: I wrote a blog post for the first time, but I cannot read it ......

2. avoid having too many views

Each view consumes memory. If too many views are arranged in one layout, the layout occupies too much memory. If a layout contains more than 80 views, layoutopt may give the following suggestions:

-1:-1 This layout has too created views: 83 views, it shoshould have <= 80!

The suggestion above is that the number of views cannot exceed 80. Of course, the latest device may support so many views. However, if the performance is poor, you 'd better adopt this suggestion.

3. Never nest too many la s

Layoutopt (and the Android Team) suggests that the layout should be within 10 levels. The layout should not exceed 10 levels even for the largest tablet screen, relativeLayout may be a solution, but its usage is more complex. It is better to make it easier after the Graphical Layout resource tool in Eclipse is updated.

The following figure shows the output content of layoutopt when there are too many layoutopt la s:

-1:-1 This layout has too created nested layouts: 12 levels, it shoshould have <= 10! 305: 318 This LinearLayout layout or its RelativeLayout parent is possibly useless

Nested layout warnings are usually accompanied by warnings of useless la S, which help to identify which la s can be removed and avoid all la s being redesigned.

4. In some scenarios, I used a UI component drawn by a non-main thread. I forgot the specific component name. I want to add it later.

 

By enjoy wind chimes
Source:Http://www.cnblogs.com/net168/
The copyright of this article is shared by the author and the blog Park. You are welcome to reprint this article. However, you must keep this statement without the author's consent and provide a connection to the original article clearly on the article page. Otherwise, you will not be reposted next time.

Android development experience: in a UI, You need to click an image (the image has a certain position and size) to switch the application interface.

Android: scaleType = "fitXY"

Has anyone introduced the third-party open-source android UI components?

Continue learning with patience. You have little knowledge about android. The problem you described does not exist. Be patient.
One step at a time.
Track: familiar with the controls provided by the android system-familiar with system controls, changing various control styles-in-depth study of source code, custom controls-.