• Android performance test is divided into two categories: 1, one is ROM version (system) performance test 2, one is the application app performance test

  • Android app performance test includes test items such as: 1, resource consumption 2, memory leakage 3, power consumption 4, time consumption 5, network traffic consumption 6, mobile terminal related resource utilization 7, frame rate 8, rendering and so on….

  • Tool: (The principle of the tool is based on calling some android underlying API to obtain the value used by the test) GT, etc

  • Test method: 1. Design scenario: manual or automatic scenario 2. Obtain data: Available data includes: memory, CPU, power consumption, HPROF (memory leak analysis file), response time, etc. 3. Result analysis: After getting the data, analyze which modules’ data are abnormal and then Check code to locate the cause of the problem

  • Android state of several scenarios: 1, the idle state: refers to the open after the application, click the home button to let the application background, the application in a state called free 2, medium specifications and full specifications: medium size and full specification refers to the application of operation time interval length is differ, medium specification for a long time, the full specification is shorter

Article 1.1 memory

Background: C/C++ allocates memory in the Native heap, while Java allocates memory in the Dalvik heap. This is because the Android system imposes a hard limit on dalvik’s VMheapsize. When the Java process applies for more Java space than the threshold, an OOM exception will be thrown (the threshold can be 48M, 24M, 16M, etc., depending on the model). . Can be achieved by the adb shell getprop | grep dalvik vm. Heapgrowthlimit check this value. That is, OMM does not indicate a RAM shortage, but rather that the Java Heap object requested by the program exceeds the Dalvik VMheapgrowthlimit. That is, OOM can happen if RAM is sufficient.

This seems unreasonable, but why does Google do it? The purpose of this is to allow the Android system to have more processes resident in memory at the same time, so that applications don’t have to be reloaded into memory each time they start, giving users a faster response. By forcing each application to use a smaller amount of memory, mobile devices’ very limited RAM allows more apps to live in them. But there are some large applications that just can’t stand the vmheapgrowthlimit

Actually dalvik. Vm. Heapgrowthlimit and dalvik vm. Heapsize are the biggest memory limit, the Java virtual machine application if you don’t want to come when you least expect them to OOM in dalvikheap achieve heapgrowthlimit limitation, You need to declare Android: largeHeap= “true” in the application tag in the Manifest, after which the application Dalvik heap reaches the heapsize, OOM will appear

  1. Memory test in the test items: 1) the application memory consumption condition of idle 2) medium specification application memory consumption situation of the 3) full specifications of memory consumption situation 4) application memory peak 5) and 6) application memory leaks application whether permanent memory 7) after the stress tests of memory usage

  2. Symptoms of memory problems: 1) memory jitter 2) Large memory objects allocated 3) Memory growth 4) Frequent GC

  3. 1. Various Linux commands (top, free, meminfo…) 2, through the dumpsys adb shell dumpsys meminfo [pakagename | pid] 3, through/system/xbin/procrank tools adb shell procrank description: VSS – Virtual Set Size Virtual memory (including memory occupied by the shared library) RSS – Resident Set Size Actual physical memory (including memory occupied by the shared library) PSS – Proportional Set Size Actual physical memory (proportionally allocated to the memory occupied by the shared library) USS – Unique Set Size Physical memory occupied by a process alone (excluding the memory occupied by the shared library) USS is the virtual memory generated when a program is started when a process has suspected memory leaks. It will be released once the program process is killed. However, USS needs to use root’s phone. Generally, we can get PSS for mobile phones without root. PSS can be obtained by running the following command: The adb shell dumpsys meminfo < Package Name > | grep, TOTAL 4 procrank provided by android 1) Go to Google for procrank, procmem and libpagemap.so Run adb push procrank /system/xbin adb push procmem /system/xbin adb push libpagemap.so /system/lib 3) to grant adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmem adb shell chmod 6755 /system/lib/libpagemap.so , 4) in open tool records the adb shell procrank | grep packagename > / address/procrank. TXT 5, provided by the android ActivityManager getMemoryInfo (ActivityManager. MemoryInfo outInfo) (this approach is to write a simple app to monitor the use of, light simple)

  1. privatevoidGetMemory()
  2. {
  3. finalActivityManager activityManager =(ActivityManager) getSystemService(ACTIVITY_SERVICE);
  4. ActivityManager.MemoryInfo info =newActivityManager.MemoryInfo();
  5. activityManager.getMemoryInfo(info);
  6. Log. I (tag," system remaining memory :"+(info.availmem >>10)+"k");
  7. Log. I (tag," is the system running lowMemory: "+ info.lowmemory);
  8. Log. I (tag," low memory running when system free memory is lower than "+info.threshold+");
  9. }

MemTotal: all available RAM size. MemFree: sum of LowFree and HighFree. Unused memory reserved by the system. Buffers: Used to make Buffers for files. Cached: Cache memory size (diskcache minus SwapCache). SwapCached: The size of the swap space used by cache memory. The memory that has been swapped is still stored in a swapfile, which can be quickly replaced when needed without having to open the I/O port again. Active: Buffer or cache page file size in Active use that is not diverted to other uses unless absolutely necessary. Inactive: The size of a page file in infrequently used cache or cache storage that may be used in other ways. SwapTotal: indicates the total size of the swap space. SwapFree: indicates the size of unused swap space. Dirty: Size of memory waiting to be written back to disk. Writeback: Size of memory being written back to the disk. AnonPages: Memory size of unmapped pages. Mapped: Size of Mapped devices and files, etc. Slab: specifies the size of the kernel data structure cache to reduce the cost of allocating and freeing memory. SReclaimable: specifies the size of a Slab that can be retracted. SUnreclaim: The size of Slab cannot be reclaimed (SUnreclaim+SReclaimable = Slab). PageTables: Manages the size of index tables for paging pages in memory. NFS_Unstable: Size of unstable page table.

5. Check for memory leaks.Copy the code

1. Run the Monkey stress test: The adb shell monkey – p cn. Microinvestment. Weitou – 100 PCT – touch – ingore – crashes – throttle 100 – v – 1000 – s 50 2 v, to monitor memory value, Save the HPROF file (which is the Heap snapshot of the Java VIRTUAL machine) for analyzing commands to view the application memory: The adb shell dumpsys meminfo cn. Microinvestment. Weitou (process name) if it is found that the memory is too big, save HPROF files: Adb shell am dumpheap < process name > < save path > adb shell am dumpheap < process name > 4. Open the transformed hprof file with the MAT tool, and generally select Leak Suspects Report (through SQL statement to query whether the object is released, if there are multiple identical objects, there will be a memory leak problem)

Article 1.2 CPU

  1. CPU test items are as follows: 1) Application CPU consumption in idle state 2) Application CPU consumption in medium specification state 3) Application CPU consumption in full specification state 4) Application CPU peak value

  2. CPU data acquisition: 1) the adb shell dumpsys cpuinfo | grep packagename 2) top command adb shell top – m 10 – s CPU # see the top 10 highest CPU program (-t display process name, -s specified line sorting, -n refresh several times before exit, 3-d refresh interval, -m shows the greatest number) adb shell top | grep PackageName > / address/CPU. TXT

Article 1.3 flow

  1. Concept: Medium load: application normal operation High load: application limit operation

  2. The test items in the flow test are as follows: 1. Flow rate of the application starting for the first time; 2. Flow rate of the application running continuously for 2 hours in the background; 3

  3. To obtain traffic data: 1, wireshark tcpdump + 2, / proc/net/directory file cat/proc/net/dev acquisition system of traffic information, query the application of pid: adb shell ps | grep tataufo #, such as: 31002 Using PID to obtain the application traffic data: Adb shell cat /proc/31002/net/dev The adb shell ps | grep tataufo # : 31002 by PID for UID: adb shell cat/proc / / the status through the UID for: Adb shell cat/proc/net/xt_qtaguid/stats | grep 5, 31002 by the adb shell dumpsys package to get the application uid information, and then before the operation application by looking at: Adb shell cat /proc/uid_stat/uid/tcp_rcv ADB shell cat /proc/uid_stat/uid/tcp_snd Again, you can obtain the traffic received and sent by the application by subtracting the total traffic consumption of the application

1.4 article power consumption

  1. The test items in power consumption test are as follows: 1. There is no significant difference in standby power consumption before and after the mobile phone is installed with the target APK; 2. The mobile phone can enter standby power normally in common use scenarios, and the standby current is within the normal range; 3

  2. Power consumption test method: Method 1: software 1. Use third-party tools provided by the market, such as Kingsoft Battery Manager. 2, is the self-writing tool, here will generally use three methods: 1) Based on android PowerManager.WakeLock 2) more complex, Power consumption =CPU consumption +Wake Lock consumption + data transmission consumption +GPS consumption +Wi-Fi connection consumption 3) Adb shell Dumpsys battery Hardware generally uses a multimeter or a power meter to test. When using power meter to test, fake batteries need to be made. Some mobile phones that cannot plug and plug batteries also need to be welded to test power consumption

1.5 GPU (FPS)

  1. Frame rate: screen sliding frame rate Frame variance: screen sliding smoothness **FPS: **Frames Per Second Depending on the physiology of the human eye, frame rates higher than 24 are considered consistent. 30fps is the minimum acceptable for game graphics, 60fps is realistic, and if the framerate is higher than the screen refresh rate, it’s a waste of time. To achieve 30fps, each frame needs to take less than 33 ms

  2. The test items in GPU test are as follows: 1. Excessive drawing of interface 2. Screen sliding frame rate 3

  3. Debug GPU overdraw test: (manually test) Open the Developer option to Debug GPU overdraw. The acceptance criteria are as follows: 1. Black pixels are not allowed; 2.

  4. Screen sliding frame rate test: Method 1:1. On the mobile end, open the Enable Trace in developer options and select Graphics and View 2. Start the SDK tool Systrace, check the application under test, click Systrace, set the continuous capture time in the pop-up dialog box, check GFX and View option 3 under TRACE TAPS. The manual slide screen can be swiped or swiped by beats, and the frame rate data is saved to the default path, named trace.html 4. Will trace. The HTML file copy to under Linux system transformed from the command, to generate trace. The CSV file grep ‘postFramebuffer trace. The HTML | sed -e’ s /.

    ]\W

    //g’ -e ‘s/:.*$//g’ -e ‘s/.//g’ > trace.csv

    5. Use Excel to open the file and calculate the frame rate

    Method 2:

    The hardware method: open the high-speed camera, open the camera mode, record the video of manually sliding or sweeping the application under test, and then calculate the frame rate through the method of manual or program several frames

  5. Screen sliding smoothness test: methods such as frame rate test, the only difference is the final result calculation formula difference

  6. Capture app frame rate (Android Fluency FPS test) : 1. Open the mobile developer option Select the GPU display configuration file (adb shell Dumpsys gfxInfo com.xxx.xxx > zinfo.txt) (the system will record and retain the time information related to the drawing of the last 128 frames of images on each interface) Process: the time it takes the Android 2D rendering engine to Execute the DisplayList. The more views it takes, the longer it takes to Execute: The time to give a frame image to a synthesizer (compsitor) is smaller

  7. Other tools: GameBench tests Android Apps FPS tool Gfxinfo to check out the app drawing performance tool

1.6 Response time section

  1. To understand: 1) Time consumed from click event trigger to container startup of NativeAPP (buried point) 2) Time consumed by the complete startup of NativeAPP (which can be obtained from system.log) 3) Delay time of Native calling RPC request method (buried point) 4) Specific data in the process of sending RPC requests (req_size, req_header, req_time, etc., obtained through buried points) 5) Specific data returned by RPC requests (res_size, res_header, res_time, etc., 6) Time consumed by local parsing of returned data (buried or TraceView tools can be obtained) 7) interface rendering time (can be obtained by slow camera or buried)

  2. Android app startup time test (Android Activity startup performance section: www.rudy-yuan.net/archives/59…)

  3. The startup time of the application can be divided into three categories: 1) initial startup — the time taken for the first startup of the application; 2) non-initial startup — the time taken for the non-initial startup of the application; 3) application interface switching — the time taken for switching within the application interface

  4. Data acquisition of application startup time: Adb logcat > /address/logcat. TXT Find “ActivityName” /newaddress/fl.txt > /newaddress/last.txt 2. Hardware test, use a high-speed camera or mobile phone to record the application startup process, and then calculate the startup time by manual frame or program frame

2 Weak network test

  1. Test method: 1, using real SIM card, the operator network to test (there’s some special bugs in the mobile wireless test must be in a particular network can find true operators) 2, weak simulation by means of proxy network environment test (Charles hard delay) 3, connected to the analog weak network hot spots for testing

  2. Hot spot simulation method: 1) Share hot spots after setting iPhone developer mode (hard delay) 2) FaceBook open source ATC (raspberry PI can be used to build ACT environment)

  3. User experience needs to do: 1) unify the weak network loading interface style, animation effect, chrysanthemum icon, etc. 2) unify the network error, server error, timeout and other interface displayed to the user and prompt statements. 3) clearly define the user interaction behavior in each intermediate process

  4. From: https://www.zybuluo.com/defias/note/592309