The previous article mentioned that you can use a global static context instead of a context singleton. Would it be a problem to define a global static context in a common base class of App (like our RunningContext)?

	public static Context sAppContext = null;
Copy the code

The sAppContext is retrieved with getApplicationContext if null, typically singleton (but not initialized in the constructor). The IDE will always warn you “Do not place Android Context classes in static fields, this is a memory leak.”

One could argue that since the ApplicationContext will exist as long as the app process is running, it won’t cause a memory leak. Is that right? That sounds right to me, as long as you don’t pass the global static context to the singleton constructor like the example in EP38 and can’t think of a scenario that would leak memory.

But I’ve always felt that Android Studio’s warnings against using static context are justified. Someone on StackOverflow explained that there is almost no need to use static variables in order to avoid memory leaks. Constants can be static because there are not many of them and they don’t take up much space.

Using a global static Context is one solution from the last article, but there are some problems with this. The authors of 6 THINGS YOU SHOULD KNOW make the following points.

###1. The construction parameters will not work

Google’s Guide to Writing code testable:

Fetching global variables statically does not tell the reader of the code about their constructor and method dependencies. Global variables and singletons mask their true dependencies through the API. To truly understand dependencies, a developer must read the code line by line.

For example, if you write a method called displayString (), if you pass a Context and a String to its constructor, we might assume that you are using some context-managed method to display strings, such as Toast. This is also an indication of the construction parameters.

I can’t help but wonder why static methods/objects/variables/constants don’t need to be called by objects, because staticstatic methods/objects/variables/constants are always in memory once they are initialized, so they don’t need to be reinitialized every time.

###2. Violating the encapsulation principle sounds a bit far-fetched. Encapsulation ensures that an object’s behavior can only be affected by its API. But you don’t have to wrap it and it doesn’t crash.

Unit testing is “checking and verifying the smallest testable units in software.” A function in C, a class in Java, an interface for a graphical application, a button; This minimum unit is artificial. Global static Context breaks unit tests.

What do Android unit tests measure? View/UI are not easy to test, you can test databases, file operations, etc.

conclusion

Do not use a global static ApplicationContext and rely on external injection. Despite the trouble.

References: [1]http://www.philosophicalhacker.com/post/what-should-we-unit-test/ [2]http://blog.csdn.net/hwz2311245/article/details/47731477 [3]http://www.jianshu.com/p/03118c11c199