Android的七巧闆Activity之二 Activity的加載模式
版權聲明：原創作品，謝絕轉載！否則将追究法律責任。
在上一文中，我們說過，Activity就相當于一塊塊的七巧闆，每個應用用這一個個七巧闆組合成了美麗的圖畫，并用代碼驗證了每個Activity的生命周期。
那麼，每個應用又是如何将各個Activity組合起來的呢？這就是本文要講的内容。
通常情況下，一個應用有一個Task，這個Task就是為了完成某個工作的一系列Activity的集合。而這些Activity又被組織成了堆棧的形式。
然而，事實上我們的需求遠沒有我們想的那麼簡單。有時候，你可能希望在開啟一個Activity時，重新開啟一個Task；有時你可能希望将已經存在的一個Activity放到棧頂，而不是重新建立一個...
Android為了使我們能夠打破預設的堆棧的先後出的模式，提供了兩個種方式：一種是在AndroidManifest.xml定義Activity時指定它的加載模式，另一種是在用Intent開啟一個Activity時，在Intent中加入标志。如果兩種方式都用了，則後者的優先級更高。
兩種方式的差别在于，前者在于描述自己，向别的Acttivity等聲明你們如何來加載我；而後者則是動态的，指出我要求你（要啟動的Activity）如何來加載。本文的重點在于研究在AndroidManifest.xml中聲明加載模式。
Android為我們定義了四種加載模式，分别是：standard、singleTop、singleTask和singleInstance。
“拿來主義”——standard模式
我們寫一段代碼來測試一下standard加載模式，如下
AndroidManifest.xml裡Activity的設定如下：
<activity android:name=".Activity1"
android:launchMode="standard"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
Activity1的代碼如下：
public class Activity1 extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
/**當點選Activity時，啟動另一個Activity1*/
public boolean onTouchEvent(MotionEvent event) {
Intent intent = new Intent(this, Activity1.class);
startActivity(intent);
return super.onTouchEvent(event);
}
然後我們啟動程式，開啟Activity1，然後點選Acitivity1，啟動另一個Activity1，然後再點選，再點選，再點選... 之後我們點傳回鍵。
發生了什麼事情？沒錯，我們按傳回鍵傳回一個又一個相同的Activity1。
standard是Activity預設的加載模式，這種方式用一個詞來形容的話就是“拿來主義”。使用這種模式的Activity向所有使用它的Task聲明：“我這裡的這種Activity多着呢，誰需要的話我就給誰”。是以當一個Task請求加載這個Activity時，該Task直接執行個體化該Activity，并把它放到棧頂。
是以我們的例子就出現了這樣的堆棧結構（假設我們點選了4次）：
Activity1
我們設想一個情形：我們要做一個圖檔浏覽器，第一個界面是圖檔清單界面（假設為PictureListActivity），第二個界面是浏覽該張圖檔（假設為PictureViewActivity）。在PictureViewActivity中可以startActivity啟動浏覽界面浏覽上一張和下一張。
如果每一張圖檔的浏覽啟動一個PictureViewActivity（當然你可能不是采用這種方式來浏覽上一張和下一張，這裡隻是舉個例子），如果采用standard模式的話，就會出現多個PictureViewActivity在堆棧中堆疊的情形。下面介紹的singleTop便可以解決這個問題。
“拒絕堆疊”——singleTop模式
我們将上面的例子稍加改動，AndroidManifest.xml中Acitivity1的launchMode改為singleTop，Activity1的代碼修改如下：
//Activity1建立時顯示Toast
Toast.makeText(this, "onCreate called!", Toast.LENGTH_SHORT).show();
protected void onNewIntent(Intent intent) {
setTitle("I am Activity1 too, but I called onNewIntent!");
super.onNewIntent(intent);
//點選進入加載Activity1
同樣，我們啟動程式，開啟Activity1，然後點選Acitivity1，啟動另一個Activity1，然後再點選，再點選，再點選... 之後我們點傳回鍵。
結果，Activity1第一次建立時，顯示一個Toast提示，onCreate被調用，當再次點選時，onCreate沒有被調用相反是進入了onNewIntent函數。當按傳回鍵時，直接退出了該應用，可見，堆棧中隻存在一個Acitivity1。
可見，當activity被設定為singleTop的加載模式時，如果堆棧的頂部已經存在了該Activity，那麼，它便不會重新建立，而是調用onNewIntent。如果，該Activity存在，但不是在頂部，那麼該Activity依然要重新建立，請讀者自行驗證。
是以singleTop模式的思想便是“拒絕堆疊”！
以上說的兩種加載模式，Activity均可以執行個體化多次，而下面講的兩個加載模式就隻可以執行個體化一次。
“獨立門戶”——singleTask模式
我們首先測試一下，在本應用内調用singleTask模式的Activity會出現什麼情況。
我們寫兩個Activity（Activity1和Activity2），互相調用，其中Activity1為singleTask模式。AndroidManifest.xml如下：
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity android:name=".Activity1"
android:launchMode="singleTask"
android:label="@string/app_name">
</activity>
<activity android:name=".Activity2">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</application>
兩個Activity的代碼如下：
/**Activity1的代碼*/
private static final String TAG = "Activity1";
Log.e(TAG, "Activity1 onCreate! HashCode=" + this.hashCode() + " TaskId=" + getTaskId());
Log.e(TAG, "Activity1 onNewIntent! HashCode="+ this.hashCode() + " TaskId=" + getTaskId());
protected void onDestroy() {
Log.e("Activity1", "Activity1 onDestroy! HashCode="+this.hashCode()+ "TaskId="+getTaskId());
super.onDestroy();
/**點選進入Activity2*/
Intent intent = new Intent(this, Activity2.class);
/**Activity2的代碼*/
public class Activity2 extends Activity {
private static final String TAG = "Activity2";
protected void onCreate(Bundle savedInstanceState) {
setContentView(R.layout.main2);
Log.e(TAG, "Activity2 onCreated! HashCode=" + this.hashCode() + " TaskId="+getTaskId());
Log.e(TAG, "Activity2 onDestroy! HashCode="+this.hashCode()+" TaskId="+getTaskId());
/**點選進入Activity1*/
從代碼中我們可以看出，每當兩個Activity建立、銷毀以及onNewIntent時，都會列印該Activity的HashCode和所在的Task id。
我們的操作步驟是這樣的，打開應用程式，預設啟動Activity2，點選Activity2，進入Activity1，再點選Activity1進入Activity2，再點選Activity2進入Activity1，然後按傳回鍵，直到傳回到Home。
暈了吧，好寫個順序來形象的表示下：Activity2->Activity1(singleTask)->Activity2->Activity1(singleTask)。^_^
進入Activity2，然後到Activity1，我們看Log資訊為：
03-01 14:50:08.144: ERROR/Activity2(371): Activity2 onCreated! HashCode=1156067168 TaskId=7
03-01 14:50:13.923: ERROR/Activity1(371): Activity1 onCreate! HashCode=1156107384 TaskId=7
我們看到，當本應用啟動singleTask的Activity（Activity1）時，Activity1并沒用另外啟用一個任務。而是在原來的任務中建立了它。
再從Activity1進入Activity2，然後再進入Activity1，這個過程，我們再看log資訊：
03-01 14:53:50.823: ERROR/Activity2(371): Activity2 onCreated! HashCode=1156128904 TaskId=7
03-01 14:53:58.154: ERROR/Activity1(371): Activity1 onNewIntent! HashCode=1156107384 TaskId=7
03-01 14:53:58.394: ERROR/Activity2(371): Activity2 onDestroy! HashCode=1156128904 TaskId=7
從這個Log資訊我們可以得到這個結論：當singleTask模式的Activity啟動時，如果發現在某個Task中已經存在，那麼它會先将該Activity（Activity1）上部的Activity（Activity2）銷毀，然後調用它（Activity1）的onNewIntent函數。
我們下面來研究一下當singleTask的Activity被其他應用調用時的情況。
為了使Activity1能夠被其他應用程式調用，我們在AndroidManifest.xml中加入action，如下：
android:launchMode="singleTask"
<action android:name="com.winuxxan.singleTask" />
<category android:name="android.intent.category.DEFAULT" />
然後我們另外建立一個工程，建立一個Activity在初始化的時候啟動Activity1，代碼如下：
public class MyActivity extends Activity {
Log.e("MyActivity", "TaskId=" + getTaskId());
Intent intent = new Intent("com.winuxxan.singleTask");
我們的操作方法是，MyActivity->Activity1->Activity2->Activity1，之後我們按Home鍵，然後再從Home重新進入MyActivity所在的應用。
首先看MyActivity->Activity1這個過程，我們檢視Log資訊如下：
03-01 15:04:25.784: ERROR/MyActivity(429): TaskId=9
03-01 15:04:26.244: ERROR/Activity1(401): Activity1 onCreate! HashCode=1156107632 TaskId=10
從這個Log資訊我們可以看出：當某個應用調用其他應用裡聲明的singleTask模式的Activity時，它會重新建立一個Task，然後将該Activity執行個體化并壓入堆棧。
接着我們看Activity1和Activity2的互相切換，log資訊如下：
03-01 15:04:47.524: ERROR/Activity2(401): Activity2 onCreated! HashCode=1156128104 TaskId=10
03-01 15:04:50.674: ERROR/Activity1(401): Activity1 onNewIntent! HashCode=1156107632 TaskId=10
03-01 15:04:50.994: ERROR/Activity2(401): Activity2 onDestroy! HashCode=1156128104 TaskId=10
和我們所期望的那樣，如果Activity發現已經存在時，會銷毀其上的Activity，然後調用onNewIntent。
之後，我們按Home鍵，傳回桌面，然後，再次進入該應用，我們神奇的發現，我們進入的是MyActivity界面，taskId為10的所有Activity不知了蹤影！
這是因為，該應用對應的task的id為9，是以，進入後之後MyActivity在該task中，是以最後顯示的是MyActivity。我的以上Activity1的代碼實際上是不好的習慣，因為Activity1很可能會成為一個孤島，是以建議，如果該Activity的類型不是LAUNCHER,最好不要設為singleTask。
那麼singleTask的這些特性有什麼用處？我們舉一個例子，浏覽器就是一個singleTask的例子，啟動一個浏覽器，在Android中是一個比較沉重的過程，它需要做很多初始化的工作，并且會有不小的記憶體開銷。如果有多個應用都來請求打開網頁，那麼系統就不會不堪重負。是以，如果浏覽器采用singleTask模式，如果有多個請求打開網頁的請求，都會在一個Task中響應，這樣就會避免以上的情況。
“孤獨寂寞”——singleInstance模式
我們現在來研究最後一個加載模式，singgleInstance，測試很簡單，我們隻要在singleTask測試的例子中，将Activity1的模式改為singleInstance模式即可。
我們首先進行同一應用内部的測試。
首先Activity2->Activity1，觀察log資訊：
03-01 15:41:59.283: ERROR/Activity2(488): Activity2 onCreated! HashCode=1156067168 TaskId=12
03-01 15:42:04.103: ERROR/Activity1(488): Activity1 onCreate! HashCode=1156107520 TaskId=13
我們發現，當采用singleInstance模式時，啟動時建立了一個新的Task，并将Activity1執行個體化加入到該Task中。
然後我們Activity1->Activity2->Activity1，觀察log資訊：
03-01 15:43:52.214: ERROR/Activity2(488): Activity2 onCreated! HashCode=1156127728 TaskId=12
03-01 15:43:56.804: ERROR/Activity1(488): Activity1 onNewIntent! HashCode=1156107520 TaskId=13
我們通過該log資訊可以得出結論：singleInstance的Activity（Activity1）不允許其他的Activity（Activity2）加入到自己的Task中，它是的内心容不下另一個人，它是一個孤獨寂寞的人。 當Activity1發現已經存在一個Task中包含自己的執行個體時，它會調用自己的onNewIntent。
然後，我們同樣也測試一下，如果其它應用程式調用Activity1會出現什麼樣的情況：
MyActivity->Activity1, 觀察log資訊：
03-01 15:50:21.134: ERROR/MyActivity(556): TaskId=16
03-01 15:50:21.484: ERROR/Activity1(534): Activity1 onCreate! HashCode=1156107344 TaskId=17
不出意料，Activity1重新建立了一個Task，并将自己的執行個體入棧。
Activity1->Activity2->Activity1->Activity2, 我們觀察log資訊：
03-01 15:50:36.484: ERROR/Activity2(534): Activity2 onCreated! HashCode=1156128056 TaskId=18
03-01 15:50:46.114: ERROR/Activity1(534): Activity1 onNewIntent! HashCode=1156107344 TaskId=17
我們從該過程可以看出：如果從其它應用程式調用singleInstance模式的Activity（Activity1），從該Activity開啟其他Activity（Activity2）時，會建立一個新的Task（task id為18的那個），實際上，如果包含該Activity（Activity2）的Task已經運作的話，他會在該運作的Task中重新建立。
OK，上面啰嗦了那麼多，如果這部分不是很清楚的人，可能已經頭昏腦脹了。那我們總結一下吧，這總該看看了吧。
“拿來主義”standard模式。哪裡需要調用我我就去哪裡，可以多次執行個體化，可以幾個相同的Activity重疊。
“拒絕堆疊”singleTop模式。可以多次執行個體化，但是不可以多個相同的Activity重疊，當堆棧的頂部為相同的Activity時，會調用onNewIntent函數。
“獨立門戶”singleTask模式。同一個應用中調用該Activity時，如果該Activity沒有被執行個體化，會在本應用程式的Task内執行個體化，如果已經執行個體化，會将Task中其上的Activity銷毀後，調用onNewIntent；其它應用程式調用該Activity時，如果該Activity沒有被執行個體化，會建立新的Task并執行個體化後入棧，如果已經執行個體化，會銷毀其上的Activity，并調用onNewIntent。一句話，singleTask就是“獨立門戶”，在自己的Task裡，并且啟動時不允許其他Activity淩駕于自己之上。
“孤獨寂寞”singleInstance模式。加載該Activity時如果沒有執行個體化，他會建立新的Task後，執行個體化入棧，如果已經存在，直接調用onNewIntent，該Activity的Task中不允許啟動其它的Activity，任何從該Activity啟動的其他Activity都将被放到其他task中，先檢查是否有本應用的task，沒有的話就建立。
附：由于android文檔中的解釋不是很清楚，是以做了上述測試，結論也是根據測試得出的結論，singleTask和singInstance的任務建立還跟taskAffience有關，我們下次再研究。如果有不對的地方請大家趕快指正，以防影響他人。多謝。