Activity的四種加載模式：
standard(默認)
singleTop
singleTask
singleInstance
-
standard
Activity的默認加載方法，即使某個Activity在Task棧中已經(jīng)存在，另一個activity通過Intent跳轉(zhuǎn)到該activity，同樣會新創(chuàng)建一個實例壓入棧中。例如：現(xiàn)在棧的情況為：A B C D，在D這個Activity中通過Intent跳轉(zhuǎn)到D，那么現(xiàn)在的棧情況為： A B C D D 。此時如果棧頂?shù)腄通過Intent跳轉(zhuǎn)到B，則棧情況為：A B C D D B。此時如果依次按返回鍵，D D C B A將會依次彈出棧而顯示在界面上。
-
singleTop
如果某個Activity的Launch mode設(shè)置成singleTop，那么當(dāng)該Activity位于棧頂?shù)臅r候，再通過Intent跳轉(zhuǎn)到本身這個Activity，則將不會創(chuàng)建一個新的實例壓入棧中。例如：現(xiàn)在棧的情況為：A B C D。D的Launch mode設(shè)置成了singleTop，那么在D中啟動Intent跳轉(zhuǎn)到D，那么將不會新創(chuàng)建一個D的實例壓入棧中，此時棧的情況依然為：A B C D。但是如果此時B的模式也是singleTop，D跳轉(zhuǎn)到B，那么則會新建一個B的實例壓入棧中，因為此時B不是位于棧頂，此時棧的情況就變成了：A B C D B。
-
singleTask
如果某個Activity是singleTask模式，那么Task棧中將會只有一個該Activity的實例。例如：現(xiàn)在棧的情況為：A B C D。B的Launch mode為singleTask，此時D通過Intent跳轉(zhuǎn)到B，則棧的情況變成了：A B。而C和D被彈出銷毀了，也就是說位于B之上的實例都被銷毀了。
關(guān)于singleTask這個網(wǎng)上頗有爭議，包括google api上的說明比奇怪，自己用實例親測，終于算是搞清楚了
正解：
- singleTask 并不一定處于棧底
- singleTask 并一定會是棧底的根元素
- singleTask 并不一定會啟動新的task
情況一：如果在本程序中啟動singleTask的activity：假設(shè)ActivityA是程序的入口，是默認的模式（standard）,ActivityB是singleTask 模式，由ActivityA啟動，剛ActivityB不會位于棧底，不是根元素，不會啟動新的task，此種情況ActivityB會和ActivityA在一個棧中，位于ActivityA上面
情況二：如果ActivityB由另外一個程序啟動：假設(shè)apkA是情況一中的應(yīng)用，apkB是測試程序，在apkB中啟動apkA中的ActivityB，剛ActivityB會位于棧底，是根元素，會啟動新的task
其實這歸根到底應(yīng)該是activity的affinity之間的原因，如果將情況一中的activity的affinity改為跟其他不同，也會出現(xiàn)跟情況二一樣的結(jié)果。affinity對于的是元素是 taskAffinity
注意：
singleTask模式的Activity不管是位于棧頂還是棧底，再次運行這個Activity時，都會destory掉它上面的Activity來保證整個棧中只有一個自己
-
singleInstance
將Activity壓入一個新建的任務(wù)棧中。例如：Task棧1的情況為：A B C。C通過Intent跳轉(zhuǎn)到D，而D的Launch mode為singleInstance，則將會新建一個Task棧2。此時Task棧1的情況還是為：A B C。Task棧2的情況為：D。此時屏幕界面顯示D的內(nèi)容，如果這時D又通過Intent跳轉(zhuǎn)到D，則Task棧2中也不會新建一個D的實例，所以兩個棧的情況也不會變化。而如果D跳轉(zhuǎn)到C，則棧1的情況變成了：A B C C，因為C的Launch mode為standard，此時如果再按返回鍵，則棧1變成：A B C。也就是說現(xiàn)在界面還顯示C的內(nèi)容，不是D。就是說現(xiàn)在界面還顯示C的內(nèi)容，不是D。
