❶ android中,Context,什麼是Context
Context對象是如此常見和傳遞使用,它可能會很容易產生並不是你預期的情形。載入資源、啟動一個新的Activity、獲取系統服務、獲取內部文件路徑以及創建view(其實還遠不止這些)統統都需要Context對象來完成。我(原文作者)想做的只是給大家提供一些Context是如何工作的見解,以及讓大家在應用中更有效的使用Context的技巧。
Context的類型
並不是所有的context實例都是等價的。根據Android應用的組件不同,你訪棗兄掘問的context推向有些細微的差別。
Application - 是一個運行在你的應用進程中的單例。在Activity或者Service中,它可以通過getApplication()函數獲得,或者人和繼承於context的對象中,通過getApplicationContext()方法獲得。不管你是通過何種方法在哪裡獲得的,在一個進程內,你總是獲得到同一個實例。
Activity/Service - 繼承於ContextWrapper,它實現了與context同樣API,但是代理這些方法調用到內部隱藏的Context實例,即我們所知道的基礎context。任何時候當系統創建一個新的Activity或者Service實例的時候,它也創建一個新的ContextImpl實例來做所有的繁重的工作。每一個Activity和Service以及其對應的基礎context,對每個實例來說都是唯一的。
BroadcastReciver - 它本身不是context,也沒有context在它裡面,但是每當一個新的廣播到達的時候,框架都傳遞一個context對象到onReceive()。這個context是一個ReceiverRestrictedContext實例,它有兩個主要函數被禁掉:registerReceiver()和bindService()。這兩個凳核函數在BroadcastReceiver.onReceive()不允許調用。每次Receiver處理一個廣播,傳遞進來的context都是一個新的實例。
ContentProvider - 它本身也不是一個Context,但是它可以通過getContext()函數給你一個Context對象。如果ContentProvider是在調用者的的本地(例如,在同一個應用進程),getContext()將返回的是Application單例。然而,如果調用這和ContentProvider在不同的進程的時候,它將返回一個新創建的實例代表這個Provider所運行的包。
保存引用
第一個我們需要解決問題是,在一個對象或者類內部保存一個context引用,而它生命周期卻超過其保存引用的對象的塵遲生命周期。例如,創建一個自定義的單例,它需要一個context來載入資源或者獲取ContentProvider,從而保存一個指向當前Activiy或者Service的引用在單例中。
糟糕的單例
[java] view plain
public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
sInstance = new CustomManager(context);
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
這里的問題在於,我們不知道這個context是從哪裡來的,並且如果保存一個最終指向的是Activity或者Servece的引用是並不安全的。這是一個問題,是因為一個單例在類的內部維持一個唯一的靜態引用,這意味著我們的對象,以及所有其他它所引用的對象,將永遠不能被垃圾回收。假如這個Context是一個Activity,我們將保存與這個Activity相關的所有的view以及其他大的對象,從而造成內存泄漏。
為了解決這個問題,我們修改單例永遠只是保存Application context:
改善的單例:
[java] view plain
public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
//Always pass in the Application Context
sInstance = new CustomManager(context.getApplicationContext());
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
現在這個例子中,我們的Context來自哪裡都沒有關系,因為我們這里保存引用是安全的。Application Context 本身就是一個單例,所以我們再創建另外一個static引用,不會造成任何內存泄漏。另外一個很好的例子是,在後台線程或者一個等待的Handler中保存Context的引用,也可以使用這樣的方法。
為什麼我們不能總是引用Application context呢?正如前面說的,引用Application context永遠不用擔心內存泄漏的問題。問題的答案,就像我在開始的介紹中說的,是因為不同context並不是等價的。
Context的能力
Conext能做的通用操作決定於這個context最初來源於哪裡。下表所列的是,在應用中常見的會收到context對象的,以及對應的每種情況,它可以用於哪些地方:
Application
Activity
Service
ContentProvider
BroadcastReceiver
Show a Dialog NO YES NO NO NO
Start an Activity NO1 YES NO1 NO1 NO1
Layout Inflation NO2 YES NO2 NO2 NO2
Start a Service YES YES YES YES YES
Bind to a Service YES YES YES YES NO
Send a Broadcast YES YES YES YES YES
Register BroadcastReceiver YES YES YES YES NO3
Load Resource Values YES YES YES YES YES
註:NO1 表示Application context的確可以開始一個Activity,但是它需要創建一個新的task。這可能會滿足一些特定的需求,但是在你的應用中會創建一個不標準的回退棧(back stack),這通常是不推薦的或者不是是好的實踐。
NO2 表示這是非法的,但是這個填充(inflation)的確可以完成,但是是使用所運行的系統默認的主題(theme),而不是你app定義的主題。
NO3 在Android4.2以上,如果Receiver是null的話(這是用來獲取一個sticky broadcast的當前 值的),這是允許的。
用戶界面UI
從前面的表格中可以看到,application context有很多功能並不是合適去做,而這些功能都與UI相關。實際上,只有Activity能夠處理所有與UI相關的任務。其他類別的context實例功能都差不多。
幸運的是,在應用中這三種操作基本上都不需要在Activity范圍之外進行,這很可能是android框架故意這么設計的。嘗試顯示一個使用Aplication context創建的Dialog,或者使用Application context開始一個Activity,系統會拋出一個異常,讓你的application崩潰,非常強的告訴你某些地方出了問題。
一個並不明顯的問題是填充布局(inflating layout)。如果你已經讀過了我(原文作者)的上一篇文章Layout inflation,你就已經知道它可能是一個非常神秘過程,伴隨一些隱藏的行為。使用正確的context關繫到其中的一個行為。當你使用Application context來inflate一個布局的時候,框架並不會報錯,並返回一個使用系統默認的主題創建一個完美的view給你,而沒有考慮你的applicaiton自定義的theme和style。這是因為Acitivity是唯一的綁定了在manifast文件種定義主題的Context。其他的Context實例將會使用系統默認的主題來inflater你的view。導致顯示的結果並不是你所希望的。
規則的路口
可能有些讀者已經得出兩個規則互相矛盾的結論。可能有些情況下,在某些Application的設計中,我們可能既必須長期保存一個的引用,並且為了完成與UI相關的工作又必須保存一個Activity。如果出現這種情況,我將會強烈建議你重新考慮你的設計,它將是一個很好的「反框架」教材。
經驗法則
絕大多數情況下,使用在你的所工作的組建內部能夠直接獲取的Context。只要這個引用沒有超過這個組建的生命周期,你可以安全的保存這個引用。一旦你要保存一個context的引用,它超過了你的Activity或者Service的生命周期范圍,甚至是暫時的,你就需要轉換你的引用為Application context。