Small knowledge, big challenge! This paper is participating in theEssentials for programmers”Creative activities.

This paper has participated inProject DigginTo win the creative gift package and challenge the creative incentive money.

Why focus on performance

When we are very happy to use the APP on the mobile terminal, suddenly the APP does not respond. The anxious feeling in our heart is almost up to our throat. I believe that most people will encounter such a scene, right

In general, when evaluating the quality of an APP, users often pay attention not only to the normal basic functions of the APP, but also to the performance of the APP, such as its size, running speed and difficulty

Therefore, what users are concerned about is also what we focus on when testing the APP in the early stage

So why focus on performance?

  • User experience: User experience APP runs fast or does not flow smoothly
  • Stable performance: APP runs stably on different platforms without crash
  • Product competitiveness: in the same environment, performance tuning helps products compete in the market

So in this installment, we’re going to look at some of the metrics you’ll see during Android performance testing, Let’s go~

1. Performance Test Overview

Performance test is one of the stress tests, which aims to verify the performance of APP stability, responsiveness and other index data under load conditions, and discover and eliminate APP performance defects in the process.

APP performance testing common indicators in the industry are summarized as follows:

2. Memory indicator concept

Apps rely on memory on the device, but the total size of memory on the device is limited.

The device’s memory usage for a single application is also limited.

Therefore, memory management is crucial for an APP

  • Memory metrics The full name meaning equivalent
    USS Unique set Size Physical memory Process-exclusive memory
    PSS Proportional Set Size Physical memory PSS= USS+ includes shared libraries proportionally
    RSS Resident Set Size Physical memory RSS= USS+ contains shared libraries
    VSS Virtual Set Size Virtual memory VSS= RSS+ No actual physical memory allocated 
1.VSS >= RSS >= PSS >= USS2.When we look at the memory size of our APP, what we're really looking at is the PSS value of our APPCopy the code
  • Memory viewing method
Adb shell Dumpsys meminfo Specifies the application package nameCopy the code

You can also use procrank

adb shell procrank | grep packagename
Copy the code

3. Memory limit

Memory properties instructions
dalvik.vm.heapstartsize=8m The initial Heap size that the system assigns to an application after it starts. Increases with application use
dalvik.vm.heapgrowthlimit=192m By default, the maximum Heap that can be used by an application, above which OOM will be generated
dalvik.vm.heapsize=512m If the largeHeap attribute is configured in the application manifest file, the maximum Heap available to the App is set for this item
dalvik.vm.heapminfree=2M Minimum value of a single Heap memory adjustment
dalvik.vm.heapmaxfree=8M Maximum size of a single Heap adjustment
dalvik.vm.heaptargetutilization=0.75 Current ideal heap memory utilization. After GC, Dalvik’s Heap memory is adjusted so that the size of the currently living objects and the/Heap size are close to the value of this option, i.e. 0.75 is only a reference value here

. We can use the adb shell getprop | get dalvik vm. Heap for memory

  • Android sets heap size limits for each App, which can be configured in the system, but which the App cannot control
  • An OutOfMemoryError is received if the memory occupied by an App runs in excess of the App heap size limit

4. Reclaim memory

Memory collection stands for Android garbage Collection, or GC for short. This is when Android cleans up unwanted objects to free up memory for use by other applications

A single GC does not take much time, but a large number of GC operations can be significant, consuming frame intervals (16ms)

  • GC trigger condition

    1. When a process dies

    2. When starting the specified Activity fails

    3. Update process adj

    4. When all current broadcasts are processed

  • GC memory collection rules:

    1. According to the process priority, the lower priority is killed first
    2. Applications with the same process priority are preferred to applications with larger memory usage

  • Check the method

You can use the adb logcat | grep < pid >

5. Memory scenarios are faulty

  • Memory jitter

    • Severity level: C or D. The problem has limited impact and is not mandatory
    • Cause: A large number of objects are created and released in a short period of time, frequently triggering GC and causing UI to stagnate

  • A memory leak

    • Severity level: B or C. Optional solutions are required with a high probability
    • Cause: The program fails to release an object that is no longer in use due to an oversight or error
    • Impact: A memory leak causes the remaining available Heap Size in memory to become smaller and smaller, which can lead to frequent GC triggers, further causing performance problems such as eventual memory overruns

  • Out of memory

    • Hereinafter referred to as: OOM
    • Severity level: A or B. The problem must be solved
    • Cause: The heap memory limit for the application is exceeded

6. Performance optimization

  • Bitmap optimization:

    1. On-demand display: BitmapFactory.Options Sets inSampleSize
    2. Timely recovery
    3. Use image caching (LruCache, DiskLruCache)

  • Code optimization:

    1. Avoid new objects and reuse objects in the body of the loop
    2. Prevent Activity/Fragment leakage
    3. Close resources (files, databases, etc.) in a timely manner
    4. Thread management: Use thread pools and stop threads in time

conclusion

In this issue, I mainly studied the memory-related concepts and scenarios of Android APP performance test indicators

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