android中Context的應用總結

概述 作為一名Android開發人員，每天使用最多的類中，恐怕Context可以排的上一號了。因為Context對象在我們的項目中實在是太常見了，我們在加載資源，啟動Activity，獲取Service，發送Broadcast，創建View時都需要Context的參與。總之，Context是為一個Android程序提供各種功能，資源，服務的一個環境，Context的資源在系統中只有一套，因為它的子類（Application，Activity，Service）對這同一塊資源處理方式的不同，讓Context對象在功能上表現出各自之間的差異。   保存Context引用 在編寫工具類時，我們經常會編寫成單例的模式，而這些工具類大都會訪問資源，也就是說需要Context的參與。這時就會涉及到Context的引用問題。比如下面工具類的寫法： publicclassUtil{   privateContextcontext;   privatestaticUtilutil;   privateUtil(Contextcontext){ this.context=context; }   publicstaticUtilgetInstance(Contextcontext){ if(null==util){ synchronized(Util.class){ if(null==util){ util=newUtil(context); } } } returnutil; } } 上面的工具類中，使用單例模式，內部保存了一個Context引用，表面上看這樣的寫法是沒有問題的，但是實際應用中可能會造成內存的洩露。因為我們不能夠確定傳入的Context來自哪裡，如果是在某個Activity中，直接傳入的是this，這時這個Util類中是一個static修飾且強引用的是常駐內存的，它內部會一直持有這個Activity作為Context引用，這就會導致即使這個Activity被銷毀掉，這個Activity還是沒有辦法進行內存回收。所以就造成了內存洩漏。 為了避免上面的問題，我們可以對getInstance方法進行優化，如下： publicstaticUtilgetInstance(Contextcontext){ if(null==util){ synchronized(Util.class){ if(null==util){ util=newUtil(context.getApplicationContext()); } } } returnutil; } 采用上面的方式可以理解為引用的是ApplicationContext，它的生命周期與單例對象一致，只要這個應用還在運行這個Context就會一直存在。所以說當Application的Context能解決的情況下，優先使用Application的Context，這樣能避免內存洩漏。   Context的應用場景 但是上面的解決方案並不是萬能的，在涉及到UI加載操作，啟動Activity等，使用Application的Context時，程序無法運行的。這主要是因為Activity和Application所代表的Context返回的不是同一個對象，它們各自的使用場景也是不同的。下面是它們各自的使用場景，可以進行比較。

大家注意看到有一些NO上添加了一些數字，其實這些從能力上來說是YES，但是為什麼說是NO呢？下面一個一個解釋：

數字1：啟動Activity在這些類中是可以的，但是需要創建一個新的task。一般情況不推薦。

數字2：在這些類中去layout inflate是合法的，但是會使用系統默認的主題樣式，如果你自定義了某些樣式可能不會被使用。

數字3：在receiver為null時允許，在4.2或以上的版本中，用於獲取黏性廣播的當前值。（可以無視）

注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因為在其內部方法中都有一個context用於使用。

從上面的表格中可以看出，和UI相關的方法都不可使用Application，都應該使用Activity作為Context來處理；然後再配合工具類中Context引用的持有，防止內存洩漏，這是便能達到好的應用效果。