AndroidView display and event distribution WSM end process sorting

For init, Zygote, systemServer process startup you can search by yourself and there’s a lot of stuff on the web about that

Start the APP process:

When the four components are started, the corresponding application process is not started. AMS uses sockets to communicate with the Zygote process and forks the process to execute the main function of a particular class. The application process is the main function of ActivityThread.

If startActivity is the cause, AMS will set up ActivityStack before telling Zygote to create the process, go to PMS to find the corresponding ActivityInfo object, Create a new TaskRecord stack (this one is set to Flag manually) to hold this ActivityInfo. This is then used to start the Activity after the process has been established.

Zygote will fork a process that executes ActivityThread’s main function.

The Main function of ActivityThread creates an ActivityThread object and then calls the Attach method of that object. The constructor initializes Looper. When the MH class (Handler) is created to respond to AMS requests, an application process is created, but the process does not know which application APK it corresponds to. So you pass yourself to AMS (actually ApplicationThreadProxy) and wait for AMS to tell you which Package it is.

After receiving the ATP, AMS queries the PMS for which ProcessRecord corresponds to the package name passed in by the original caller (APK corresponding structure). When Android restarts or installs the application process, PMS will scan the APK or the list file information in the scanned installed APK is saved in ProcessRecord and maps the package name to ProcessRecord with a data structure. It also saves a copy of the APK package name that has been started and the corresponding ProcessRecord.

After the PMS side finds the corresponding ProcessRecord information, it stores the useful information (manifest file) in a data structure to tell the newly started APP (via ATP)

According to the newly launched APP, only one process provides the running environment of Android, but it does not know which Package it corresponds to. In the previous step, AMS tells the information to ATP, and ATP uses MH to send a message for processing. The message name is BIND_APPLICATION. This message is processed in the following order: First, some information about the Process such as oOMADJ (Process priority), processName (Process name), etc. 1. Create LoakedApk (which marks an installed APK structure) 2. Create Context (resources and other information can be taken directly from LoadedApk) 3. Reflection to create listing file set of Application and calls onCreate 4. InstallContentP0rovider installation content providers, 5. Instrumention (this is a very important tool to use when you start an activity. This is how many AMS tools are used.)

At this point the process is already a qualified application process (bound to a package). — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Activity attach onCreate onStart

Remember that startActivity keeps a copy of the TaskRecord and the ActivityInfo query. This is where it’s going to be used. When THE AMS bar process starts, it’s going to create that Activity. AMS inform APT

When receiving the creation Activity message in APT, mh in AT will be entrusted to send the message processing, namely PerformLaunchActivity, which will reflect the creation Activity and call the Attach method of the Activity.

Attach: Creates the Policy class using the PolicyManager reflection, and policy uses the reflection to create the PhoneWindow class. Phonewindow is a concrete implementation of the Window abstract class.

Summary: So the attach method creates the window object: phoneWindow.

Oncreate creates drcoreView, decoreView initializes the status bar title bar, and adds a custom view to the DecoreView. Then call onStart

The setContentView calls the Window setContentView and sets the actionBar content of the decorRView.

The window method is the same thing as the phonewindow method. 1. Check whether decore is created or not. == 2. Then check whether content is empty to indicate whether content (i.e. our view) has been set before. If so, remove view 3. 4. Set decoreView’s ActionBar Content Summary: Initialize the DecoreView and set the incoming view to decorevirw.

Target Activity onResume Target Activity onStop, onDestory

So after the ATP gets the handlerResume message, it says window add View display, it adds an idleHandler object, it gets the HandlerResume message, it gets the DecoreView and the Window, So if YOU call the AddView method of window, it’s going to call Windows ImpL and it’s really windowGlobal doing things like add, delete, update, etc. When WindowGlobal is added, it calls the setView method of ViewRoot (which creates an InputChannel for event distribution) and then interacts with the WMS, which adds the view The subsequent operations such as adding, deleting and updating are all WindowGlobal objects. Session (WMS proxy) is used internally to interact with WMS, and WMS does the processing

Which IdleHnadler object is added for what? The reader should be able to guess that the onStop and OnDestory of the calling Activity are called. Depending on the Finishing state, which method to call back to. In fact, the interaction between AMS and APP mentioned above will send an extra message (recording the timeout), but when AMS calls the Activity onStop of the caller in Idle, onDestory is not set ~

WMS event distribution

Communicate using shared memory (the app side can fetch data, binder is slower than memory) and PIPES (real time input only one character is mainly used for wake up).

WMS –app: sends events for app to handle app– WMS: tells app to handle itself

Each activity is associated with a window, and each window is associated with a Viewrootimpl, viewrootimpl. This object is used to receive notifications from the WMS side to process events.

1. Decordview is added to the window by calling addView when the app resumes the window. Call viewrootimpl setView, which communicates and binds to the WMS. Setview creates an InputChannel (there is nothing going on in this object constructor and the initialization process will notify WMS when it has created an InputChannel). Then use the session (which can be understood as the WMS proxy) to pass inputChannel to the WMS 3.systemServer WMS initializes its own InputChannel object and binds the InputChannel on the app side (there is one on the APP side and one on the WMS side). It starts two threads, one for receiving events and one for distributing events (to prevent the time of receiving events and distributing events in real time).

Note: 1. The reader thread will receive the lowest level dev/input event, which is the EventHub upload, because it will be registered. Filter it to see if it’s an event handled by the App. 2. The distributing thread will read the queue message, and when the message processing in the previous queue is complete (Looper keeps repeating whether the processing is complete), it will store the message in memory (memory sharing makes the app end also have corresponding processing events), and use pipe to notify the APP end to process (real-time).

4. After the APP end WMS completes the task (create two threads for reading events and distributing events respectively, and establish their own InputChannel, which is used to inform app message processing)

The APP side reads the event (registered Native layer) through the message queue, and establishes the association with the INputChannel on the WMS side (shared memory and PIPE).

complete

Process: The message reading thread on the WMS side receives the event from NativeInput and intercepts it to see if it needs to be distributed to the APP. The distributor thread sends the event to the shared memory and calls inputChannel for pipe communication to the InputChannel object on the app side.

After receiving the InputChannel object on the APP end, the corresponding Viewrootimpl is taken out, and the VierootimPL is distributed to the DecoreView.

Reresolve event distribution

The shared memory provides events to the memory. The INputChannel on the WMS side notifies the InputChannel on the APP side using PIPE. The app side then reads events in the shared memory.

The inputChannel initialization on the WMS side is done when viewroot calls the setView method in the app side activity calls the Resume method.

The WMS side receives the Add method (Viewroot’s setView), applies for shared memory, and then saves their file descriptors in the two InputChannels, that is, initializes the app side. After pointing two InputChannels at each other, we can communicate

The InputChannel on the APP side will register with nativeInputQuene, which is the only one in the whole system. So he needs to manage the event passing of different applications by creating a separate Connection class for each Viewroot.

The WMS end is aided by InputManager (there is only one in the whole system), whose business is in the instance of NativeInputManager. What is the difference between the last conclusion that we did not use Looper and MQ? The previous summary stated that WMS does not use looper because WMS is system and Viewroot has one for every activity. WMS would be too big to do that, but WMS has another solution, I create a thread to train with its Looper (looper and MQ are private, so WMS doesn’t have to pay attention to the Looper thread), but this is not a FD. Later speak

App registration event: In fact, nativeInputquene is an input fd file descriptor like ADDFD in Looper, which borrows the epoll mechanism of handler. When native MQ receives a request from FD, it encapsulates it into a response for processing (involving Looper). The next step is that when an event is heard, the FD sends out a request, which the native MQ receives and calls back to the NativeInputQuene queue.

WMS side: The NativeInputManager establishes the entire event passing logic for WMS at creation time. The WMS side creates two threads: one inputreader reads the event and one InputDispatcher dispatches the event. Inputreader registers the input event callback and intercepts the event when it receives eventhub to see if it needs to be processed by the activity and how it needs to be passed on to the InputDispatcher thread.

Inputdispatcher uses the looper mechanism mentioned above to do two things: 1. Pre-dispatcher handling of events. Focus determination, preprocessing, etc. It is then placed in a queue associated with viewrooot (i.e., polling to see if the event is finished) 2. Train the Looper to check if nativeInputQuene has finished processing the last event before writing the event in the queue to shared memory with pipe notification.

The reader provides the event to be processed (pre-processed) and the dispatcher stores the pre-processed event in the queue. After the processing, Looper’s NativePutquene takes the event out of the queue and puts it into the shared memory, and then notifies PIPR.

The App inputChannel is registered with nativeInputQuene. The INputChannel at the WMS is registered with the Disoatcher field. Receive the event preprocessing event, and train whether the last event is finished filling the shared memory to notify InputChannel for PIPE communication with app end. The app side reads the event from shared memory, i.e. view wroot, and knows about it. Decoreview can also be found, and finally the app event distribution process.

ps

Personal notes, sorted out later. Please point out the mistakes and communicate with us