Skip to main content

Android UI Internal : SurfaceView Vs View

SurfaceView is-a View but is for different purpose and has its distinct characteristics in several aspects.

We don't use View directly but use its sub-class such as ImageView, TextView or customize View. Those subclass are called widget.SurfaceView have three primary usages: video playback, camera preview and  2D game. SurfaceView contains a SurfaceHolder which you can pass to MediaPlayer or Camera as display sink.  (Another option is to pass a TextureView - which deserves a article for explaining ) MediaPlayer/Camera don't accept widget as display sink.

Developer Effort  
To utilize SurfaceView , you need to implement the SurfaceHolder.Callback and listen to the SurfaceCreate event. Only when SurfaceCreated is called, the underlying Surface is guaranteed to be safe to use, such as calling mediaPlayer.setDisplay(SurfaceHolder).   For purpose other than video playback or camera, you will also need create an render thread, calling lockCanvas to get the Canvas , drawing to it and call unlockAndPost to post the change. More importantly, you need to synchronize the render thread and main thread. 

However, to customize a View, all you need to do is to override the onDraw() method.(set aside for the measure, layout stuff). The drawing is always in main thread and the Canvas is offered to you from framework. Much less work. 

To emphasis,  in case you overlooked, View is updated in main thread while SurfaceView is updated in another thread. 
Those are the main differences application developers should knows and cares about. However, there are a few more items that are not obvious unless you have looked into the framework internal. 

SurfaceView has dedicate Surface buffer while all the view share one surface buffer that is allocated by ViewRoot. In another word, SurfaceView cost more resources.

SurfaceView can not be hardware accelerated (as of JB 4.4) while 95% operations on normal View are HW accelerated using openGL ES.  

SurfaceView almost always goes to Hardware Composer and therefore power efficient. 

Every SurfaceView introduce a new Window while all the widget reside in the same Application Window as created in the RootView when a Activity is instantiated.By default, the Window for SurfaceView has lower z-order than the Application Window. If so , how is the video still visible? It is because the corresponding area of the application window is marked as transparent region.

Draw Timing
The time to draw is different. Normal view update mechanism is constraint or controlled by the framework. You call view.invalidate in the UI thread or view.postInvalid in other thread to ask the framework to update your view. However, the view won't be updated until next VSYNC arrived. The easy way to understand VSYNC is to consider it as a timer that fires up every 16 ms for a 60 fps screen. This mechanism to sync up drawing  with VSYNC was introduced in later Android to achieve better smoothness. However, for SurfaceView, you can render it anytime as you wish. 

Check out other articles in Android UI Internal series 

Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.

You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.

Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.