Application specific explanation (i)



What is 1:application?

Application, like Activity,service, is a system component of the Android framework. The system creates a Application object when the Android program is started. Some information used to store the system.

Usually we do not need to specify a application, then the system will voluntarily help us to create, assuming the need to create their own application, but also very easy to create a class inheritance Application and register in manifest's Application tab (just add a name attribute to the application tag to set the name of your application).

The Android system creates an object of the application class for each program execution and creates only one, so application can be said to be a class in the singleton (singleton) pattern. And the lifetime of the Application object is the longest in the entire program. , its life cycle is equal to the life cycle of the program.

Because it is a global singleton, the objects obtained in different activity,service are the same object. So through the application to do some, data transfer, data sharing, such as data caching operations.

2: Passing Data through application

If you have an activity a, jump to activity B and need to recommend some data, it's usually Intent.putextra () to let intent carry it. Or there is a bundle that adds information to the bundle so that intent recommends bundle objects for delivery. But there is a problem with that. The types of data that intent and bundles can carry are some of the main data types, and it is often necessary to implement a serializable or parcellable interface if it is cumbersome to implement complex data transfer.

This is actually an IPC data transfer method for Android. Let's say that our two activity is in the same process and why it's so troublesome, just pass the reference to the object that needs to be passed in the past.

The basic idea is this. Create a HashMap in application, with the string as index, and object as value so our HashMap can store whatever type of object. In activity A, you put the object that needs to be passed in the HashMap, and then pass the index string to activity B through intent or other passes, and activity B can take the object out of the HashMap based on the string.

Just go down another type. It implements the object's delivery.

3:application data Cache

I usually get used to building two HashMap in application one for data transfer and one for caching some data. For example, an activity needs to get some data from the site, and then we can cache this data to application. When the page is set to another activity, it will be able to use the cached data directly. But suppose you need to cache some large amounts of data. It is best to cache some (soft reference) SoftReference and cache the data on the local ROM or SD card. Assume that the cache in application does not exist. From the local cache lookup, assume that the locally cached data does not exist and is then fetched from the network.

4:pitfalls (Chinese: easy to make mistakes)

Using the application hypothesis saves some objects that should not be saved very easy to cause a memory leak. Assume that a time-consuming operation is performed in the application OnCreate, which will directly affect the startup times of the program.

No cleaning work can not rely on Onterminate finished. Since Android will try to keep your program executing, it is very likely that onterminate will not be called.

5:memoryleak

In Java, a memory leak is simply that a certain (some) object is no longer being used and should be reclaimed by the GC. But there is an object that holds a reference to this object and prevents the object from being recycled. For example, we typically create a view TextView TV = new TextView (this), where this is usually activity. So this textview holds the reference to the activity. See the picture below (copy in Google IO ppt)
Normally, when the user turns on the phone, Android calls the OnCreate () method again to generate a new activity, and the original activity should be recycled by the GC.

But suppose there is an object that has more scope than the activity (for example, a static object or we put a reference to the view in application). At this time the original activity will not be recycled by GC, and the activity itself holds very many references to objects. So the entire activity's memory is compromised.
Note: Memory leaks are often caused by core causes: keeping a long-lived reference to a context. Holds a context object. Thus GC cannot be recycled. Conditions such as the following:

1. The scope of a view is beyond the scope of the activity, such as a static view or a view cache to application where etc
Understanding: Memory: Attention to static data and data in the cache; Pay attention to release;

2. Some drawable that are associated with the view are scoped beyond the scope of the activity.

3.Runnable objects: For example, a new thread is enabled in an activity to run a task, during which the activity is reclaimed by the system. However, Runnalbe's task has not been completed and has a reference to the activity of the leak, but such a leak is generally leaked for a period of time, only the Runnalbe threads run close, the activity can be recycled.

4. The object scope of the memory class is beyond the scope of the activity: for example, a memory class is defined to store the data, and the object of the memory class is passed to other activity or service.

Because an object of an inner class holds a reference to the current class. So it holds a reference to the context. The workaround is to assume that no current reference is required to write the inner class as static or to extract the inner class into a separate class. Or, avoid the scope of the inner object scope beyond activity. Out of Memery error The memory size of each program in Android is limited, assuming that more than this number will be reported out of the error. The amount of memory that Android assigns to programs is related to the phone's hardware, and here are some of the phone's data:

g1:16m droid:24 Nexus one:32m xoom:48ms
So try to cache some of the big data in the program to a local file.

Avoid exceeding the amount of memory used.

Remember after the data is delivered. Remove the data stored in the application HashMap to avoid memory leaks

6: Life cycle:

OnCreate When you create an application

Onterminate called when the Application object is terminated, is not guaranteed to be called, when the program is terminated by the kernel to release resources for other applications, that
Will not be alerted, and the process is terminated directly without invoking the Onterminate method of the application's object

Onlowmemory This method is called when the daemon has terminated the resource and is scarce. A good application usually releases some unnecessary
The resources to cope when the daemon has been terminated. The foreground application memory is not enough when the situation.

This method is triggered when the onconfigurationchanged configuration changes
Remark: Application killed situation analysis:
To decide which process to kill when memory is low, Android divides the process into a "level of importance" based on the components and their state that are executing within those processes. The degree of importance is sorted by the following rules:

1: The front-end process can be a process that holds the activity that executes in front of the screen and interacts with the user (when the Onresume method is called), or it can hold an executing intentreceiver ( That is, he is performing his own onreceiveintent method) process. In the system, there are only a few such processes, and unless the memory is low enough for these processes to execute, the system will not actively kill those processes. At this point, the device usually has to be in a state of memory collation, so the process is killed in order not to let the user interface stop responding.

2: The visual process is a process that holds an activity that is visible to the user but does not show up in the front-end (when the OnPause method is invoked). For example, such a process usually occurs when a front end activity appears in a dialog box and keeps the previous activity visible. Such processes are considered extremely important by the system and are usually not killed unless these visible processes are killed in order to keep all the front-end processes running properly.
3: The service process is a process that holds the services, which are initiated by the StartService () method, although the users of these processes are not directly visible, but usually they do the work users are very concerned about (for example, in the background to play MP3 or in the background download upload files), Therefore, the system will not kill the service process until all the front-end processes and visual processes are executed properly.

4: A background process is a process that holds an activity that is no longer visible to the user (the OnStop () method is invoked). These processes do not directly affect the user experience. Adding these processes is complete, right over their life cycle (visit the activity to see a lot of other details), and the system will kill the background process at any time when it frees up memory for the first three processes. There are typically a lot of background processes executing, so these processes are stored in an LRU list to ensure that in low memory, a process that is seen by the user is finally killed.

5: An empty process is a process that does not hold any active application components. The only reason to keep such a process is to provide a caching mechanism that shortens the startup time of his application next time it executes. In itself, the system kills these processes to balance the resources of the entire system between these empty processes and the underlying core caches.

When a process needs to be categorized, the system will select one of the most important levels in the active component of the process as the classification basis. Review the documentation for activity, Service, and intentreceiver to see how each component contributes throughout the life cycle of the process. Each classes document specifically describes their role in the life cycle of their respective applications.

The context of 7:application

1, it describes the information of an application environment, that is, the context.
2, the class is an abstract class. Android provides a detailed implementation class for this abstract class (we'll talk about the Contextiml class later).
3, through it we can get the resources and classes of the application, also contains some application-level operations, such as: Start an activity, send broadcast, accept intent
Information and so on.

。

Use the method to explain specifically:

Myapp.java

2. Package com.android.test;
   
4. Import android.app.Application;
   
6. 
   
8. public class MYAPP extends application{
   
10. 
    
12. Private String MyLabel;
    
14. Public String Getlabel () {
    
16. return mylabel;
    
18. }
    
20. public void SetLabel (String s) {
    
22. This.mylabel = s;
    
24. }
    
26. 
    
28. @Override
    
30. public void OnCreate () {
    
32. TODO auto-generated Method Stub
    
34. Super.oncreate ();
    
36. SetLabel ("welcome!"); Initializing global variables
    
38. }
    
40. }

Copy Code

Mainactivity.java

2. Import android.app.Activity;
   
4. Import android.content.Intent;
   
6. Import Android.os.Bundle;
   
8. Import Android.util.Log;
   
10. 
    
12. public class Mainactivity extends Activity {
    
14. 
    
16. Private MyApp MyApp;
    
18. 
    
20. @Override
    
22. public void OnCreate (Bundle savedinstancestate) {
    
24. Super.oncreate (savedinstancestate);
    
26. Setcontentview (R.layout.main);
    
28. MyApp = (MyApp) getapplication (); Get your own definition of application MyApp
    
30. LOG.I ("Guoll", "Initlabel:" +myapp.getlabel ()); Take out the global variables we put in the process to see if we've set the values before
    
32. 
    
34. Myapp.setlabel ("changing!"); Change it.
    
36. LOG.I ("Guoll", "Changelabel:" +myapp.getlabel ()); Look, this value has changed.
    
38. 
    
40. Intent Intent = new Intent (); Let's see if there's another activity that takes the initialized value or the changed value.
    
42. Intent.setclass (this, otheractivity.class);
    
44. StartActivity (Intent);
    
46. }
    
48. }

Copy Code

Otheractivity.java:

2. Import android.app.Activity;
   
4. Import Android.os.Bundle;
   
6. Import Android.util.Log;
   
8. 
   
10. public class Otheractivity extends activity{
    
12. 
    
14. Private MyApp MyApp;
    
16. 
    
18. @Override
    
20. protected void OnCreate (Bundle savedinstancestate) {
    
22. 
    
24. Super.oncreate (savedinstancestate);
    
26. Setcontentview (R.layout.main);
    
28. 
    
30. MyApp = (MyApp) getapplication (); Get your own definition of application MyApp
    
32. LOG.I ("Guoll", "Ohteractivity receive the Label:" +myapp.getlabel ()); See if the value of the variable has changed
    
34. 
    
36. }
    
38. }

Copy Code

Change the configuration file applicationmanifest.xml. The application that will be executed MyApp adds in:

2. 2<?xml version= "1.0" encoding= "Utf-8"?>
   
4. <manifest xmlns:android= "Http://schemas.android.com/apk/res/android"
   
6. Package= "Com.android.test"
   
8. Android:versioncode= "1"
   
10. Android:versionname= "1.0" >
    
12. <!--here, set the default application to your own myapp-->
    
14. <application android:name= "MYAPP"
    
16. android:icon= "@drawable/icon"
    
18. Android:label= "@string/app_name"
    
20. >
    
22. <activity android:name= ". Mainactivity"
    
24. Android:label= "@string/app_name" >
    
26. <intent-filter>
    
28. <action android:name= "Android.intent.action.MAIN"/>
    
30. <category android:name= "Android.intent.category.LAUNCHER"/>
    
32. </intent-filter>
    
34. </activity>
    
36. <activity android:name= ". otheractivity" >
    
38. </activity>
    
40. </application>
    
42. 
    
44. </manifest>

Copy Code

Application specific explanation (i)