Continuous rendering of SurfaceView in Android game programming

The SurfaceView class is a view used to process the Surface. It is also a class provided by the Android API. What is Surface? It is an abstract original buffer and is used by the screen assembler to render a specific view. The screen aggregator is the behind-the-scenes driver for all rendering on Android and is responsible for pushing all pixels to the GPU. Our goal is to execute rendering in an independent thread, instead of occupying a large number of UI threads, because the UI thread still has a lot of work to do. The SurfaceView class provides a rendering method in threads other than the UI thread. SurfaceHolder and locked in order to render SurfaceView to another different thread outside the UI thread, we need to obtain an instance of the SurfaceHolder class, as shown below: SurfaceHolder holder = surfaceView. getHolder (); SurfaceHolder is a Surface package that can help us with our work. It provides two methods: Canvas SurfaceHolder. lockCanvas (); SurfaceHolder. unlockAndPost (Canvas canvas); the first method locks the Surface for rendering and returns an available Canvas instance. The second method is to unlock the Surface and ensure that the content drawn through Canvas can be displayed on the screen. We will use these two methods in the rendering thread to get the Canvas, use it for rendering and ultimately ensure that the rendered image is visible on the screen. Make sure that the Canvas passed to the SurfaceHolder. unlockAndPost () method is the same as the Canvas received from the SurfaceHolder. lockCanvas () method. When SurfaceView is instantiated, the Surface is not created immediately. Instead, it is created asynchronously. This Surface will be destroyed whenever the activity is paused or resumed and re-created. As long as the Surface does not take effect, we cannot obtain the Canvas from SurfaceHolder. However, we can use the following statement to check whether the Surface has been created: boolean isCreated = surfaceHolder. getSurface (). isValid (); if this method returns true, we can safely lock the Surface and draw it through the received Canvas. We must make sure that the Surface is unlocked again after SurfaceHolder. lockCanvas () is called. Otherwise, our activity may lock the phone. The following example shows how to use SurfaceHolder to perform rendering in a separate thread. [Java] package org. example. ch04_android_basics; import java. util. random; import android. app. activity; import android. content. context; import android. graphics. canvas; import android. OS. bundle; import android. view. surfaceHolder; import android. view. surfaceView; import android. view. window; import android. view. windowManager; public class SurfaceViewTest extends Activity {FastRenderView renderView; @ Ov Erride protected void onCreate (Bundle savedInstanceState) {// TODO Auto-generated method stub super. onCreate (savedInstanceState); requestWindowFeature (Window. FEATURE_NO_TITLE); getWindow (). setFlags (WindowManager. layoutParams. FLAG_FULLSCREEN, WindowManager. layoutParams. FLAG_FULLSCREEN); renderView = new FastRenderView (this); setContentView (renderView);} @ Override protected void onPause () {// Todd O Auto-generated method stub super. onPause (); renderView. pause () ;}@ Override protected void onResume () {// TODO Auto-generated method stub super. onResume (); renderView. resume ();} class FastRenderView extends SurfaceView implements Runnable {Thread renderThread = null; SurfaceHolder holder; Random rand = new Random (); volatile boolean running = false; public FastRenderView (Context context Context) {sup Er (context); // TODO Auto-generated constructor stub holder = getHolder ();} public void resume () {running = true; renderThread = new Thread (this); renderThread. start ();} public void run () {while (running) {if (! Holder. getSurface (). isValid () continue; Canvas canvas = holder. lockCanvas (); canvas. drawRGB (rand. nextInt (255), rand. nextInt (255), rand. nextInt (255); holder. unlockCanvasAndPost (canvas) ;}} public void pause () {running = false; while (true) {try {renderThread. join (); break;} catch (InterruptedException e) {// retry }}} in the onCreate () method, we started the full screen mode, create a FastRenderView instance and set it to the active content view. This time, we have rewritten the onResume () method. In this method, we call the FastRenderView. resume () method to indirectly start the rendering thread. This method will process all operations internally. This means that the thread is started when the activity is created (the onResume () method is always called after onCreate () is executed ). When the activity resumes from the paused state, the thread is restarted. Of course, this also means that we must stop this thread somewhere; otherwise, we need to create a new thread each time we call the onResume () method. This operation should be performed in the onPause () method. When the FastRenderView. pause () method is called, the thread is completely stopped. This method will not be returned until the thread is completely stopped. Here, why does the volatile modifier of the running flag need it? The cause is subtle: When the compiler knows that there is no dependency between the first line of the method and the while block, it will decide to re-sort the statement in the FastRenderView. pause () method. As long as it thinks this can speed up code execution, it will allow this. However, we still rely on the sequence specified in this method. Imagine what if we set the running flag after trying to connect to the thread. We will enter an infinite loop and the thread will never be terminated. The volatile modifier is used to prevent this situation. Any statements that reference modified members are executed in order. This avoids a BUG that cannot be completely reproduced. After we return from the active onPause () method, the Surface will always be destroyed. Because we wait through the FastRenderView. pause () method until the thread is destroyed, when the Surface is actually destroyed, the rendering thread will not survive. Running effect: the running effect should be said that the screen displays a random color, but the mobile phone is always flashing in different colors, and the pictures taken by the mobile phone become like this.