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

Source: Internet
Author: User

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:

  1. Turn on the Linux process.
  2. Create a Dalvik virtual machine.
  3. Creates an application instance.
  4. 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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.