Use two pictures to tell you why your app freezes?

[[192710]]

What's the material?

You can get these materials from this article:

• Do you know what happens after setContentView()?
• Do you know how Android displays the images we expect on the screen?
• Have an overall grasp of Android's view architecture.
• Learn to analyze the causes of screen freezes from the root causes.
• Learn how to write a smooth app.
• Learn the details of Android from the source code.
• Here are two self-made pictures to help you understand Android's view architecture.

[[192711]]

Let's start with setContentView()

 public class AnalyzeViewFrameworkActivity extends Activity {
 @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_analyze_view_framework);
 }
 }

Most Android users must be familiar with the above code. But do you know what happens after writing it like this? Where is this layout added? Oh my god, here comes the knowledge point!

Many of you may know that this layout is placed in a parent layout called DecorView, but I still want to say it again.

This picture may be different from what you often see in books or on the Internet. Why is it different? Because I drew it myself, hahahaha...

Let's take a look at the picture and take a look at the most basic view framework of Android.

PhoneWindow

I guess many students know that every Activity has an instance of a Window object. This instance is actually of PhoneWindow type. So PhoneWindow is easy to see from the name that it should be the son (i.e. subclass) of Window!

Knowledge point: Every Activity has a PhoneWindow object.

So, what is the use of PhoneWindow? What role does it play in Activity? Let me call PhoneWindow the same as Window.

[[192712]]

Window literally means a window, which is similar to the concept of windows on a PC. But it is not that accurate. Let's look at the picture. As you can see, the layout we want to display is placed in its attribute mDecor, which is an instance of DecorView. I will focus on DecorView below, but let's focus on Window for now. Window also has a relatively important attribute mWindowManager, which is an instance of an implementation class of WindowManager (an interface). What we usually get through the getWindowManager() method is this mWindowManager. As the name suggests, it is the manager of Window, responsible for managing the window and the content displayed in it. Its actual implementation class is WindowManagerImpl. Maybe you are now looking for where this mWindowManager is instantiated in PhoneWindow. Can't you find it even if you scroll up and down? STOP! mWindowManager is instantiated in its father. The following code is in Window.java.

 public void setWindowManager(WindowManager wm,
 IBinder appToken,
 String appName,
    boolean hardwareAccelerated) {
 ...
 if (wm == null ) {
            wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
 //Get a WindowManager
 }
        mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
 //From here we can know that the wm obtained above is actually of WindowManagerImpl type.
 }

Through the above introduction, we already know that there is DecorView in Window that is responsible for carrying the layout, and WindowManager that is responsible for management (in fact, it is just a proxy, and we will talk about who it represents later).

DecorView

As mentioned earlier, the layout set by setContentView() in Activity's onCreate() is actually placed in DecorView. Let's find DecorView in the figure.

As can be seen from the figure, DecorView inherits FrameLayout, and generally, it will add a preset layout first. For example, DecorCaptionView places its own sub-layouts from top to bottom, which is equivalent to a LinearLayout. Usually it has a title bar and then an mContentRoot to hold the content. The type of this layout depends on the situation. The layout we want to display is placed in mContentRoot.

Knowledge point: The layout set by setContentView() is placed in DecorView, which is the top level of the view tree.

WindowManager

As mentioned before, WindowManager plays an important role in Window. Let's find it in the figure first. Here we need to explain that mWindowManager in PhoneWindow is actually of WindowManagerImpl type. WindowManagerImpl is naturally an implementation class of the interface WindowManager. This is something I did not reflect in the figure.

WindowManager is created when Activity executes attach(), which is called before onCreate(). For the creation of Activity, you can read my article: [Maybe the easiest one in history! One picture and 3 minutes to let you understand the Activity startup process, you will regret it if you don't read it! http://www.jianshu.com/p/9ecea420eb52].

Activity.java

 final void attach(Context context, ActivityThread aThread,
    Instrumentation instr, IBinder token, int ident,
    Application application, Intent intent, ActivityInfo info,
    CharSequence title, Activity parent, String id,
    NonConfigurationInstances lastNonConfigurationInstances,
    Configuration config, String referrer, IVoiceInteractor voiceInteractor,
 Window window){
 ...
        mWindow = new PhoneWindow(this, window);
 //Create Window
 ...
        mWindow.setWindowManager(
         (WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
         mToken, mComponent.flattenToString(),
         (info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
 //Note! This is where WindowManager is created.
 //This method has been mentioned before.
        if (mParent != null ) {
           mWindow.setContainer(mParent.getWindow());
 }
        mWindowManager = mWindow.getWindowManager();
 }

Continue looking at the picture. WindowManagerImpl holds a reference to PhoneWindow, so it can manage PhoneWindow. At the same time, it also holds a very important reference mGlobal. This mGlobal points to a singleton object of type WindowManagerGlobal, and each application has only one singleton. In the figure, I explained that WindowManagerGlobal maintains the DecorView of all Windows in this application, as well as the ViewRootImpl associated with each DecorView. This is why I mentioned earlier that WindowManager is just a proxy, and the actual management function is implemented through WindowManagerGlobal. It will be clearer if we look at an example of the source code. Let's get started!

[[192713]]

WimdowManagerImpl.java

 public void addView(@NonNull View   view , @NonNull ViewGroup.LayoutParams params) {
 ...
    mGlobal.addView( view , params, mContext.getDisplay(), mParentWindow);
 //Actually implemented through WindowManagerGlobal.
 }

From the above code, we can see that WindowManagerImpl is just a proxy of WindowManagerGlobal. At the same time, the above method is very important in the entire Android view framework process. We know that the interface will start rendering after the Activity executes onResume(). The reason is that when onResume() is called, the addView() method of WindowManager will be called (actually the addView() method of WindowManagerGlobal is called at the end) to add the view to the window. Combined with my article [Maybe the easiest in history! One picture will let you understand the Activity startup process in 3 minutes, you will regret it if you don't read it! http://www.jianshu.com/p/9ecea420eb52], it can help you better understand the Android view framework.

ActivityThread.java

 final void handleResumeActivity(IBinder token,
    boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
 ...
    ViewManager wm = a.getWindowManager();
 //Get WindowManager, actually WindowManagerImpl
 ...
 wm.addView(decor, l);
 //Add view
 ...
    wm.updateViewLayout(decor, l);
 //Will go here when refresh is needed
 ...
 }

As you can see above, when the Activity executes onResume(), it will add views or refresh views. One thing needs to be explained: WindowManager implements the ViewManager interface.

As shown in the figure, when WindowManagerGlobal calls addView(), it adds DecorView to the array it maintains, creates another key and extremely important object of type ViewRootImpl (this must be mentioned specifically), and also stores it in an array for maintenance.

WindowManagerGlobal.java

 public void addView( View   view , ViewGroup.LayoutParams params,
    Display display, Window parentWindow) {
 ...
    root = new ViewRootImpl( view .getContext(), display);
 //Important characters appear
 view .setLayoutParams(wparams);
 mViews.add ( view );
 mRoots.add (root);
 //Save and maintain
 mParams.add (wparams);
 ...
    root.setView( view , wparams, panelParentView);
 //Set the necessary properties view is DecorView, panelParentView is PhoneWindow
 ...
 }

It can be seen that ViewRootImpl is created when Activity executes onResume(), and DecorView is passed in for management at this time.

Knowledge point: WindowManager is created in onCreate(). Its ability to manage windows is actually implemented through WindowManagerGlobal. Views are added to windows through WindowManager in onResume().

ViewRootImpl

ViewRootImpl can interact with the system's WindowManagerService and manage the drawing and window status of DecorView. It is very important. Find the corresponding position in the picture quickly!

ViewRootImpl is not a View, but is responsible for managing views. It cooperates with the system to manage the view tree in a Window. As can be seen from the figure, it holds a reference to DecorView, and the view tree is the starting point for drawing the view tree. Therefore, ViewRootImpl is a little more complicated and requires us to understand it more deeply. In the figure, I marked its more important components, Surface and Choreographer, which will be mentioned later.

So far, we have gone through the first picture together, and now you should have a general understanding of the Android view framework. Next, we will take a closer look at the Android drawing mechanism.

What is the reason why the app is always stuck?

The following will explain in detail why the view we set can be drawn to the screen? What kind of weirdness is hidden in the middle? After reading it, you will naturally be able to understand the root cause of why your App is so stuck, and start to have ideas to solve these problems.

Let's use a picture to show this process. Since the Android drawing mechanism is indeed a bit complicated, you may be very excited when you first see it. Don't be afraid! We start from the source and sort out this seemingly complicated drawing mechanism bit by bit. Why does it seem complicated? Because this process only takes a few minutes. Just Do It!

What the hell is going on with CPU and GPU?

We hear about CPU and GPU all the time, but do you know what they do? Let me briefly mention them here to help you understand the following content.

In Android's drawing architecture, the CPU is mainly responsible for measuring, laying out, recording, and calculating the content into Polygons or Textures, while the GPU is mainly responsible for rasterizing Polygons or Textures so that they can be imaged on the screen. After using hardware acceleration, the GPU will share the CPU's computing tasks, while the CPU will focus on processing logic, thus reducing the CPU's burden and making the entire system more efficient.

RefreshRate refresh rate and FrameRate frame rate

RefreshRate is the number of times the screen refreshes per second, and is a fixed value related to hardware. On the Android platform, this value is generally 60HZ, that is, the screen refreshes 60 times per second.

FrameRate is the number of frames drawn per second. Usually, as long as the frame rate and refresh rate are consistent, you can see a smooth picture. On the Android platform, we should try to maintain a frame rate of 60FPS. But sometimes due to the complexity of the view, they may be inconsistent.

As shown in the figure, when the frame rate is less than the refresh rate, such as 30FPS < 60HZ in the figure, the same picture will appear in two adjacent frames, which causes lag. This is why we always say that we should try to ensure that a frame can be drawn within 16ms, just to keep pace with the screen refresh rate.

The following will describe how Android ensures that the refresh rate and frame rate remain in sync.

What is Vsync (vertical sync)?

You may have seen Vsync in the game settings. Turning it on usually improves game performance. In Android, Vsync is also used to improve display performance. It can force the frame rate FrameRate and the hardware RefreshRate to be consistent.

What HWComposer and Vsync have to say

Look at the picture. First, on the far left, we see a class called HWComposer, which is a class written in C++. It is created when the Android system is initialized, and then starts to cooperate with the hardware to generate Vsync signals, which is the HW_Vsync signal in the picture. Of course, it is not generated all the time, which will cause the recipient of the Vsync signal to continuously receive drawing and rendering commands, even if they are not needed, which will bring serious performance loss because a lot of useless drawing is performed. So it is designed to be able to wake up and sleep. This allows HWComposer to generate Vsync signals only when needed (such as when the content on the screen needs to change), and enter sleep state when not needed (for example, when the content on the screen remains unchanged, each screen refresh displays the unchanged content in the buffer).

As shown in the figure, there are two receivers of Vsync, one is SurfaceFlinger (responsible for synthesizing various Surfaces), and the other is Choreographer (responsible for controlling the drawing of views). We will introduce them later, but for now, just know what they do.

Vsync offset mechanism

In order to improve efficiency and minimize lag, the Vsync mechanism was introduced in Android 4.1, and the Vsync offset mechanism was added in the subsequent 4.4 version.

Figure 1 shows the Vsync mechanism in the 4.1 period. As you can see, when a Vsync signal arrives, SurfaceFlinger and the UI drawing process will start at the same time, causing them to compete for CPU resources. The CPU allocation of resources will take time, which will reduce system performance. At the same time, when a Vsync signal is received, the Nth frame starts to be drawn. When another Vsync signal is received, the Nth frame is synthesized by SurfaceFlinger. To display it on the screen, you need to wait for the third Vsync signal. This is relatively inefficient. So there is Figure 2. The Vsync offset mechanism added in version 4.4.

Figure 2. After Google added the Vsync offset mechanism, the original HW_Vsync signal will be divided into two virtualized Vsync signals, Vsync and SF_Vsync, through DispSync. The Vsync signal will be sent to Choreographer, while SF_Vsync will be sent to SurfaceFlinger. In theory, as long as the two offset parameters, phase_app and phase_sf, are set reasonably and the time consumed in the drawing phase is well controlled, the picture will be orderly and smooth like the first few frames in Figure 2. Ideals are always beautiful. In fact, it is difficult to maintain this order and smoothness all the time. For example, frame_3 is a more complex frame. The time it takes to complete its drawing exceeds the time it takes SurfaceFlinger to start synthesizing, so it must wait until the next Vsync signal arrives before it can be synthesized. This results in the loss of one frame. But even so, as you can see, after adding the Vsync offset mechanism, the drawing efficiency is still much improved.

As you can see from the figure, the offset of Vsync and SF_Vsync are controlled by phase_app and phase_sf respectively. These two values ​​are adjustable, the default is 0, and can be negative. You only need to find the BoardConfig.mk file to adjust these two values.

Back to ViewRootImpl

Several key concepts have been introduced above. Now let's go back to ViewRootImpl and find the corresponding position of ViewRootImpl in the figure.

As mentioned before, ViewRootImpl controls the drawing of the entire view tree in a Window. So how does it control it? How does a drawing start?

[[192717]]

When ViewRootImpl is created, it will get the key object Choreographer mentioned above. Choreographer has only one instance in one thread, so there is only one Choreographer in the UI thread. In other words, it is usually equivalent to a singleton in an application.

When ViewRootImpl is initialized, a Choreographer.FrameCallback (an inner class in Choreographer) is implemented and posted to Choreographer. As the name implies, FrameCallback is called back every time a Vsync signal is received.

Choreographer.java

 public interface FrameCallback {
 public void doFrame(long frameTimeNanos);
 //Once registered in CallbackQueue, then
 //Choreographer will call back every time it receives a Vsync signal.
 }

Once FrameCallback is registered, it will be called back every time a Vsync signal is received. Using it, we can monitor the frame rate.

ViewRootImpl.java

 //This method will only be called when ViewRootImpl is initialized
 private void profileRendering(boolean enabled) {
 ...
    mRenderProfiler = new Choreographer.FrameCallback() {
 @Override
 public void doFrame(long frameTimeNanos) {
 ...
 scheduleTraversals();
 //Request a Vsync signal, this method will be mentioned later
        mChoreographer.postFrameCallback(mRenderProfiler);
 //Each time the callback is called, post the FrameCallback to Choreographer again
 ...
 }
 };
 ...
    mChoreographer.postFrameCallback(mRenderProfiler);
 //Post the FrameCallback to Choreographer
 ...
 }

The above code shows an important method scheduleTraversals(). Let 's see why it is important.

 void scheduleTraversals() {
 ...
    mChoreographer.postCallback(
        Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null );
 //Post a TraversalRunnable to Choreographer
 //This is another very important object
 ...
 }

It can be seen that each time scheduleTraversals() is called, a TraversalRunnable is posted to Choreographer, which prompts Choreographer to request a Vsync signal. So the function of this method is to request a Vsync signal to refresh the interface. In fact, you can see that it is called in operations such as invalidate() and requestLayout(). The reason is that these operations need to refresh the interface, so a Vsync signal needs to be requested to trigger the drawing of the new interface.

ViewRootImpl.java

 final class TraversalRunnable implements Runnable {
 @Override
 public void run() {
 doTraversal();
 //Start traversing the view tree, which means starting to draw a frame of content
 }
 }

As can be seen from the figure, every time doTraversal() is called, a series of measurement, layout and drawing operations begin. When drawing, a Canvas memory block is obtained through Surface and handed over to DecorView for view drawing. The entire View content is drawn into this Canvas.

The ups and downs in Choreographer

We have repeatedly mentioned post callbacks to Choreographer, so what happened in the post? As can be seen from the figure, all post operations eventually enter postCallbackDelayedInternal().

[[192718]]

Choreographer.java

 private void postCallbackDelayedInternal( int callbackType,
    Object action , Object token, long delayMillis) {
 ...
 synchronized (mLock) {
        final long now = SystemClock.uptimeMillis();
        final long dueTime = now + delayMillis;
        mCallbackQueues[callbackType].addCallbackLocked(dueTime, action , token);
 //Add Callback to CallbackQueue[]
 if (dueTime <= now) {
            scheduleFrameLocked(now);
 //If the callback time is reached, request a Vsync signal
 //After receiving it, doFrame() will be called to callback this Callback.
 } else {
            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action );
            msg.arg1 = callbackType;
            msg.setAsynchronous( true );
 //Asynchronous message to avoid being intercepted by the interceptor
            mHandler.sendMessageAtTime(msg, dueTime);
 //If the callback time has not yet arrived, send it to FrameHandelr
 //MSG_DO_SCHEDULE_CALLBACK message
 }
 }
 ...
 }

The above code will add the Callback posted to Choreographer to Callback[], and when it is due to be called back, it will request a Vsync signal and call back the Callback when the next Vsync signal is received. If the callback time is not reached, a MSG_DO_SCHEDULE_CALLBACK message will be sent to FrameHandler, but a Vsync signal will be requested in the end, and then the Callback will be called back.

A brief talk about CallbackQueue: Let me briefly talk about CallbackQueue. It is similar to MessageQueue, both are single linked list structures. In my article [Shocking Secret! Starting from Thread, revealing the tricks of Android thread communication and the conspiracy of the main thread http://www.jianshu.com/p/8862bd2b6a29], you can see more about MessageQueue and Handler mechanism. The difference is that it is also a one-dimensional array, and the subscript indicates the Callback type. In fact, counting the single linked list structure of each type, it looks more like a two-dimensional array. To describe it simply, suppose there is a MessageQueue[] array, which stores several MessageQueues. Looking at its creation, you may understand that it is created when Choreographer is initialized.

 private Choreographer(Looper looper) {
    mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
 //The CALLBACK_LAST value is 3.
 for ( int i = 0; i <= CALLBACK_LAST; i++) {
        mCallbackQueues[i] = new CallbackQueue();
 }
 }

Now let's take a look at how scheduleFrameLocked() called in the previous code requests a Vsync signal.

 private void scheduleFrameLocked(long now) {
 ...
 //First determine whether it is currently in the UI thread
    if (isRunningOnLooperThreadLocked()) {
        scheduleVsyncLocked();
 //If it is a UI thread, request a Vsync signal
 } else {
        Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
        msg.setAsynchronous( true );
        mHandler.sendMessageAtFrontOfQueue(msg);
 //Send a MSG_DO_SCHEDULE_VSYNC message to FrameHandler without using the UI thread
 //To request a Vsync signal
 }
 } 
 
 private void scheduleVsyncLocked() {
    mDisplayEventReceiver.scheduleVsync();
 //Request a Vsync signal through DisplayEventReceiver
 //This is a hate character, we'll talk about it later.
 //The MSG_DO_SCHEDULE_VSYNC message also requests the Vsync signal by calling this method.
 }

As we mentioned above, there is only one Choreographer in one thread. Therefore, if it is in other threads, it is necessary to switch to the UI thread through the Handler and then request the Vsync signal.

Let's take a look at what the mDisplayEventReceiver that just appeared is.

[[192719]]

 private final class FrameDisplayEventReceiver extends DisplayEventReceiver
 implements Runnable { 
 
 //This method is used to receive the Vsync signal
 public void onVsync(){
 ...
        Message msg = Message.obtain(mHandler, this);
        msg.setAsynchronous( true );
        mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
 //The message type is not set here
 //In fact, the default is 0, that is, the MSG_DO_FRAME type message
 //It actually notifies Choreographer to start calling back the Callback in CallbackQueue[]
 //That is, start drawing the content of the next frame
 } 
 
 //This method is in the parent class, written here for easy viewing
 public void scheduleVsync() {
 ...
        nativeScheduleVsync(mReceiverPtr);
 //Request a Vsync signal
 }
 }

This makes the class function clearer, and it's important!

[[192720]]

The above has been talking about sending messages to FrameHandler, which makes it mysterious. Next, let's take a look at FrameHandler itself. Please find the corresponding position in the picture.

 private final class FrameHandler extends Handler {
 public FrameHandler(Looper looper) {
 super(looper);
 } 
 
 @Override
 public void handleMessage(Message msg) {
 switch (msg.what) {
 case MSG_DO_FRAME:
 //Start callback to start drawing the next frame
                doFrame(System.nanoTime(), 0);
 break;
 case MSG_DO_SCHEDULE_VSYNC:
 //Request a Vsync signal
                doScheduleVsync();
 break;
 case MSG_DO_SCHEDULE_CALLBACK:
 //Actually it also requests a Vsync signal
                doScheduleCallback(msg.arg1);
 break;
 }
 }
 }

FrameHandler mainly processes three types of messages in the UI thread.

• MSG_DO_FRAME: The value is 0. This type of message is sent when a Vsync signal is received, and then the callback in CallbackQueue[] is started. For example, as mentioned above, there are two important callbacks in ViewRootImpl, FrameCallback (request Vsync and register callback again) and TraversalRunnable (execute doTraversal() to start drawing the interface), which are frequently registered.
• MSG_DO_SCHEDULE_VSYNC: The value is 1. This message is sent when a Vsync message is required (i.e. the content on the screen needs to be updated). After receiving Vsync, the same step is followed.
• MSG_DO_SCHEDULE_CALLBACK: The value is 2. Request a callback. In fact, it will first request a Vsync signal, then send the MSG_DO_FRAME message, and then the callback.

FrameHandler is not complicated, but it plays an important role in the UI drawing process, so be sure to sort out this process with the help of the diagram.

SurfaceFlinger and Surface in a nutshell

When introducing Vsync, we may have seen that the Android system now virtualizes HW_VSYNC into two Vsync signals. One is VSYNC, which is sent to the Choreographer mentioned above to trigger the drawing and rendering of the view tree. The other is SF_VSYNC, which is sent to SurfaceFlinger, which I will talk about next, to trigger the synthesis of Surface, that is, the synthesis of each Window window. Next, let's take a brief look at SurfaceFlinger and Surface. Since this part is basically written in C++, I will focus on the principle.

Surface hidden behind

Usually, students all know that our views need to be drawn. So where are they drawn? Perhaps many students immediately think of a word: Canvas. But, ~ that's right! It is drawn to Canvas. So how does Canvas come from? Yes, it can be New. But as mentioned earlier, the view tree in our Window is drawn to a Canvas provided by Surface. Those who have forgotten, please reflect on your mistakes 😄.

[[192721]]

Canvas actually represents a piece of memory used to store drawn data. In the Canvas constructor you can see:

 public Canvas() {
 ...
    mNativeCanvasWrapper = initRaster( null );
 //Apply for a block of memory and return a long-type tag or index of the memory.
 ...
 }

As you can see, Canvas actually holds the index of a memory block for drawing, long mNativeCanvasWrapper. Each time you draw, you find the corresponding memory block through this index, and then draw the data into the memory. For example:

 public void drawRect(@NonNull RectF rect, @NonNull Paint paint) {
    native_drawRect(mNativeCanvasWrapper,
        rect. left , rect. top , rect. right , rect.bottom, paint.getNativeInstance());
 //Draw a rectangle in the memory marked by mNativeCanvasWrapper.
 }

Let me explain it briefly. Android draws graphics through the graphics library Skia (mainly for 2D) or OpenGL (mainly for 3D). What is the concept of a graphics library? It is like drawing with a drawing board on a PC. In this case, the drawing board is equivalent to the graphics library in Android, which provides a series of standardized tools for us to use for drawing. For example, our drawRect() actually operates the graphics library to write a rectangular data in the memory.

Enough of the talk, let's get back to Surface. When ViewRootImpl executes the draw() method (that is, it starts drawing graphics data), it will decide whether to use CPU soft drawing or GPU hard drawing based on whether hardware acceleration is enabled (it is enabled by default since Android 4.0). If soft drawing is used, the graphics data will be drawn on the default CompatibleCanvas of Surface (the only difference from ordinary Canvas is that the Matrix is ​​processed to improve compatibility on different devices). If hard drawing is used, the graphics data will be drawn on DisplayListCanvas. DisplayListCanvas uses the openGL graphics library through the GPU for drawing, so it is more efficient.

As mentioned briefly above, each Window will have its own Surface, which means that there will be multiple Surfaces in an application. Through the above explanation, you all know that the role of Surface is to manage the Canvas used to draw the view tree. This Surface is shared with SurfaceFlinger. Since it implements the Parcelable interface, you can expect it to be serialized and passed. In fact, the drawing data in the Surface is shared with SurfaceFlinger through anonymous shared memory, so that SurfaceFlinger can find the drawing data in the memory area corresponding to different Surfaces and then synthesize them.

Compositor SurfaceFlinger

SurfaceFlinger is a system service. As mentioned above, it is responsible for compositing the contents of each Surface into a cache to be displayed on the screen. When SurfaceFlinger synthesizes Surface, it does so layer by layer according to the Z-order of the Surface. For example, a Dialog's Surface will be on top of an Activity's Surface. I won't mention this anymore.

Finally, I can tell you why your app is so stuck.

Through understanding the Android drawing mechanism, we know that the root cause of application jams is that the drawing, rendering and synthesis process cannot be completed within 16ms, because the hardware refresh rate of the Android platform is 60HZ, which is refreshed approximately every 16ms. If this process cannot be completed within 16ms, the screen will repeat the content of the previous frame, which will cause jams. Within these 16ms, all measurement, layout, drawing, rendering and synthesis of the view tree need to be completed. And our optimization work is mainly aimed at this process.

Complex view trees

If the view tree is complex, the entire Traversal process will be longer. Therefore, we must control the complexity of the view tree during development. Reduce unnecessary hierarchical nesting. For example, using RelativeLayout can reduce the nesting of complex layouts. For example, using [Shock! This control is definitely worth collecting. Easily achieve rounded corners, text strokes, status indicators and other effects http://www.jianshu.com/p/cfe18cbc6924] 😄, this control can reduce the complexity of layouts that require both text display and images and special backgrounds, and all things are implemented by one control.

Frequent requestlayout()

If requestLayout() is triggered frequently, layout calculations may occur frequently within a frame cycle, which will also cause the entire Traversal process to take longer. Some ViewGroup type controls, such as RelativeLayout, will calculate and confirm the position of the child View through two layout() operations within a frame cycle. This small amount of operation will not cause noticeable performance problems. However, if layout() calculations occur frequently within a frame cycle, it will cause serious performance problems, and each calculation will take time! The requestLayout() operation will add Views that need to be re-layouted to a List collection called mLayoutRequesters in ViewRootImpl, and these Views will all be re-layout()ed in the next frame. Usually after a control is loaded, if there is no change, it will not be re-layout()ed once in each refresh, because this is a time-consuming calculation process. Therefore, if there are many Views that need to be layout()ed in each frame, you can imagine that your interface will be stuck! Stuck! It should be noted that setLayoutParams() will eventually call requestLayout(), so it should not be used indiscriminately! Students must be careful to pay attention to those places that may cause requestLayout() when writing code!

The UI thread is blocked

If the UI thread is blocked, it is obvious that our traversal process will also be blocked! The screen will freeze. This is why everyone has been emphasizing not to do time-consuming operations on the UI thread. Usually the blocking of the UI thread is closely related to the following reasons.

Perform IO read and write data operations in the UI thread. This is a very time-consuming process, okay? Don't do this. If you don't want to get an App that is stuck, put all IO operations in the child thread.

Perform complex calculations in the UI thread. The calculation itself is a time-consuming operation. Of course, simple calculations are completed almost instantly, so you won't feel it is time-consuming. But for very complex calculations, the time consumption is very eye-catching! If you don't want to get an App that is stuck, put the complex calculations in the child thread.

Perform complex data processing in the UI thread. I mean data encryption, decryption, encoding, etc. These operations require complex calculations, especially when the data is complex. If you don't want an app that is stuck, put the complex data processing work in the child thread.

Frequent GC causes frequent interruptions of the UI thread. In Java, GC (garbage collection) means Stop-The-World, which means that all other threads will be suspended. How terrible! It is acceptable for normal GC to cause occasional screen freezes, but frequent occurrences are very annoying! The culprit of frequent GC is memory jitter. At this time, you need to read my article [Android Memory Basics - Memory Jitter http://www.jianshu.com/p/69e6f894c698]. Simply put, a large number of objects are frequently created in a short period of time, resulting in the GC threshold being reached, and then GC occurs. If you don't want to get an App that is stuck, manage the memory well, even if it is Java.

Deliberately block the UI thread. Well, I believe no one would do this. For example, sleep()?

Summarize

It takes motivation to take out spare time to write articles and share them. Please give me some encouragement by giving me a thumbs up.😄

I have been creating new useful information from time to time. If you want to join the train, just go to my personal homepage and follow me.

After reading this article, I believe you have a more comprehensive understanding of Android's drawing mechanism. Now when you go back to write code, do you feel confident that you know everything? 😄

Reference Links

1. Implementing VSYNC: https://source.android.com/devices/graphics/implement-vsync
2. SurfaceFlinger and Hardware Composer: https://source.android.com/devices/graphics/arch-sf-hwc
3. Surface and SurfaceHolder: https://source.android.com/devices/graphics/arch-sh
4. Implementing the Hardware Composer HAL: https://source.android.com/devices/graphics/implement-hwc
5. It may be the simplest one in history! One picture will let you understand the Activity startup process in 3 minutes. You will regret it if you don't read it! http://www.jianshu.com/p/9ecea420eb52
6. Shocking secret! Starting from Thread, revealing the tricks of Android thread communication and the conspiracy of the main thread http://www.jianshu.com/p/8862bd2b6a29
7. Shocking! This control is definitely worth collecting. Easily achieve rounded corners, text strokes, status indicators and other effects http://www.jianshu.com/p/cfe18cbc6924
8. Android Memory Basics - Memory Jitter http://www.jianshu.com/p/69e6f894c698
9. Android performance optimization rendering http://hukai.me/android-performance-render/
10. Introduction to the principles and implementation of Android hardware acceleration http://tech.meituan.com/hardware-accelerate.html
11. Analysis of Android SurfaceFlinger's processing of VSync signals http://blog.csdn.net/yangwen123/article/details/17001405
12. Android Vsync principle http://www.10tiao.com/html/431/201601/401709603/1.html
13. Android Choreographer source code analysis http://www.jianshu.com/p/996bca12eb1d?utm_campaign=hugo&utm_medium=reader_share&utm_content=note
14. Analysis of the creation process of the view object (View) of the Android application window (Activity): http://blog.csdn.net/luoshengyang/article/details/8245546
15. Virtualization of VSync signal in Android 4.4 (KitKat) http://blog.csdn.net/jinzhuojun/article/details/17293325
16. Understanding necessity of Android VSYNC signals: http://stackoverflow.com/questions/27947848/understanding-necessity-of-android-vsync-signals