Android SurfaceView (1)

SurfaceView has recently been exposed to many unfamiliar users. With the help of Bolg, we have grown a lot. Make a summary and make progress together

I. First, let's talk about the View class and SurfaceView class.

(1) View class:

The View class is a superclass of Android. Each View has a canvas for painting. This canvas can be expanded as needed.
When you need to draw complex images or have high requirements on program execution efficiency, the View cannot meet your needs. View is a product of controls that are directly dragged in the Widget framework. For example, when dual buffering is required for display and direct access to the canvas, we need SurfaceView that is more powerful than View.

View: display View, built-in canvas, graphic rendering function, touch screen time, button event function, etc., must be updated in the main UI thread, the speed is slow.
(2) SurfaceView class: (API)

SurfaceView is an inherited class of View, which is embedded with a Surface specially used for drawing. You can control the format and size of this Surface. SurfaceView controls the position of this Surface.
SurfaceView: Expanded view Class Based on view, which is more suitable for the development of 2D games. It is a subclass of view and uses double buffering mechanism on the class, in the new thread, the new interface is faster than the view.
Surface is sorted in depth, which means it is always behind the window where it is located. SurfaceView provides a visible area where only the surface content in the visible area is visible. The layout display of the surface is affected by the hierarchical relationship of the view, and its sibling nodes are displayed at the top. This means that the content of the surface is blocked by its sibling view, which can be used to place overlays (for example, controls such as text and buttons ). However, when the surface has a transparent control, every change to it will cause the framework to recalculate its transparency with the top-level control, which will affect the performance. You can access this surface through the SurfaceHolder interface. The getHolder () method can obtain this interface.
When Surfaceview is visible, the surface is created. Before surfaceView is hidden, the surface is destroyed. This saves resources. Surface creation: surfaceCreated (SurfaceHolder) and surfaceDestroyed (SurfaceHolder ).
The core of SurfaceView provides two threads: the UI thread and the rendering thread. Note the following:
A. All SurfaceView and SurfaceHolder. Callback methods should be called in the UI thread, which is generally the main thread of the application. Various variables accessed by the rendering thread should be synchronized.
B. because the surface may be destroyed, it is only in SurfaceHolder. callback. surfaceCreated () and SurfaceHoledr. callback. surfaceDestroyed () is valid, so make sure that the rendering thread accesses the surface legally and effectively.

Ii. Differences between SurfaceView class and View class

The most essential difference between SurfaceView and View is that surfaceView can be re-painted in a new separate thread, and View must be updated in the main thread of the UI. Updating the screen in the main UI thread may cause problems. For example, if you update the screen too long, your main UI thread will be blocked by the function you are painting, then, you cannot respond to the buttons, touch, and other messages. When surfaceView is used to update the screen in the new thread, it will not block your main UI thread, but there will be another problem, that is, event synchronization. For example, if you touch the screen, you need to process the thread in surfaceView. Generally, you need an event queue design to save the touch event, which is a bit complicated.
View: You must update the screen in the main UI thread for passive update.
SurfaceView: both the UI thread and sub-thread can be used. Re-draw the screen in a new thread to take the initiative to update the screen.

Therefore, game applications generally fall into two categories based on the characteristics of the game:
A. Update the screen passively. For example, you can use view for chess. Because the image and the new image depend on onTouch for update, you can directly use invalidate. In this case, this Touch and next Touch takes a longer time and will not produce

Impact.
B. Proactive updates: for example, a person is always running. This requires a separate thread to repeatedly redraw a human's turntable to avoid blocking mian UI Thread. Obviously, view is not suitable and needs surfaceView for control.

 

 

From Damon_tong's column