Foreword: I have encountered the memory leak problem caused by static variables in recent projects and code reviews. In addition, I understand that static variables will always exist somewhere occupying memory, so I can try not to add static, but there is no basis, just Thinking about writing an example to describe the life cycle of static in Android applications.
demo address: my github
1. demo
Write a simple demo, two activities hold a static variable, and then perform ++ operation on it to switch the two activities back and forth
test:
1) When are static variables loaded?
2) Can static variables be shared?
3) When are static variables destroyed?
Operation steps: (There are 3 activities, namely activity1, activity2, activity3, of which activity3 has no reference to static)
1) On the initial interface of activity1, click add (add one to the static variable) × 2, click to jump to activity2, and finish yourself
2) On the activity2 interface, click add (add one to the static variable) × 2, click to jump to activity3, finish yourself
3) Activity3 interface, do not do any operation on static, click to jump to activity1, finish yourself
2. Experimental results
3. Inference
test:
1) When are static variables loaded?
2) Can static variables be shared?
2) When are static variables destroyed?
infer:
1) The static variable of the class is loaded when the class is called for the first time (this is very reasonable, otherwise many static variables occupy the memory at the beginning, which is not good)
2) Static variables can be shared in different activities and operated separately, so there may be synchronization problems.
3) The value of static variable becomes initial after exiting the program, it should be cleared after the program exits. (Specially tested whether static is still cached after two activity finishes that have referenced static variables)
Extension: If the static variable holds the context of an activity, then unless the application is killed, the activity will not be recycled, resulting in memory leaks. Static variables really need to hold Context, ApplicationContext is more suitable for it, and the life cycle seems to correspond.
PS: Maybe the example is rough and can't fully prove the above conclusion, but at least I have an actual impression =-=Think in java seems to have a special introduction, when will I look at it.
4. What about static inner classes?
Test by yourself is still applicable to static member variables of static inner classes.
4.1 static variables of static inner classes
Wow, there is a singleton pattern that uses the static member variables of the static inner class to be initialized only once to ensure the implementation of the singleton.
4.2 Ordinary variables of static inner classes
If it cannot be called, it prompts that non-static variables cannot be called by static context, emmmm
