Getting started with Android (hello, Android world)

Use the built eclipse + ADT environment.

In eclipse, choose File> New> project. If you have successfully installed the android plug-in, you will see an entry named "android" in the pop-up new project dialog box that contains a project named "android project ".

Select "android project" and click Next to go to the next step. In the displayed Project Properties window, enter the following fields:

Project name: the name of the directory where the project file is saved on the computer.

Package name: this is the same package name as Java-your source code will belong to this package name. At the same time, Stub activity will also generate

Activity name: the android plug-in will create a stub Class Based on this name. It is a subclass inherited from the activity class. Activity is similar to a simple class that can run and work. It can create user interfaces according to your needs. Of course this is not necessary.

SDK: select an SDK from the list. Now you can select an SDK from sdk1.1 sdk1.5.

Automatically generate some code:

After the android plug-in is executed, a helloandroid class will be created. Its content is as follows:

Public class helloandroid extends activity {/** called when the activity is first created. * // ** run after the activity is created */

   @Override   public void onCreate(Bundle icicle)   {       super.onCreate(icicle);       setContentView(R.layout.main);   }

}

You can change the code:

Public class helloandroid extends activity {/** called when the activity is first created. * // ** run after the activity is created */

   @Override   public void onCreate(Bundle icicle) {       super.onCreate(icicle);       TextView tv = new TextView(this);       tv.setText("Hello, Android");       setContentView(tv);   }

}

Now you can compile and run it.

The Eclipse plug-in provided by Android makes running our program very simple. Select the run> open run dialog menu. You will see a dialog box in which you can configure a luncher like configuring the j2_runtime environment.

Success! Click the run button to run the androi simulator. When the simulator is started, you will see your program. Here we are done!

 

According to the normal idea, I will definitely think, where is the program entry point? Why is it started from this activity?

Now we can express it in the easiest way we can understand:

This is because when the image file of this program is started, an event object intent will be sent with the main action attribute, and the automatically generated code and file contains an androidmanifest. xml

An event filter will be configured for the activity helloworld, indicating that the main action and launcher category entry points are implemented. Note the following lines:
<Intent-filter>
<Action Android: Name = "android. Intent. Action. Main"/>
<Category Android: Name = "android. Intent. Category. launcher"/>
</Intent-filter>

 

Application Lifecycle

In most cases, each android application runs in its own Linux Process. when a code segment of an application needs to be run, the process will be created until the application or system no longer needs to release memory for other applications.

A very important and rare feature is that the survival time of an application process is not directly controlled by this application. it is determined by the system. The system determines the status of each known running application, including the importance of the application to the user and all available memory of the system.

For developers, understanding the impact of each application component (especially activity, service, and intentcycler) on the survival time of application processes is very important. if it is not properly used, the application process may be killed by the system when handling important tasks.

In understanding the life cycle of an application process, a typical error is that after an intentreceiver receives the intent, it starts a thread in its onreceiveintent () method, then return this method. once this method is returned, the system will think that the intentreceiver is not active and that its host process is no longer needed (unless other active application components are included ). so that when the system needs to recycle the memory, it will release the kill process at any time and stop the sub-thread. the solution to this problem is to enable a service in intentreceiver, so that the system will know that there are still active tasks to be completed in this process.

To determine which process to kill when the memory is low, Android divides the process into a "importance level" based on the components running in these processes and their statuses ". the importance is sorted by the following rules:

1. Frontend ProcessIt can be a process that holds the activity that runs at the front of the screen and interacts with the user (when the onresume method is called ), it can also be a process that holds a running intentreceiver (that is, he is executing his onreceiveintent method. in the system, there are only a few such processes, and the system will not take the initiative to kill these processes unless the memory is low enough. at this time, the device usually has reached the state that requires memory sorting, so killing these processes is to prevent the user interface from stopping the response.

1. Visualized ProcessIs a process that is visible to the user but not displayed at the frontend (when the onpause method is called. for example, this process usually appears in a front-end activity in a dialog box and remains visible to the previous activity. this process is considered to be extremely important by the system and will not be killed unless the visible processes have to be killed to keep all front-end processes running normally.

1. Service ProcessIs a process that holds a service. The service is started by the startservice () method. Although these process users cannot directly see it, the users who do their work are usually very concerned (for example, playing MP3 files in the background or downloading and uploading files in the background). Therefore, the system will not kill service processes unless all front-end processes and visual processes are properly running.

1. Background ProcessIt is a process that holds an activity (onstop () method called) that is no longer visible to users. these processes do not directly affect user experience. the added processes are complete, and the lifecycle is completed correctly (access activity to view more details). The system will kill these background processes at any time when releasing the memory for the first three processes. there are usually many background processes running, so these processes are stored in an LRU list to ensure that the last process seen by the user will be killed at low memory.

1. Empty ProcessIs a process without any active application components. the only reason to keep this process is to provide a caching mechanism to shorten the startup time of its application at the next run. in itself, the purpose of the system to kill these processes is to balance the resources of the entire system between these empty processes and the underlying core cache.

When you need to classify a process, the system selects the highest level of importance from all the components in the active process as the basis for classification. view the activity, service, and intentcycler documents to understand the contribution of each component throughout the process lifecycle. each classes document describes in detail their role in the lifecycle of their respective applications.

(The application lifecycle section is taken from "http://www.androidcn.net/wiki/index.php/Intro/lifecycle ")