建站
咨詢
售后
建站咨詢
新聞中心
activity的歸屬，也就是Activity應該在哪個Task中，Activity與Task的吸附關(guān)系。我們知道，一般情況下在同一個應用中，啟 動的Activity都在同一個Task中，它們在該Task中度過自己的生命周期，這些Activity是從一而終的好榜樣。
專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)隨縣免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000+企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
那么為什么我們創(chuàng)建的Activity會進入這個Task中？它們會轉(zhuǎn)到其它的Task中嗎？如果轉(zhuǎn)到其它的Task中，它們會到什么樣的Task中去？
解決這些問題的關(guān)鍵，在于每個Activity的taskAffinity屬性。
每個Activity都有taskAffinity屬性，這個屬性指出了它希望進入的Task。如果一個Activity沒有顯式的指明該 Activity的taskAffinity，那么它的這個屬性就等于Application指明的taskAffinity，如果 Application也沒有指明，那么該taskAffinity的值就等于包名。而Task也有自己的affinity屬性，它的值等于它的根 Activity的taskAffinity的值。
一開始，創(chuàng)建的Activity都會在創(chuàng)建它的Task中，并且大部分都在這里度過了它的整個生命。然而有一些情況，創(chuàng)建的Activity會被分配其它 的Task中去，有的甚至，本來在一個Task中，之后出現(xiàn)了轉(zhuǎn)移。我們首先分析一下android文檔給我們介紹的兩種情況。
***種情況。如果該Activity的allowTaskReparenting設(shè)置為true，它進入后臺，當一個和它有相同affinity的Task進入前臺時，它會重新宿主，進入到該前臺的task中。
我們驗證一下這種情況。
Application Activity taskAffinity allowTaskReparenting
application1 Activity1 com.winuxxan.affinity true
application2 Activity2 com.winuxxan.affinity false
我們創(chuàng)建兩個工程，application1和application2，分別含有Activity1和Activity2，它們的taskAffinity相同，Activity1的allowTaskReparenting為true。
首先，我們啟動application1,加載Activity1，然后按Home鍵，使該task（假設(shè)為task1）進入后臺。然后啟動application2，默認加載Activity2。
我們看到了什么現(xiàn)象？沒錯，本來應該是顯示Activity2，但是我們卻看到了Activity1。實際上Activity2也被加載了，只是Activity1重新宿主，所以看到了Activity1。
第二種情況。如果加載某個Activity的intent，F(xiàn)lag被設(shè)置成FLAG_ACTIVITY_NEW_TASK時，它會首先檢查是否存在與自 己taskAffinity相同的Task，如果存在，那么它會直接宿主到該Task中，如果不存在則重新創(chuàng)建Task。
我們來做一個測試。
我們首先寫一個應用，它有兩個Activity（Activity1和Activity2），AndroidManifest.xml如下：
android:taskAffinity="com.winuxxan.task" android:label="@string/app_name">
Activity2的代碼如下：
public class Activity2 extends Activity {
private static final String TAG = "Activity2";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main2);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
Intent intent = new Intent(this, Activity1.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
return super.onTouchEvent(event);
}
}
然后，我們再寫一個應用MyActivity，它包含一個Activity（MyActivity），AndroidManifest.xml如下：
android:taskAffinity="com.winuxxan.task" android:label="@string/app_name">
我們首先啟動MyActivity，然后按Home鍵，返回到桌面，然后打開Activity2，點擊Activity2，進入Activity1。然后按返回鍵。
我們發(fā)現(xiàn)，我們進入Activity的順序為Activity2->Activity1，而返回時順序為 Activity1->MyActivity。這就說明了一個問題，Activity1在啟動時，重新宿主到了MyActivity所在的Task 中去了。
以上是驗證了文檔中提出的兩種TaskAffinity的用法。
下面就是見證奇跡的時刻，同志們，不要眨眼！
我們現(xiàn)在將上一文中的launchMode和本文講的taskAffinity結(jié)合起來。
首先是singleTask加載模式與taskAffinity的結(jié)合。
我們還是用上一文中的singleTask的代碼，這里就不在列出來了，請讀者自己查閱上一文。***不同的就是，我們?yōu)镸yActivity和Activity1設(shè)置成相同的taskAffinity，重新執(zhí)行上文的測試。
我們發(fā)現(xiàn)測試結(jié)果令我們驚訝：從同一應用程序啟動singleTask和不同應用程序啟動的結(jié)果完全與上文講的相反！
我們經(jīng)過思考，就可以把從同一應用程序執(zhí)行和從不同應用程序執(zhí)行另種方式同一起來，得到一個結(jié)論：
當一個應用程序加載一個singleTask模式的Activity時，首先該Activity會檢查是否存在與它的taskAffinity相同的Task。
1、如果存在，那么檢查是否實例化，如果已經(jīng)實例化，那么銷毀在該Activity以上的Activity并調(diào)用onNewIntent。如果沒有實例化，那么該Activity實例化并入棧。
2、如果不存在，那么就重新創(chuàng)建Task，并入棧。
用一個流程來表示：
然后我們來檢測singleInstance模式融入taskAffinity時的情況，我們也是用上文中測試singleInstance的例子，在此 不列出，讀者翻閱前文查閱。***不同的是，我們將MyActivity和Activity2設(shè)置成相同的taskAffinity。
我們發(fā)現(xiàn)測試結(jié)果也有一定的出入，就是，當從singleInstance中啟動Activity時，并沒用重新創(chuàng)建一個Task，而是進入了和它具有相同affinity的MyActivity所在的Task。
于是，我們也能得到以下結(jié)論：
1、當一個應用程序加載一個singleInstance模式的Activity時，如果該Activity沒有被實例化，那么就重新創(chuàng)建一個Task，并入棧，如果已經(jīng)被實例化，那么就調(diào)用該Activity的onNewIntent；
2、singleInstance的Activity所在的Task不允許存在其他Activity，任何從該Activity加載的其它 Actiivty（假設(shè)為Activity2）都會被放入其它的Task中，如果存在與Activity2相同affinity的Task，則在該 Task內(nèi)創(chuàng)建Activity2。如果不存在，則重新生成新的Task并入棧.
當前文章：android的taskAffinity屬性
URL地址：http://www.5511xx.com/article/dhocpdh.html
