上一篇提到可以用一個(gè)全局靜態(tài)context來替代context單例。那在App的一個(gè)公共基礎(chǔ)類里面（比如我們的RunningContext）定義一個(gè)全局靜態(tài)context會有問題嗎？
public static Context sAppContext = null;
這個(gè)sAppContext如果為null就用getApplicationContext獲取，典型的單例（但不是在構(gòu)造函數(shù)里初始化）。但只要你用static修飾Context，IDE還是會一直警告你"Do not place android context classes in static fields, this is a memory leak."
有人會說既然ApplicationContext只要app的進(jìn)程還在就會一直存在，就不會造成內(nèi)存泄露。這話對嗎？我感覺挺對的，只要你不像EP38里的例子一樣，把這個(gè)全局靜態(tài)context傳遞給單例的構(gòu)造函數(shù)，也想不出什么會泄露內(nèi)存的場景。
但是我總覺得Android Studio警告不要把context用static修飾是有道理的。
stackoverflow上有人解釋說，為了避免內(nèi)存泄露，幾乎沒有任何必要使用靜態(tài)變量。常量可以用靜態(tài)的，因?yàn)樗鼈兊臄?shù)量和占據(jù)的空間都不多。
使用全局靜態(tài)Context是上一篇文章得到的一個(gè)方案，但是這樣還是會有一些問題的。6 THINGS YOU SHOULD KNOW的作者提出了以下幾點(diǎn)。
1. 會讓構(gòu)造參數(shù)的作用得不到發(fā)揮
Google’s Guide to Writing testable code說:
靜態(tài)的獲取全局變量并沒有將它們（全局變量）構(gòu)造函數(shù)和方法的依賴關(guān)系告訴給閱讀代碼的人。全局變量和單例通過API掩蓋了它們真實(shí)的依賴關(guān)系。如果想要真正理解依賴關(guān)系，開發(fā)人員必須逐行閱讀代碼。
比如你寫了一個(gè)方法叫作displayString ()，如果你給它的構(gòu)造方法傳入一個(gè)Context 和一個(gè) String，那我們可能會推測你用了Context管理的某個(gè)方法來展示字符串，比如Toast。這也是構(gòu)造參數(shù)的一個(gè)指示作用。
說到這兒我不禁猜到為什么static方法/對象/變量/常量不需要用對象來調(diào)用了，因?yàn)閟taticstatic方法/對象/變量/常量一旦初始化就一直存在于內(nèi)存中，不會被GC，自然不需要每次都重新初始化一遍了。
2. 違反了封裝原則
這個(gè)說法聽起來有點(diǎn)牽強(qiáng)。
封裝保障了一個(gè)對象的行為只能被它的API所影響。但其實(shí)不用封裝也不會造成程序崩潰。
3. 不容易進(jìn)行單元測試
單元測試就是「對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證」。比如C語言中的一個(gè)函數(shù)，Java中的一個(gè)類，圖形化程序的一個(gè)界面，一個(gè)按鈕；這個(gè)最小單元是人為規(guī)定的。全局靜態(tài)Context破壞了單元測試。
Android單元測試都測些什么？
View/UI都不太好測，可以測數(shù)據(jù)庫、文件操作之類。
結(jié)論
不要使用全局靜態(tài)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.itdecent.cn/p/03118c11c199
