This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/yili_xie/archive/2009/11/12/4803565.aspx
The pictures in Android apk are divided into 2D and 3D: 2D is implemented by Skia, that is, the SGL we see on the Framework diagram, SGL also calls some opengl content to achieve simple 3D effects. The 3D content is implemented by OpenGL | ES, and OpenGL | ES is an embedded version of Opengl, first, let's take a look at several ways of drawing Android apk, and then let's take a look at how this entire graphic system is built.
First of all, drawing is aimed at a piece of memory filled data provided to the application. If you haven't studied whether an Activity corresponds to a surface at the underlying layer, you should operate on the surface memory. To put it bluntly, we either call the 2D API drawing, call the 3D API drawing, and save the drawn image in the memory, finally, the content in the memory will be rendered by Opengl and then become pixel information that can be displayed on the screen. 1. the Apk application is mainly concerned with the use of these Apis. There are two ways to draw images in the Android apk [2D]:
1. Simple Graphics in View
It refers to some painting operations that have been directly implemented by Android, such as images, shapes, colors, pre-defined animation, etc. These simple painting operations are actually 2D graphic operations provided by skia. With these predefined operations, we can achieve operations such as pasting a background image, drawing a simple shape, and implementing some simple animations. Here, we can understand this simply, that is, we have not constructed a graph in a simple way. we just put our graphic resources into the view system, the graphic is drawn by the system. For example, we now bind an imageview to the activity. We can set the image View content to our picture, and then we can make the overall color of this picture blue, then we can add a pre-defined animation for this imageview, so that when the system wants to display this view, our picture will be displayed and there will be an animation with a blue tone, instead of defining the Drawing operation, we put the content into the view, and the system will draw the content. This method can only draw static or extremely simple 2D images. For highly real-time animations, high-quality games cannot be achieved.
2. Canvas
First, we need to understand that Canvas is a 2D concept defined in Skia. That is to say, in this way, we can still draw 2D images. We can understand this Canvas as a memory area provided by the system (but it is actually just a set of drawing APIs, and the real memory is the Bitmap below ), it also provides a complete set of operations on the memory area, all of which are drawing APIs. That is to say, in this way, we can draw exactly what we need or use Graphic to draw what we need. We can control everything we need to draw. This method can be divided into two types based on the environment: canvas painting with common View, and canvas painting with special SurfaceView. The main difference between the two is that you can define a special thread in SurfaceView to complete the drawing work. The application does not need to wait for the View to be refreshed to improve the performance. The previous one is suitable for animations with a small processing capacity and a small frame rate, such as chess games. The latter is mainly used in games and high-quality animations. Below are the typical sequence of the two methods:
2.1 View canvas
(1) define your own View: class your_view extends View {};
(2) Reload the onDraw method of the View: protected void onDraw (Canvas canvas ){};
(3) define your own painting operations in the onDraw method;
Ps: You can define your own Btimap:
Bitmap B = Bitmap. createBitmap (100,100, Bitmap. Config. ARGB_8888 );
Canvas c = new Canvas (B );
However, this Bitmap must be placed in the View canvas, and the drawn image can be displayed: public void drawBitmap (Bitmap bitmap, Matrix matrix, Paint paint );
After the invalidate () function is called, the system will re-call the onDraw () function in the near future. This time is short but not predictable. I used to call onDraw () write an if statement and use validate to let the system call onDraw in an endless loop to fl two images. The two images are almost flushed together. 2.2. Surface View Canvas
(1) define a SurfaceView: class your_surfaceview extends SurfaceView implements SurfaceHolder. Callback (){};
(2) surfaceCreated () surfaceChanged () surfaceDestroyed ();
(3) define your own focus on drawing thread: Class your_thread extends thread (){};
(4) The run () function of the overload thread [generally defines the Drawing operation in run and starts this thread in surfacecreated]
(5) The drawing process is generally as follows:
Surfaceholder = getholder (); // Get holder. This holder is mainly applicable to surface operations, and users do not have permissions to perform surface operations.
Surfaceholder. addcallback (this); // register the implemented callback
Canvas canvas = surfaceholder. lockcanvas (); // obtain the canvas for drawing.
/* ----------------------------------- Draw
** ---------------------------------- Finish drawing */
SurfaceHolder. unlockCanvasAndPost (); // submit and display
Some examples of drawing in the previous three methods are available in the SDK and are clearly written. I will not talk about it here. Here I will write some little experience in the code process, it should mainly involve Activity, which should be used in the future:
The first is about Eclipse:
(1) ctrl + shift + O can automatically add the required dependency package. This function is quite practical, and alt +/is a complete syntax;
(2) There are many useful functions in the code. What I remember is the declaration of F3 searching for classes, and the inheritance relationship of F4 searching for classes;
(3) breakpoint debugging is more convenient. You can choose to read the code in the top-right corner of Eclipse, as well as debug mode. I now use two log playing methods:
Log. E ("class", "value:" + classname); // checks whether the class is a null pointer.
Log. E (this. getclass (). getname (), "notice message ");
Then there is activity:
(1) First, try to put the UI design in XML for implementation, rather than in code for implementation, so as to facilitate design, modification and transplantation;
(2) All components used must be declared in manifest. Otherwise, an error will be reported if the corresponding conponet cannot be found in the program;
(3) Generally, each activity corresponds to a class and a corresponding layout file XML;
(4) Each activity is displayed only after setcontentview () is bound to the content, and you can obtain the required elements from this content (such as XML;
(5) The difference between res/drawable and res/raw is that the element pixels in drawable may be optimized by the system, but not in raw;
(6) When multiple activities obtain the same element from res/drawable, if one of them modifies its attributes, the corresponding attributes of this element in all other activities will be changed;
(7) res/anim stores animation-related xml. Below we summarize the packages used for 2D drawing:
Android. view // picture is in View
Android. view. animation // defines some simple Animation effects, such as Tween Animation and Frame. animation.
Android. graphics // defines APIs commonly used for drawing, such as canvas, paint, and bitmap.
Android. graphics. drawable // defines the corresponding Drawable, such as BitmapDrawable and PictureDrawable.
Android. graphics. drawable. shapes // defines some shapes. 2. Learn about 2D. Let's take a look at the 3D drawing method. 3D drawing SDK is very simple. It just introduces a general method, that is, inheriting a View, and then obtaining the Opengl handle in this View for drawing, it should be the same as 2D. The difference is that 2D APIs are used for drawing, and 3D is used for drawing. However, because 3D openGl | ES has a set of operating mechanisms, such as rendering process control, Android provides us with a dedicated GLSurfaceView for 3D drawing. This class is placed in a separate package android. opengl, which implements operations not available in other views:
(1) It has OpenGL | errors tracking and checking tools during elasticsearch calling, which facilitates debugging in Opengl programming;
(2) All plotting is performed on a special Surface, which can be finally combined into the android View system;
(3) It can select its own buffer type based on The EGL configuration, such as RGB565 and depth = 16 (in this case, SurfaceHolder is SURFACE_TYPE_GPU, is the memory allocated from EGL ?)
(4) All painting operations are provided through render, and render calls Opengl in a separate thread.
(5) the Opengl running cycle can be coordinated with the Activity life cycle.
Next let's take a look at a typical Sequence that uses GLSurface to draw 3D images.
(1) select your EGL configuration (that is, the buffer type required for drawing) [optional]:
SetEGLConfigChooser (boolean)
SetEGLConfigChooser (EGLConfigChooser)
SetEGLConfigChooser (int, int)
(2) Select whether debug information is required [Optional]:
Setdebugflags (INT)
Setglwrapper (glsurfaceview. glwrapper ).
(3) register an Renderer: setrenderer (glsurfaceview. Renderer) for glsurfaceview)
(4) set reander mode, which can be continuous rendering or rendering based on commands. The default value is continuous rendering [Optional]: setrendermode (INT)
Note that OpenGL must be bound to the lifecycle of the activity. That is to say, during activity pause, OpenGL rendering must also be pause. In addition, glsurfaceview also provides a very practical function of thread interaction queueevent (runnable), which can be used for interaction between the main thread and the render thread. The following is an example provided by the SDK:
Class myglsurfaceview extends glsurfaceview {
Private myrenderer mmyrenderer;
Public void start (){
MMyRenderer = ...;
SetRenderer (mMyRenderer );
}
Public boolean onKeyDown (int keyCode, KeyEvent event ){
If (keyCode = KeyEvent. KEYCODE_DPAD_CENTER ){
QueueEvent (new Runnable (){
// This method will be called on the rendering
// Thread:
Public void run (){
MMyRenderer. handleDpadCenter ();
}});
Return true;
}
Return super. onKeyDown (keyCode, event );
}
}
GLSurfaceView is a very learning class provided by Android. It is actually an example of how to add a drawing thread to the View and how to use a thread in Java, an example of how to add an event queue is a classic Sequence drawn using SurfaceView, and an example of how to define Debug information. I think I can learn a lot about it. The specific source code is as follows: /framworks/base/opengl/java/android/opengl/GLSurfaceView. java.
The 3D content is basically finished here, and the rest is mainly about how to use the Opengl API. Let's look at the simple cube in the API demo, for details about the complexity, see the implementation of the cube. Next we will summarize the packages required for 3D drawing:
Android. opengl // mainly defines GLSurfaceView
Javax. microedition. khronos. egl // egl interface of java Layer
Javax. microedition. khronos. opengles // opengl API
3. After learning about the basic 2D and 3D drawing methods, let's look back at the calling hierarchies of Opengl and Skia for Android.
3.1 first, let's look at 2D. 2D is the main graphics engine used. After all, 3D is subject to its high hardware requirements and is rarely used on mobile phones, skia can also partially achieve the effect similar to 3D, so it can be said that SKia implements the vast majority of graphics work on the Android platform. Next we will look at the call relationship between the application layer and the underlying layer to skia:
Android calls skia in a classic call process. Several packages of the application are provided in the SDK; JNI is placed in the Graphic directory under the JNI directory of the Framework; skia is placed under the external directory as a third-party component. Let's take a look at the skia structure:
The three databases involved are as follows:
Libcorecg. So contains part of/skia/src/CORE. For example, the region and rect are the basic unit for calculating the region in surfaceflinger.
Libsgl. So contains the/skia/src/Core | EFFECTS | images | ports | utils part and all content. This achieves most of skia's graphic effects and codec of the graphic format.
Libskiagl. So contains the content in/skia/src/GL, which is mainly used to call OpenGL for partial effect.
In addition, I have seen two directories in/skia/src: animator and view, which are not written into the makefile compilation path. I think these two directories are very important, I don't know whether Android is not used yet, or it is loaded in other ways.
To use skia interfaces to draw images at the underlying layer, we need to fully understand skia's entire set of mechanisms. In fact, it is not long before skia is open-source, and the information we can find on the Internet is very rough, if you really need to work in this area in the future, it will definitely require a certain amount of work.
3.2 Android's 3D call has puzzled me for a while, because OpenGL-related content has not been found in the framewoks/base/CORE/JNI directory, later, let's take a closer look at the content in OpenGL to know that android has implemented OpenGL locally. JNI and Java interfaces are all placed under/frameworks/base/OpenGL, in addition, it also includes a tool to generate JNI code.
Let's take a look at the opengl directory structure:
/Include all header files of egl and gles
The/java/android/opengl directory contains the GLSurfaceView to be used for 3D drawing.
The/java/com/google/android/gles_jni directory contains some automatically generated files.
/Java/javax/microedition/khronos/egl This Is The egl interface used by the application layer.
/Java/javax/microedition/khronos/opengl this is the opengl interface used by the application layer.
/Libagl. This is the main implementation of opengl.
/Libs contains the implementation of two libraries, one is libegl. so and the other is libGL | ES_CM.so
/Tools in my understanding, this is a jni generation tool.
Who knows Opengl programming is a big project. I think the current demand for 3D should be very low, and skia can also be used for many effects. So I think we should focus on skia in the future.
