Android performance testing has always been a part of android testing that has been forgotten by some people, and something that some people have no choice but to do. In the vast majority of startups, performance testing is basically forgotten, because functional testing and stability testing are the focus, while some testers in mid-sized companies want to perform performance testing on Android , but have no idea where to start. Android performance testing has always been characterized by a small number of test dimensions, difficult to collect test data, and difficult to quantify the collected data. These characteristics are caused by the fragmentation of Android mobile phone versions, the diversification of hardware, and the complexity of App functions.
In general, performance tests can be divided into stuck ANR tests, fluency tests, power tests, and traffic tests. Why does an APP need performance testing? Generally speaking, it is some imprecise code, which causes lag on low-end models, wastes limited power on mobile phones, wastes expensive traffic, and causes user loss.
Today, let's talk about the Caton ANR test
Caton ANR and Android are natural friends. From the first day of Android 's birth to the current 8 -core CPU , Android still has not been able to get rid of the criticism of the page is not smooth, stuck, and crashes, so I personally think that the Caton ANR test is the most important performance test. a piece.
To put it simply, the phone does not respond in time, the page is delayed, the frame is dropped, or the click does not respond. Most of the stuck, the system will return to normal after a while, but if it exceeds 5S, it may cause the mobile phone ANR and cause a higher level of warning.
What can trigger an ANR ?
In Android , application responsiveness is monitored by the Activity Manager and WindowManager system services . Android displays an ANR for a specific application when it detects one of the following conditions :
There are generally three types of ANRs :
1 ) KeyDispatchTimeout(5 seconds) -- the main type key or touch event is unresponsive for a specific time
2 ) BroadcastTimeout(10 seconds) --BroadcastReceiver cannot process completion within a certain time
3 ) ServiceTimeout(20 seconds) -- a small probability type Service cannot be processed within a specific time
All three reasons can cause ANR , but the first case basically accounts for more than 90% of all ANRs , and the third case is very small. These three ANRs are not isolated and may influence each other. For example, an application process has an Activity that is being displayed and a BroadcastReceiver that is processing messages at the same time, both of which are running in the main thread of the process. If the onReceive function of BR does not return, the user clicks on the screen at this time, and onReceive does not return for more than 5 seconds, the main thread cannot handle the user input event, which will cause the first ANR . If it continues for more than 10 seconds without returning, it will cause the second ANR . The main reason for ANR is that potentially time-consuming operations, such as network or database operations, or highly time-consuming calculations such as changing the size of a bitmap, should be performed in child threads (or in the case of database operations, by means of asynchronous requests). Finish. However, it's not that your main thread is blocking there waiting for the child thread to finish - nor is it calling Thread.wait() or Thread.sleep(). Instead, the main thread should provide a Handler for the child threads to submit to the main thread when done. Designing your application in this way will ensure that your main thread remains responsive to input and avoid ANR dialogs due to a 5 second timeout on input events .
When the three types of ANRs occur, error information will be output in the log . You will find that the function stack information of each application process and system process is output to a file /data/anr/traces.txt . After the ROOT phone exports the file, analyze Some conclusions can be drawn from this log, but the traces file information is abstract and difficult to understand. In general, logs are difficult to collect and results are difficult to analyze.
How to avoid ANR ?
1 ) Any method running in the main thread does as little as possible. In particular, an activity should do as little creation as possible in its key lifecycle methods such as onCreate() and onResume() . (You can use the method of restarting the child thread, and then use the Handler+Message method to do some operations, such as updating the ui in the main thread, etc.)
2 ) Applications should avoid doing time-consuming operations or calculations in BroadcastReceiver . But instead of doing these tasks in child threads (because of the short life cycle of BroadcastReceiver ), the application should start a Service if it needs to perform a time-consuming action in response to an Intent broadcast . (It should be noted here that the Service can be started in the broadcast receiver , but the broadcasereciver cannot be started in the Service . The reason will be introduced later, which is not the focus of this article)
3 ) Avoid starting an Activity in the Intent Receiver , because it will create a new screen and grab the focus from the current user's running program. If your application needs to show the user something in response to an Intent broadcast , you should use the Notification Manager to do so.