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

Android: an efficient UI is a popular UI (2)
Preface in the previous blog, I introduced 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 ----------------------------------- tiantiantiao queued up, one by one slowly when ActivityA and ActivityB say: "I want to go home, you 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 following code: The ActivityB layout to load (ignore complex animation code) copies the 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_p Arent "android: src =" @ drawable/loading_image "/> </meger> copy the code on 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: copy the 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. layo Ut_main); // set the LoadHandler to load the resource. 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); copy the code above to execute a complex animation first. When the interface is switched to Ms, handler starts to execute and load complex interface sub-threads, thus staggered the centralized use of resources. Here we use the method of dynamically adding ViewStub to point to the layout resource, which is simple and practical, for a user, loading the interface with a latency of half a second is much easier to accept than switching the screen. ViewStub requires the following main points: 1. ViewStub can only be Inflate once. After Inflate, The ViewStub object is set to a null value. A more common point is that after ViewStub is Inflate by a layout, 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. It is a good habit to reuse the layout. 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? Copy the Code <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"/> </LinearL The advantages of ayout> copying code using <include> are: 1. modular layout, improved reuse rate, and easy to maintain and expand in the future. 2. Reduce the weight of the generated app. The user traffic is very expensive! Let's 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 the next inflate 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: blog post written for the first time, you can't read it ...... 2. avoid having too many views. Each view consumes memory. If too many views are arranged in a layout, the layout will occupy too much memory. Assume that a layout contains more than 80 views, layoutopt may give the following suggestions:-1:-1 This layout has too custom 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. Do not layout nested layout too much layout should not have too many nesting. layoutopt (and the Android Team) suggests that the layout should be 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 complicated. Fortunately, after the Graphical Layout resource tool in Eclipse is updated, it makes all this easier. The following figure shows the output content of layoutopt when there are too many layoutopt la S:-1:-1 This layout has too has 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 laent S, helping to identify which layout can be removed and avoid all screen 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.