Overview and startup process of FrameWork

FrameWorkframe

Framework defines client component and server component functions and interfaces. In the following description, "application" generally refers to the ".apk" program.

The framework contains three main parts, namely server, client and Linux driver.

Server

The server mainly contains two important classes, namely WindowManagerService (WmS) and ActivityManagerService
(AmS).

The role of WmS is to allocate windows to all applications and manage these windows. Including allocating the size of the window, adjusting the stacking order of each window, hiding or showing the window.

The role of AmS is to manage activities in all applications.

In addition, the server also includes two message processing classes.

KeyQ class: This class is an internal class of WmS and inherits from the KeyInputQueue class. Once the KeyQ object is created, a thread will be started immediately. The thread will continuously read the user's UI operation messages, such as buttons, touch screen, trackball, mouse, etc. And put these messages into a message queue QueueEvent class.

InputDispatcherThread class: Once an object of this class is created, a thread will be started immediately. This thread will continuously take out user messages from the QueueEvent and perform certain filtering. After filtering, these messages will be sent to the currently active client program. middle.

client

The client mainly includes the following important categories.

• ActivityThread class : This class is the main thread class of the application. All APK programs have one and only one ActivityThread class. The entry point of the program is the static main() function in this class.

• Activity class : This class is the smallest running unit of the APK program. An APK program can contain multiple Activity objects. The main ActivityThread class will choose which Activity object to run based on user operations.

• PhoneWindow class : This class inherits from the Window class. At the same time, the PhoneWindow class contains a DecorView object. In short, PhoneWindow wraps a FrameLayout to a certain extent and provides a set of common window operation interfaces.

• Window class : This class provides a set of common window (Window) operation APIs. The window here is only at the program level. The window managed by WMS is not the Window class, but a View or ViewGroup class, which generally refers to DecorView. Class, that is, a DecorView is a window managed by WmS. Window is an abstract type.

• DecorView class : This class is a subclass of FrameLayout and an internal class in PhoneWindow. The English name of Decor is Decoration, which means "modification". DecorView modifies the ordinary FrameLayout to a certain extent, such as adding a general Title bar and responding to specific key messages.

• ViewRoot class : When WmS manages the client window, it needs to notify the client to perform certain operations. These are all done through asynchronous messages. The way to achieve this is to use Handler. ViewRoot inherits from Handler, and its main function is to receive notifications from WmS.

• Class W : This class inherits from Binder and is an internal class of ViewRoot.

• WindowManager class : The client needs to apply to create a window, and the specific task of creating a window is completed by WmS. The WindowManager class is like a department manager. Anyone who has any needs can tell it, and it will interact with WmS. The client cannot Interact directly with WmS.

Linux driver

The Linux driver and Framework mainly include two parts, namely SurfaceFlinger (SF) and Binder. Each window corresponds to a Surface, and the function of the SF driver is to display each Surface on the same screen.

The function of the Binder driver is to provide cross-process message passing.

APK program running process

public static final void main(String[] args) {
        SamplingProfilerIntegration.start();
 
        Process.setArgV0("<pre-initialized>");
 
        Looper.prepareMainLooper();
        if (sMainThreadHandler == null) {
            sMainThreadHandler = new Handler();
        }
 
        ActivityThread thread = new ActivityThread();
        thread.attach(false);
 
        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }
 
        Looper.loop();
 
        if (Process.supportsProcesses()) {
            throw new RuntimeException("Main thread loop unexpectedly exited");
        }
 
        thread.detach();
        String name = (thread.mInitialApplication != null)
            ? thread.mInitialApplication.getPackageName()
            : "<unknown>";
        Slog.i(TAG, "Main thread of " + name + " is now exiting");
    }

First, execution begins ActivityThreadin main()the function, calling prepareMainLooper()Create a message queue for the UI thread ( MessageQueue).

Then create an ActivityThreadobject, and an object and an object ActivityThreadwill be created in the initialization code .H（Handler）ApplicationThread（Binder）

Binder is responsible for receiving the IPC call from the remote AmS. After receiving the call, it sends the message to the message queue through the Handler. The UI main thread will asynchronously retrieve the message from the message queue and perform corresponding operations, such as start, stop, pause, etc.

    final ApplicationThread mAppThread = new ApplicationThread();
    final H mH = new H();

Then the UI main thread calls Looper.loop()a method to enter the message loop body. After entering, it will continuously read and process messages from the message queue.

When ActivityThreadreceiving a start activity from AmS, the specified Activity object will be created. Activity will create the PhoneWindow class → DecorView class → create the corresponding View or ViewGroup.

After the creation is completed, the Activity needs to display the created interface on the screen, so it calls the WindowManagerclass, which then creates an ViewRootobject. The object actually creates ViewRootthe class and W. After the object 类is created , it calls the remote interface provided by WmS to complete the addition. A window is displayed on the screen.ViewRootWindowManager

Next, the user starts working on the program interface. KeyQThe thread continuously stores user messages into QueueEventthe queue, InputDispatcherThreadthe thread takes out the messages one by one, and then calls WMSthe corresponding function in the queue to process the message. When WMSit is found that the message belongs to a certain window of the client, the W interface of the corresponding window will be called.

Class W is a Binder, responsible for receiving IPC calls from WmS and passing the call message to ViewRoot. ViewRoot then passes the message to the UI main thread ActivityThread. ActivityThread parses the message and handles it accordingly.

In the client program, the first thing to process the message is DecorView. If DecorView does not want to process a message, it can pass the message to its internal sub-View or ViewGroup. If it has not been processed yet, it is passed to PhoneWindow, and finally passed to Activity.

Threads in the client

In a multitasking operating system, any program runs in threads. The system first allocates a thread to the client program, and then the thread starts execution from the entry of the program. So, consider the following questions.

What threads are there in the program when launching an Android APK?

First of all, it is very clear that the client program containing Activity contains at least three threads. Each Binder object corresponds to a thread. After the Activity is started, an ViewRoot.Wobject will be created and ActivityThreadan object will be created at the same time ApplicationThread. Both objects inherit from Binder, so two threads will be started, responsible for receiving IPC calls sent by the Linux Binder driver. The last main thread is the thread where the program itself is located, also called the user interaction (UI) thread, because all processing of user messages and drawing the interface are completed in this thread.

private final class ApplicationThread extends ApplicationThreadNative { ... }
public abstract class ApplicationThreadNative extends Binder
        implements IApplicationThread { ... }

static class W extends IWindow.Stub { ... }

In order to verify this, you can create a new Hello Android program in Eclipse, and then run it in debug mode. In the debug window, you will see the interface as shown in the figure.

Window related concepts

In the source code, the following concepts are often mentioned, window, Window class, ViewRoot class and W class. Briefly introduce the connection and difference between these concepts.

• Window (not referring to the Window class): This is a purely semantic term, that is, an independent interface on the screen that the programmer sees, such as an Activity interface with a Title Bar, a dialog box, and a Menu menu. etc. These are called windows. The window management mentioned in this book generally refers to all these windows. In English-related articles about Android, the word Window is used directly. From the perspective of WmS, the window is the smallest unit for receiving user messages. WmS uses a specific class internally to represent a window to manage the window. After WmS receives a user message, it must first determine which window the message belongs to, and then pass the message to the client's ViewRoot class through IPC calls.

• Window class: This class is an abstract class in the android.view package. This class abstracts the basic operations of the "client window" and defines a set of Callback interfaces. The Activity class implements this Callback interface to obtain messages. opportunity to handle because the message is initially delivered to the View object by WmS.

• ViewRoot class: This class is in the android.view package. When the client applies to create a window, it needs a client agent to interact with WmS. The ViewRoot internal class W completes this function. Each window managed by WmS will correspond to a ViewRoot class.

• W class: This class is an internal class of the ViewRoot class, inherited from Binder, and used to provide an IPC interface to WmS, thereby allowing WmS to control the behavior of the window client.

The reason why so many classes are used to describe a window is that the concept of window exists in the client and server (WmS), and the Framework defines a Window class, which is easy to cause confusion. In fact, WmS The managed window has nothing to do with the Window class.

Framework (Android) startup process

The Android startup process includes the entire process from Linux kernel loading to Home application startup.

• 1) Android is a system platform based on the Linux kernel. When starting, the Linux kernel is first loaded through the Bootloader (system loader). When Linux is loaded and started, the process is the same as the ordinary Linux startup process. The kernel is initialized first, and then the init process is called (the first process in the Linux user space is the parent process of all processes).

• 2) The Init process starts Zygote. The init process starts. The init process mainly creates and mounts the file directories required for startup, starts the attribute service (similar to the Windows registry), and starts the Zygote process.

• 3) The establishment of the Zygote (incubator) process is a real Android running space. Zygote incubates the first process SystemServer, and SystemServer starts various system service threads.

The SystemServer process plays the role of "nerve center" in the Android operating environment. Most system services that can be directly interacted with in APK applications run in this process. Common ones include WindowManagerServer (WMS), ActivityManagerSystemService (AMS), PackageManagerServer ( PMS), etc. These system services exist in the SystemServer process as a thread.

SystemService will start the Binder thread pool to create SystemServiceManage to create, start and manage the life cycle process of system services, and start various java layer system services, and then call systemReady() of WMS, AMS and other services to complete the startup.

• 4) When the above service threads are started, AMS completes the final startup with the systemReady call, and calls ActivityManagerServicein systemReadythe method startHomeActivityLockedto start the first Activity for the application, which is the label configured by the Launcher . At this point, the startup of the Android system is completed.ActionIntent.ACTION_MAINCategoryIntent.CATEGORY_HOME