"Andriod to take you to Android" List of performance optimizations--Take the "Jane book" app as an example

These days idle bored, on the phone on the developer mode inside the "GPU over-drawing" function, to see what other apps do, and then accidentally opened the "Jane Book", and then it was stunned by its excessive drawing, so wrote this article of performance analysis, from a only apk file angle, Here's how to look for possible performance problems in the layout, as well as solutions. This article is based on the latest version of 1.9.1 Android.

• • GPU Over-drawing
  • Hierarchy View
  • Systrace
  • TraceView
  • Summarize
  • Analysis Resources Download

GPU Over-drawing

First open the following two function switches

• Debug GPU Over-drawing in developer mode
• Developer Mode->GPU Rendering mode analysis

And then you get the picture below.

We can see, it's horrible! Redraw phenomenon is serious, frame rate of more than 16ms standard line many, I was frightened by this interface! This shows that the interface of the book is to be optimized, and we'll look at the layout with hierarchy view.

Hierarchy View

After opening, we can get the following data

As can be seen from the figure, the main interface has a total of 143 view, really a lot, but more importantly, the following data

• mesure:2.937 ms
• layout:9.113 ms
• draw:15.679 ms

Mesure data is normal, and layout and draw time is significantly longer, so that the total time per drawing = 2.937+9.113+15.679 = 27.729 ms

More than 16ms, the frame rate of less than 60fps per second, so there will be dropped frame lag phenomenon.

So why is draw so time-consuming?

Because the main interface has a carousel diagram.

The picture of the carousel map is very big, occupy the memory is not small, draw such a picture very time, do not believe? Look at this picture below, which is the effect of staying in the main interface for some time

It can be seen that the drop frame phenomenon is regular, the time interval and the rotation of the auto-play interval, so this also shows that the large size of the carousel is the main cause of the missing frame suspects.

But not only for this reason, there are a lot of unnecessary layouts being redrawn in this interface.

The following diagram shows the layout of item for each article, the container for item or the ListView, don't ask how I know, don't tell you ~

We can see that an item nested three layers of viewgroup. I do not know whether there is any special use or for any consideration, but in order to use the ImageView to control the placeholder, using a two-layer layout can complete the display of this interface, so as to avoid the 1-layer layout redraw, you can reduce draw time.

<?xml version= "1.0" encoding= "Utf-8"?><relativelayout  android: ID  = "@id/rootview" //This layer can omit android:layout_ Width  = "fill_parent"  android:layout_height  = "wrap_content"  xmlns:android  = "http://schemas.android.com/apk/res/android" ;     <linearlayout  android: Gravity  = "center_vertical"  android:o Rientation  = "horizontal"  android:layout_ Width  = "fill_parent"  android:layout_height
      = "110.0dip"  android:layout_marginleft  =         "15.0dip"  android:layout_marginright  = "15.0dip"  android:layout_centerinparent  = "true" ;         <relativelayoutandroid:layout_width="0.0dip"android:layout_height= "Wrap_content" android:layout_marginright="10.0dip"android:layout_weight="1.0">                                                            <TextView            android:textsize="12.0SP"            Android:textcolor="@color/text_blue"            android:ellipsize="End"            Android:id="@id/author_name"            Android:layout_width="Wrap_content"            Android:layout_height="Wrap_content"            Android:maxwidth="200.0dip"            Android:text="Author"            Android:singleline="true"/>...</relativelayout>        <ImageViewandroid:id="@id/image"android:visibility="visible"  android:layout_width="80.0dip"android:layout_height="80.0dip" android:layout_marginright="5.0dip"android:src="@drawable/image_list"  Android:scaletype="Centercrop" />                                                            </linearlayout></relativelayout>

Otherwise, you see, the main layout is all bright, which indicates that there may be a problem with the layout writing.

Let's go down and find out what's wrong.

We can see that the layout of the hierarchy is very deep, using a double viewpager nested mechanism, the main and simple book interface design, because there are 3 tabs on the main interface, in order to achieve the head of two tabs switching function, only double nested Viewpager.

But I'm not very good at this design, one is because Google's design specifications mentioned, do not use too much tab, not to use the upper and the bottom of the same tabs, not to say three tab, this will create confusion for users.

However, in the domestic product design market, it is difficult to abide by the design norms.

The following is the layout level of item, not the level of the system layout, there are more than 14 layers, so that this design, will certainly result in a large layout hierarchy, layout, drawing slow results.

After my verification, found that each viewpager inside the fragment will not be destroyed, that is, how many interface modules you open, how many fragment instances in memory.

This product design is of course also pros and cons, the advantage is

• You can save user status for each interface, such as the drop-down location
• Can reduce the user's wait time, do not need to get back
• Reduce traffic consumption

There are drawbacks, that is, increased memory consumption, on low-profile phones, there may be frequent GC, resulting in Kaka.

However, I think that the users of Jane's book should be Gen Y, the Internet crowd as the main body, this group of people's consumption level should not be too low, the configuration of mobile devices should also not be too low, so combined with this consideration, not fragment recycling is also a completely acceptable solution.

Let's take a look at the drawing of the ListView, which is also a three-lamp red, which means there may be a problem with this layout.

Then I found the drawing of each item

As you can see from the graph, measure and layout are very long, but I don't see why this problem can be caused because the layout is 5 TextView, and there's not a very complicated view, If Relativelayout layout is more time-consuming and understandable, then why does measure take so long? Tell me what's next.

Systrace

Later, using Systrace to capture the data, swipe the entire ListView when crawling to get the following results

There is a drop frame in the back, it may be because the UIL load picture caused insufficient memory, the drop frame, because after the drop frame, due to insufficient memory, ALLOC memories produced a GC, so that layout nesting too much additional memory cache, may cause this result.

And one thing is strange, is that in the process of sliding, is always called looper.dispatchmessage (), what is the operation has been processing the message? Put on TraceView and see.

TraceView

In front of the slide, we see that Looper.dispatchmessage () has been executing, what is it doing? To solve this problem, I used TraceView to crawl the data when the list was sliding.

As we can see from the graph, the Loop.loop () operation takes up 70% of the CPU time, and the handler-related method also takes up more than 50% of the time, what are these operations doing?

In the refresh screen.

Handler mechanism big family in crazy occupy CPU

Viewrootimpl and ListView Calculations are also CPU-large

Chreographer occupies a large part of the CPU

Familiar here, here began to draw the interface, do not know the entire drawing process of friends, please refer to my article "you learn the framework of the Celtics brother" activity interface display full resolution.

Summarize

Until now, we finally know why the Jane book Android client is stuck, and we summarize

• Due to the multi-tab design, resulting in a serious interface layout, not the system layout, there are more than 14 layers
• Due to unreasonable interface, the partial layout is redrawn seriously
• Due to the fragment resident memory design, the memory consumption is too high, frequent GC may cause the interface to lag
• Because the picture of banner is too large, causing the picture to occupy more memory, frequent GC may cause the interface to lag

Because of the above four reasons, resulting in CPU and memory consumption of excessive results, know the possible causes, then the solution is very simple

• Re-interface design, eliminate multi-tab layout, optimize interaction
• Optimize layout code to remove unnecessary interface elements and ViewGroup
• Consider whether to discard fragment resident memory scheme, do not use Hide () and show () to control the fragment, instead of using replace () and other scenarios
• Reduce the banner image size or resolution

By the way, do you have an Android engineer in your home ^_^

Analysis Resources Download

• Analysis file

Respect the original, reproduced please specify: from Kaizico (http://blog.csdn.net/zhaokaiqiang1992) infringement must investigate!

Follow my Weibo to get more content

"Andriod to take you to Android" List of performance optimizations--Take the "Jane book" app as an example