[干貨]讓你徹底搞懂Context到底是什么,如果沒弄明白,還怎么做Android開發?

Activity mActivity =new Activity()

作為Android開發者,不知道你有沒有思考過這個問題,Activity可以new嗎?Android的應用程序開發采用JAVA語言,Activity本質上也是一個對象,那上面的寫法有什么問題呢?估計很多人說不清道不明。Android程序不像Java程序一樣,隨便創建一個類,寫個main()方法就能運行,Android應用模型是基于組件的應用設計模式,組件的運行要有一個完整的Android工程環境,在這個環境下,Activity、Service等系統組件才能夠正常工作,而這些組件并不能采用普通的Java對象創建方式,new一下就能創建實例了,而是要有它們各自的上下文環境,也就是我們這里討論的Context??梢哉庋?,Context是維持Android程序中各組件能夠正常工作的一個核心功能類。

Context到底是什么

Context的中文翻譯為:語境; 上下文; 背景; 環境,在開發中我們經常說稱之為“上下文”,那么這個“上下文”到底是指什么意思呢?在語文中,我們可以理解為語境,在程序中,我們可以理解為當前對象在程序中所處的一個環境,一個與系統交互的過程。比如微信聊天,此時的“環境”是指聊天的界面以及相關的數據請求與傳輸,Context在加載資源、啟動Activity、獲取系統服務、創建View等操作都要參與。

那Context到底是什么呢?一個Activity就是一個Context,一個Service也是一個Context。Android程序員把“場景”抽象為Context類,他們認為用戶和操作系統的每一次交互都是一個場景,比如打電話、發短信,這些都是一個有界面的場景,還有一些沒有界面的場景,比如后臺運行的服務(Service)。一個應用程序可以認為是一個工作環境,用戶在這個環境中會切換到不同的場景,這就像一個前臺秘書,她可能需要接待客人,可能要打印文件,還可能要接聽客戶電話,而這些就稱之為不同的場景,前臺秘書可以稱之為一個應用程序。

如何生動形象的理解Context

上面的概念中采用了通俗的理解方式,將Context理解為“上下文”或者“場景”,如果你仍然覺得很抽象,不好理解。在這里我給出一個可能不是很恰當的比喻,希望有助于大家的理解:一個Android應用程序,可以理解為一部電影或者一部電視劇,Activity,Service,Broadcast Receiver,Content Provider這四大組件就好比是這部戲里的四個主角:胡歌,霍建華,詩詩,Baby。他們是由劇組(系統)一開始就定好了的,整部戲就是由這四位主演領銜擔綱的,所以這四位主角并不是大街上隨隨便便拉個人(new 一個對象)都能演的。有了演員當然也得有攝像機拍攝啊,他們必須通過鏡頭(Context)才能將戲傳遞給觀眾,這也就正對應說四大組件(四位主角)必須工作在Context環境下(攝像機鏡頭)。那Button,TextView,LinearLayout這些控件呢,就好比是這部戲里的配角或者說群眾演員,他們顯然沒有這么重用,隨便一個路人甲路人乙都能演(可以new一個對象),但是他們也必須要面對鏡頭(工作在Context環境下),所以Button mButton=new Button(Context)是可以的。雖然不很恰當,但還是很容易理解的,希望有幫助。

源碼中的Context


源碼中的注釋是這么來解釋Context的:Context提供了關于應用環境全局信息的接口。它是一個抽象類,它的執行被Android系統所提供。它允許獲取以應用為特征的資源和類型,是一個統領一些資源(應用程序環境變量等)的上下文。就是說,它描述一個應用程序環境的信息(即上下文);是一個抽象類,Android提供了該抽象類的具體實現類;通過它我們可以獲取應用程序的資源和類(包括應用級別操作,如啟動Activity,發廣播,接受Intent等)。既然上面Context是一個抽象類,那么肯定有他的實現類咯,我們在Context的源碼中通過IDE可以查看到他的子類最終可以得到如下關系圖:



Context類本身是一個純abstract類,它有兩個具體的實現子類:ContextImpl和ContextWrapper。其中ContextWrapper類,如其名所言,這只是一個包裝而已,ContextWrapper構造函數中必須包含一個真正的Context引用,同時ContextWrapper中提供了attachBaseContext()用于給ContextWrapper對象中指定真正的Context對象,調用ContextWrapper的方法都會被轉向其所包含的真正的Context對象。ContextThemeWrapper類,如其名所言,其內部包含了與主題(Theme)相關的接口,這里所說的主題就是指在AndroidManifest.xml中通過android:theme為Application元素或者Activity元素指定的主題。當然,只有Activity才需要主題,Service是不需要主題的,因為Service是沒有界面的后臺場景,所以Service直接繼承于ContextWrapper,Application同理。而ContextImpl類則真正實現了Context中的所以函數,應用程序中所調用的各種Context類的方法,其實現均來自于該類。一句話總結:Context的兩個子類分工明確,其中ContextImpl是Context的具體實現類,ContextWrapper是Context的包裝類。Activity,Application,Service雖都繼承自ContextWrapper(Activity繼承自ContextWrapper的子類ContextThemeWrapper),但它們初始化的過程中都會創建ContextImpl對象,由ContextImpl實現Context中的方法。

一個應用程序有幾個Context

其實這個問題本身并沒有什么意義,關鍵還是在于對Context的理解,從上面的關系圖我們已經可以得出答案了,在應用程序中Context的具體實現子類就是:Activity,Service,Application。那么Context數量=Activity數量+Service數量+1。當然如果你足夠細心,可能會有疑問:我們常說四大組件,這里怎么只有Activity,Service持有Context,那Broadcast Receiver,Content Provider呢?Broadcast Receiver,Content Provider并不是Context的子類,他們所持有的Context都是其他地方傳過去的,所以并不計入Context總數。上面的關系圖也從另外一個側面告訴我們Context類在整個Android系統中的地位是多么的崇高,因為很顯然Activity,Service,Application都是其子類,其地位和作用不言而喻。

Context能干什么

Context到底可以實現哪些功能呢?這個就實在是太多了,彈出Toast、啟動Activity、啟動Service、發送廣播、操作數據庫等等都需要用到Context。

TextView tv = new TextView(getContext());

ListAdapter adapter = new SimpleCursorAdapter(getApplicationContext(), ...);

AudioManager am = (AudioManager) getContext().
                       getSystemService(Context.AUDIO_SERVICE);
getApplicationContext().getSharedPreferences(name, mode); getApplicationContext().getContentResolver().query(uri, ...); getContext().getResources().getDisplayMetrics().widthPixels * 5 / 8; getContext().startActivity(intent); getContext().startService(intent); getContext().sendBroadcast(intent);

Context作用域

雖然Context神通廣大,但并不是隨便拿到一個Context實例就可以為所欲為,它的使用還是有一些規則限制的。由于Context的具體實例是由ContextImpl類去實現的,因此在絕大多數場景下,Activity、Service和Application這三種類型的Context都是可以通用的。不過有幾種場景比較特殊,比如啟動Activity,還有彈出Dialog。出于安全原因的考慮,Android是不允許Activity或Dialog憑空出現的,一個Activity的啟動必須要建立在另一個Activity的基礎之上,也就是以此形成的返回棧。而Dialog則必須在一個Activity上面彈出(除非是System Alert類型的Dialog),因此在這種場景下,我們只能使用Activity類型的Context,否則將會出錯。



從上圖我們可以發現Activity所持有的Context的作用域最廣,無所不能。因為Activity繼承自ContextThemeWrapper,而Application和Service繼承自ContextWrapper,很顯然ContextThemeWrapper在ContextWrapper的基礎上又做了一些操作使得Activity變得更強大,這里我就不再貼源碼給大家分析了,有興趣的童鞋可以自己查查源碼。上圖中的YES和NO我也不再做過多的解釋了,這里我說一下上圖中Application和Service所不推薦的兩種使用情況。

1:如果我們用ApplicationContext去啟動一個LaunchMode為standard的Activity的時候會報錯android.util.AndroidRuntimeException: Calling startActivity from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?這是因為非Activity類型的Context并沒有所謂的任務棧,所以待啟動的Activity就找不到棧了。解決這個問題的方法就是為待啟動的Activity指定FLAG_ACTIVITY_NEW_TASK標記位,這樣啟動的時候就為它創建一個新的任務棧,而此時Activity是以singleTask模式啟動的。所有這種用Application啟動Activity的方式不推薦使用,Service同Application。

2:在Application和Service中去layout inflate也是合法的,但是會使用系統默認的主題樣式,如果你自定義了某些樣式可能不會被使用。所以這種方式也不推薦使用。

一句話總結:凡是跟UI相關的,都應該使用Activity做為Context來處理;其他的一些操作,Service,Activity,Application等實例都可以,當然了,注意Context引用的持有,防止內存泄漏。

如何獲取Context

通常我們想要獲取Context對象,主要有以下四種方法

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也可以。

getApplication()和getApplicationContext()

上面說到獲取當前Application對象用getApplicationContext,不知道你有沒有聯想到getApplication(),這兩個方法有什么區別?相信這個問題會難倒不少開發者。



程序是不會騙人的,我們通過上面的代碼,打印得出兩者的內存地址都是相同的,看來它們是同一個對象。其實這個結果也很好理解,因為前面已經說過了,Application本身就是一個Context,所以這里獲取getApplicationContext()得到的結果就是Application本身的實例。那么問題來了,既然這兩個方法得到的結果都是相同的,那么Android為什么要提供兩個功能重復的方法呢?實際上這兩個方法在作用域上有比較大的區別。getApplication()方法的語義性非常強,一看就知道是用來獲取Application實例的,但是這個方法只有在Activity和Service中才能調用的到。那么也許在絕大多數情況下我們都是在Activity或者Service中使用Application的,但是如果在一些其它的場景,比如BroadcastReceiver中也想獲得Application的實例,這時就可以借助getApplicationContext()方法了。

publicclassMyReceiverextendsBroadcastReceiver{
   @Override
   publicvoidonReceive(Contextcontext,Intentintent){
       Application myApp =
           (Application)context.getApplicationContext();    } }

Context引起的內存泄露

但Context并不能隨便亂用,用的不好有可能會引起內存泄露的問題,下面就示例兩種錯誤的引用方式。

錯誤的單例模式

public class Singleton {    
   private static Singleton instance;    
   private Context mContext;  
     
   private Singleton(Context context) {        
       this.mContext = context;    }    
       
   public static Singleton getInstance(Context context) {      
       if (instance == null) {             instance = new Singleton(context);        }      
       return instance;    } }

這是一個非線程安全的單例模式,instance作為靜態對象,其生命周期要長于普通的對象,其中也包含Activity,假如Activity A去getInstance獲得instance對象,傳入this,常駐內存的Singleton保存了你傳入的Activity A對象,并一直持有,即使Activity被銷毀掉,但因為它的引用還存在于一個Singleton中,就不可能被GC掉,這樣就導致了內存泄漏。

View持有Activity引用

public class MainActivity extends Activity {
    private static Drawable mDrawable; 
   
   @Override    protected void onCreate(Bundle saveInstanceState) {        
       super.onCreate(saveInstanceState);        setContentView(R.layout.activity_main);        
       ImageView iv = new ImageView(this);        mDrawable = getResources().getDrawable(R.drawable.ic_launcher);        iv.setImageDrawable(mDrawable);    } }

有一個靜態的Drawable對象當ImageView設置這個Drawable時,ImageView保存了mDrawable的引用,而ImageView傳入的this是MainActivity的mContext,因為被static修飾的mDrawable是常駐內存的,MainActivity是它的間接引用,MainActivity被銷毀時,也不能被GC掉,所以造成內存泄漏。

正確使用Context

一般Context造成的內存泄漏,幾乎都是當Context銷毀的時候,卻因為被引用導致銷毀失敗,而Application的Context對象可以理解為隨著進程存在的,所以我們總結出使用Context的正確姿勢:
1:當Application的Context能搞定的情況下,并且生命周期長的對象,優先使用Application的Context。
2:不要讓生命周期長于Activity的對象持有到Activity的引用。
3:盡量不要在Activity中使用非靜態內部類,因為非靜態內部類會隱式持有外部類實例的引用,如果使用靜態內部類,將外部實例引用作為弱引用持有。

總結

總之Context在Android系統中的地位很重要,它幾乎無所不能,但它也不是你想用就能隨便用的,謹防使用不當引起的內存問題。

來源:微信公眾號

上一篇: 50個安卓開發者應該熟悉的Android Studio技巧和資源

下一篇: WebP 原理和 Android 支持現狀介紹

分享到: 更多
pk10模拟投注安卓版 太子中心特中特 两张扑克牌比大小技巧 云南时时的台子 七乐彩app下载 pk拾计划软件手机版免费 3d直选和单选有什么不同 幸运飞艇计划app苹果 抢庄牌九怎么玩 抢庄牛牛可以开挂吗 体育比分及时比分 百人斗龙虎现金 北京塞车人工一期计划 黑龙江时时开奖视频lm0 重庆时时彩国家不管吗 福建时时平台推荐