preface
Recently applied for a relatively low-end test machine, and was surprised to find… Our app is so jammed… Although said app card is very annoying, but I do not use, it is not my business ~ but as a moral, intellectual, physical and American labor comprehensive development of the new era programmer, or should “symbolic” check the problem. The occurrence of lag is nothing more than a time-consuming operation in the main thread, which affects the main thread to the UI drawing, causing the phenomenon of lag. So we just need to find the time-consuming functions in the main thread and asynchronously process them to solve the problem. So today let’s talk about a tool in AndroidStudio that checks function time: CPU Profiler.
Of course you also can directly refer to official document: developer. The android, Google. Cn/studio/initial…
CPU Profiler
First of all, CPU profilers are not specifically used to deal with page lag frames. Rather, CPU profilers are used to look at each thread, which functions are executed over a period of time, and how much CPU each function consumes during its execution. You can use the built-in gadget systrace specifically for frame lag.
Not the official website so many “fancy” introduction, let’s go straight on the application.
1. Use interface
After clicking launch, we should see something like this:
The Profiler uses a real card
The contents circled in red are, from top to bottom:
- The currently running Activity
- CPU usage
- Memory usage
- Network usage
Click on CPU to further check CPU usage.
2. Detailed analysis
This chart represents the current CPU usage, which of course corresponds to the entire mobile phone, but cannot accurately reflect the real situation of our app. Now let’s look at the specific use of the code:
What did I do in the code? Very simple, a postdelay, and then a recursive Fibonacci sequence with an input of 40.
Handler().postDelayed({
fibonacci(40)},20000)
Copy the code
Now let’s look at the time of this function.
We need to click on Record when we think it’s appropriate.
Because the delay here is 20 seconds, SO I Record at 17 or 8 seconds
Then, at an appropriate time, hit Stop again.
Then we get something like this:
This allows us to clearly see the function call relationships generated during this time. Mouse over the corresponding function, you can also see the corresponding time.
So we can move the time function asynchronously, for example:
Never mind the crazy use of Thread, which means asynchronous. Ha ha ~
Handler().postDelayed({
Thread {
fibonacci(40)
}.start()
}, 20000)
Copy the code
So next, let’s Record:
At this point, we notice that although our CPU usage is increasing, there are no time-consuming operations for our main thread (the second red box).
If we scroll down to the options box, we’ll see that our time-consuming operation is here:
When we click on it, we can see the function call for this thread:
3. Display mode
The observant might have noticed that there are four tabs to choose from when parsing function calls.
So what do they all mean? Here is a brief introduction:
Call Chart:
The X-axis represents the time period and time when the function was called (or called), and the Y-axis shows who was called. Function calls to system apis are shown in orange, calls to application-owned functions are shown in green, and function calls to third-party apis (including Java language apis) are shown in blue.
The schematic looks something like this:
Flame Chart:
Commonly known as the fire map. For the flame Chart, this is a summary of the Call Chart in reverse order of Call, like this:
I’ve been Top Down in the Bottom Up.
These two modes are relatively complex, you can refer to the official documentation to explain how to use them.
The end of the
This article is what I want to talk about, which is a very simple and simple tool application. But it represents the first step in performance optimization, and taking the first step will mean that there will be more potholes waiting for you.
Come, since we have chosen the distance, we will only struggle ahead.