In the process of APP/ game experience, users often have obvious problems such as unstable new screen refresh, incoherent visual and sensory images, game screen buffer time, low frame count and operation delay, etc. What are the specific influencing factors? We analyze the performance issues from the perspective of common metrics such as FrameTime, FPS, fluency, and Jank to help you improve the performance and quality of your apps and games.
A, FrameTime
FrameTime: The time taken between two frames (or simply the time taken to render a single frame).
Is there a connection between FrameTime and Caton? Take a look at the case diagram below:
As can be seen from the figure, the GPU rendering time (frame generation time) of FRAME B in the picture is greater than the display refresh interval, occupying two display refresh time. So one time the screen didn’t refresh. When there are multiple times when the screen does not refresh (that is, the screen does not change), there may be a lag.
From there, the conclusion is that what the player user really sees is the time between the new screen refresh, not the eglSwapbuffers- the time between the GPU rendering completes (with no submitted screen display). So all of the Frametime references below are to display-frametime.
Advantages of the PerfDog tool: the FPS and Frametime statistics of PerfDog are both screens that the user sees. Display the real FPS and Frametime of refreshing a new screen. So you can use Frametime directly to determine if there is a lag during the test.
Second, the FPS
Definition of FPS: the frame rate (the average number of frames refreshed in 1 second).
Average frame rate (FPS) : The average number of frames refreshed per second.
Instantaneous frame rate: The real-time FPS calculated from the time spent on a single frame, and the real-time frame rate calculated from the time taken to refresh each frame.
The picture rendering flow chart is as follows, each frame FrameTime.
The following figure shows the Frame rate and FrameTime of PerfDog:
Does FPS rate have anything to do with lag? We are divided into two scenes of Android and ios to further understand:
1, the iOS side
Apple’s WDDC18 developer conference Frame Acing
For example, in the following two game screens, the one on the left tries to run at 60 frames, but only gets to 40. The one on the right runs steadily at 30 frames:
The frame rate at the left side of the picture is high, and it looks like there’s a calorie/meal effect due to Micro Stuttering. The FrameTime at the left is shown below:
It can be seen from the FrameTime, the left high FrameTime FPS=40 frame rate occurs once FrameTim>=180ms, the theoretical average FrameTime=25ms. So non-uniform rendering, even though the frame rate is as high as 40, still feels very stuck.
Running the FrameTime at a low frame rate of 30 frames on the right is shown below:
As you can see from the FrameTime above, the frame rate is 30 FPS and the FrameTime is even 33ms, so the picture will be very smooth.
Conclusion: High frame rate, not necessarily smooth.
2, the Android side
Test system version: Android4.4 fluency mechanism – butter plan (Jank)
Calculation idea of Google Jank: Considering visual inertia, with hardware vsync time interval, if there is no new picture refreshed for one consecutive vsync, it is considered as a lag. In other words, no new picture refreshed at the next vsync time point, it is considered as a Jank.
Three, fluency
The relationship between fluency and lag can be summarized in the following flowchart:
Fluency affects caton. This can be simply understood in terms of visual inertia and movie frames:
1. Visual inertia
The visual expected frame rate, the user subconsciously thinks that the next frame should be the same as the current frame rate so let’s say it’s always 60 frames, the user subconsciously thinks that the next frame should also be 60 frames. Refresh is always 25 frames, and the user subconsciously thinks that the next frame should also be 25 frames. But refreshing 60 frames jumps to 25 frames, disrupting the user’s visual inertia. At this point, the user experience will feel sluggish.
2. Movie frames
Film frame rate (18-24), usually 24 frames. Film frame time: 1000ms/24=40ms. The film frame rate is a critical point. Below this frame rate, the human eye can basically sense a discontinuity in the picture, that is, a lag.
Fourth, PerfDog – Jank
The calculation idea of PerfDog Jank is as follows: Considering the visual inertia, the average frame time of the previous three frames is assumed as the reference. As the vsync interval, if there is no new render in two consecutive Vsync frames, it is considered as a potential lag. In other words, if the time of the next frame is more than twice the average frame time of the previous three frames, it is considered as a potential lag. At the same time, the time of a single frame is more than twice as long as that of a movie frame, which is 1000ms/24*2 (because the human eye can identify the discontinuity only when the frame is lower than 24), then it is considered a real lag. At the same time, if the single frame time is more than 3 times the film frame time, it is considered as a serious lag.
Note: Why vsync twice? GPU generally has a three-frame buffer. The current frame has occupied one buffer, that is, the remaining two buffer buffers. Generally, the human eye can tolerate two frames of delay.
Why is two movie frames time-consuming? The human eye can sense a discontinuity below 24 frames, which is the typical frame for a movie. That is, 1000ms/24=41.67ms for a movie frame, 41.67ms*2 for two movie frames and 41.67ms*3 for three movie frames.
Calculation method of PerfDog Jank:
If both conditions are satisfied at the same time, it is considered to be a caton Jank.
①Display FrameTime> The first three frames take twice as long on average.
Display FrameTime> Two movie frames (1000ms/24*2=84ms)
If both conditions are met, it is considered to be a serious catonbigjank.
①Display FrameTime > The first three frames take twice as long on average.
Display FrameTime > 3 frames (1000ms/24*3=125ms)
Google – Jank as shown in figure:
PerfDog – Jank as shown in figure:
A real-world test FrameTime calculates Jank, as shown below:
PerfDog – Jank as shown in figure:
Note: Low frame rate is not a lag, such as frame rate is only a few frames, what lag?
The current mainstream games compare Jank:
PerfDog – web platform
From the previous section, we learned that FrameTime, FPS, fluency, and Jank are closely related, and we can naturally come to our conclusions:
1. Games
Game fluency is the biggest impact on the user experience, so focus on FPS and Jank.
Note: For example, the game has foreseen the delay, such as the new UI pop-up caused by the delay, can be considered as interference, need to be eliminated, should not be counted in Jank, can be deleted through the web cloud, right-click the box.
2. APP
Apps also need to focus on FPS and Jank. You just need to distinguish the use scenarios, such as:
- Static page window
Only focus on FPS, FPS should be 0 in theory, otherwise, redundant refresh is likely to cause heat and power consumption of the phone.
- There is a scrolling animated page window
Just focus on the FPS, which is at an appropriate value, without the need for frequent refreshes.
- Quickly slide the page window.
Need to pay attention to FPS and Jank. This is the source of mobile interaction sensitivity, Android butter project Jank. In the sliding state, the higher the frame rate, the better, and the smaller the Jank, the better.
- The video window is displayed.
Need to pay attention to FPS and Jank, video lag directly affects the user. Video frame rate is generally 18-24 frames, Jank=0. For example, wechat play video, video player, etc.
Through the above content analysis, I believe you can clearly understand the performance parameters that affect the APP and game experience, and the focus of testing before and after launch. PerfDog is Tencent’s WeTest client performance testing tool that quickly locates and analyzes performance issues and is dedicated to improving APP and game performance.