Android Application class details:
Detailed explanation of Application class in Android:
In our daily development, we may sometimes need some global data to allow all the activities and Views in the application to be accessible. When you encounter this situation, you may first think of defining a class yourself and then creating many static members.
However, this method does not conform to Android's framework architecture, but andorid has provided us with a solution to this situation: in Android, there is a class called Application, which we can use getApplication() in Activity to obtain. It is a class representing our application. Using it can obtain the theme of the current application, the content in the resource file, etc. A more flexible feature of this class is that it can be inherited by us to add our own global attributes. Make the entire App's Activity and View accessible.
1. Concept:
The Android system will create an Application class object for each program runtime and create only one, so Application can be said to be a class in the singleton pattern. And the life cycle of the application object is the longest in the entire 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 Service are the same object. Therefore, some operations such as data transmission, data sharing, data caching, etc. are carried out through Application.
2. Function:
(1).Application is a base class. The function of this base class is to obtain the state of the entire App. We need to define a class ourselves to inherit this base class.
(2). Define some variables and methods that need to be used for both global and contexts.
3. Advantages:
(1). Inheritance method:
Life cycle is destroyed as the application is destroyed.
(2). Static class or static method:
After the program exits, this class or variable cannot be recycled by GC immediately.
When you enter again, you will find that the information saved by the static class is previous. It may cause the program to not be the initialization state you want.
(3). When the App process is created, this class will be instantiated, and the onCreate() method will be executed, assigning initial values to all global variables. In this way, all activities share the variables in this class.
The difference between (), getApplication(), getApplicationContext(), getActivity():
(1).getContext(): Get the context of the current object.
(2).getApplication(): Obtain the Application object
(3).getApplicationContext(): Get the context of the application. There is and only one identical object. Life cycle is destroyed as the application is destroyed. Just like society, everything happens in this society, and only one society. Each Activity has its own context, and the entire application has only one context
(4)getActivity(): Get the Activity object attached to the Fragment. The reasons why getActivity() in Fragment are not recommended are as follows: This method will return the Activity attached to the current Fragment. When the Fragment life cycle ends and is destroyed, getActivity() returns null, so when using it, you should pay attention to judging null or catching null pointer exceptions. Therefore, as long as you judge that getActivity() is empty, the following code can no longer be executed, which will not affect the use of the business at all.
5. There are several cases where the application creates a Context instance:
(1).When creating an Application object, there is one Application object in the entire App.
(2).When creating a Service object
(3).When creating an Activity object.
Activity Service Application is a subclass of Context. Context is an abstract class, and the concrete implementation is in the ContextImpl class. Therefore, the formula for the number of Contexts that the application app has is:
Total number of Context instances = number of Service + number of Activity + 1 (Context instance corresponding to Application)
Memory leak problem in the application:
(1). Hold an overly long reference to the Context. A reference to a Context exceeds its own life cycle. The restricted heap memory used by Android applications is 16M
(2). Static variables have more object references, and memory will still not be destroyed.
To summarize: The issues that should be paid attention to to avoid Context leaks:
1. Use Application Context type
2. Be careful not to reference the Context beyond its own life cycle
3. Use static keywords with caution
If there is a thread in it, it must be stopped in onDestory() in time.
Thank you for reading, I hope it can help you, thank you for your support for this site!