The analysis tool for Android Application Performance Optimization last recorded the process of solving excessive plotting. This time, how can we determine whether the process is smooth and conceptual? In fact, at first I thought it was a bit nonsense, and it was obviously not smooth when I used it. However, this is the same thing as I would like to talk about many applications. It makes sense that the cards are just the same.
Theory is always theory, and practice is the first productivity.
Because my own applications can also feel choppy, now I can look back and understand that choppy is never the original intention of "careful programmers", but it is hard to say a lot of things. If you know something wrong, you can change it to a good person... Therefore, you need to know where the error is. 1. Looking at the global analysis of smoothness, we must first know the overall situation, whether it is local or global, so that we can have a direction in optimization. If it is a local problem, you need to carefully analyze specific operations. If it is a general problem, you need to consider the overall implementation mechanism when thinking about it, there may be problems with the implementation method. In android4.1, Google provides a tool called "Profile GPU rendering". After enabling this function, the system records the time information related to the last 128 frames of image painting on each interface.
If this function is enabled only after the application is enabled, remember to stop the application and restart it. After the feature is enabled, perform operations on the part you want to analyze (such as the slide list), and then run the ADB command.
$ ADB shell dumpsys gfxinfo com. xxxx. xxx
In the execution result, there is a pile of data under "profile data in MS". Draw: indicates the time occupied by the ondraw () method in the create and display list section in Java. Process: indicates the time it takes for the rendering engine to display the list. The more views, the longer the time it takes. Execute: indicates the time it took to send a frame of data to the screen for typographical display. In fact, it is the time when the background cache area that actually displays frame data is switched with the foreground buffer zone and the content of the foreground buffer zone is displayed on the screen. So this time is usually very short. PS: The View class contains the surface (variable name msurface). Each surface usually corresponds to two buffers, one front buffer and one back buffer. (3 after 4.1, one before and two after) among them, back buffer is the bitmap corresponding to the canvas drawing (study android_view_surface.cpp: lockcanvas ). Therefore, painting is always in the back
Buffer. When an update is required, the back buffer and front buffer are exchanged. Draw + process + execute = displays a complete frame. This time must be less than 16 ms to save 60 frames per second. Copy the data to an Excel file (WIN remembers to copy the data one by one, and copy the data directly under the MAC). Then, generate a "Stacked column Chart", which shows several phenomena. First, it is true that 4.1 of the butter project is really useful, and the time of each frame is controlled at around 16 Ms. Second, there are several frames that exceed 16 ms, and frames are indeed dropped. It seems that page freezing is a problem of some operations. But can we see other problems with this data? According to the content marked by the three data items, theoretically, if the time occupied by the UI thread is too long, the time data of draw will be too long, so an experiment is conducted, slept for 1 s in the UI thread. The figure below is displayed. From the figure, we can see that there are several frames of draw which are abnormally high. The draw section shows the general usage of the UI thread. Of course, in fact, this data mainly shows the overall situation. A single part is also closely related to the test environment. For example, the two groups of data are all Instagram, for the same data, the above is the Desire Z 4.1 system, and the following is the 3 4.1 system. In the execute part, there is a significant gap between the two. 2. the specific analysis of the "GPU rendering mode analysis" data can only describe one symptom. For example, the data mentioned above can indicate that there will be a short long draw problem in actual operation. The specific cause of the problem is not described. In addition, "GPU rendering mode analysis" displays the last 128 frames of data, but frame dropping may also result from a long operation between two frames. Therefore, we need to analyze the situation between frames to better understand the overall performance of the analyzed application. Two tools are provided in Android to achieve this purpose: 1. systrace (this tool pitfall me .... 2. traceview systrace is used to analyze the entire system. The data is accurate and includes the application to be analyzed. This tool is provided only after 4.1. (2) the kernel of the mobile phone must support trace (you can check whether the directory/sys/kernel/debug/tracing exists ), therefore, many third-party Rom or Samsung Rom remove this module from the kernel. It seems that none of them exist in the simulator. [This pitfall I brushed a lot of Rom to find the right one... I still remember one X in the past. This also indirectly shows that as a developer, I am still a good buyer.] There are two ways to run systrace, one is to run the py file under the SDK package, which requires many environment configurations. The other is the tool under ADT. Click to run it directly. Therefore, the following is an introduction. In this special analysis scenario, we generally only focus on the graphic performance. Therefore, we need to select graphics and view. There are many other options. If you are doing audio processing or video playback analysis and testing, you can choose other options. After the task is run, the scroll wheel is the list we want to test. The tool records data for 5 seconds, and then we get an HTML page. After opening, we can see that the page shows an overview of all running conditions in the system. Wasd is used to complete browsing operations. W/s zoom in/out A/D left shift/right shift there is a surfaceflinger in the page. People who know the android draw principles should be able to understand it, this is the service responsible for drawing the UI of the android application. Therefore, surfaceflinger can reflect the overall rendering situation. Generally, the normal situation is continuous. If there is a blank file, either it is not operated or it is slide to the header, there is nothing to draw. This is normal. The other is that there is a problem and other operations take too long. The line corresponding to the program to be analyzed can be enlarged to see the specific situation, and click to see the time used for each part. For example, deliverinputevent is a touch event provided by the system. Performtraversals is the process of starting the layout and painting the screen. Draw is the painting process.... For a listview, if deliverinputevent is too long, it is likely that the processing time in the getview method of the adapter is too long. Therefore, the systrace data can be used to identify whether there are performance problems. However, if you want to know the specific situation, you need to use another tool. Traceview is a simple tool, which records the execution time of each function in the application. In ddms, select the expected site for analysis and click "start method profiling" (the red dot icon in the upper right corner ). Then, start the application to be analyzed, and click the button again to stop the trail. The data shown below should be easy to understand. For details, see: http://hubingforever.blog.163.com/blog/static/17104057920112825035143/
Here I would like to introduce one of my experiences. Viewrootimpl. Draw (). This is the plotting function. After you click it, the Drawn Part is highlighted. Theoretically, the draw () diagram should be continuous as long as there is not much pause during the operation. To ensure smooth operation, each draw area should be 16 ms or less. So once you see that the region is larger than 16 ms, You can carefully analyze and see what operations have been done. In this way, you can find the problem that causes the rendering time to be too long. Although the use of these tools can help us locate problems more quickly, there are still many limitations. If you have a certain understanding of the principle of the overall Android system, and have a deep understanding of the running status of your program, this analysis will make you feel the best. The above are some of my personal opinions. I hope it can help you. I didn't write it too carefully. It is good to use it. Because some of them have many questions and I found a bunch of materials, no details are provided. Here are some of the references. You can check them out and some of them need to go out (how can we get this stuff done by every programmer ?) : Http://www.youtube.com/watch? V = q8m9shdyxne (Google Io, need to flip) http://udinic.wordpress.com/2013/03/04/android-app-to-the-challenge (
Need turn) http://www.curious-creature.org/docs/android-performance-case-study-1.html (need turn) http://blog.chengyunfeng.com /? P = 458 (this is the English translation above) http://www.linuxidc.com/Linux/2010-10/29168.htm
