Android: An efficient UI is a pull-wind UI (ii)

While the boss is not sneaking off early tonight, so sometimes I continue to pull the pain of the UI design, but also is a "Android: An efficient UI is a pull the wind UI (a)" full complement it. If you don't write well, you can shoot bricks. Hit me to kill me ~)

Objective

The previous blog ransacked the two ways to optimize the UI design, the first is to use as few components as possible to implement the layout function, the second is to use <meger> tags to reduce unnecessary root nodes , both of which can improve the efficiency of the application UI running, But is it enough? Is far from enough, the method is like money never too much, so no longer introduce a few more UI design optimization method is plausible?

Touch the pocket inside the four-year-old, running the old Android 2.2 system of the cock silk machine for me, any application of more than 10M has been a burst of his several street crashes the ability to collapse. But for a letter, it is now 24M of the size of the screw machine is still on the verge of dying hardware resources to run flying (at least not crash), so I have to sigh that the application of the optimization done quite well, but also to meet us this kind of cock silk in the deep lonely night to shake the emotional needs. Therefore, an application can win the market, not only to win the opportunity, but more because the same needs it function to do better than you, the same features it than your minimalist, the same minimalist design it runs faster than you!

----------------------------------I am the split line---------------------------------the king of the ground tiger-------------------------------------------- -----------------

Line up, one by one slowly

When Activitya with Activityb said: "I want to go home, you come on top." The explanation immediately slipped into a trace, at this time, activityb hurriedly measure ah, layout ah, draw ah hurriedly make an interface to deal with the audience first, busy the joy; what's more, they're going to have a handover ceremony--super-awesome switch animation! However, in the increasingly boundless desire and gradually withered resources this powerful fundamental contradiction, without hesitation when the machine for hundreds of milliseconds. This is how much psychological trauma the compulsive patient in front of the cell phone is, and it's natural to say: "This software is so scum!" Cut a picture will have to have a meal to forget. " User experience instantly drops to 0~

What are the solutions? Of course, it's easy to cancel the awesome toggle animation, but if your product manager doesn't agree, there's no way to find it. In the premise of not giving up the animation, we can put some measure Ah, layout ah, draw AH step delay in the animation after the execution of the line, queued to one, as to how to operate it? Then we're going to introduce a lightweight component, <ViewStub>, which is a dynamic load method.

We usually use it to do preload processing, to improve page loading speed and improve fluency, viewstub itself does not occupy the hierarchy, it will eventually be replaced by its designated hierarchy. Sometimes we also need complex views and less, and we can load them as needed to reduce memory and improve the experience. Previously we were all set up in the layout and then used the View.gone property to hide the component, but consuming resources affected performance. This thing is a lightweight view, it's an invisible, non-occupying layout, and takes up very small resources.

The following code:

Activityb layout to load (ignore complex animation code)

<Megerxmlns:android= "Http://schemas.android.com/apk/res/android"Android:layout_width= "Match_parent"Android:layout_height= "Match_parent"    >    <viewstubAndroid:id= "@+id/mystub"Android:layout_width= "Match_parent"Android:layout_height= "Match_parent"        />    <ImageViewAndroid: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 activityb, we take into account the animation effect. So we let viewstub load more complex layout, and the more simple display loading screen loading_image loaded, when we later in the code to start loading the layout, see the code as follows:

@Overrideprotected voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate);            　　Setcontentview (r.layout.layout_loading); Loadhandler=NewHandler (); Mystub=(viewstub) Findviewbyid (r.id.mystub); Loadingview=(ImageView) Findviewbyid (r.id.loading_image); Mystub.setlayoutresource (r.layout.layout_main);//Set Load ResourceLoadhandler.postdelayed (NewRunnable () {@Override Public voidrun () {mystub.inflate ();//start loading complex interfacesLoadingview.setvisibility (View.gone);//hide the simple interface that is temporarily loaded 　　　　 }},500);

The above code implementation of the first complex animation, when the switch interface to 500MS, handler began to load complex interfaces, thus stagger the centralized use of resources, where the use of dynamic add Viewstub point to the layout of resources, simple and practical, for a user, The delayed half-second loading interface is much easier to accept than the toggle screen.

The main points to use Viewstub are:

1, viewstub can only be inflate once, when inflate after the Viewstub object is set to null value, said more popular point is when Viewstub is a layout inflate, it can not be controlled by viewstub, because it has been retire, Naturally, it is recommended to use visibility to show hidden situations in different scenarios.

2, viewstub can only be used to inflate a layout file, for a single specific view it is powerless, of course, if the view in a layout file is also acceptable.

3, Viewstub cannot nest merge tag.

Reusing layouts is a good habit

Reuse is a good habit, since we often say, no picture no truth Ah Lou Zhu, in order to avoid everyone said no pictures you say a JB~ this kind of reply, I still barely the last picture bar.

The interface consists of three small parts, namely the title bar, the content display, and the bottom button. If your finger restless up and down, press a button, and you'll find the style of each interface surprisingly similar! And not only in this software will be reflected, and most of the market applications are like this! In fact, this is a question of style.

So, since so much repetition, as the 21st Century standard Code Farm we, can we endure this waste? So we're going to use the <include> tag-- Modular layout .

The layout is as follows: How easy is it to reuse your layouts, and would you say you don't like to use <include> tags?

<LinearLayoutxmlns:android= "Http://schemas.android.com/apk/res/android"Android:layout_width= "Fill_parent"Android:layout_height= "Fill_parent"android:orientation= "vertical"    > <includeAndroid:id= "@+id/head_menu"Layout= "@layout/head_menu" /> <includeAndroid:id= "@+id/content"Layout= "@layout/content_showweibo" /> <includeAndroid:id= "@+id/bottom_menu"Layout= "@layout/bottom_menu" /></LinearLayout>

The benefits of using <include> are:

1, modular layout, improve the reuse rate, easy to maintain and expand later.

2, reduce the weight of the generated app, the user's traffic is very expensive!

Simply say the rest of the point

1. Reduce unnecessary inflate

(1) For inflate layout can be cached directly, with all variables instead of local variables, to avoid the next need to inflate

if NULL ) {    loadingview.setvisibility (view.visible);} Else {    thistrue);}

(2) Convertview cache usage of item in Baseadapter, please refer to " about baseadapter usage and optimization "

PS: The first time to write the blog, write the slag can not see ...

2. Avoid having too many views

Each view consumes memory, too many views are placed in one layout, the layout consumes too much memory, and if a layout contains more than 80 views, layoutopt might suggest the following:

-1:-1 This layout had too many views:83 views, it should had <= 80!

The advice given above is that the number of views cannot exceed 80, and of course the latest devices may be able to support so many views, but if there is a real performance situation, it is best to adopt this recommendation.

3. Do not embed too many layouts

Layouts should not have too many nesting, layoutopt (and Android team) recommend that the layout remain within 10 levels, even the largest tablet screen, the layout should not exceed 10 levels, relativelayout may be a solution, but its usage is more complex, Fortunately, the graphical Layout resource tool in Eclipse has been updated to make it all easier.

The following is the output of the layoutopt when the layout is too nested:

-1:-1 This layout had too many nested layouts:12 levels, it should has <= 10! 305:318 this linearlayout layout or it relativelayout parent is possibly useless

Nested layout warnings are often accompanied by warnings of unwanted layouts, helping to find out which layouts can be removed, and avoid all screen layouts being redesigned.

4, in some scenarios using non-main thread drawing UI component, the specific component name I forgot, back to make up Kazakhstan.

Enjoy wind chimes
Source: http://www.cnblogs.com/net168/
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph statement, and in the article page obvious location to the original connection, or next time not to you reproduced.

Android: An efficient UI is a pull-wind UI (ii)