Analysis of Android surfaceview operating mechanism — handling exceptions when switching to the background and re entering the program

Many friends have encountered this kind of problem. When the program is executed, switch to the background, and then re-enter the system. This paper comprehensively explains the operation mechanism of surfaceview. After understanding these principles, you can solve these problems by yourself.

We usually switch to the background by clicking the home button or the return button, and then we may enter the program again. At this time, we may report an exception. There are two possible exceptions reported by surfaceview, as follows:

1、 Exception submitting canvas. The following figure (simulator error prompt and logcat detail)

Java code

First look at note 1. In the previous article, I explained why SFH unlockCanvasAndPost(canvas); It is written in finally to ensure that the canvas can be submitted normally.

Today, we mainly talk about note 2. Here we must determine whether the canvas is empty, because when the program cuts into the background, the canvas cannot be obtained! Once the canvas is empty, the error of parameter exception will appear when submitting the canvas!

2、 Thread startup exception. The following figure (simulator error prompt and logcat detail)

This exception is only reported when you click the home button during the running of the program and enter the program again. The exception says that our thread has started! Why is the back button all right?

OK, let's first explain in detail the mechanism of back and home buttons in Android! Then analyze the problem and solve the problem!

First look at mysurfaceviewanimation Code in Java class:

Java code

The above is our commonly used custom surfaceview, and we use the old framework of runnable interface. I won't say more. I add printing to the construction, creation, state change and extinction functions of this class!

OK, let's look at the first picture: (just running the program)

The left part of the figure above is dubug. This shows that we have a running thread called "himI"_ Thread_ one”。

The right part of the figure above is the logcat log. You can clearly see that when you enter the program for the first time, you will first enter the view constructor, then create the view, and then change the view state. OK, we all know this!

Here is the process of clicking the home button. At this time, the program is in the background, and then re-enter the program!

It can be seen from the above figure that our thread is still one. Here, we mainly observe the process from clicking home to entering the program again, as follows:

Click home to call view destruction, and then enter the program. First enter view creation, and finally change the view state.

The above process is easy to understand. The important roles play the ~ back button! Click the back button to see what happened!

First look at the debug column on the left. There is one more thread! Looking at logcat, I found that the constructor was called more than once by clicking the home button!

Well, from the program we tested, there is no doubt that when you click home and click back to enter the program again, the steps are different, and the number of threads has changed!

So here we can explain why it is not abnormal when we click the back button, but it will be abnormal when we click the home button!

Reason: when you click the back button to enter the program again, you first enter the view constructor, which means that a new thread comes out and starts! However, when we click home, it is different, because when we click home, the program will not enter the constructor again, but directly enter view to create the function. In view to create the function, we have an operation to start the thread. In fact, the thread that started the program for the first time is still running, so~ here must be an exception, saying that the thread has been started!

Some children's shoes will ask, why don't we put th = new thread (this, "himi_thread_one"); Just put it in the view creation function?!

Yes, you can! But when you repeat it several times, you find that there will be many more processes in your program! (as shown below)

Although the exception that the thread has started can be avoided, it is obvious that this is not the result we want!

Here is the most appropriate solution:

Modify mysurfaceviewanimation java：

Java code

The modifications here are as follows:

1. We all know that after a thread starts, as long as the execution of the run method ends, the thread will be destroyed, so I added a Boolean member variable himI (Note 1), which can control the demise of our thread! (Note 4)

2. Before starting the thread, set the Boolean value to true to keep the thread running.

3. When the view is destroyed, set the Boolean value to false to destroy the current thread! (Note 3)

OK, the diagram and explanation here are detailed enough. I hope you will be strict with the code when you really develop a game in the future~

The above describes the operating mechanism of Android surfaceview in detail. We will continue to supplement relevant knowledge in the future. Thank you for your support for this site!