注：NO1 表示Application context的確可以開始一個Activity，但是它需要創(chuàng)建一個新的task。這可能會滿足一些特定的需求，但是在你的應用中會創(chuàng)建一個不標準的回退棧(back stack)，這通常是不推薦的或者不是是好的實踐。

NO2 表示這是非法的，但是這個填充(inflation)的確可以完成，但是是使用所運行的系統(tǒng)默認的主題(theme)，而不是你app定義的主題。

NO3 在Android4.2以上，如果Receiver是null的話(這是用來獲取一個sticky broadcast的當前 值的)，這是允許的。

用戶界面UI

從前面的表格中可以看到，application context有很多功能并不是合適去做，而這些功能都與UI相關。實際上，只有Activity能夠處理所有與UI相關的任務。其他類別的context實例功能都差不多。

幸運的是，在應用中這三種操作基本上都不需要在Activity范圍之外進行，這很可能是android框架故意這么設計的。嘗試顯示一個使用Aplication context創(chuàng)建的Dialog，或者使用Application context開始一個Activity，系統(tǒng)會拋出一個異常，讓你的application崩潰，非常強的告訴你某些地方出了問題。

一個并不明顯的問題是填充布局(inflating layout)。如果你已經(jīng)讀過了我(原文作者)的上一篇文章Layout inflation，你就已經(jīng)知道它可能是一個非常神秘過程，伴隨一些隱藏的行為。使用正確的context關系到其中的一個行為。當你使用Application context來inflate一個布局的時候，框架并不會報錯，并返回一個使用系統(tǒng)默認的主題創(chuàng)建一個完美的view給你，而沒有考慮你的applicaiton自定義的theme和style。這是因為Acitivity是唯一的綁定了在manifast文件種定義主題的Context。其他的Context實例將會使用系統(tǒng)默認的主題來inflater你的view。導致顯示的結果并不是你所希望的。

規(guī)則的路口

可能有些讀者已經(jīng)得出兩個規(guī)則互相矛盾的結論?？赡苡行┣闆r下，在某些Application的設計中，我們可能既必須長期保存一個的引用，并且為了完成與UI相關的工作又必須保存一個Activity。如果出現(xiàn)這種情況，我將會強烈建議你重新考慮你的設計，它將是一個很好的“反框架”教材。

經(jīng)驗法則

絕大多數(shù)情況下，使用在你的所工作的組建內(nèi)部能夠直接獲取的Context。只要這個引用沒有超過這個組建的生命周期，你可以安全的保存這個引用。一旦你要保存一個context的引用，它超過了你的Activity或者Service的生命周期范圍，甚至是暫時的，你就需要轉(zhuǎn)換你的引用為Application context。