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

In the previous blog, I introduced two methods to optimize UI design. The first one is to use as few components as possible to implement layout functions, and the second one is to use the <meger> tag to reduce unnecessary root nodes. Both methods can improve the operating efficiency of the application UI, but are they enough? Far from enough. Methods are like money, and you can never have too many. So is it reasonable not to introduce more methods to optimize UI design?

I touch the almost four-year-old Diaosi phone in my pocket, which runs the old Android 2.2 system. For me, any application larger than 10M has the superpower to crash and freeze it. But for a certain message, it is now 24M in size and still runs like a rocket on the Diaosi phone's dying hardware resources (at least it has never crashed), which makes me sigh that the application optimization is quite good, and it also meets the emotional needs of Diaosi like us to shake a ball in the deep and lonely night. Therefore, an application can win the market not only because it wins the first opportunity, but more because it has better functions than you for the same needs, it is simpler than you for the same functions, and it runs faster than you for the same simple design!

Line up, one by one, slowly

When ActivityA says hello to ActivityB, "I'm going home, you take over.", the app immediately disappears without a trace. At this time, ActivityB is in a hurry to measure, layout, draw, and quickly come up with an interface to deal with the audience. They are very busy. What's more, they have to do a handover ceremony at this time - a super cool switching animation! However, under the powerful fundamental contradiction between the ever-increasing desires and the gradually shrinking resources, the system crashes for hundreds of milliseconds without hesitation. This freeze is a great psychological trauma for obsessive-compulsive patients in front of their phones. Naturally, they will say, "This software is really bad! It always freezes for a while before giving up when switching the screen." The user experience is instantly reduced to 0~

What are the solutions? Of course, the simplest one is to cancel the awesome switching animation, but if your product manager disagrees, you have to find another way. Without giving up the animation, we can delay the execution of some measures, layouts, and draws after the animation, and queue them up one by one. As for how to do it? Then we need to introduce a lightweight component <ViewStub>, which is a dynamic loading method.

We usually use it for preloading to improve page loading speed and fluency. ViewStub itself does not occupy the hierarchy, and it will eventually be replaced by the hierarchy it specifies. Sometimes we also need complex views and use them sparingly. We can load them when needed to reduce memory and improve the experience. In the past, we set them in the layout and then used the View.GONE property to hide the components, but it consumed resources and affected performance. In general, this thing is a lightweight View, which is an invisible control that does not occupy layout space and occupies very little resources.

Here is the code:

ActivityB layout to be loaded (ignore the complex 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 interface, when we switch to ActivityB, we need to consider the animation effect. So we let ViewStub postpone loading the more complex layout and load the simpler loading screen loading_image first. Later, we start loading the layout in the code. See the code below:

 @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); //Set loading resources  
  LoadHandler.postDelayed( new Runnable() {
 @Override    
 public   void run() {
 myStub.inflate(); //Start loading complex interface  
 loadingView.setVisibility(View.GONE); //Hide the simple interface for temporary loading  
 }
 }, 500 );

The above code implements the execution of complex animation first. When the interface switching reaches 500ms, the handler starts to execute the sub-thread of loading complex interface, thus staggering the centralized utilization of resources. The method used here is to dynamically add ViewStub to point to layout resources. It is simple and practical. For a user, delaying the loading of the interface for half a second is far more acceptable than switching screen freezes.

There are several main points to using ViewStub:

1. ViewStub can only be Inflated once. After Inflate, the ViewStub object is set to null. To put it more simply, when ViewStub is Inflated by a layout, it cannot be controlled by ViewStub because it has already completed its mission. Naturally, it is recommended to use visibility for situations where display and hiding are required 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 put the View in a certain layout file.

3. The merge tag cannot be nested in VIewStub.

Reusing layouts is a good habit

Reusing is a good habit. Since everyone often says that there is no truth without a picture, in order to avoid replies like "no picture you say a jb~", I will still reluctantly post a picture.

This interface consists of three small parts, namely the title bar, content display and bottom buttons. If you keep your fingers busy and click around, you will find that the styles of each interface are surprisingly similar! And it is not only reflected in this software, but also in most applications on the market! In fact, to put it bluntly, this is a question of style.

So, since there are so many repetitions, as standard coders in the 21st century, can we tolerate this waste? So we need to use the <include> tag - modular layout.

The layout is as follows: What a simple layout reuse, would you still say that you don’t like using the <include> tag?

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

The benefits of using <include> are:

1. Modular layout improves reuse rate and facilitates future maintenance and expansion.

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

Let me briefly talk about the rest

1. Reduce unnecessary inflation

(1) The inflated layout can be cached directly, using all variables instead of local variables to avoid the need to inflate again next time

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

(2) Usage of convertView cache of item in BaseAdapter, please refer to "About the use and optimization experience of BaseAdapter" for details.

PS: This is my first blog post and it’s so poorly written that it’s unbearable to read. . . . .

2. Avoid having too many views

Each view consumes memory. If you arrange too many views in a layout, the layout will take up too much memory. Assuming 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 given above is that the number of views should not exceed 80. Of course, the latest devices may be able to support so many views, but if poor performance really occurs, it is best to adopt this suggestion.

3. Don’t nest your layout too much

Layouts should not have too much nesting. Layoutopt (and the Android team) recommends that layouts be kept within 10 levels. Even for the largest tablet screens, the layout should not exceed 10 levels. RelativeLayout may be a solution, but its usage is more complicated. Fortunately, the Graphical Layout resource tool in Eclipse has been updated to make everything simpler.

Here is what layoutopt outputs when there are too many nested layouts:

-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 about some useless layouts, which helps to find out which layouts can be removed to avoid completely redesigning the screen layout.

4. In some scenarios, UI components drawn in non-main threads are used. I forgot the specific component names and will add them later when I remember them.

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