As the Android Framework layer, Framework provides many apis for App to call, but many mechanisms are wrapped by Framework for App to use, if you do not know the principle of these mechanisms, it is difficult to optimize on this basis.

Android Framework knowledge is widely used in various areas:

  • Frame drop monitoring
  • Function instrumentation
  • Slow function detection
  • ANR monitoring
  • Start the monitoring
  • …

All of this requires a deep understanding of the Framework. Only if you are familiar with the Framework layer can you know how to do monitoring, what mechanism to use to monitor, where the function peg is inserted, which class which method which attribute is called to reflect the reflection……

The importance of knowing the Android Framework is self-evident.

What I want to share with you is an introduction to WMS.

The original address: blog.csdn.net/yaoming168/…

Brief introduction:

In Android, WindowManagerService is responsible for managing all Windows in the system. Management generally involves creating, deleting, and changing the focus of Windows.

A window is usually an independent interface, such as a dialog window, an Activity interactive window, a menu, etc.

Window is a class whose implementation class is PhoneWindow, and the Activity class implements the window. CallBack interface, thus becoming a Window with a general operation mode.

A View is also a class, usually a View, that refers to a single interactive element, such as a button, a text box, etc.

Function:

  • Assign Surface to all Windows: The process of the client adding a window to WMS is actually the process of WMS assigning a Surface to it. Each Surface is arranged on the screen in an orderly manner under the management of WMS. A Window is essentially a Surface and is used to manage the display order, size, position, and Window animation of the Surface.

  • Input system related: WMS is the best person to distribute system keys and touch messages. When receiving a touch event, it needs to find the most appropriate window to process the message, and WMS is the window manager, and all the window states and information in the system are in its control, so it is easy to complete this work.

WMS main class introduction:

W class

The WindowManagerService can use the mClient member of the WindowState object it creates internally to ask the Activity component running on the side of the application process to match the state of the management window, for example:

  1. The WindowManagerService calls this when the size of an Activity component’s window changes

The member function resized of the IWindow interface notifies the Activity component that its size has changed.

  1. The WindowManagerService calls this Iwindow when an Activity component’s window is visible

The interface’s member function dispatchAppVisibility notifies the Activity component that its visibility has changed.

  1. The WindowManagerService service calls this when an Activity component’s window gains or loses focus

The member function windowFoucusChanged of the IWindow interface notifies the Activity component that its focus has changed.

Window class/frameworks/base/core \ Java \ android \ views \ Windows Java

To understand:

  • It Outlines the basic properties and functions of Android Windows.

  • Although each App can be different, as a system with a large number of user interactions, there must be a unified interaction mode between Windows, so as to reduce the learning cost of users. These commonalities, such as the title, the display of the action bar, and the handling of common keys, are abstracted from the Window class.

  • It defines a set of callbacks that the Activity implements to be called to handle events.

Note: To be distinguished from Windows in WMS, Windows in WMS are more like app-side views.

Specific functions:

  • Define the Callback interface, which contains a series of dispatchXxxx methods and a series of onXxxx methods for handling UI events.

  • Defines interfaces such as setContentView, findViewById(), and so on. Implemented by PhoneWindow.

WindowManager class

  • WindowManager inherits the ViewManager interface, which mainly has the following implementation sub-interface:

AddView (), updateViewLayout(), removeView(); WindowManager can add and remove views from the screen. It is object oriented side screen, on the other side is the View, through the WindowManager addView method to create the View, so the View produced according to the WindowManager. LayoutParams property is different, the effect is also different, such as creating a top-level window system, To achieve the floating window effect.

  • Each time we create an Activity, we also add the current Activity’s View to the window, which is a DecorView, again by calling the addView () method. In activityRecord.java, handleResumeActivity is implemented.

ViewRootImpl class

The ViewRootImpl class acts as an intermediary in the Android UI structure, connecting PhoneWindow to WindowManagerService, which is the bridge between the window management system and the window rendering system. It has two main functions:

1. Send a received user event to the DecorView, such as a button button, touch screen, etc.

2. Interact with WindowManagerService to complete the drawing of the Activity’s GUI.

3. There are two important variables mWindowSessoin and mWindow.

  • MWindowSessoin is a session layer between ViewrotimPL and WindowManagerService. Its entity is defined in WMS as a bridge for viewrotimPL to send requests to WMS.

  • MWindow is the interface that ViewRootImpl provides to WMS so that WMS can reverse notify ViewRootImpl. Since ViewRootImpl is on the application side and WMS is on the System_server side, they are in different processes, we need to add this W interface so that WMS can pass information to ViewRootImpl.

WindowState:

The most basic element in WMS, describing a window in WMS. It can be either a View added by App or a system window created by the system. MAttrs for WindowManager. LayoutParams type, the layout parameters. MClient is of type IWindow, that is, viewrotimpl ::W on the App side. For lookups, mWindowMap in WMS stores the mapping from IWindow to WindowState, and mTokenMap stores the mapping from IApplicationToken to WindowToken.

The Session:

Provide IWindowSession interface for App to communicate with WMS. Each App has a Session object in WMS. App sends window management application to WMS through this Session. The dumpsys window sessions command is used to view sessions in the system.

WindowToken:

Describes a set of Windows in WM whose member variable Windows corresponds to the WindowState. Its main inheritance class is AppWindowToken, which is a WindowToken structure for App. The mAppToken in WindowState refers to the AppWindowToken to which it belongs. In the case of a system window, the mAppToken is empty and refers to the WindowToken object.

AppWindowToken:

Each App Activity corresponds to an AppWindowToken. The appToken is of IApplicationToken type and connects to the ActivityRecord::Token object in the corresponding AMS. With it, you can follow the AppWindowToken to find the corresponding ActivityRecord in AMS. Where allAppWindows is an unordered list of all the Windows in the Activity. Use Dumpsys window display to view z-ordered AppWindowToken list:

AMS main class diagram

WMS main class diagram

AMS, WMS data structure relationship

TaskStack

AppWindowToken holds an ordered list of its WindowStates, and is itself managed as a list in the mTasks member of the TaskStack.

An important variable in TaskStack is mBounds. AppWindowToken in the same Task corresponds to the same size of the Activity, so mBounds represents the size of the Activity.

DisplayContent:

Represents the content on a display device, which can be an external or virtual display. Where mWindows is a Z-ordered (bottom-first) WindowState list. MStackBoxes contain several StackBoxes, one for HomeStack and the other for App StackBox. All stackboxes are organized into a binary tree, where stackboxes are nodes with three important member variables, mFirst and mSecond, which are left and right children (also stackboxes). StackBox member mStack is what we really care about -TaskStack. As you can see, in order to store the TaskStack as a tree, you need a container, the StackBox.

ActivityRecord:

Describes a single Activity, the basic unit in the Activity stack.

TaskRecord:

MActivities in TaskRecord are a list of ActivityRecords, sorted in historical order.

ActivityStack:

The Activity stack, in which activityRecords are managed indirectly through the TaskRecord layer.

Framework layer system learning

What I want to share with you here is a learning manual of Android Framework layer inside Ali shared with me by a friend of Ali. This is where they have a P7 big man every day to stay up until the early hours of the morning, liver half a month to finish.

The Android Framework kernel has been dissected into a 452-page PDF! This material is now available for download!

PS: This material is only for open source learning, you do not use it for other things oh ~

Click on the【 the 】Enter my official account and add remarks [FWGet the full version of this for free

The Framework manual compiles the details

Chapter 1 in-depth analysis of Binder

  • Section 1 Binder series – Introduction

  • Section two Preliminary study of Binder Driver

Binder Driver Overview Binder core approach…

  • The third section of Binder Driver again

Binder Communication Overview Binder Communication Protocol Scenarios Binder Memory Mechanism……

  • Section 4 Binder starts the ServiceManager

Start process core work……

  • Section 5 Obtaining the ServiceManager

Get ProcessState object get BpBinder object get BpServiceManager…

  • Section 6 addService

ProcessState Service Register Binder Driver ServiceManager……

  • Section 7 getService

  • Section 8 framework layer analysis
  • Section 9 How to Use Binder

  • Section 10 How to Use AIDL
  • Section 11 Summary of Binder

  • Binder interview question 12

Chapter 2 delves into the Handler message mechanism

  • The first section is macro theoretical analysis and Message source code analysis

  • The second section of MessageQueue source code analysis
  • The third section of Looper source code analysis
  • The fourth section handler source code analysis
  • The fifth section summarizes the implementation principle of Handler mechanism
  • Section 6 Handler interview questions

Chapter 3 Dalvik VM process system

  • Section 1 Android system startup – overview

  • Section 2 Init
  • Section 3: Zygote
  • Section four SystemServer part one
  • Section five SystemServer part two

Chapter 4 analyzes WMS in depth

Chapter 5 PackageMS Startup

The Android Framework internal learning manual, compiled by the big guys of Alibaba P7, has been compiled as a PDF document.

Click on the【 the 】Enter my official account and add remarks [FWGet the full version of this for free

PS: This material is only for open source learning, you do not use it for other things oh ~

The last

You can pay attention to my B station, regularly share mobile development technology learning videos and other learning resources!

Video series:

  • Tencent/Alibaba/Baidu/Byte/JINGdong…… All included

  • FrameWork layer source code analysis

  • Android Project

  • Android advanced UI combat

  • Performance optimization