Android Concurrent Programming: (i) basic knowledge--1.2 program start and end

All contents of this chapter are original, if need to be reproduced, please specify the source.

http://blog.csdn.net/manoel/article/details/38471825

Android is a multi-user, multi-tasking system.

Allows multiple apps to execute at the same time, switching between multiple programs with no noticeable delay.

Multitasking is handled by the Linux kernel, and the program runs based on the Linux process.

Linux Process

Linux assigns each user a unique user ID, which is used to differentiate between different users.

Because of the permissions, each user can only access private resources, no users (except the root user, that is, Super Administrator. We don't consider this user here. ) To access other users ' private resources. Thus, the "sandbox" is used to separate these users.

In Android, each app has a unique user ID, which means that the app in Android corresponds to a user in Linux, and there's no way to exchange resources between apps.

Android adds a Dalvik virtual machine to each process, which means that each app corresponds to a Dalvik virtual machine.

Shows the Linux process, Dalvik the relationship between the virtual machine and the app.

By default, apps and processes have a one-to-a-way relationship.

But if necessary, an app can run in several processes, or several apps run in the same process.

Life cycle

The life cycle of the app is encapsulated in its own Linux process, which, from the Java perspective, is the Android.app.Application class.

When Dalvik calls application's OnCreate () method, the Applicationg object is generated. Ideally, the app stops when Dalvik calls application's Onterminate ().

But remember, you can't rely on this to judge that a application object has been destroyed!

Because the potential Linux process may have been killed, this time Dalvik has not yet called onterminate ().

In summary, the Application object is the first object to be instantiated in a process and the last to be destroyed.

App Launch

When any component of an app is activated, the app is turned on.

Any component is a portal to the app. Remember, the components include: Activity,broadcastreceiver,service and ContentProvider.

When the first component is activated, the Linux process for the app is activated, unless the Linux process is already running.

The process of opening the app is summarized as follows:

2. Turn on the Linux process.
4. Create a Dalvik virtual machine.
6. Creates an application instance.
8. Create an app's portal component.

Building a new Linux process and Dalvik virtual machines is not an instantaneous operation. This process degrades performance and has a slight impact on the user experience.

Therefore, the Linux system will shorten the startup time of the app by opening a special zygote process at startup (System boot).

What the hell is going on here? Zygote includes all preloaded core libraries, and the new app process is hatched from this zygote process, but the app process does not replicate those preloaded core libraries, but rather the shared zygote core library.

That's it, shortening the start-up time of your app.

app End

When the app starts, the Linux process is created, and the Linux process ends when the system needs to reclaim resources. To ensure that users do not repeat the above process every time they enter the app. If it weren't for the lack of resources, Dalvik would not destroy all the resources of the app. So, even though all the components of an app are destroyed, the app doesn't end automatically.

When the system is in a resource shortage, Dalvik is responsible for deciding which process to kill. So what is the basis for deciding which process to make?

Based on the visibility of the app and its component operation, the system processes the process hierarchically. In other words, a low-level process is killed before a high-level process.

The following are the various levels of the process:

Foreground

The

app has visible components in the foreground, or a service is bound to a visible activity in other processes, or broadcastreceiver is running.

Visible

the app has a partially visible component.

Service

The

service is in a running state, but it is not bound to a visible component.

Background

activity that is not visible.

Empty

a process without active components. Empty processes exist to improve the number of app launches, but they are also the first to be killed.

ReferencesHttp://developer.android.com/guide/components/processes-and-threads.html#Lifecycle