1. 單例模式

在單例模式下如果需要獲取Context相關對象，由于會長期持有該對象，會導致相關對象無法被回收，從而引起內存泄露問題，所以經量通過該Context獲取ApplicationContext對象使用，由于ApplicationContext會存在整個app生命周期中，所以長期持有不會導致內存泄露。

2. 匿名內部類使用問題

   通常在Activity中會創建Handler對象，執行某些方法，而當Activity被finish時，未被處理的方法會被保存10分鐘左右，從而導致Activity無法被銷毀。所以應該創建一個靜態內部類，通過WeakReference獲取相關引用，避免內存泄露。

   還可以在onDestroy中調用handler的removeCallbacksAndMessages(null)，刪除所有與該Handler對象相關的Runnable和Message

3. 開發中需要注意的點以免內存泄漏

   1. 不要讓生命周期長于Activity的對象持有到Activity的引用
   2. 盡量使用Application的Context而不是Activity的Context
   3. 盡量不要在Activity中使用非靜態內部類，因為非靜態內部類會隱式持有外部類實例的引用（具體可以查看細話Java：”失效”的private修飾符了解）。如果使用靜態內部類，將外部實例引用作為弱引用持有。
   4. 垃圾回收不能解決內存泄露，了解Android中垃圾回收機制

4. 獲取context的方法，以及使用上context和applicationContext的區別

   1. View.getContext,返回當前View對象的Context對象，通常是當前正在展示的Activity對象。
   2. Activity.getApplicationContext,獲取當前Activity所在的(應用)進程的Context對象，通常我們使用Context對象時，要優先考慮這個全局的進程Context。
   3. ContextWrapper.getBaseContext():用來獲取一個ContextWrapper進行裝飾之前的Context，可以使用這個方法，這個方法在實際開發中使用并不多，也不建議使用。
   4. Activity.this 返回當前的Activity實例，如果是UI控件需要使用Activity作為Context對象，但是默認的Toast實際上使用ApplicationContext也可以。

Paste_Image.png

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

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

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

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

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

好了，這里我們看下表格，重點看Activity和Application，可以看到，和UI相關的方法基本都不建議或者不可使用 Application，并且，前三個操作基本不可能在Application中出現。實際上，只要把握住一點，凡是跟UI相關的，都應該使用 Activity做為Context來處理；其他的一些操作，Service,Activity,Application等實例都可以，當然了，注意 Context引用的持有，防止內存泄漏。