Objective
This article is the Android optimized Layout section, which should be important in Android, whether in a custom control, or in a simple writing layout, should try to follow some optimization principles, so that the layout of the drawing efficiency is higher, the experience can be better.
a Optimized Layout the Hierarchy
If the layout structure is too complex, the drawing process of Android will be very complex, the measure process will be very complex, I analyzed the view drawing mechanism in detail the entire measurement, layout and drawing process, overly complex, nested layout can cause performance problems.
1.1 Avoid nesting
Nested linearlayout may make the View hierarchy very deep. When using linearlayout, we usually prefer to use nested layouts to dynamically set a view's visibility, because linearlayout is linear, so even hiding a view does not affect the arrangement of other view. In Relativelayout, the position of view is relative to other view, so, after hiding, it will cause the previous view to have no reference object, resulting in relative position change, then you can use alignwithparentifmissing= " True "to handle this situation.
In addition, the calculation of linearlayout with nested layout_weight parameters is particularly large because each child element needs to be measured two times. This is especially important for Layout that requires multiple repetitions of the inflate, such as when using a ListView or GridView.
1.2 Use Merge Label Optimization Hierarchy
Using include may cause the layout to be nested too much, resulting in unnecessary layouts nodes, which can cause parsing to become slower.
The Merge tab can be used in two typical cases:
- The top node of the layout is framelayout and does not need to set properties such as background or padding, which can be replaced with the merge because the parent view that the activity content tries is a framelayout. So you can use merge to eliminate only one left.
- When a layout is used as a sub-layout by another layout include, use merge as the top node of the layout, so that the top nodes are automatically ignored when they are introduced, and all of their child nodes are merged into the main layout.
For example, if you have a layout that is a vertical linearlayout that contains two consecutive view that can be reused in another layout, then you would do a linearlayout to include the two view for reuse. However, when using another linearlayout to nest this reusable linearlayout, this nesting linearlayout does not make sense except to slow down your UI performance.
To avoid this situation, you can replace the root node of the reusable Layout with elements. For example:
|
<merge xmlns:android= "Http://schemas.android.com/apk/res/android" > <button Android:layout_width= "Fill_parent" android:layout_height= "Wrap_content" android:text= "@string/add"/> <button Android:layout_width= "Fill_parent" android:layout_height= "Wrap_content" android:text= "@string/delete"/> </merge> |
Now, when you want to include this layout in another layout (and use a tag), the system will put two buttons directly into layout, without any extra layout being nested.
two Reuse with Tags Layout
If your program UI reuses a layout in different places, this section teaches you how to create efficient, reusable layout parts and "include" them into UI layout.
To efficiently reuse the entire layout, you can use and tag to embed other layout into the current layout.
three load views on demand
In addition to simply incorporating one layout into another, you might want to start loading only when your layout is visible to the user after the program has started.
3.1 you do not need to load the layout immediately, set to GONE , the system skips, does not load
3.2 Use viewstub implement on-demand loading
Viewstub is a lightweight view that does not require size information and does not draw anything in the added Layout. Each viewstub only needs to set the Android:layout property to specify the type of layout that needs to be inflate. Viewstub is often used to introduce layouts that are not displayed by default, only in special cases, such as progress layouts, refresh layouts for network failures, prompt layouts for information errors, and so on.
The following viewstub is a translucent progress bar overlay. Functionally, it should only be visible when new data items are imported into the application.
|
<viewstub Android:id= "@+id/stub_import" Android:inflatedid= "@+id/panel_import" android:layout= "@layout/progress_overlay" Android:layout_width= "Fill_parent" android:layout_height= "Wrap_content" android:layout_gravity= "Bottom"/> |
Gta5-In viewstub
When you want to load the Layout declared with viewstub, either use Setvisibility (view.visible) to set its visibility, or call its inflate () method.
The following is an example of the hint page network_error.xml when adding a network error in a layout main.xml. The MAIN.MXL code is as follows:
|
<?xml version= "1.0" encoding= "Utf-8"?> <relativelayout xmlns:android= "Http://schemas.android.com/apk/res/android" Android:layout_width= "Match_parent" android:layout_height= "Match_parent" > ...... <viewstub Android:id= "@+id/network_error_layout" Android:layout_width= "Match_parent" android:layout_height= "Match_parent" android:layout= "@layout/network_error"/> </RelativeLayout> |
Where Network_error.xml is a layout that needs to be displayed only in the case of a network error
Setvisibility (view.visible) mode
|
View viewstub = ((viewstub) Findviewbyid (R.id.stub_import)); Viewstub.setvisibility (view.visible); Neterrorlayout = Findviewbyid (r.id.net_error_layout)) |
Inflate Way
|
View neterrorlayout = ((viewstub) Findviewbyid (r.id.net_error_layout)). Inflate (); |
Attention:
The inflate () method returns to the inflate view after rendering is complete, so you do not need to call Findviewbyid () to find the element. Reduce the number of inflate, but also a little increase in efficiency.
The setvisible method also needs to Findviewbyid find the elements in Viewstub again.
Once the viewstub is visible or inflate, the viewstub element does not exist. Instead, the Layout is inflate, whose ID is the Android:inflatedid attribute on the viewstub. (The Android:id property of Viewstub is only available until viewstub is visible)
Note: One drawback of viewstub is that it currently does not support the use of label Layout
Four ListView the optimization
If you have a ListView that contains complex or individual items that contain a lot of data, the performance of scrolling up and down may be degraded. This section gives you some tips on how to make scrolling smoother.
The key to keeping the program flowing is to keep the main thread (UI thread) from doing a lot of arithmetic. You want to make sure that you perform disk read-write, network read-write, or SQL operations on other threads. To test the status of your app, you can enable Strictmode.
4.1 using a background thread
You should extract time-consuming operations from the main thread into a background thread, making the main thread focus only on UI painting.
4.2 in the View Holder fill in the View object
Use Convertview,
Your code may often use Findviewbyid () when the ListView is sliding, which can degrade performance. Even if Adapter returns a convertview for recycling, you still need to find this element and update it. One way to avoid frequent calls to Findviewbyid () is to use view Holder (view placeholder) design patterns.
Viewholder stores each view under the tag. So you don't have to find this element frequently:
|
Static Class Viewholder { TextView text; TextView timestamp; ImageView icon; ProgressBar progress; int position; } |
Then, a Viewholder object is generated in the class of Layout:
|
Viewholder holder = new Viewholder (); Holder.icon = (ImageView) Convertview.findviewbyid (r.id.listitem_image); ... Convertview.settag (holder); |
This allows you to easily get each view, rather than using Findviewbyid () to constantly find the view, saving valuable computing time.
4.3 getView don't do complicated operations.
Because every item is moved into the screen, GetView is called, do not do complex operations in GetView, do not create objects frequently. The item click does not have to be processed in advance. In particular, when sliding quickly, it causes frequent calls to GetView.
Five Optimization Tips
Use Relativelayout as much as possible to reduce nesting of hierarchies.
Use the Layout_weight attribute of the linearlayout with caution, using Relativelayout's Centerhorizontal= "true", ToLeft, ToRight instead
Six optimization in the writing specification
6.1 Id the naming
To make it easier to identify, you can name the current interface's resources according to your business, such as the current login interface, so you can name it:
Login_edit_username
Login_edit_password
Login_btn_submit
Login_txv_forgot_pass
6.2 name of the resource
Ic_action_add, Ic_action_location (ActionBar Icons)
Ic_play, Ic_save (General Icons)
Ic_tab_music, Ic_tab_more (tab Icons)
6.3 generic resource naming
The naming of Style.xml and Dimens.xml can be generalized as much as possible, because the basic view of a project is common, such as Actionbar, ListView, etc., the canonical generic naming can be easily ported to other projects.
|
<color name= "List_item_large" > #FCA558 </color> <color name= "List_item_small" > #FBA228 </color> <dimen name= "List_item_large" >24dp</dimen> <dimen name= "List_item_small" >18dp</dimen> <!--simple ListView style-- <style name= "List_view_style_default" > <item name= "Android:layout_width" >fill_parent</item> <item name= "Android:layout_height" >wrap_content</item> ... </style> |
Reference documents
Best-practices-for-android-user-interface
Layout-performance
Reproduced from Lightsky's blog Android layout optimization
Android Layout optimization