Identifying the Problem<\/h2>\n
Have you ever experienced anything like this with your application?<\/p>\n
Or maybe you’ve seen the following in your logs:<\/p>\n This is the Android Choreographer warning you in advance that your application is not performing with the buttery smooth experience we’re aiming for. In fact, it’s telling you that you’re skipping frames and not providing your users a 60 FPS<\/strong> experience. We can do better! Here’s the basic process for identifying and fixing UI performance issues:<\/p>\n Android refers to these skipped or delayed frames as janky frames<\/a>. After your application has been running and interacted with to reproduce janky frames, run the following command:<\/p>\n This command will output something similar to the following:<\/p>\n Numbers never lie, so it’s apparent we have some janky frames (~9%). Let’s dig in further with the Systrace tool.<\/p>\n Systrace gives you an overview of the whole Android system and tells you what’s going on at specific intervals\u00a0of time.<\/p>\n Let’s start a Systrace on our device. First open Android Device Monitor<\/a> to get started. Once inside, we see the option to start a Systrace:<\/p>\n We’re then\u00a0prompted with a request for what we would like to trace. Selecting all of the Commonly Used Tags<\/strong> and leaving the Advanced Options<\/strong> deselected will generate a Here’s an example of a Okay great! But what does this all mean? Let’s take it a step at a time.<\/p>\n We can see that we have a number of alerts identified by the circular warning signs in our Alerts row. Taking a look at our process, we can see a row of frames. Frames colored yellow or red are those that exceed our 16 ms render time.<\/p>\n Clicking on the alert will show us an overview of the issue at the bottom of our trace window. We can drill down to the specific frame(s) in question by clicking on the correlating frame icon in the process, or by simply clicking Frame<\/em> in the alert description. This will show us the amount of time spent during this step:<\/p>\n Finally, you can mark that frame using the This example is showing a yellow<\/strong> frame, but we can get a general idea of what a performant\u00a0frame might look like.<\/p>\n From our Alert<\/strong>, we can see that we might want to avoid significant work in For our Frame<\/strong>, we can see that our Scheduling delays happen when the thread that is processing a specific slice wasn’t scheduled on the CPU for a long amount of time. Thus it takes longer for this thread to fire up and complete.<\/p>\n The amount of time that passed from the moment a slice is started until it’s finished.<\/p>\n The amount of time the CPU spent processing that slice.<\/p>\n Overdraw is excessive redraw of our user interface, resulting in a slow user interface experience (for layout inflation, animations, etc.). Debugging overdraw is fairly easy; we can enable diagnostics for this in your Android device’s settings by going to Settings -> Developer Options -> Debug GPU overdraw -> Show overdraw areas.<\/p>\n Once enabled, you will see many different colors on your layouts.<\/p>\n Bad Layout Performance:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Good Layout Performance:\n![\"\"](\"http:\/\/i.imgur.com\/e7imzwm.gif\")
Credit: Doug Sillars<\/a> for the great example.Scrolling is extremely choppy and, as a result, the user interface doesn’t seem responsive to the user. During the time that the application is unresponsive and choppy, if the user attempts to interact with the application and it takes longer than 5000 ms (5 seconds)<\/strong> for the application to respond, the Android OS will give us this lovely message:<\/p>\n![\"\"](\"http:\/\/i.imgur.com\/9iMFlmB.png\" "\\"\\"")
<\/p>\nI\/Choreographer(1200): Skipped 60 frames! The application may be doing too much work on its main thread.<\/pre>\n
\n
Getting Started<\/h2>\n
Counting Skipped Frames<\/h3>\n
adb shell dumpsys gfxinfo [PACKAGE_NAME]<\/code><\/p>\nStats since: 524615985046231ns\nTotal frames rendered: 8325\nJanky frames: 729 (8.76%)\n90th percentile: 13ms\n95th percentile: 20ms\n99th percentile: 73ms\nNumber Missed Vsync: 294\nNumber High input latency: 47\nNumber Slow UI thread: 502\nNumber Slow bitmap uploads: 44\nNumber Slow issue draw commands: 135\n<\/pre>\n
Using the Systrace Tool<\/h2>\n
Getting Started<\/h3>\n
![\"12.08.2016-13.30\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/44\/2019\/03\/12.08.2016-13.30.png\")
<\/p>\ntrace.html<\/code> file for the Trace Duration that you specify.<\/p>\nSystrace<\/code> over 30 seconds:<\/p>\n![\"jank1\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/44\/2019\/03\/jank1.png\")
<\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/44\/2019\/03\/blankjank.jpg\"){kind=spacer}
<\/p>\nm<\/code> hotkey and zoom in to the affected frame to see what work is being done on various threads, such as CPU Threads<\/code>, the\u00a0UI Thread,<\/code> and the\u00a0RenderThread<\/code>.<\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/44\/2019\/03\/jank6-1.jpg\")
<\/p>\nView.OnDraw()<\/code> or Drawable.Draw()<\/code>, especially allocations or drawing to Bitmaps<\/code>. Google gives us a tip to watch in this video<\/a>.<\/p>\nAdapter.GetView()<\/code> should recycle the incoming View<\/code> instead of creating a new one.<\/p>\nSystrace Terms<\/h3>\n
Frame Color<\/h4>\n
\n
Scheduling Delay<\/h5>\n
Wall Duration<\/h5>\n
CPU Duration<\/h5>\n
Overdraw<\/h2>\n
\n
![\"\"](\"http:\/\/i.imgur.com\/Nm9esfG.png\" "\\"\\"")
![\"\"](\"http:\/\/i.imgur.com\/KuoINc2.png\" "\\"\\"")
<\/p>\n
![\"\"](\"http:\/\/i.imgur.com\/VjPu4P1.png\" "\\"")
<\/p>\n![\"\"](\"http:\/\/i.imgur.com\/VWDa4ux.png\" "\\"")
<\/p>\n![\"\"](\"http:\/\/i.imgur.com\/m1XHLRi.png\" "\\"")
<\/p>\n