Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to optimize Catton in Android

2025-03-29 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to optimize Catton in Android". In daily operation, I believe many people have doubts about how to optimize Catton in Android. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "how to optimize Catton in Android". Next, please follow the editor to study!

CPU performance

During the development process, we can obtain the CPU information of the device through the following methods.

/ / get the number of CPU cores

Cat / sys/devices/system/cpu/possible

/ / get the frequency of a CPU

Cat / sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

Catton problem analysis index

After the stutter problem, we should first check the usage of CPU. How can I find out? We can go through / proc/stat

Get the CPU usage of the whole system through / proc/ / stat

You can get the CPU usage of a process.

For the meaning of the attributes of the stat file and the calculation of CPU utilization, you can read "CPU occupancy of processes in Linux" and Linux documents. The more important fields are:

Proc/self/stat:

Utime: user time, reflecting the time spent on the execution of user code

Stime: system time, reflecting the time spent on the execution of system calls

MajorFaults: the number of missing pages that need to be copied from the hard disk

MinorFaults: the number of missing pages without hard disk copy

If the CPU usage is more than 60% over a long period of time, indicating that the system is busy, you need to further analyze the ratio of user time to system time. For ordinary applications, the system time will not be more than 30% for a long time. If this value is exceeded, we should further check whether there is too much IWeiO or other system call problems.

Android is standing on the shoulder of the Linux giant. Although he has made a lot of changes and cut down some tools, he still retains a lot of useful tools that can help us troubleshoot problems more easily. Here are some common commands for you. For example, the top command can help us see which process is the largest consumer of CPU; the vmstat command can dynamically monitor the virtual memory and CPU activity of the operating system in real time; and the strace command can track all system calls in a process.

In addition to CPU usage, we also need to look at CPU saturation. CPU saturation reflects the thread queuing up for CPU, that is, the load of CPU.

CPU saturation is first of all related to the number of threads in the application. If too many threads are started, it is easy to cause the system to constantly switch executing threads, wasting a lot of time on context switching. We know that every CPU context switch needs to refresh registers and counters, at least dozens of nanoseconds.

We can use vmstat

Command or / proc/ [pid] / schedstat

File to view the number of CPU context switches, you need to pay special attention to nr_involuntary_switches here

The number of passive switches.

Proc/self/sched:

Nr_voluntary_switches:

The number of active context switches, the most common being IO, because the thread is unable to get the resources it needs.

Nr_involuntary_switches:

The number of passive context switches, which is caused by the forced scheduling of threads by the system, for example, a large number of threads are preempting CPU.

Number of times se.statistics.iowait_count:IO waits

Se.statistics.iowait_sum: the time that IO waits

You can also check the average load of CPU in 1 minute, 5 minutes, and 15 minutes through the uptime command. For example, for a 4-core CPU, if the current average load is 8, this means that there is one thread running and one thread waiting on each CPU. In general, it is recommended that the average load be controlled within "0.7 × core".

00:02:39 up 7 days, 46 min, 0 users

Load average: 13.91, 14.70, 14.32

Another factor that will affect CPU saturation is thread priority, which affects the scheduling policy of Android system, which is mainly determined by nice and cgroup types. The lower the nice value, the stronger the ability to preempt CPU time slices. When CPU is idle, the impact of thread priority on execution efficiency is not particularly obvious, but when CPU is busy, thread scheduling has a great impact on execution efficiency.

With regard to thread priority, you need to pay attention to whether there are low-priority threads such as high-priority thread null, such as the main thread waiting for a lock from a background thread. From the point of view of the application, whether it is user time, system time, or waiting for CPU scheduling, it is the time it takes for the program to run.

Android Catton troubleshooting tool

Traceview and systrace are both familiar tools for troubleshooting stutters, which are divided into two schools in terms of implementation.

The first school is instrument. To get the calling process of all the functions in a period of time, you can further analyze the points to be optimized by analyzing the function call process during this period.

The second school is sample. Selectively or by sampling to observe the process of some function calls, we can speculate the doubtful points in the process from these limited information, and then continue to refine the analysis.

What is the difference between the two schools? In what scene should we choose which appropriate tool? Are there any other useful tools you can use? Let's take a look at them one by one.

Traceview

Traceview is the first performance analysis tool I use and one that complains a lot. It uses the event event called by the Android Runtime function to write the time spent and the calling relationship of the function into the trace file.

Thus, Traceview belongs to the instrument type, which can be used to see which function calls are made throughout the process, but the performance overhead caused by the tool itself is too high to reflect the real situation sometimes. For example, the time taken by a function itself is 1 second, which may become 5 seconds when Traceview is turned on, and the time-consuming changes of these functions are not scaled up.

After Android 5.0, startMethodTracingSampling has been added

Method, you can use a sample-based approach to reduce the performance impact of the analysis on the runtime. With the addition of the sample type, we need to make a tradeoff between overhead and information richness.

No matter what kind of Traceview it is, it doesn't support the release package very well, such as no anti-obfuscation. In fact, the format of trace files is very simple. Before, I wrote a gadget that supports anti-confusion of trace through mapping files.

Systrace

Systrace is a new performance analysis tool for Android 4.1. I usually use the systrace tracking system to track events such as the CPU O operation, CPU payload, Surface rendering, GC, and so on.

Systrace makes use of Linux's ftrace debugging tool, which is equivalent to adding some performance probes in every key location of the system, that is, adding some performance monitoring points in the code. Android encapsulates atrace on the basis of ftrace and adds more unique probes, such as Graphics, Activity Manager, Dalvik VM, System Server and so on.

The systrace tool can only monitor the time-consuming of specific system calls, so it is of the sample type and the performance overhead is very low. However, it does not support time-consuming analysis of application code, so it has some limitations in use.

Because the Trace.beginSection is reserved in the system

Interface to listen for application calls is time-consuming, so is there any way to automatically increase the time-consuming analysis of applications on systrace?

To highlight the point, we can do this by stuffing each function at compile time, that is, adding Trace.beginSection at the entrance and exit of the important function, respectively.

And Trace.endSection

. Of course, for performance reasons, we will filter most of the functions with fewer instructions, thus increasing the time-consuming monitoring of the application on the basis of systrace. The benefits of this approach are:

You can see the invocation flow of the entire process system and application. It includes function calls of key threads of the system, such as rendering time, thread lock, GC time and so on.

The performance loss is acceptable. Because most of the short functions are filtered, and the Imax O is not magnified, the whole run time is less than twice that of the original, which basically reflects the real situation.

Systrace produces results in HTML format.

Currently, both tools only support debugable applications. If you want to test the release package, you need to root the test machine. For this limitation, we will specifically type out the test package for debugable in practice, and then implement the anti-obfuscation function for mapping ourselves.

As the Android version evolves, Google not only provides more performance analysis tools, but also slowly optimizes the experience of existing tools to make them more powerful and less accessible. On the other hand, Android Studio shoulders another important task, which is to make it easier for developers to use and more intuitive graphical interface.

Several performance analysis tools are directly integrated into the Profiler of Android Studio 3.2, among which:

The function of Sample Java Methods is similar to Traceview's sample type.

The function of Trace Java Methods is similar to Traceview's instrument type.

The function of Trace System Calls is similar to systrace.

SampleNative (API Level 26 +) functions like Simpleperf.

Frankly speaking, the Profiler interface is not as good as the interface that comes with these tools in some ways, and the parameters that support configuration are not as good as the command line, but Profiler does greatly reduce the barriers for developers to use.

Another big change is the way the analysis results are presented. These analysis tools support both Call Chart and Flame Chart presentation. Now let me talk about the scenarios that are suitable for these two ways of presentation.

Call Chart

Call Chart is the default presentation method used by Traceview and systrace. It is shown in the order in which the functions of the application are executed, and is suitable for analyzing the calls of the whole process. To take the simplest example, A function calls B function, B function calls C function, loop three times, you get the following Call Chart.

Call Chart is like giving an electrocardiogram to an application. We can see the specific work of each thread during this period of time, such as whether there is a lock between threads, whether the main thread has a long time of Imax O operation, whether there is idle, and so on.

Flame Chart

Flame Chart is also known as the flame map. Unlike Call Chart, Flame Chart looks at the distribution of calls over a period of time from a global perspective. It is like taking X-rays of an application, and it can naturally combine the information of time and space on one picture. For the example of the above function call, the result shown in the flame diagram is as follows.

When we don't want to know the entire invocation process of the application, but just want to visually see which code paths take more CPU time, the flame diagram is a very good choice. For example, one of my previous deserialization implementations was very time-consuming, and I found that the most time-consuming was the creation and copying of a large number of Java strings, resulting in a many-fold improvement in performance by turning the core implementation into Native.

At this point, the study of "how to optimize Catton in Android" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report