android中的context

A. android里每個服務啟動時context到底從哪裡來的呢

1.android里每個服務啟動時context到底從哪裡來的呢？？？？以mountservice的context為例
在SystemServer.java的run函數中有如下代碼
context = ActivityManagerService.main(factoryTest);
......
if (!"0".equals(SystemProperties.get("system_init.startmountservice"))) {
try {
/*
* NotificationManagerService is dependant on MountService,
* (for media / usb notifications) so we must start MountService first.
*/
Slog.i(TAG, "Mount Service");
mountService = new MountService(context);
ServiceManager.addService("mount", mountService);
} catch (Throwable e) {
reportWtf("starting Mount Service", e);
}
}
由此可知，由systemserver啟動的服務的context都來自ActivityManagerService
ActivityManagerService.java

public static final Context main(int factoryTest) {
......
ActivityThread at = ActivityThread.systemMain();
......
Context context = at.getSystemContext();
......
return context;
}
由上可知，該context是由ActivityThread 創建的
ActivityThread .java
public ContextImpl getSystemContext() {
synchronized (this) {
if (mSystemContext == null) {
ContextImpl context =
ContextImpl.createSystemContext(this);
LoadedApk info = new LoadedApk(this, "android", context, null,
CompatibilityInfo.DEFAULT_COMPATIBILITY_INFO);
context.init(info, null, this);
context.getResources().updateConfiguration(
getConfiguration(), getDisplayMetricsLocked(
Display.DEFAULT_DISPLAY,
CompatibilityInfo.DEFAULT_COMPATIBILITY_INFO));
mSystemContext = context;
//Slog.i(TAG, "Created system resources " + context.getResources()
// + ": " + context.getResources().getConfiguration());
}
}
return mSystemContext;
}
在ContextImpl .java中
static ContextImpl createSystemContext(ActivityThread mainThread) {
final ContextImpl context = new ContextImpl();
context.init(Resources.getSystem(), mainThread, Process.myUserHandle());
return context;
}
由此可知所有systemserver啟動的服務的context對象實際為一個ContextImpl對象
即ServerThread::run<-ActivityManagerService.main<-ActivityThread::getSystemContext<-ContextImpl.createSystemContext

2.對於一個apk中的context一般直接指向這個activity本身，因為activity本身即繼承自context

B. Android中，Context，什麼是Context

context其實就是句柄，只不過不像windows一樣，每個資源都可以是一個句柄，Android的一個句柄包含了很多全局信息，比如說Activity就是一個句柄。

官方文檔的解釋是：Context提供了關於應用環境全局信息的介面。它是一個抽象類，它的執行被Android系統所提供。它允許獲取以應用為特徵的資源和類型。同時啟動應用級的操作，如啟動Activity，broadcasting和接收intents。

C. Android中的context是什麼東西

Context，中文直譯為「上下文」，SDK中對其說明如迅敗察下：
Interface to global information about an application environment. This is an abstract class whose implementation
is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls
for application-level operations such as launching activities, broadcasting and receiving intents, etc

從上可知一下三點,即：
1、它描述的是一個應用程序環境的信息，即上下文。
2、該類是一個抽象(abstract class)類，Android提供了該抽象類的具體實現類(後枯纖面我們會講到是ContextIml類)。
3、通過它我們可以獲取應用程序的資源和類，也包括一些應用級別操作，例如：畝茄啟動一個Activity，發送廣播，接受Intent信息等。

D. android中的Context到底該怎麼用

在Android系統中，有很多的service，也就是服務。我們的程序如果用到系統功能，一般都是調用服務間接完成的。也就是在Android系統中存在許多C/S架構。而context的作用，就是android應用連接service的橋梁。比如Activity中有一個方法，getSystemService()。這個方法調到最後，實際上是調用的ContextImpl的getSystemService()方法。而ContextImpl是對Context的實現。
Context不是函數而是一個類——如果不返檔太了解面向對象，可以把「類」看做一種數據類型，就像int，不過類型為「類」的數據（稱為對象）可能儲存遠比int多的信息，比如這里的類型為Context的對象就儲存關於程序、窗口的一些資源。

有些函數調用時需要一個Context參數，漏核亂比如Toast.makeText，因為函數需要知道是在哪個界面中顯示的Toast。
再比如，Button myButton = new Button(this); 這里也需要Context參數（this），表示這個按鈕是在「this」這個屏幕中顯示的。
Android開發使用（純粹的）面向對象語言，一切都是對象，就連我們寫的函數都是對象的函數。
public class MainActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Toast.makeText(this,
"OK!",
Toast.LENGTH_LONG).show();
Button button1 = (Button)findViewById(R.id.button1);
button1.setOnClickListener(new Button.OnClickListener(){
public void onClick(View v)
{
Toast.makeText(MainActivity.this,
"Hello, world!",
Toast.LENGTH_LONG).show();
}
});
}
}
這里OnCreate就是MainActivity的對象的函數（MainActivity是類），所以這個函數中的this就表示當前的、包含這個函數的MainActivity對象。
MainActivity extends Activity，意思是MainActivity 繼承 Activity，即MainActivity 是 Activity 的一種，所有的MainActivity 都是 Activity。同樣，在Android文檔中Activity繼承ContextThemeWrapper，ContextThemeWrapper繼承ContextWrapper，ContextWrapper繼承Context。所以this這個MainActivity也是Context，氏雹把this傳入Toast.makeText表示「OK!」是在當前的MainActivity對象（也是Context）中顯示的。
對於顯示"Hello, world!"的Toast.makeText，這個函數在onClick中，而onClick是new Button.OnClickListener(){...}這個沒有名字的類的函數，this表示匿名類的對象，不表示MainActivity對象，所以這里用MainActivity.this，強制選擇外面一層MainActivity的this。
望採納，謝謝。

E. 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。

F. android中的context是什麼意思，能詳細說一下嗎

context是環境，上下文的意思。在程序中，起碼我沒有發現更帆型好腔轎局的翻譯。軟體中間很多詞在翻譯成中文的時候，都是只可意會不可言傳的。大意就是只一個伍讓范圍，比如變數的生存范圍、會話范圍等。

G. android context是什麼

Context字面意思是上下文，位於framework package的android.content.Context中，其實該類為LONG型，類似Win32中的Handle句柄。很多方法需要通過 Context才能識別調用者的實例：比如說Toast的第一個參數就是Context，一般在Activity中我們直接用this代替，代表調用者的實例為Activity，而到了一個button的onClick(View view)等方法時，我們用this時就會報錯，所以我們可能使用ActivityName.this來解決，主要原因是因為實現Context的類主要有Android特有的幾個模型，Activity以及Service。
Context提供了關於應用環境全局信息的介面。它是一個抽象類，它的執行被Android系統所提供。它允許獲取以應用為特徵的資源和類型。同時啟動應用級的操作，如啟動Activity，broadcasting和接收intents。

H. Context是什麼

                                                                        Context

   Context，翻譯是上下文環境，在android應用開發中的地位舉足輕重，甚至源碼也有一句話：everything needs a context（看到過，但是忘了在哪裡了）。

從這個類圖中我們看到，Context是一個抽象類，一邊是Context的具體實現ContextImpl，一邊則是組件的封裝類ContextWrapper，便於二者各司其職，我理解是介面和實現分開，這樣比較符合開閉原則吧。

  既然要搞清楚Context是幹嘛的，得先看纖配Context的實例什麼時候創建的。這里有兩個我們經常接觸的組件，Activity和Service，以及用的較少的Application，它們的關系如下：

    1.Application：保存應用的全局信息的類，它的實例在應用創建的時候被創建，生命周期最長，應用銷毀了才會被銷毀。

    2.Activity：創建一個Activity便對應一個Context的實例，生命周期隨著Activity的周期變化。

    3.Service：創建一個Service便對應一個Context的實例，生命周期隨著Service的周期變化。

下面逐一看看它們是什麼時候實例Context類的，我們需要知道，一個ContextWrapper類對應一個ContextImpl類的實例，因為具體實現的地方還是在ContextImpl中，ContextWrapper中的mBase變數指向ContextImpl變數的實例。

（1） Application的Context創建：

如圖：

  跳過Process創建過程，在我們的應用被zygote進程孵化出來後，被反射調用main函數，這里毀返指會創建ActivityThread類的實例，該類並不是一個線程類的子類，但是它的main函數跑在新創建的進程的主線程。 創建後，調用attach方法，與AMS綁定：

這里傳入的mAppThread變數為ApplicationThread類，它為ActivityThread的內部類，作用就是作為應用端的binder服務端，負責接收AMS的調度，這里我們傳入這個服務端的句柄，讓AMS持有，從而AMS可以通過這個句柄來操控應用的行為。我們向AMS請求，則是通過AMS的句柄。接下來就到了AMS的邏輯：

    在ApplicationThread的實現端中，就是把跨進程傳遞過來的各種數據再用一個AppBindData類保存下來，然後調用Handler對象H發送消息BIND_APPLICATION，最後在app線程中處理此邏輯，讓AMS線程可以不必同步阻塞。接下來就到了handleBindApplication：

    Instrumentation類是用於管理Acitivty的工具類。這又有一個比較重要的對象出現，LoadedApk，它裡面保存了類載入器ClassLoader，data.info的對象便是它，makeApplication函數中的邏輯：

  這里我們看到了ContextImpl的創建時機，就是在Application實例創建的時候：

  如此就完成了Application的創建，並且調用attach方法把Application的mBase對象賦值給創建的ContextImpl，至此Application的創建就完成了，getApplicationContext（) 返回的便是此處我們創建的Application類的對象。

  這里為什麼要去LoadedApk類中利用類載入器，把對象創建出來呢？因為我們的Application類是可以自己拓展的，創建的時候是不確定應用自己是否復寫了Application對象， 利用類載入器就可以動態決定創建什麼類的對象了 ，我們只需要從PMS中獲取到application的具體類名即可，這個類名是寫在Mainfest文件中的，後面Activity也是利用這種機制去創建對象。

（2）Actvity的啟動過世早程，網上非常多文章分析了，我也就不再重復羅列出來了，大概的過程就是startActivity()被調用，然後檢查目標Acitivity的進程是否創建，沒創建就先向Zygote進程請求fork應用進程，然後一系列初始化過程後，最後在AMS模塊中的ActivityStackSupervisor中realStartActivityLocked(）調用IApplicationThread代理類，調用到scheleLaunchActivity(），然後在應用的線程開始執行handleLaunchActivity()，最主要的邏輯在performLaunchActivity：

  至於Activity的生命周期後面怎麼走的，這里不在乎，我們只看Context實例化過程。同樣的，這里也會創建ContextImpl對象，在Activity對象創建後，調用Attach()，這個函數挺重要的，我們看看都幹了什麼：

  在attach函數中，也會為ContextWrapper中的mBase對象賦值一個ContextImpl對象，我們這里也能猜想到Service的創建估計也會有這個過程，而事實上Service的創建差不多也是這個過程，所以不再贅述了。

    我們可以知道Context例的實例化都是在我們在Application，Activity和Service創建的時候會實例化，而這些組件的父類都是ContextWrapper，所以在創建的時候還會先創建一個ContextImpl類對象，然後給自己的父類mBase變數賦值，既然如此，Context的引用對應的就是Application，Activity和Service了，Context的用處就是提供了一組抽象的函數，讓子類去相對應的實現，當你持有一個Context引用的時候，你可以通過這個引用去獲取相對應組件的信息。比如持有一個Activity的Context引用，你可以在別的地方調用startActivity（）去啟動一個新的activity。

總結：

  1.Context是抽象類，所以實例化要在子類中，Application，Service，Activity是我們實例化的地方，一般應用創建會實例化一個Application類，Service和Activity則是在startService和StartActivity被調用的時候會實例化，它們都會創建一個ContextImpl類實例，給自己的父類ContextWrapper的mBase變數賦值。

  2.Context是組件中通用操作的一組集合，當具體的子類實例化後，可以在別的地方通過保存一個Context引用去獲取信息和通用操作等，也就是說，我們可以通過這個引用去獲取到這個應用中的重要信息以及這個應用的通用操作。

I. android中的context是起什麼作用的

當我們訪問當前應用的資源，啟動一個新的activity的時態大仔候都需要提供Context。

Context是一個抽象基類，我們仿唯通過它訪問當前包的資源（getResources、getAssets）和啟動其他組件（Activity、Service、Broadcast）以及得到各種服務（getSystemService），當然，通過Context能得到的不僅僅只有上述這些內容。對Context的理解可以來說：Context提供了一個應用的運行環境，在Context的大環境里，應用才可以訪問資源，才能完成和其他組件、服務的交互，Context定義了一套基本的功能介面，可以理解為一套規范，而Activity和Service是實現這套規范的子類，這么說也許並不準確，因為這套規范實際是被ContextImpl類統一實現的，Activity和Service只是繼承並有選擇性地重寫了某些規范的實現。

activity繼承關系

可以看出幾個組件都繼承於Context

一個應用中Context的數量等於Activity的個數+ Service的個數+ 1，這帆汪個1為Application

J. android中的context和this的區別

在android中常常會遇到與context有關的內容，特寫下這篇blog，淺論一下context ： 在語句 AlertDialog.Builder builder = new AlertDialog.Builder(this); 中，要求傳遞的 參數就是一個context，在這里我們傳入的是this，那麼這個this究竟指的是什麼東東呢？ 這里的this指的是Activity.this，是這個語句所在的Activity的this，是這個Activity 的上下文。網上有很多朋友在這里傳入this.getApplicationContext（），這是不對的。 AlertDialog對象是依賴於一個View的，而View是和一個Activity對應的。 於是，這里涉及到一個生命周期的問題，this.getApplicationContext（）取的是這個應 用程序的Context，Activity.this取的是這個Activity的Context，這兩者的生命周期是不同 的，前者的生命周期是整個應用，後者的生命周期只是它所在的Activity。而AlertDialog應 該是屬於一個Activity的，在Activity銷毀的時候它也就銷毀了，不會再存在；但是，如果傳 入this.getApplicationContext（），就表示它的生命周期是整個應用程序，這顯然超過了它 的生命周期了。 所以，在這里我們只能使用Activity的this

context指的上下文環境
this指的是本類的對象，
一般情況：有context但是不一定有this，有this一定有context環境