概述

Activity mActivity =new Activity()
作為Android開(kāi)發(fā)者岭辣，不知道你有沒(méi)有思考過(guò)這個(gè)問(wèn)題，Activity可以new嗎饮睬？Android的應(yīng)用程序開(kāi)發(fā)采用JAVA語(yǔ)言现恼，Activity本質(zhì)上也是一個(gè)對(duì)象凛澎，那上面的寫法有什么問(wèn)題呢量九？估計(jì)很多人說(shuō)不清道不明适掰。Android程序不像Java程序一樣颂碧，隨便創(chuàng)建一個(gè)類，寫個(gè)main()方法就能運(yùn)行类浪。 Android應(yīng)用模型是基于組件的應(yīng)用設(shè)計(jì)模式载城，組件的運(yùn)行要有一個(gè)完整的Android工程環(huán)境，在這個(gè)環(huán)境下戚宦，Activity个曙、Service等系統(tǒng)組件才能夠正常工作，而這些組件并不能采用普通的Java對(duì)象創(chuàng)建方式受楼，new一下就能創(chuàng)建實(shí)例了，而是要有它們各自的上下文環(huán)境呼寸，也就是我們這里討論的Context艳汽。可以這樣講对雪，Context是維持Android程序中各組件能夠正常工作的一個(gè)核心功能類河狐。

Context到底是什么？

Context的中文翻譯為：語(yǔ)境; 上下文; 背景; 環(huán)境瑟捣，在開(kāi)發(fā)中我們經(jīng)常說(shuō)稱之為“上下文”馋艺，那么這個(gè)“上下文”到底是指什么意思呢？在語(yǔ)文中迈套，我們可以理解為語(yǔ)境捐祠，結(jié)合語(yǔ)境就能分析出這篇文章的中心思想，在程序中桑李，我們可以理解為當(dāng)前對(duì)象在程序中所處的一個(gè)環(huán)境踱蛀，一個(gè)與系統(tǒng)交互的過(guò)程。比如微信聊天贵白，此時(shí)的“環(huán)境”是指聊天的界面以及相關(guān)的數(shù)據(jù)請(qǐng)求與傳輸率拒，Context在加載資源、啟動(dòng)Activity禁荒、獲取系統(tǒng)服務(wù)猬膨、創(chuàng)建View等操作都要參與。那Context到底是什么呢呛伴？一個(gè)Activity就是一個(gè)Context勃痴，一個(gè)Service也是一個(gè)Context。Android程序員把“場(chǎng)景”抽象為Context類磷蜀，他們認(rèn)為用戶和操作系統(tǒng)的每一次交互都是一個(gè)場(chǎng)景召耘，比如打電話、發(fā)短信褐隆，這些都是一個(gè)有界面的場(chǎng)景污它，還有一些沒(méi)有界面的場(chǎng)景，比如后臺(tái)運(yùn)行的服務(wù)（Service）。一個(gè)應(yīng)用程序可以認(rèn)為是一個(gè)工作環(huán)境衫贬，用戶在這個(gè)環(huán)境中會(huì)切換到不同的場(chǎng)景德澈，這就像一個(gè)前臺(tái)秘書，她可能需要接待客人固惯，可能要打印文件梆造，還可能要接聽(tīng)客戶電話，而這些就稱之為不同的場(chǎng)景葬毫，前臺(tái)秘書可以稱之為一個(gè)應(yīng)用程序镇辉。

如何生動(dòng)形象的理解Context

上面的概念中采用了通俗的理解方式，將Context理解為“上下文”或者“場(chǎng)景”贴捡，如果你仍然覺(jué)得很抽象忽肛，不好理解。在這里我給出一個(gè)可能不是很恰當(dāng)?shù)谋扔骼谜Ｍ兄诖蠹业睦斫猓阂粋€(gè)Android應(yīng)用程序屹逛，可以理解為一部電影或者一部電視劇，Activity汛骂，Service罕模，Broadcast Receiver，Content Provider這四大組件就好比是這部戲里的四個(gè)主角：胡歌帘瞭，霍建華淑掌，詩(shī)詩(shī)，Baby图张。他們是由劇組（系統(tǒng)）一開(kāi)始就定好了的锋拖，整部戲就是由這四位主演領(lǐng)銜擔(dān)綱的，所以這四位主角并不是大街上隨隨便便拉個(gè)人（new 一個(gè)對(duì)象）都能演的祸轮。有了演員當(dāng)然也得有攝像機(jī)拍攝啊兽埃，他們必須通過(guò)鏡頭（Context）才能將戲傳遞給觀眾，這也就正對(duì)應(yīng)說(shuō)四大組件（四位主角）必須工作在Context環(huán)境下（攝像機(jī)鏡頭）适袜。那Button柄错，TextView，LinearLayout這些控件呢苦酱，就好比是這部戲里的配角或者說(shuō)群眾演員售貌，他們顯然沒(méi)有這么重用，隨便一個(gè)路人甲路人乙都能演（可以new一個(gè)對(duì)象）疫萤，但是他們也必須要面對(duì)鏡頭（工作在Context環(huán)境下）颂跨，所以Button mButton=new Button（Context）是可以的。雖然不很恰當(dāng)扯饶，但還是很容易理解的恒削，希望有幫助池颈。

Context源碼中

public abstract class Context {
public static final int MODE_PRIVATE = 0x0000;

public static final int MODE_WORLD_WRITEABLE = 0x0002;

public static final int MODE_APPEND = 0x8000;

public static final int MODE_MULTI_PROCESS = 0x0004;

......
......
......
}

源碼中的注釋是這么來(lái)解釋Context的：Context提供了關(guān)于應(yīng)用環(huán)境全局信息的接口。它是一個(gè)抽象類钓丰，它的執(zhí)行被Android系統(tǒng)所提供躯砰。它允許獲取以應(yīng)用為特征的資源和類型，是一個(gè)統(tǒng)領(lǐng)一些資源（應(yīng)用程序環(huán)境變量等）的上下文携丁。就是說(shuō)琢歇，它描述一個(gè)應(yīng)用程序環(huán)境的信息（即上下文）；是一個(gè)抽象類梦鉴，Android提供了該抽象類的具體實(shí)現(xiàn)類李茫；通過(guò)它我們可以獲取應(yīng)用程序的資源和類（包括應(yīng)用級(jí)別操作，如啟動(dòng)Activity尚揣，發(fā)廣播涌矢，接受Intent等）。既然上面Context是一個(gè)抽象類快骗，那么肯定有他的實(shí)現(xiàn)類咯，我們?cè)贑ontext的源碼中通過(guò)IDE可以查看到他的子類最終可以得到如下關(guān)系圖：

Context_image.png

Context類本身是一個(gè)純abstract類塔次，它有兩個(gè)具體的實(shí)現(xiàn)子類：ContextImpl和ContextWrapper方篮。其中ContextWrapper類，如其名所言励负，這只是一個(gè)包裝而已藕溅，ContextWrapper構(gòu)造函數(shù)中必須包含一個(gè)真正的Context引用，同時(shí)ContextWrapper中提供了attachBaseContext（）用于給ContextWrapper對(duì)象中指定真正的Context對(duì)象继榆，調(diào)用ContextWrapper的方法都會(huì)被轉(zhuǎn)向其所包含的真正的Context對(duì)象巾表。ContextThemeWrapper類，如其名所言略吨，其內(nèi)部包含了與主題（Theme）相關(guān)的接口集币，這里所說(shuō)的主題就是指在AndroidManifest.xml中通過(guò)android：theme為Application元素或者Activity元素指定的主題。當(dāng)然翠忠，只有Activity才需要主題鞠苟，Service是不需要主題的，因?yàn)镾ervice是沒(méi)有界面的后臺(tái)場(chǎng)景秽之，所以Service直接繼承于ContextWrapper当娱，Application同理。而ContextImpl類則真正實(shí)現(xiàn)了Context中的所以函數(shù)考榨，應(yīng)用程序中所調(diào)用的各種Context類的方法跨细，其實(shí)現(xiàn)均來(lái)自于該類，ContextImpl在IDE中時(shí)找不到的河质，這是屬于保護(hù)文件在frameworks\base\core\java\android\app目錄中冀惭。一句話總結(jié)：Context的兩個(gè)子類分工明確震叙，其中ContextImpl是Context的具體實(shí)現(xiàn)類，ContextWrapper是Context的包裝類云头。Activity捐友，Application，Service雖都繼承自ContextWrapper（Activity繼承自ContextWrapper的子類ContextThemeWrapper）溃槐，但它們初始化的過(guò)程中都會(huì)創(chuàng)建ContextImpl對(duì)象匣砖，由ContextImpl實(shí)現(xiàn)Context中的方法。

一個(gè)應(yīng)用程序有幾個(gè)Context昏滴？

其實(shí)這個(gè)問(wèn)題本身并沒(méi)有什么意義猴鲫，關(guān)鍵還是在于對(duì)Context的理解，從上面的關(guān)系圖我們已經(jīng)可以得出答案了谣殊，在應(yīng)用程序中Context的具體實(shí)現(xiàn)子類就是：Activity，Service姻几，Application宜狐。那么Context數(shù)量=Activity數(shù)量+Service數(shù)量+1抚恒。當(dāng)然如果你足夠細(xì)心春贸，可能會(huì)有疑問(wèn)：我們常說(shuō)四大組件萍恕，這里怎么只有Activity，Service持有Context绳姨，那Broadcast Receiver飘庄，Content Provider呢谴仙？Broadcast Receiver，Content Provider并不是Context的子類，他們所持有的Context都是其他地方傳過(guò)去的，所以并不計(jì)入Context總數(shù)二打。上面的關(guān)系圖也從另外一個(gè)側(cè)面告訴我們Context類在整個(gè)Android系統(tǒng)中的地位是多么的崇高装获，因?yàn)楹茱@然Activity走芋，Service肋杖，Application都是其子類，其地位和作用不言而喻。

Context能干什么

Context到底可以實(shí)現(xiàn)哪些功能呢梳庆？這個(gè)就實(shí)在是太多了，彈出Toast、啟動(dòng)Activity、啟動(dòng)Service存哲、發(fā)送廣播、操作數(shù)據(jù)庫(kù)等等都需要用到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神通廣大，但并不是隨便拿到一個(gè)Context實(shí)例就可以為所欲為巢块，它的使用還是有一些規(guī)則限制的。由于Context的具體實(shí)例是由ContextImpl類去實(shí)現(xiàn)的弥姻，因此在絕大多數(shù)場(chǎng)景下，Activity疼电、Service和Application這三種類型的Context都是可以通用的区丑。不過(guò)有幾種場(chǎng)景比較特殊魄鸦，比如啟動(dòng)Activity，還有彈出Dialog庭惜。出于安全原因的考慮，Android是不允許Activity或Dialog憑空出現(xiàn)的判耕，一個(gè)Activity的啟動(dòng)必須要建立在另一個(gè)Activity的基礎(chǔ)之上昌执，也就是以此形成的返回棧煤禽。而Dialog則必須在一個(gè)Activity上面彈出（除非是System Alert類型的Dialog）汁汗，因此在這種場(chǎng)景下，我們只能使用Activity類型的Context忿墅，否則將會(huì)出錯(cuò)。

Context_image.png

從上圖我們可以發(fā)現(xiàn)Activity所持有的Context的作用域最廣棍弄，無(wú)所不能望薄。因?yàn)锳ctivity繼承自ContextThemeWrapper，而Application和Service繼承自ContextWrapper呼畸，很顯然ContextThemeWrapper在ContextWrapper的基礎(chǔ)上又做了一些操作使得Activity變得更強(qiáng)大痕支，這里我就不再貼源碼給大家分析了，有興趣的童鞋可以自己查查源碼蛮原。上圖中的YES和NO我也不再做過(guò)多的解釋了卧须，這里我說(shuō)一下上圖中Application和Service所不推薦的兩種使用情況。
1：如果我們用ApplicationContext去啟動(dòng)一個(gè)LaunchMode為standard的Activity的時(shí)候會(huì)報(bào)錯(cuò)android.util.AndroidRuntimeException: Calling startActivity from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?這是因?yàn)榉茿ctivity類型的Context并沒(méi)有所謂的任務(wù)棧，所以待啟動(dòng)的Activity就找不到棧了花嘶。解決這個(gè)問(wèn)題的方法就是為待啟動(dòng)的Activity指定FLAG_ACTIVITY_NEW_TASK標(biāo)記位笋籽，這樣啟動(dòng)的時(shí)候就為它創(chuàng)建一個(gè)新的任務(wù)棧，而此時(shí)Activity是以singleTask模式啟動(dòng)的察绷。所有這種用Application啟動(dòng)Activity的方式不推薦使用干签，Service同Application。
2：在Application和Service中去layout inflate也是合法的拆撼，但是會(huì)使用系統(tǒng)默認(rèn)的主題樣式容劳，如果你自定義了某些樣式可能不會(huì)被使用。所以這種方式也不推薦使用闸度。
一句話總結(jié)：凡是跟UI相關(guān)的竭贩，都應(yīng)該使用Activity做為Context來(lái)處理；其他的一些操作莺禁，Service,Activity,Application等實(shí)例都可以留量，當(dāng)然了，注意Context引用的持有哟冬，防止內(nèi)存泄漏楼熄。

如何獲取Context

通常我們想要獲取Context對(duì)象，主要有以下四種方法
1：View.getContext,返回當(dāng)前View對(duì)象的Context對(duì)象浩峡，通常是當(dāng)前正在展示的Activity對(duì)象可岂。
2：Activity.getApplicationContext,獲取當(dāng)前Activity所在的(應(yīng)用)進(jìn)程的Context對(duì)象，通常我們使用Context對(duì)象時(shí)翰灾，要優(yōu)先考慮這個(gè)全局的進(jìn)程Context缕粹。
3：ContextWrapper.getBaseContext():用來(lái)獲取一個(gè)ContextWrapper進(jìn)行裝飾之前的Context，可以使用這個(gè)方法纸淮，這個(gè)方法在實(shí)際開(kāi)發(fā)中使用并不多平斩，也不建議使用。
4：Activity.this 返回當(dāng)前的Activity實(shí)例咽块，如果是UI控件需要使用Activity作為Context對(duì)象绘面，但是默認(rèn)的Toast實(shí)際上使用ApplicationContext也可以。

getApplication()和getApplicationContext()

上面說(shuō)到獲取當(dāng)前Application對(duì)象用getApplicationContext侈沪，不知道你有沒(méi)有聯(lián)想到getApplication()飒货，這兩個(gè)方法有什么區(qū)別？相信這個(gè)問(wèn)題會(huì)難倒不少開(kāi)發(fā)者峭竣。

image.png

我們通過(guò)上面的代碼，打印得出兩者的內(nèi)存地址都是相同的晃虫，看來(lái)它們是同一個(gè)對(duì)象皆撩。其實(shí)這個(gè)結(jié)果也很好理解，因?yàn)榍懊嬉呀?jīng)說(shuō)過(guò)了，Application本身就是一個(gè)Context扛吞，所以這里獲取getApplicationContext()得到的結(jié)果就是Application本身的實(shí)例呻惕。那么問(wèn)題來(lái)了，既然這兩個(gè)方法得到的結(jié)果都是相同的滥比，那么Android為什么要提供兩個(gè)功能重復(fù)的方法呢亚脆？實(shí)際上這兩個(gè)方法在作用域上有比較大的區(qū)別。getApplication()方法的語(yǔ)義性非常強(qiáng)盲泛，一看就知道是用來(lái)獲取Application實(shí)例的濒持，但是這個(gè)方法只有在Activity和Service中才能調(diào)用的到。那么也許在絕大多數(shù)情況下我們都是在Activity或者Service中使用Application的寺滚，但是如果在一些其它的場(chǎng)景柑营，比如BroadcastReceiver中也想獲得Application的實(shí)例，這時(shí)就可以借助getApplicationContext()方法了村视。

public class MyReceiver extends BroadcastReceiver{
@Override
public void onReceive(Context context,Intent intent){
ApplicationmyApp=(Application)context.getApplicationContext();
    }
}

Context引起的內(nèi)存泄露

但Context并不能隨便亂用官套，用的不好有可能會(huì)引起內(nèi)存泄露的問(wèn)題，下面就示例兩種錯(cuò)誤的引用方式蚁孔。

錯(cuò)誤的單例模式

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;
    }
}

這是一個(gè)非線程安全的單例模式奶赔，instance作為靜態(tài)對(duì)象，其生命周期要長(zhǎng)于普通的對(duì)象杠氢，其中也包含Activity站刑，假如Activity A去getInstance獲得instance對(duì)象，傳入this修然，常駐內(nèi)存的Singleton保存了你傳入的Activity A對(duì)象笛钝，并一直持有，即使Activity被銷毀掉愕宋，但因?yàn)樗囊眠€存在于一個(gè)Singleton中玻靡，就不可能被GC掉，這樣就導(dǎo)致了內(nèi)存泄漏中贝。

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);
}

有一個(gè)靜態(tài)的Drawable對(duì)象當(dāng)ImageView設(shè)置這個(gè)Drawable時(shí),ImageView會(huì)將自身設(shè)置到Drawable的callback上去,因?yàn)閂iew是實(shí)現(xiàn)了Drawable.Callback接口, 這樣當(dāng)Drawable需要刷新的時(shí)候,可以調(diào)用.這個(gè)Callback,然后通知View重新繪制該Drawable. 所以引用的正確順序應(yīng)該Drawable->View->Context囤捻，因?yàn)楸籹tatic修飾的mDrawable是常駐內(nèi)存的，MainActivity是它的間接引用邻寿，MainActivity被銷毀時(shí)蝎土，也不能被GC掉，所以造成內(nèi)存泄漏绣否。

public void setImageDrawable(@Nullable Drawable drawable) {
    if (mDrawable != drawable) {
        mResource = 0;
        mUri = null;

        final int oldWidth = mDrawableWidth;
        final int oldHeight = mDrawableHeight;

        updateDrawable(drawable);//1

        if (oldWidth != mDrawableWidth || oldHeight != mDrawableHeight) {
            requestLayout();
        }
        invalidate();//2
    }
}

注釋 1： 在ImageView中updateDrawable該方法中 有一個(gè)d.setCallback(this)誊涯，ImageView將自身設(shè)置到Drawable的callback上去，當(dāng)Drawable需要刷新的時(shí)候,可以調(diào)用.這個(gè)Callback,然后通知View重新繪制該Drawable.
注釋 2：重繪

正確使用Context

一般Context造成的內(nèi)存泄漏蒜撮，幾乎都是當(dāng)Context銷毀的時(shí)候暴构，卻因?yàn)楸灰脤?dǎo)致銷毀失敗跪呈，而Application的Context對(duì)象可以理解為隨著進(jìn)程存在的，所以我們總結(jié)出使用Context的正確姿勢(shì)：
1：當(dāng)Application的Context能搞定的情況下取逾，并且生命周期長(zhǎng)的對(duì)象耗绿，優(yōu)先使用Application的Context。
2：不要讓生命周期長(zhǎng)于Activity的對(duì)象持有到Activity的引用砾隅。
3：盡量不要在Activity中使用非靜態(tài)內(nèi)部類误阻，因?yàn)榉庆o態(tài)內(nèi)部類會(huì)隱式持有外部類實(shí)例的引用，如果使用靜態(tài)內(nèi)部類晴埂，將外部實(shí)例引用作為弱引用持有究反。

總結(jié)

總之Context在Android系統(tǒng)中的地位很重要，它幾乎無(wú)所不能邑时，但它也不是你想用就能隨便用的奴紧，謹(jǐn)防使用不當(dāng)引起的內(nèi)存問(wèn)題。