[Think about] what is android, And the andorid Mechanism

The nature of a good programmer is curiosity. How does the software work, how the screen is displayed, and why is the desktop form so human-friendly as being dragged by the mouse? If you have such problems frequently, congratulations, you are a very promising programmer.

I majored in automation in college and belong to electronics. I am also very interested in computers. When I first saw this, this is amazing (in fact, it is amazing to see things with screens ). The depth of hardware and software allows me to directly understand the two secrets of this mysterious machine. I am not the best software, but the hardware is actually very good. However, I guess I have a little say in the software through hardware. The following is a personal experience, hoping to inspire everyone. Because I have been using Android for about two years since I graduated from college, let's look at Android.

Android is an operating system (hereinafter referred to as OS) that runs on top of hardware. It can be equipped with apps on the OS, and apps are written based on OS exposed APIs. When you compile an android program, you will see that the program references android. jar (about 18.2 MB in the "ad directory \ sdk \ platforms \ android-17"), most of the APIs used in the program are here (such as activity ), however, this is not the case in the compiled apk. A simple demo only has a few MB of apk. However, if you reference a third-party class library (such as importing a jar package to libs or referencing an external package), the compiled apk will contain the jar package and increase the size. This is because android. the code in jar already exists in the operating system (not necessarily android. jar), and the android. jar is mainly used for checking during compilation, supporting code prompts, jump to the source code, android. jar is a programming template.
OK. After writing the minimum demo, you can run it on your Android phone. A short piece of code shows a wide range of interfaces, buttons, and click processing. However, this short piece of code cannot be run without the OS, and the simple effect is backed up by the pondang system.

For example, the layout file written in xml is translated into java at runtime, and the class, attribute, and structure layers correspond one to one (so the content written in xml can be completely replaced by java ). Most of the displayed views are based on views. View. draw is responsible for drawing all the views. The default background and click effect of the buttons you see are the png images that are provided by the system. However, View. who calls draw? If you call a breakpoint for debugging, you will find that the levels are very high. It is easy to look dizzy from the external to the internal. (the breakpoint finding mechanism should be honed for a long time, not a cold day ). From the breakpoint, we can see that the final initiator is Choreographer (this is responsible for "initiation" of "Drawing/event" and so on). Then, who is driving Choreographer to "initiate the painting"? ActivityThread, activityThread is the root cause of apk operation per frame. Those who know about GUI programming know that the program does not work, but can respond to clicks because the app is constantly monitoring you. This kind of monitoring is called "message loop" (to put it bluntly, is an endless loop). This endless loop is always judging whether there is any message (you can simply think of it as a flag) (such as clicking ), if yes, the branch calls back the corresponding processing function.

OK, Choreographer is a clear step on how to be driven. Someone threw a "Draw message" to the ActivityThread message loop ". But where does the message come from. When the program runs for the first time, it will take the initiative to throw one (you can imagine throwing it in program initialization). During running, all clicks and animations will be throttled (similar to views. invalidate), trigger re-draw.

OK. The root cause of the draw trigger is also tracked to a certain extent. But how is the view displayed on the screen. in draw, you can clearly see what you have written using canvas (for example, the most commonly used canvas. drawBitmap), but how does the draw on the canvas be transmitted to the screen. I haven't explored the source code for the moment, but after all, I have worked on arm and manually driven the display screen. Here I just make a rough guess that the basic principle should be different.

The basic idea is to draw apps → OS → drivers → hardware. Haha, it seems that all the final mechanisms related to hardware are like this. Drivers work directly with hardware. They are generally compiled in assembly or c and directly control the hardware interface. They are generally called hal (Hardware Abstraction Layer ). OS serves as an intermediate bridge. Canvas contains a bitmap (corresponding to a piece of memory). Various draws of canvas form a pixel matrix (the description of the screen pixel) which exists in bitmap and are passed to the driver through the OS. The driver directly drives the screen. The detailed code and mechanism in this process are rather cumbersome. However, theoretically, the image description can be displayed in the memory. How is the bitmap memory displayed?

There is a piece of memory called "Memory" (not very familiar with it, desktop graphics can be stored in the graphics card, which is actually a block of memory), as the name suggests, the memory is used to display the memory. The basic principle is that the driver uses two for (row and column) scan video memory to read each pixel and set a single pixel signal to a point on the corresponding screen. Two for statements are just one surface. But how is this single pixel signal set to a single point on the screen? Here we can simplify a single point of light to a "light bulb" with only two colors (white + black). The light bulb is connected to an I/O interface on the motherboard, and the light is on when the I/O port is powered on. If it is disconnected, the light will be black. The driver code controls the power failure of the io Interface Based on the single point of data in the video memory.
OK. A little more complicated. The current screen color is RGB (0xffffff table is white, and alpha in ARGB is only used to mix multiple layers, and the final display is RGB ). A screen is actually composed of three dots (red, green, and blue) (the TV that is close to your home can be quite clear ). The intensity of each vertex ranges from 0 to the brightest. The classification level is expressed in one byte (0x00 ~ 0xff, that is, 0 ~ 255, a total of 256 levels), one point can be controlled by eight io interfaces, the driver can control 8x3 io ports to display all the colors of a point.

Is it much clearer. However, a screen has so many points (1024x768 = 69632). Although the chip is small, it cannot have so many interfaces. Students who have played the embedded course know that generally there should be no more than 50 wires connected to a display screen (it should be much less than this one, but I do not know it clearly ). As I mentioned earlier, the driver is usually drawn by scanning two for one point and one point. Therefore, theoretically, a single point interface (8x3) is enough (actually slightly different ), but how does the screen know which actual point this point is drawn on? The motherboard and screen can be synchronized through the agreed timing sequence (add several synchronous signal interfaces to indicate which rows and columns ).

This time, I will probably roam here. I am not chasing for nothing, but to verify my ideas step by step and train my mind on the left. The best source code in Android is andorid-OS, which is the crystallization of cohesive thinking.