“This is the 26th day of my participation in the First Challenge 2022. For details: First Challenge 2022”

preface

As we all know, the current mobile device system is mainly divided into Android and IOS two systems camp. Among them, The Android system is open source, so many manufacturers are based on the Android system to develop application software.

APP testing on Android devices includes: function test, UI test, performance test, compatibility test, stress test, boundary value test, interrupt test and so on

Among them, device performance problems will directly bring bad experience to users when using APP products.

This issue will summarize and learn about the performance test indicators of Android APP, Let’s go~~

1. The memory

In Android, each APP memory consists of two parts:

  • Share drity with other processes
  • Private dirty memory exclusive by APP

In the industry, we usually use PSS (USS+ shared memory) to determine the memory overhead of an APP

The command is adb shell dumpsys meminfo application package name or ADB shell procrank

For example, let’s look at the memory performance of the Youtube app:

  • Memory tests test the system in different situations

    1. In idle state, application memory consumption
    2. In the medium specification state (long operation time), the application memory is consumed
    3. In the full state (the operation time is short), the application memory is consumed
    4. During the test, pay attention to memory peak, leakage, memory release, and memory usage after pressure measurement

  • Memory scenario Problem

    1. Memory jitter: Frequent GC, resulting in UI stutter
    2. Memory overflow: The application does not have enough memory
    3. Memory leak: The memory space cannot be released after the application is complete. If there are a large number of times, the memory leaks
    4. Frequent GC

For more details, see the previous performance test metrics

2. CPU

CPU is a measure of how much system resources are used by APP applications.

If the APP occupies too much CPU resources, the stability of the entire system will be caused, and the operation of the system will be abnormally slow.

So there are two things we need to focus on in Android CPU metrics:

  • Total CPU usage
  • Application CPU usage

You can run the following command to check the CPU usage:

  • adb shell dumpsys cpuinfo | grep packagename

  • Adb shell Dumpsys top-n 10-s CPU Displays the 10 programs with the highest percentage of CPU money

(-t displays the process name, -s sorts by the specified line,-n refreshes several times before exiting, -d refreshes interval, -m displays the maximum number)

Adb shell cat /proc/stat reads the /proc file. It provides a file system interface for kernel and process communication. Users and applications can obtain system information and change some kernel parameters through /proc files.

When using the performance monitoring tool CPU metrics, there is a concept of CPU utilization (the first type is displayed by default)

  • CPU Usage: Traditional CPU Usage, also known as unnormalized CPU Usage

    Calculation method: In current CPU frequency, CPU Usage = CPU execution time/TOTAL CPU time

  • CPU Usage (Normalized) : Normalized CPU Usage

    Sep sep sep sep sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep

User: jiffies in user mode accumulated from the start of the system to the current moment, excluding the process whose nice value is negative. Nice: jiffies occupied by processes whose nice value is negative from the start of the system to the current time. System: jiffies of the system state accumulated from the system startup to the current time; Idle: indicates the jiffies that wait until the current time except the DISK I/O waiting time accumulated from the system startup. Iowait: jiffies of disk I/O waits accumulated from the system startup to the current time. Irq: Jiffies of hard interrupts accumulated from system startup to the current time. Softirq: Jiffies of soft interrupts accumulated from system startup to the current time note: Jiffies are Linux core variablesCopy the code

total=user+system+nice+idle+iowait+irq+softirq

cpu usage=[(user_end +sys_end+nice_end) – (user_begin + sys_begin+nice_begin)]/(total_end – total_begin)*100

Similarly, you need to view CPU changes in idle, medium, and full scenarios.

When we are faced with problems such as hot, stuck and ANR during APP operation, we need to check whether there is a CPU problem:

  • If it is ANR, search the logcat file for ANR in and adb pull the trace file
  • If there is no ANR, use the preceding method to obtain the CPU usage. If the CPU usage trend in a scenario is abnormal and the average value of the peak value is higher than the baseline, use TraceView to view the Trace analysis file and send it to RD for solution.

For more details, see CPU for performance test metrics

3. GPU

During the operation of an APP, the lag may be caused by CPU or GPU problems.

The GPU index specifically measures the rendering speed of an APP’s picture, and the impact of excessive drawing on picture performance is extremely serious.

  • Concerns in GPU indicators:

    1. Overdraw: The interface displays an activity with nested layers
    2. Screen slide frame rate
    3. Smoothness of screen slide

  • Procedure for obtaining GPU data

    1. Adb shell dumpsys gfxinfo > gpu.txt
    2. TXT file to the local PC
    3. Locate Profile datain MS copy to Excel to draw table display

  • GPU test points:

    1. Overdraw test:

      • Open developer options
      • Conduct operation test APP
      • Test indicators:
        • Control over drawing to 2X
        • 4X overdrawing is not allowed
        • It is not allowed to overdraw in 3X that is larger than 1/4 of the screen

  • Images caton

4. FPS

FPS is a measure of the number of frames per second transmitted by an APP. The more frames per second, the smoother the operation of the APP.

FPS indicator is a kind of display indicator. There are two main categories of display indicators:

  1. The system-level indicator is only FPS, and the composition of the Surface itself needs to be carried out in SurfaceFlinger

  2. There are three categories of application-level indicators:

    • Aggregate Frame Stats, HWUI function. Analysis can only be performed after Surface drawing by HWUI
    • Jankiness Count, MAx accumulate Frames and Frame Rate are suitable for a wide range of applications
    • 2. To be Skipped frames needs Choreographer to draw Surface to work properly

  • FPS metrics generally require:

    • The refresh rate on the Android screen is 60 frames per second
    • Each frame time is not more than 16.6ms, the picture is smooth without lag

  • FPS data acquisition command:

    1. Adb shell Dumpsys SurfaceFlinger –latency current activity
    2. Adb shell dumpsys gfxinfo Package name

In general, FPS and GPU are viewed together, and they complement each other.

conclusion

In this issue, we mainly study the concepts related to CPU, memory, GPU and FPS in Android performance test.

That’s the content of this episode, please give your thumbs up and comments. See you next time