Seven points required for the Android Application Object

1: What is Application? Like Activity and Service, Application is a system component of the android framework. When the android program starts, the system creates an application object to store some information about the system. Generally, we do not need to specify an Application. In this case, the system automatically creates an Application for us. If you need to create your own Application, it is also easy to create a class that inherits the Application and registers it in the application tag of manifest (you only need to add a name attribute to the Application tag to set the name of your Application ). The android system creates only one Application Class Object for each program running. Therefore, the Application is a class in singleton mode. the life cycle of the application object is the longest in the whole program, and its life cycle is equal to the life cycle of the program. Because it is a global Singleton, the objects obtained in different activities and services are all the same object. Therefore, you can use the Application to perform operations such as data transmission, data sharing, and data caching. 2: transfer data through Application. Assume that there is Activity A, jump to Activity B, and recommend some data. The common practice is Intent. putExtra () allows Intent to carry, or a Bundle adds information to the Bundle so that Intent recommends Bundle objects for transmission. However, there is a problem in this process: Intent and Bundle can carry some basic data types. If you want to implement complex data transfer, it will be more troublesome, serializable or Parcellable interfaces are usually required. This is actually an IPC data transmission method for Android. If our two activities are in the same process, why is it so troublesome? You just need to pass the reference of the object to be passed in the past. The basic idea is this. Create a HashMap in the Application, with the string as the index, and the Object as the value so that our HashMap can store any type of objects. Put the objects to be passed into this HashMap in Activity A, and then pass the index string to Activity B through Intent or other methods, activity B can retrieve this object in HashMap based on this string. You only need to go down to the next type to transfer the object. 3: Application data cache I usually get used to creating two hashmaps in the application for data transmission and one for slow data storage. For example, an Activity needs to obtain some data from the website. After obtaining the data, we can cache the data to the Application. When the page is set to another Activity, you can directly use the cached data. However, if you need to cache a large amount of data, it is best to cache some SoftReference and cache the data to the local rom or SD card. If the cache in the application does not exist, search from the local cache. If the locally cached data does not exist, it will be retrieved from the network. 4: PitFalls (Chinese: easy to make mistakes) uses the Application to easily cause memory leakage if some objects that should not be saved are saved. If you perform time-consuming operations in oncreate of the Application, the startup time of the program will be directly affected. You cannot use onTerminate for cleanup. Because android will try to keep your program running, it is very likely that onTerminate will not be called. 5: MemoryLeak Memory leakage in Java is only. A (some) object is no longer in use and should be recycled by gc, however, an object holds a reference to this object to prevent this object from being recycled. For example, we usually create a View TextView TV = new TextView (this) like this; here this is usually Activity. Therefore, this TextView holds the reference of this Activity. The following figure shows the figure (copied in Google IO 2011 ppt). Generally, when a user turns the mobile phone, android will call the OnCreate () method again to generate a new Activity, the original Activity should be recycled by GC. However, if an object such as a View has a larger scope than this Activity (for example, there is a static object or we include the reference of this View in the Application ), at this time, the original Activity cannot be recycled by GC, and the Activity itself holds a lot of object references, so the memory of the entire Activity is leaked. Note: The core cause of frequent Memory leakage is keeping a long-lived reference to a Context. The gc cannot recycle because it holds a context object. Situation: 1. the scope of a View exceeds the scope of the Activity. For example, a static View or a View is cached in the application. etc: Memory: Pay attention to static data and cache data; pay attention to release; 2. the scope of some Drawable associated with the View exceeds the scope of the Activity. 3. runnable object: for example, a new thread is enabled in an Activity to execute a task, during which the Activity is recycled by the system, however, the Runnalbe task has not been completed and the reference of the Activity is leaked. However, this leakage generally occurs for a period of time, and only the Runnalbe thread has completed the execution, this Activity can be recycled again. 4. The scope of objects in the memory class is beyond the scope of the Activity. For example, a memory class is defined to store data, and the memory class object is passed to other activities or services. Because the object of the internal class holds the reference of the current class, it also holds the reference of Context. The solution is to write the internal class as static without the current reference, extract the internal class into a separate class, or avoid the internal object scope exceeding the Activity scope. Out Of Memery Error in android, the Memory size allocated to each program is limited. If this number is exceeded, an Out Of Memory Error is reported. The memory size allocated by android to the program is related to the mobile phone hardware. The following figure shows the data of some mobile phones: G1: 16 M Droid: 24 Nexus One: 32 M Xoom: so try to cache some big data in the program to a local file within 48 Ms. To avoid excessive memory usage. Remember to remove the data stored in the HashMap of the application after the data is transferred to avoid Memory leakage. 6: lifecycle: onCreate creates onTerminate when creating an application. It is called when the application object is terminated. It is not guaranteed to be called. When the program is terminated by the kernel, it can release resources for other applications, this method will not be called, and will be called without calling the onTerminate method of the application's object and directly terminating the onLowMemory process when the background program has terminated the resource is still scarce. Good applications usually release unnecessary resources in this method to cope with situations where the background program is terminated and the foreground application memory is insufficient. This method is triggered when the onConfigurationChanged configuration changes. Remarks: Analysis of application killing: To determine which process to kill when the memory is low, android divides processes into "importance levels" based on components running in these processes and their statuses ". the importance of the onResume method is sorted by the following rules: 1. A front-end process can be a process that holds the Activity running 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. 2: The visible process is visible to the user but not displayed at the frontend (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. 3: a Service process is a process that holds a Service. The Service is started by the startService () method, although these process users cannot directly see it, however, users are usually very concerned about their work (for example, playing mp3 files in the background or downloading and uploading files in the background, the system will not kill service processes unless you want to keep all front-end processes and visual processes running normally. 4: background processes hold a process that is no longer visible to users when the onStop () method is called. these processes do not directly affect user experience. these processes are complete and the lifecycle is completed correctly (access Activity to view more details ). When three processes release the memory, they are killed at any time. 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. 5: A blank process is 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 at www.2cto.com, the system will drop an important level among all the components in the active state of the 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. 7: application context 1. It describes an application Information about the program environment, that is, context. 2. This class is an abstract class. Android provides the concrete implementation class of this abstract class (we will talk about the ContextIml class later ). 3. We can use it to obtain application resources and classes, as well as some application-level operations, such as starting an Activity, sending broadcasts, and accepting Intent information ..