android上下文對象

❶ android Activity 和 上下文Context 的關系

首先看繼承關系：

可以看到Activity繼承於ContextThemeWrapper，ContextThemeWrapper繼承於ContextWrapper，ContextWrapper繼承於Context。也就是說，Context是Activity的父類。

相關延伸：

說到Activity與Context關系，少不了Application與二者的關系，上圖可以明確看到Context是Application的父類，那麼對於參數傳遞，需要傳遞Context對象的時候，

我們是傳activity.this還是this.getApplicationContext()呢？

activity的生命周期肯定沒有application長，所以為了防止內存泄露：

1. 只要application可以滿足的就傳this.getApplicationContext()。比如用來ShowToast、獲取LayoutInflater對象、獲取資料庫對象、獲取SharedPreferences對象、發廣播context.sendBroadcast等，都可以傳this.getApplicationContext()。

2. application不能滿足的必須傳activity。比如showDialog、activity之間跳轉等。

❷ android中能否有兩個opengl上下文

不能。
OpenGL本身就是一個非常龐大的狀態機(State Machine) ，其狀態通常被稱為OpenGL上下文(Context)。它裡面保存了一系列的變數用來描述OpenGL此刻需要如何運行，比如拍照時候要開啟濾鏡功能等等。
OpenGL使用C語言編寫的，進而他的Api的封裝也都是面向過程的，其函數本質上都是對OpenGL上下文狀態機中的某個狀態或者對象進行操作。
應用程序中可以創建多個不同的上下文，他們分別在各自的線程中使用。上下文之間共享紋理，緩沖區等資源，採用這中方案更為高效，因為它避免了反復切換上下文，或者大量修改渲染狀態所造成的較大的開銷。

❸ static 方法中 如何獲取上下文 android 中 靜態方法中不能使用this當做上下文的對象，怎麼辦

可以在把具體的場景說一下嗎，這樣不太好回答
從現在的提問上來看 你可以直接創一個null
也可以傳一個Context的子類 一般來說
或new一個Context 或者它的子類

❹ Android下Context，Activity，Application之間有什麼區別

我發現這個表超級有用的決定何時使用不同類型的上下文:

應用程序可以從這里開始一個活動,但它需要一個新的任務被創建。 這可能適合特定的用例,但是可以創建標准棧行為一般不建議在您的應用程序,或者一種不錯的做法。

這是合法的,但通貨膨脹將使用默認主題您正在運行的系統,而不是在應用程序中定義的。

允許如果接收者是null,用於獲取的當前值的廣播,在安卓4.2及以上。

外網譯文：

上下文對象是如此普遍,如此頻繁的傳遞,很容易創建一個情況你沒有意願。 載入資源,推出一個新的活動,獲得一個系統服務,內部文件路徑,所有需要創建視圖上下文(這是沒有開始的完整列表!)來完成這項任務。 我想做的就是為你提供一些見解上下文作品和一些技巧,這些技巧將(希望)允許您在應用程序中更有效地利用它。

上下文類型

並不是所有的上下文實例都是平等的。 根據Android應用程序組件上下文你可以訪問略有不同:

應用程序——是一個單例實例中運行您的應用程序的過程。 它可以通過訪問方法getApplication()從一個活動或服務getApplicationContext()從任何其他對象繼承上下文。 無論它如何訪問,你總是會收到相同的實例從內部流程。

活動/服務——繼承ContextWrapper實現相同的API,但是代理所有的方法調用一個隱藏的內部上下文上下文實例,也被稱為它的基地。 每當框架創建一個新的活動或服務實例,它還創建了一個新的ContextImpl實例做所有組件將包裝的重任。 每個活動或服務,及其相應的基礎背景,是獨一無二的每個實例。

BroadcastReceiver——不是一個上下文本身,而是通過一個框架上下文在onReceive()每次新的廣播事件出現的原因。 這個例子是一個ReceiverRestrictedContext有兩個主要功能殘疾;調用registerReceiver()和bindService()。 這兩個函數不允許從內部現有的BroadcastReceiver.onReceive()。 每次一個廣播接收器流程,上下文交給一個新實例。

內容提供者——也不是上下文但給出了一個創建時,可以通過訪問getContext()。 如果ContentProvider運行本地調用者(即同一應用程序的過程),那麼這個單會返回相同的應用程序。 然而,如果兩個單獨的進程,這將是一個新創建的實例代表包中運行的提供者。

保存引用

我們需要解決的第一個問題來自儲蓄的引用上下文在一個對象或類的實例的生命周期,超出你救了。 例如,創建一個自定義需要的單例上下文載入資源或訪問ContentProvider,並保存當前活動或服務的引用的單例。

壞的單例

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

公共 類 CustomManager {

私人 靜態 CustomManagersInstance;

公共 靜態 CustomManagergetInstance(上下文上下文) {

如果 (sInstance = = 零) {

sInstance = 新 CustomManager(上下文);

}

返回 sInstance;

}

私人 上下文mContext;

私人 CustomManager(上下文上下文) {

mContext = 上下文;

}

}

這里的問題是我們不知道上下文來自,不安全持有對象的引用如果它最終成為一個活動或一個服務。 這是一個問題,因為單是由一個單一的靜態引用在封閉類。 這意味著我們的對象,和所有其他對象引用它,永遠不會被垃圾收集。 如果這上下文是一個活動,我們會有效地持有人質在內存中所有與它相關的觀點和其他潛在的大對象,創建一個泄漏。

為了防止這一點,我們修改單總是參考應用程序上下文:

更好的單例

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

公共 類 CustomManager {

私人 靜態 CustomManagersInstance;

公共 靜態 CustomManagergetInstance(上下文上下文) {

如果 (sInstance = = 零) {

/ /總是通過在應用程序上下文

sInstance = 新 CustomManager(上下文。getApplicationContext());

}

返回 sInstance;

}

私人 上下文mContext;

私人 CustomManager(上下文上下文) {

mContext = 上下文;

}

}

現在我們並不重要上下文來自,因為參考我們是安全的。 應用程序上下文本身就是一個單,所以我們沒有泄露任何通過創建另一個靜態引用。 另一個很好的例子,這可以出現的地方保存一個引用上下文從正在運行的後台線程或等待處理程序。

那麼,為什麼我們不能總是只是引用應用程序上下文? 以中間人的方程,,,永遠不必擔心創造泄漏? 答案,我在引言中提到,是因為一個上下文不等於另一個。

上下文的能力

您可以安全地採取共同行動與給定上下文對象取決於最初是從哪裡來的。 下面是一個表的常見應用程序將接收的地方上下文,在每一種情況下是很有用的:

應用程序

活動

服務

內容提供者

BroadcastReceiver

顯示一個對話框 沒有 是的 沒有 沒有 沒有

開始一個活動 沒有1 是的 沒有1 沒有1 沒有1

布局的通貨膨脹 沒有2 是的 沒有2 沒有2 沒有2

啟動一個服務 是的 是的 是的 是的 是的

綁定到一個服務 是的 是的 是的 是的 沒有

發送一個廣播 是的 是的 是的 是的 是的

注冊BroadcastReceiver 是的 是的 是的 是的 沒有3

載入資源值 是的 是的 是的 是的 是的

應用程序可以從這里開始一個活動,但它需要一個新的任務被創建。 這可能適合特定的用例,但是可以創建標准棧行為一般不建議在您的應用程序,或者一種不錯的做法。

這是合法的,但通貨膨脹將使用默認主題您正在運行的系統,而不是在應用程序中定義的。

允許如果接收器零,用於獲取的當前值的廣播,在安卓4.2及以上。

用戶界面

從看著前面的表中可以看到,有很多功能的應用程序上下文是適合處理不當;他們與UI相關的工作。 事實上,只有實現裝備來處理所有與UI相關的任務活動,其他實例票價差不多在所有類別。

幸運的是,這三個動作是一個應用程序並沒有任何地方做一個活動的范圍之外,就像框架是故意這樣設計的。 試圖展示一個對話框創建應用程序上下文的引用,或者開始一個活動的應用程序上下文將拋出一個異常且應用程序崩潰…一個強大的指示器出事了。

不太明顯的問題是膨脹布局。 如果你讀過我的最後一塊布局的通貨膨脹,你已經知道它可能是一個有點神秘的過程和一些隱藏行為,使用正確的上下文與另一個的行為。 而框架不會抱怨,將返回一個完美的從一個視圖層次LayoutInflater創建應用程序上下文,主題和風格的應用程序將不考慮過程。 這是因為活動是唯一的上下文清單中定義的主題實際上是連接。 任何其他實例將使用系統默認主題膨脹你的視圖,導致顯示輸出你可能沒想到。

這些規則的十字路口

總是,有人會到達這兩個規則沖突的結論。 有一個案件在長期引用的應用程序當前的設計必須保存,我們必須拯救一個活動因為我們想要完成的任務包括UI的操作。 如果是這樣的話,我就會勸你重新考慮你的設計,因為這將是一個教科書的實例戰斗框架。

經驗法則

在大多數情況下,使用上下文直接提供給你從封閉組件在工作。 您可以安全地舉行的引用,只要引用不超越該組件的生命周期。 一旦你要保存的引用上下文從一個對象的生活超出你的活動或服務,即使暫時,開關,參考您保存到應用程序上下文。

❺ 如何理解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信息等。

❻ Android SQLiteOpenHelper類構造器中的context對象，我一個工程用一個資料庫，怎麼我的上下文對象是什麼

當前調用SQLiteOpenHelper的Activity對象的context

❼ android 上下文對象對象是什麼意思

你說的是Context吧，它代表的是某個類的引用，比如
public class B{
private Context mContext;
public B(Context context){
mContext = context;
.......................
}
}
如果在class A中新建了一個class B的對象，B b = new B(A.this);那麼B的構造方法中的context參數就是A的引用，在android中如果A是Activity那麼B中的mContext經過賦值後就可以像使用Activity一樣使用mContext，比如mContext.startActivity(..........);
((Activity)mContext).finish();等等

❽ android getContext，getApplicationContext和this有什麼區別

使用this, 說明當前類是context的子類，一般是activity application等
使用getApplicationContext 取得的是當前app所使用的application，這在AndroidManifest中唯一指定。意味著，在當前app的任意位置使用這個函數得到的是同一個Context
使用getContext獲取的是當前對象所在的Context
Context通常翻譯成上下文，我通常當成場景來理解。
比如 我在火車上。
This 指當前類就是當前的場景。我.this不是context,
我.getContext 是火車， 火車.this是一個context
AppContext 就可以理解成這個社會。發生的一切都在這個社會中.有且只有一個社會

❾ 安卓中fragment和activity的區別

Activity是ContextWrapper的子類，是一個上下文對象，也是四大組件之一，使用時必須在AndroidManifest.xml注冊，fragment只是為了分離Activity中UI控制代碼的，其view其實還屬於Activity

❿ 對於android裡面的content不理解，查找說這個是上下文，但是我還是沒有這個概念，什麼是上下文求大神講解

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以及BroadcastReceiver。
Context提供了關於應用環境全局信息的介面。它是一個抽象類，它的執行被Android系統所提供。它允許獲取以應用為特徵的資源和類型。同時啟動應用級的操作，如啟動Activity，broadcasting和接收intents。

兩種類型的Context
在android中context可以作很多操作，但是最主要的功能是載入和訪問資源。
在android中有兩種context，一種是 application context，一種是activity context，通常我們在各種類和方法間傳遞的是activity context。

application context
我們可以使用application context。application context伴隨application的一生，與activity的生命周期無關。
application context可以通過Context.getApplicationContext或者Activity.getApplication方法獲取。這個context 實際就是在AndroidManifest.xml application 節點定義的類