Android Kernel Analysis Chapter 1 Application Framework Overview

In fact, Android is a Linux kernel-based GUI system. It only runs on mobile phones and has limited resources. In addition, it not only handles button events, but also touch events; the overall architecture can be referred to (this figure comes from the network ):

This chapter mainly introduces the application framework. The previous chapter has mentioned that android is designed based on multiple processes, take a look at the following manuscript diagram (the handy UML drawing tool is not found in MAC). Its Class Name is based on version 4.2.2:

It can be seen that the core includes 3 + X processes:

1. Servicemanager daemon: it is automatically started when the system is started. It is set through init. Rc. It is mainly used to load the binder driver, implement message transmission between systemserver and app process, and implement IPC intermediate call;
2. Surfaceflinger daemon: automatically started when the system is started. RC settings, which is also a driver, each window corresponds to a surface, which is used to display each surface on the same screen;
3. Systemserver process: this process is the first process incubated by zygote (for details, see chapter 9th). It can be understood as the server of the application framework and used to provide various system services, the core services include window management service windowmanagerservice and activity management service activitymanagerservice;
   1. Iactivitymanager: Manages activities in all applications. Its implementation class is activitymanagerservice. When an app needs to start an activity, it must first request iactivitymanager through the Binder Mechanism, OK and then call back activitythread in the app process. applicationthread for real activity loading;
   2. Iwindowmanager: defines the interfaces for various operations in the application window. Its implementation class is windowmanagerservice. Based on the binder framework, the window is stacked, hidden, or displayed; after the system receives a button or touch event, the driver will switch to windowmanagerservice and then calls back phonewindow in the app process. w: Distribution of various types of messages;
   3. Iwindowsession: defines the session between an application window and an application. Its implementation class is session. iwindowmanager is responsible for opening and maintaining the session and is responsible for directly dealing with the app, the binder mechanism is used to call IPC, and the app uses it to call iwindowmanager indirectly;
   4. Please think about one question: why does the app not directly deal with iwindowmanager? Instead, it needs to use iwindowsession for a transfer. Isn't this actually making the system architecture more complex?
      
      In fact, I also have this question. At present, my understanding is that iwindowsession has added the processing of the inputmethod input method, which integrates some windows of the application and the input window; iwindowmanager does not care whether there is an input method. In his eyes, there is only a window, while in the window, there is something that he does not care about;
4. Process where the app is located: each app is an independent process after it is started. This is the reason for X. How many apps X is;
   1. Context: The base class of the activity/service component. It can be understood as the context or scenario. Its implementation class is contextimpl. When startactivity () is called, it will be remotely called to iactivitymanager through the Binder Mechanism;
   2. Activity: one of the four basic components of the Android system, is the smallest unit class of the application. It can be understood as a page control class, as we call the action on the Java Server;
   3. Iapplicationthread: The binder interface provided by the application process to the System Service callback to perform activity loading. Its implementation class is activitythread. applicationthread;
   4. Activitythread: the main thread class for application execution. Each application has only one activitythread instance. The entry is the static main () function, and the thread is the UI thread or main thread;
   5. Window: provides the basic class of the common window operation API. Note: The Window managed in WMS refers to the view, not the window. The window here is just an abstract class, the Android system can run not only on the mobile phone, but also on other devices. At this time, their window operations can be completely different;
   6. Phonewindow: inherits from window, which is an implementation class applicable to window operations on mobile phones;
   7. Phonewindow. decorview: inherits from framelayout. It is the top-level view container displayed in the application window. That is, all View Controls added to the application are actually child of decorview;
   8. Viewparent: defines various operation API interfaces required by the parent of the view, and its implementation class is viewrootimpl/viewgroup;
   9. Viewrootimpl: the parent of the top-level container decorview;
      
      When we use activitythread. when handleresumeactivity loads the corresponding page content of a specific activity, it will add decorview to the window manager in windowmanager. At this time, the parent of decorview, which is already a top-level container, will be set to viewrootimpl;
      
      Understanding this is crucial because it directly affects the understanding of core functional points such as event mechanism transfer and view page re-painting;
   10. Iwindow: The binder interface provided by the application process to the System Service callback. It is used to receive and convert incoming buttons and touch events of the WMS service. Its implementation class is viewrootimpl. W;
   11. In an app, in order to ensure the smoothness of user experience, the system uses a large number of asynchronous callback mechanisms to ensure that the main UI thread is only responsible for UI-related things, and all other things are processed asynchronously; asynchronous callback involves the system's design of asynchronous message queues. For details, see the asynchronous message processing thread section in Chapter 2nd Java basics;

APK application running process

1. First, the application starts to run from the static main () function in activitythread, and CALLS preparemainloue () to create a message queue messagequeue for the UI main thread;
2. When an activitythread instance is created, the binder applicationthread and handler instance H are created. The former is responsible for receiving the remote ams ipc callback, and then sending the message to the Message Queue through h after receiving the message, then, the UI main thread will retrieve the message from MQ and execute the CREATE, start, resume, pause, stop, and destroy operations in the response;
3. Execute logoff. Loop () to bring the main UI thread into the message loop, ready to receive asynchronous messages at any time;
4. After activitythread receives the request of starting an acitivity sent by AMS, it creates a specified activity object based on the specified intent information;
5. During the activity loading process, a phonewindow instance is created and the view loaded from layout is added to the decorview container;
6. After that, the activity needs to display the created page information to the screen, so it calls the iwindowmanager broker windowmanager in the app. Therefore, windowmanager creates a viewrootimpl and W instance, and obtains the iwindowsession reference;
7. Windowmanager. addview () --> viewrootimpl. setview () --> iwindowsession. addtodisplay () --> iwindowmanager. addwindow (); then, use surfaceflinger to output the page content to the screen;
8. After the page is displayed as OK, you can perform various buttons or touch operations on the interface. All types of messages generated are implemented through inputdispatcherthread (C ++ has already implemented in 4.2.2, earlier versions are implemented by Java.) handler is forwarded to windowmanagerservice for asynchronous processing. The specific processing process is to determine which client the message belongs, then, call back to the specific instance of iwindow in the app process through the Binder Mechanism. w;
9. After that, decorview first obtains the message processing permission. If decorview does not want to process the message, it will continue to pass to the subview, if not, it is passed to phonewindow (in fact, the dispatchxxx method of decorview is called), and finally to activity (implementing window. callback Interface );
   
   For details about the message transmission mechanism in view, see Chapter 13th view working principle.

What is the difference between a custom thread and a UI main thread?

The main UI thread runs from activitythread and has executed logoff in the main () method. preparemainloue () adds a looper object to the thread, that is, messagequeue has been created for the thread, so you can define a handler object in the activity;

In a general custom thread, the handler object cannot be defined, because the handler object must have created messagequeue in the thread where it is declared. Otherwise, how can I perform asynchronous processing without a queue?

Of course, you can also define handler after manually adding a message queue to a custom bare thread;