The announcement

I was just told that my open source “Jetpack MVVM Best Practices” project was compared to the price of Alibaba P7 architects of a course of more than 6000 yuan, 2 chapters and 12 hours were arranged to teach more than 2300 students.

In fact, the project was designed and maintained with almost all of my spare energy: frequent application scenarios were carefully designed to make it painless for developers to understand why each architectural component was there and the boundaries of its responsibilities, and the code was annotated with various “whys.”

So anyone interested in the Jetpack MVVM can go directly to GitHub and access the source code for the project, as well as the Relearn Android column, which is devoted to deep thinking and incremental updates from time to time.

See “What is the experience of an open source project being used as a course and sold more than 10 million yuan?”

preface

This article was originally intended to review the knowledge of Android by myself, but unexpectedly, in an internal knowledge assessment, I found that my colleagues’ grasp of these basic knowledge was uneven, or even ambiguous.

Are there too few Activity tutorials online? No, on the contrary, there is so much information out there that none of it is willing to explain the origin of an Activity, the boundaries of its responsibilities, what problems it exists to solve, and how well we can learn it.

Because of this ambiguity about the most basic and necessary concepts, no matter how many or how good the tutorials are, few people can digest or remember them. So I took the attitude of trying, and after several times of polishing, I shared the results of my reworking in a small meeting for my colleagues to enjoy. Can’t think of the original disdain to listen to a few colleagues, after listening to this explanation, even said really sweet.

So if you’re interested in this article, And have the most basic perceptual understanding of Activity and the origin, responsibility boundary and mutual relationship of View, Window, WindowManager, WindowManagerService, Surface and Surface Flinger. Then, without knowing it, a little curiosity begins to stir you deeper into the matter, and my wish has been fulfilled.

I’m a brick

I’m a brick running the original Android system. I have a screen that shows people what they want to see as long as they tell them to do it through HAL code. However, it is too primitive to do so, and it does not fit the use of the tiles.

The idea was to wrap a service in C++ in the runtime layer (ART) on top of HAL. The name of the service was Surface Flinger.

I am a Surface Flinger

I’m Surface Flinger, and my job is to render UI content.

Whatever people want to render on the screen, they can indirectly interact with the screen through me. It’s like when you have a document set up on your computer, you just need the intermediary of a printer driver to help you output the contents of the document to paper.

I don’t care what the content is, I’m just responsible for getting it out in a way that the output device can understand.

I am a Window

The owner of this brick wanted not only to render the UI, but also the window, so in the application framework layer, it encapsulated me in Java.

As the name indicates, I am a window. I am responsible for the layout of visual content, and then the layout results are communicated with the background service WindowManagerService through my boss WindowManager, through process communication. Finally, it is submitted to Surface Flinger for output and presentation.

Surface Flinger maps a Surface to each of our Windows to manage and render the content on the screen.

However, as a Window, I also have my difficulties.

I’m a View that knows dolls

Host because often listen to Window brother complain about the burden of typesetting is too heavy, so use combination mode encapsulation I. My “tolerant” version, ViewGroup, is able to have more views or Viewgroups within itself because of the combination mode, which makes us structurally like nesting dolls.

Thanks to recursion, our typesetting work, such as Measure, Layout and Draw, can be completed from bottom to top by ourselves through such recursion. Then Window brother can directly take our typesetting results, to the boss.

… So, Window has become something of a fish?

Window had been thinking of the end of such an easy life — the owner wanted more Windows than just one. This window it involves switching between Windows, communication and so on, very troublesome, if these dirty work to the developer to do, then I have to leave a lifetime name, a bad reputation?? !

I shuddered at the thought. No, for my good name’S sake, I must speak to the master.

In fact, as early as more than 20,000 years ago, when Nu Wa made human, it adopted the template method model of god level, encapsulating a series of universal functions, only exposing some DNA interfaces, for random input and evolution of the later.

In other words, the host just return me to encapsulate the template method pattern, and write a set of window management tasks and return stack mechanism in secretly plotting coups, they only need to inherit my future developers, and get a concise configuration template, thus in the template input their custom content above, to get the results they want.

So I changed my name to Activity

Window has become my abiding faith. It remains in me. For developers, I am just an Activity to be inherited. By inheriting me, developers can get simple templates.

To the system, I am still essentially a managed window, and the system can manage my switching and communication with other Windows.

For developers, I am essentially a View controller, through which developers can control the layout of the View in any way they want, and save and restore the layout of the View under special circumstances.

To sum up

It started with a brick running the original Android system.

Surface Flinger was created to make UI rendering easier.

Windows were created to manage the typography of UI content.

Window is overwhelmed and passes the buck to View.

The View grinds through the layout with the help of recursion through the composite mode.

Activities were created to meet the need for multi-window management and fool-proof view management.

So the knowledge boundaries of an Activity are nothing more than life cycles, rebuilds due to special conditions, multi-window jumps (launch modes, intents), view loading and optimization, and so on.

Does that make sense to you?

Copyright statement

This article is signed by CC – non-commercial – prohibited for distribution under 4.0 international agreements.

Copyright © 2019 – present KunMinX

The introduction, thought and conclusion of this paper belong to the original author KunMinX. When you use or quote the introduction, thought and conclusion of this paper for secondary creation, or reprint in full, you must indicate the link source, otherwise we reserve the right to blame.