Growth notes of Android cainiao (4)-do you really understand it?

In the previous article, we checked the layout structure in the apk source file of QQ and completed the interface of our first application following QQ's model. For details, see the column "growth notes for Android cainiao. In this article, let's take a look at how this interface is presented and how it works. Let's take a step-by-step look at the mysteries that remain in our hearts.

Some may have such questions: why can such a nice interface be displayed with a few codes?

In fact, this interface is so rich and colorful. Half of the credit lies in the code we have written, and half of the credit lies in our dear google engineer and the great linux father Linus Torvalds. Next we will go to the official website of Android Developers provided by google for us. Http://developer.android.com/index.html

Shows the main menu:

Design: the Android interface Design standards and documents.

Develop (Development ):Android Developers related APIs, tools, and examples.

Distribute (category): Category directory

Next, let's take a look at the sub-menu under the Develop menu:

Training: getting started

API Guide: API documentation

Reference: API comparison for All Versions

Tools: Tools and downloads

Google Services: a public service of Google, such as Google Map

Samples (example): Some Android development examples and source code

The Android architecture is shown on this website, as shown in:

We can see that the architecture of the entire Android system is divided into four layers:

(1) Linux Kernel (Linux Kernel)

Android is based on the Linux2.6 kernel. Its core system services, such as security, memory management, process management, network protocols, and driver models, depend on the Linux kernel. Thanks to Linus Torvalds for creating such a great system

(2) Libraries (system Runtime Library layer)

As you can see, the system Runtime Library layer can be divided into two parts: the system library and the Android runtime.

[1] System Library:

The system library is the skeleton of the application framework. Supporting the running of the entire application is an important link connecting the application framework and the Linux kernel layer. It mainly includes the following

Surface Manager: When executing multiple applications, it is responsible for managing the interaction between display and access operations, and also for 2D and 3D drawing for display and synthesis.

Media Framework: multi-Media library.

SQLite: A small relational database engine.

OpenGL | ES: 3D drawing function library.

FreeType: depicts and displays dot matrix and vector words.

WebKit: the Web browser engine.

SGL: The underlying 2D graphic rendering engine.

SSL: communication engine.

Libc: Standard c system function library.

[2] Android Runtime

Android runtime and JRE are a bit similar. JRE includes JVM and other function libraries. The Android runtime here includes the Dalvik Virtual Machine and core library set.

Every Android application runs in a single Dalvik virtual machine. That is to say, the Android Application corresponds to a Dalvik process. Isn't it a virtual machine? I learned this in Java. Note: This is different from the virtual machine in Java. The differences are as follows:

JVM runs java bytecode files, while Dalvik runs proprietary dex files.

JVM is implemented based on registers and Dalvik is implemented based on stacks, so the speed of Dalvik is very fast.

(3) Application Framework Layer

The application framework layer is the basis for Android development. Many core applications use this layer to implement their core functions. This layer simplifies Component reuse, developers can directly use the provided components for Rapid Application Development, or achieve personalized expansion through inheritance. The following describes common application frameworks.

Activity Manager: manages the lifecycle of each application and the usual navigation rollback function.

Window Manager: manages all Window programs.

Content Provider: enables different applications to access or share data.

View System: Build basic components of an application.

Notification Manager: enables applications to display custom prompts in the status bar.

Package Manager: Program Management in the Android system.

Telephony Manager: manages all mobile device functions.

Resource Manager: provides various non-code resources used by applications, such as localized strings, images, layout files, and color files.

Location Manager: Provides Location services.

XMPP Service: Provides Google Talk services.

(4) Application Layer:

The Android platform is not only an operating system, but also contains many applications, such as SMS client, dialing, image browser, and Web browser. These applications are all written in Java and can be replaced by other applications developed by developers, this is different from other mobile phone operating systems that are solidified in the system software, more flexible and personalized.

The answer to this question is obvious. In fact, the android system has done a lot of work for us at the underlying layer. Next let's take a look at the code we wrote earlier:

public class MainActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);}}

MainActivity is the entry of our program. It inherits from the Activity and overwrites the onCreate (Bundle saveInstanceState) method of the Activity. Let's take a look at the setContentView method and onCreate method in the Activity.

Open the source code of the Android system (a blog about how to download the Android source code will be written later)

    public void setContentView(int layoutResID) {        getWindow().setContentView(layoutResID);    }

You can see that the setContentView method of the Activity calls the getWindow () method to return the setContentView method of the object. Next let's look at the object returned by the getWindow () method.

    public Window getWindow() {        return mWindow;    }

    private Window mWindow;

In fact, we call the setContentView () method of the Window object at the underlying layer. Next let's take a look at another method onCreate () of the Activity ()

    protected void onCreate(Bundle savedInstanceState) {        mVisibleFromClient = !mWindow.getWindowStyle().getBoolean(                com.android.internal.R.styleable.Window_windowNoDisplay, false);        mCalled = true;    }

We can see that the getWindowStyle () method of the Window object is called.

So what is this Window?

In fact, the Window object is the object that describes the specific form of our Android mobile phone. It can be seen that Activity is not just a highly abstract UI component, but its specific UI implementation is implemented by a series of objects.

We can go to the official API documentation to view: http://developer.android.com/reference/android/view/Window.html#setContentView (android. View. view)

Abstract base class for a top-level window look and behavior policy. an instance of this class shocould be used as the top-level view added to the window manager. it provides standard UI policies such as a background, title area, default key processing, etc.

The only existing implementation of this abstract class is android. policy. phoneWindow, which you shoshould instantiate when needing a Window. eventually that class will be refactored and a factory method added for creating Window instances without knowing about a particle implementation.

This is an introduction to this class on the official website. The general idea is as follows:

This class is the abstract class of the top-level appearance and Behavior Policy. An instance of the implementation class of this class should be added to the top layer of the window manager. This class provides standard UI component interfaces. The only implementation class of this interface is the PhoneWindow class, let's take a look at the source code of the PhoneWindow class.

    @Override    public void setContentView(int layoutResID) {        if (mContentParent == null) {            installDecor();        } else {            mContentParent.removeAllViews();        }        mLayoutInflater.inflate(layoutResID, mContentParent);        final Callback cb = getCallback();        if (cb != null) {            cb.onContentChanged();        }    }

    private ViewGroup mContentParent;

    private LayoutInflater mLayoutInflater;

You can see that the underlying layer is a ViewGroup object, and the resource ID passed to the setContentView () method is loaded into a View object by the resource loader LayoutInflater and added to the ViewGroup component.

Let's take a look at the getWindowStyle method.

From the official API, we can see that the getWindowStyle () method actually returns a topic.

Now, let's write down the PhoneWindow class and the above analysis. We will introduce it in detail later.