上一篇提到可以用一個全局靜態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

轉載于:https://juejin.im/post/5a3132f46fb9a04511712148

總結

以上是生活随笔為你收集整理的EP39 全局静态ApplicationContext的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。