Measuring Jank in Android Apps
How long does it take for your app to start?
The screen should refresh 60 times per second, or 60 hertz, for the majority of modern android devices. When there are screen actions, such as scrolling, transitions, or animations, the app should produce 60 frames per second to keep up with the refresh rate. Any stuttering, guttering, or just pausing you experience when an app isn’t keeping up with the refresh rate is known as JANK. Jank is the result of an app taking too long to make frames. Android produces user interfaces by creating a frame from your program and showing it on the screen. The system is compelled to skip frames if the application has a difficult time rendering the user interface. The said rendering or persistent screen flicker of frames is called Jank.
The main objective of an android developer is to ensure and maintain 60 frames per second throughout the entire time a user interacts with the App. The 60 frames per second for a developer is to have 16 milliseconds per frame, or (1000ms/60frames=16.666ms/frame=16.67ms per frame), to accomplish all of the work, which would include input, computation, network, and rendering of every frame to sustain a fluid motion for the users. There is a multitude of stuff that may go wrong that will cause your frame to take more than 16 milliseconds.
UI Performance
One must initially be able to gauge the system’s performance to diagnose and pinpoint any issues that might arise at distinct positions throughout the pipeline. This one is crucial for performance gains.
It is crucial that one acquainted themselves with a few terminologies before embarking on the process of spotting janks.
1. Frame rate: The frequency of frames that will rendered in 1 second is termed as the frame rate or frames per second.
2. Refresh rate: The number of times the display of an android device can update in a second is widely recognized as the refresh rate. It is quantified in Hertz. The refresh rate of a 60 Hertz display is 60 times per second.
3. Vsync or Vertical Synchronization: Vsync signal synchronizes the display pipeline. The GPU’s frame rate can be synchronized with the refresh rate of the display via a tool called Vsync. Vsync is a way to ensure that the GPU’s frame rate is in sync with the display’s refresh rate.
Considered in the present case, Vsync renders the frame after buffering it if the frame rate is significantly higher than the refresh rate. Except for gaming apps, there won’t be any negative effects. A stutter or jank occurs when the user experiences, whenever the frame rate is slower than the refresh rate.
TYPES OF UI RENDERING ISSUES
Broadly there are 3 levels of rendering issues:
- Slow rendering : UI rendering( 50% of all frames, >16ms<=700ms)
The app suffers from slow UI rendering when the system is forced to skip frames and the user will perceive jittering in the app.
2. Frozen Frames: UI rendering with (>700ms<=5s)
UI frames that take longer than 700ms to render are considered to as frozen frames. In this the App appears as stuck and is unresponsive to user input for almost a full second.
3. ANR (Application Not Responding!) : UI rendering with (>5s)
The system services Activity Manager and Window Manager keep track of an application’s responsiveness. When Android notices one of the following circumstances, it will show the ANR dialogue for that application:
a) No response within 5 seconds to an input event (such as a key press or screen touch event).
b) Within 10 seconds, a BroadcastReceiver’s execution has not been completed.
Detecting UI Performance Issues
It’s essential to figure out what produces the UI janks in the first place if we’re going to successfully resolve them. There are many granularities at which UI performance may be measured.
The frame rate of the app must initially be measured. There are broadly 2 techniques by which we can accomplish this:
(a) Profile HWUI rendering/ Profile GPU rendering
- A visual depiction of how long it takes to draw each frame of a user interface window is shown by the Profile HWUI Rendering tool as a scrolling histogram. Compared to a benchmark of 16 milliseconds per frame.
(b) gfxinfo [adb shell dumpsys gfxinfo <PACKAGE_NAME>]
- You may run the shell command dumpsys gfxinfo on the device using the command line. It gives you a dump of the rendering data for the current instance of your application, and that dump contains the Jank data for your app.
These techniques allow us to determine the frame rate, the number of janky frames, missing Vsync, and the duration of time spent at various rendering pipeline stages. We decide what to do next depending on the outcomes.
If there is a deterioration in UI performance, the profiler output and dumpsys provide high-level information. We require more specific information, such as the activity/fragment/method that is causing the dip, in order to narrow down the source of the performance reduction. Traceevents, Systrace, and Perfetto are a few other technologies we may utilise to do that.
Thank you for reading!! If you have any feedback please let me know in the comments.
