Background introduction
Android users may often encounter the following problems: 1) The application background is open, and the phone quickly runs out of power-the application consumes a lot of power; 2) The application is launched for the first time/non-first time, and it is particularly slow to enter the application-the application starts slowly; 3) In the application process, more and more stuck-insufficient CPU capacity / memory leak; 4) Application page freeze-low frame rate, page freeze. Therefore, the performance of the developed Android application must be tested, otherwise it will directly affect the user experience.
Android application performance testing usually includes: startup time, memory, CPU, power consumption, traffic, fluency, etc. This time, we will first introduce the test method of startup time.
Start-up time is an important indicator for App performance testing. Start-up time is divided into two situations, one is cold start time (usually a system restart, that is, there is no App process before startup), and the other is Hot start, that is, the App is switched to the foreground (click back to exit and then click the icon to start). In QA testing, generally focus on the starting time of the cold start. The following introduces three methods of testing the startup time for your reference and can be used in a targeted manner.
Use adb command
1.1.1 Test method Enter the adbshell am start -W packagename/MainActivity command to calculate the start time. As shown in the figure below:
Figure 1 The first time the application is started is what we often call cold start. At this time, the process of your application is not created. This is also the usage scenario of most applications. The user clicks on the icon of your application on the desktop After that, the process must be created first, and then MainActivity is started. At this time, the result returned by adbshell am start -w packagename/MainActivity is the start time of the standard application. Note that phones before Android 5.0 do not have the WaitTime value. Regarding the difference between ThisTime/TotalTime/WaitTime, the following is its explanation. WaitTime=endTime-startTime
StartTime records the time point when startActivityAndWait() is just about to be called.
EndTime records the time point when the startActivityAndWait() function call returns.
WaitTime = startActivityAndWait() call time-consuming.
WaitTime is the total time consumed, including the time of the previous application Activity pause and the time of the new application startup; ThisTime represents the startup time of the last Activity that started a series of activities; TotalTime represents the time consumed by the new application startup, including the startup of the new process And Activity start, but not including the time-consuming activity pause of the previous application. In other words, developers generally only need to care about TotalTime, and this time is the time it takes for their application to actually start.
To sum up, if you only care about the time it takes to start an application itself, refer to TotalTime; if you care about the time it takes for the system to start the application, refer to WaitTime; if you care about the time it takes to start the application with an interface activity, refer to ThisTime.
to sum up
The time calculated by this method is the time from the time the system starts processing the activity to finish running the layout and draw functions. The simple understanding is the time to start the Activity, and does not include the time from clicking the icon to the system receiving the message. Obviously, this time cannot completely simulate the start time of the user operation scenario. Secondly, this method only calculates the overall startup time of an Activity, and does not count the time of each function separately, which is not easy to locate the problem. In response to these two problems, let's take a look at how the following two methods are solved.
What we focus on in the test is actually the start-up time of the user experience, so the above time cannot meet our needs. Since it is a user experience, we can use screenrecord to record the screen and analyze the video in a more intuitive way.
1.2 Use screenrecord for screen recording
Test method
(1) Input the command adb shellscreenrecord --bugreport /sdcard/lanch.mp4—bugreport parameter will make the video output some time information and frame information for us to analyze the startup time.
(2) Click the collection icon, after the app is fully launched, use ctrl+c to end the video recording.
(3) Use the command adb pullsdcard/lanch.mp4 ./ to export the video.
(4) Export the video to the computer and open it with a video software that can play by frame (quicktime on mac, kmplayer for win), and frame by frame Play. As shown below:
Figure 2 Play video by frame, the upper left corner of the video will display the time (accurate to ms) and the number of frames. As shown in the figure, 11:09:38.031 represents hours, minutes and seconds, and f=333 is the number of frames. In the video, you will see that the icon will be darkened and then highlighted. When it is highlighted, the system starts to process the icon click event. You can use this as the click time, and then according to the experience requirements, you can see that the app start page is completely drawn as the end time. This time minus the click time is the start time of the app.
Summary:
Although this method can simulate the user's operating scenario, the operating cost is high and it is impossible to accurately and clearly know which functions are called for too long. With the above two methods, it is impossible to locate which function takes more time from the start-up time alone. When the start-up time is greater than the predetermined start-up time threshold, you need to log step by step to analyze and find out the cause. The following method is the current method of calculating the startup time of Tieba, you can clearly see the call time of each function.
1.3 Code buried point, view output log
1.3.1 The test method is dotted in the code, and the output log is viewed. Take the post as an example. The following figure shows the operations to be experienced during the entire startup.
Refer to the table below for the specific steps in Figure 3.
As shown in Figure 4, the startup time is tested by outputting the log, and QA can easily view the specific time-consuming time of each module, as shown in the figure below.
to sum up:
By doing this, you can clearly see the total time consumption of the Activity and the time consumption of each function, so that if you encounter a problem during the test, you can easily locate the specific function. There are also specific points in the testing process. For example, the post live broadcast will be integrated into the post bar in the form of a plug-in. When testing, you can pay more attention to the initialization time of the plugin.
Regarding the performance index of startup time, I personally think that the way of outputting the log is ideal. After QA finds a suspected problem in the test process, it can give a specific function that takes time.
I recommend a software testing exchange group, QQ: 642830685. The group will share software testing resources, test interview questions and test industry information from time to time. You can also follow my WeChat public account program Yuan Yifei, I will organize it. The software testing resources of the company are shared with you, and I am waiting for you in the group.