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

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

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 still 24 MB in size and runs on the dying hardware resources of the diaosi machine, for example, it has not crashed at least ), 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!

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:

The layout of ActivityB to be loaded is complex. Ignore the 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:

 
 

  
  
@ Override
  
  
Protected 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); // you can call this operation to load resources.
  
  
LoadHandler. postDelayed (new Runnable (){
  
  
@ Override
  
  
Public void run (){
  
  
MyStub. inflate (); // starts loading complex interfaces.
  
  
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. To avoid saying 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 many views: 83 views, it should 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 recommend that the layout 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 many nested layouts: 12 levels, it should 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.

Link: http://www.cnblogs.com/net168/p/4017921.html