上一篇提到可以用一个全局静态context来替代context单例。那在App的一个公共基础类里面（比如我们的RunningContext）定义一个全局静态context会有问题吗？
public static Context sAppContext = null;
这个sAppContext如果为null就用getApplicationContext获取，典型的单例（但不是在构造函数里初始化）。但只要你用static修饰Context，IDE还是会一直警告你"Do not place android context classes in static fields, this is a memory leak."
有人会说既然ApplicationContext只要app的进程还在就会一直存在，就不会造成内存泄露。这话对吗？我感觉挺对的，只要你不像EP38里的例子一样，把这个全局静态context传递给单例的构造函数，也想不出什么会泄露内存的场景。
但是我总觉得Android Studio警告不要把context用static修饰是有道理的。
stackoverflow上有人解释说，为了避免内存泄露，几乎没有任何必要使用静态变量。常量可以用静态的，因为它们的数量和占据的空间都不多。
使用全局静态Context是上一篇文章得到的一个方案，但是这样还是会有一些问题的。6 THINGS YOU SHOULD KNOW的作者提出了以下几点。
1. 会让构造参数的作用得不到发挥
Google’s Guide to Writing testable code说:
静态的获取全局变量并没有将它们（全局变量）构造函数和方法的依赖关系告诉给阅读代码的人。全局变量和单例通过API掩盖了它们真实的依赖关系。如果想要真正理解依赖关系，开发人员必须逐行阅读代码。
比如你写了一个方法叫作displayString ()，如果你给它的构造方法传入一个Context 和一个 String，那我们可能会推测你用了Context管理的某个方法来展示字符串，比如Toast。这也是构造参数的一个指示作用。
说到这儿我不禁猜到为什么static方法/对象/变量/常量不需要用对象来调用了，因为staticstatic方法/对象/变量/常量一旦初始化就一直存在于内存中，不会被GC，自然不需要每次都重新初始化一遍了。
2. 违反了封装原则
这个说法听起来有点牵强。
封装保障了一个对象的行为只能被它的API所影响。但其实不用封装也不会造成程序崩溃。
3. 不容易进行单元测试
单元测试就是「对软件中的最小可测试单元进行检查和验证」。比如C语言中的一个函数，Java中的一个类，图形化程序的一个界面，一个按钮；这个最小单元是人为规定的。全局静态Context破坏了单元测试。
Android单元测试都测些什么？
View/UI都不太好测，可以测数据库、文件操作之类。
结论
不要使用全局静态ApplicationContext，依赖外界注入。。虽然麻烦。
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
