Android development engineer interview questions! Sao Nian, your screen adaptation method should be upgraded, advanced learning materials!

Find a very good material for learning Android compiled by Great God on GitHub, and share it with everyone.

2. Basic knowledge of display system

In a typical display system, it generally includes three parts: CPU, GPU, and Display. The CPU is responsible for calculating frame data and handing over the calculated data to the GPU. The GPU will render the graphics data and put it in the buffer (image Buffer), and then Display (screen or display) is responsible for presenting the data in the buffer to the screen. As shown below:

2.1 Basic concepts

• Screen refresh frequency The number of screen refreshes in one second (how many frames of images are displayed in one second), in Hz (hertz), such as the common 60 Hz. The refresh rate depends on the fixed parameters of the hardware (which will not change).

• The progressive scan display does not display the picture on the screen at once, but scans from left to right and from top to bottom line by line, sequentially displaying the pixels of the entire screen, but this process is so fast that the human eye can’t detect it. To change. Take a 60 Hz refresh rate screen as an example, this process is 1000/60 ≈ 16ms.

• Frame rate (Frame Rate) represents GPU drawing frames in one second operating unit fps. For example, in the film industry, the speed of 24 frames is enough to make the picture run very smoothly. The Android system uses a more streamlined 60 fps, that is, the GPU can draw up to 60 frames per second. The frame rate changes dynamically. For example, when the picture is still, the GPU is not drawing, and the screen refreshes the data in the buffer, that is, the frame data last operated by the GPU.

• Screen tearing (tearing) The data in one screen comes from 2 different frames, and the screen will have a sense of tearing, as shown in the figure below

2.2 Double buffer

2.2.1 Reasons for screen tearing

The screen refresh rate is fixed. For example, every 16.6ms fetches data from the buffer to display a frame. Ideally, the frame rate and the refresh frequency remain the same, that is, every time a frame is drawn, the monitor displays one frame. But the CPU/GPU writing data is uncontrollable, so some data in the buffer will be rewritten without being displayed at all. That is, the data in the buffer may come from different frames. When the screen is refreshed, it will not I don't know the status of the buffer, so the frame captured from the buffer is not a complete picture, that is, the picture is torn.

Simply put, in the display process, the data in the buffer is modified by the CPU/GPU, causing the screen to tear.

2.2.2 Double buffer

How to solve the screen tearing? The answer is to use double buffering.

Since image drawing and screen reading use the same buffer, an incomplete frame may be read when the screen is refreshed.

Double buffering , so that the drawing and the display have their own buffers: GPU always writes the completed frame of image data to the Back Buffer , while the display uses Frame Buffer . When the screen is refreshed, the Frame Buffer will not change. When the Back buffer is ready They are only exchanged when they are ready. As shown below:

2.2.3 VSync

The question is again: when to exchange two buffers?

If the Back buffer is ready to complete a frame of data, then if the screen has not fully displayed the content of the previous frame at this time, there will definitely be a problem. It seems that this operation can only be performed after the screen has processed a frame of data.

After scanning a screen, the device needs to return to the first line to enter the next cycle. At this time, there is a period of time gap, called VerticalBlanking Interval (VBI). Then, this point in time is the best time for us to exchange buffers. Because the screen is not being refreshed at this time, screen tearing during the exchange process is avoided.

VSync (Vertical Synchronization) is the abbreviation of VerticalSynchronization. It uses the vertical sync pulse (vertical sync pulse) that appears in the VBI period to ensure that the double buffer is exchanged at the best time. In addition, swap refers to their respective memory addresses, and it can be considered that the operation is completed instantaneously.

Therefore, the concept of V-sync is not pioneered by Google, it has already appeared in the field of PCs in the early years.

Three, Android screen refresh mechanism

3.1 Problems before Android4.1

Specific to Android, before Android 4.1, screen refresh also followed the double buffer + VSync mechanism described above. As shown below:

Look at the process that will happen in chronological order:

1. Display displays the 0th frame of data. At this time, the CPU and GPU render the 1st frame, and it is completed before the Display displays the next frame
2. Because the rendering is timely, after the display is completed in the 0th frame, that is, after the 1st VSync, the buffer is exchanged, and then the 1st frame is displayed normally
3. Then the processing of the second frame starts, and the processing does not start until the second VSync is coming soon.
4. When the second VSync comes, because the data of the second frame is not ready, the buffer is not exchanged, and the first frame is displayed. This situation was named "Jank" by the Android development team, that is, frame loss occurred .
5. When the data preparation of the second frame is completed, it will not be displayed immediately, but will wait for the next VSync to perform buffer exchange and then display.

So in general, the screen simply displays the first frame one more time for no reason.

The reason is that the CPU/GPU calculation in frame 2 could not be completed before the arrival of the VSync signal.

We know that the double buffer exchange is carried out when Vsyn arrives. After the exchange, the screen will fetch the new data in the frame buffer, and the actual back buffer at this time can be used by the GPU to prepare the next frame of data. If the CPU/GPU starts to operate when Vsyn arrives, there is a full 16.6ms, which should basically avoid the appearance of jank (unless the CPU/GPU calculation exceeds 16.6ms). So how to make CPU/GPU calculations happen when Vsyn arrives?

3.2 drawing with VSync

In order to optimize the display performance, Google refactored the Android Display system in the Android 4.1 system and realized the Project Butter: After receiving the VSync pulse, the system will immediately start the rendering of the next frame. That is, once the VSync notification (triggered once in 16ms) is received, the CPU and GPU immediately start computing and then write the data to the buffer . As shown below:

The CPU/GPU processes the data synchronously according to the VSYNC signal, which allows the CPU/GPU to have a complete 16ms time to process the data, reducing jank.

In one sentence, VSync synchronization allows the CPU/GPU to take full advantage of 16.6ms and reduce jank.

The problem is again, if the interface is more complicated, the CPU/GPU processing time is longer than 16.6ms? As shown below:

1. In the second time period, but because the GPU is still processing the B frame, the buffer cannot be exchanged, resulting in the A frame being displayed repeatedly.
2. After B is completed, it can only wait for the next signal to come because of the lack of VSync pulse signal. So in this process, a long period of time is wasted.
3. When the next VSync appears, the CPU/GPU immediately performs the operation (frame A), and the buffer exchange, the corresponding display screen corresponds to B. It looks normal at this time. But because the execution time is still more than 16ms, the next buffer exchange that should be executed is delayed again-this cycle is repeated, and more and more "Janks" appear.

Why can't the CPU process the drawing work in the second 16ms?

The reason is that there are only two buffers, the back buffer is being used by the GPU to process the B-frame data, and the content of the frame buffer is used for the display of the Display, so both buffers are occupied, and the CPU cannot prepare the data for the next frame. Then, if another buffer is provided, the CPU, GPU, and display device can all use their respective buffers to work without affecting each other.

3.3 Three buffers

Three-buffering is to add a Graphic Buffer buffer on the basis of the double buffering mechanism, so that the free time can be used to the maximum, and the disadvantage is that the memory occupied by a Graphic Buffer is used more.

1. The first Jank is inevitable. However, in the second period of 16ms, CPU / GPU using third Buffer complete the calculation of the C-frame, although the multi display a still frame A, but subsequently displayed on a relatively smooth, to avoid further exacerbating Jank.

2. Note that in the third paragraph, the calculation of the A frame has been completed, but it will only be displayed when the fourth vsync comes. If it is double buffered, it can be displayed in the third vynsc.

The triple buffer effectively uses the time waiting for vysnc, reduces jank, but brings delay. So, the more Buffer, the better? This is negative. Buffer is normal or two. When Jank appears, three are sufficient.

The above is the principle of Android screen refresh.

End of sentence

In any case, no matter what kind of interview it is, if you want to avoid being abused by the interviewer, you have to max out the interview questions and make a comprehensive preparation. Of course, in addition to this, you also need to lay a solid foundation in peacetime. In this way, no matter how the interviewer digs into his own knowledge, you can still cope with it~

The editor compiled my 6 years of interview experience and study notes into a **937-page PDF,** and some high-quality video tutorials I have watched during the advanced learning process. **Uploaded in my GitHub: Android architecture video + BATJ interview topic PDF + study notes ** Please pick it up and share it free of charge !

2%E4%BD%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**Please you Pick up by yourself, share for free!

[External link image is being transferred...(img-uq9E7xgA-1614050826093)]

In fact, I saw many friends complaining about their low salary, including the author, because the interviewer did not give the interviewer a good answer during the interview. Therefore, the author will continue to update the problems encountered during the interview, and I hope that everyone will make progress and learn together with the author.