首先我們來看下Task的定義，Google是這樣定義Task的：a task is what the user experiences as an “application.” It’s a group of related activities, arranged in a stack. A task is a stack of activities, not a class or an element in the manifest file. 這意思就是說Task實際上是一個Activity棧，通常用戶感受的一個Application就是一個Task。從這個定義來看，Task跟Service或者其他Components是沒有任何聯繫的，它只是針對Activity而言的。
Activity有不同的啓動模式, 可以影響到task的分配
Task，簡單的說，就是一組以棧的模式聚集在一起的Activity組件集合。它們有潛在的前後驅動關聯，新加入的Activity組件，位於棧頂，並僅有在棧頂的Activity，纔會有機會與用戶進行交互。而當棧頂的Activity完成使命退出的時候，Task會將其退棧，並讓下一個將跑到棧頂的Activity來於用戶面對面，直至棧中再無更多Activity，Task結束。
如上表所示，是一個實例。從用戶從進入郵箱開始，到回覆完成，退出應用整個過程的Task棧變化。這是一個標準的棧模式，對於大部分的狀況，這樣的Task模型，足以應付，但是，涉及到實際的性能、開銷等問題，就會變得殘酷許多。
比如，啓動一個瀏覽器，在Android中是一個比較沉重的過程，它需要做很多初始化的工作，並且會有不小的內存開銷。但與此同時，用瀏覽器打開一些內容，又是一般應用都會有的一個需求。設想一下，如果同時有十個運行着的應用（就會對應着是多個Task），都需要啓動瀏覽器，這將是一個多麼殘酷的場面，十個Task棧都堆積着很雷同的瀏覽器Activity，
是多麼華麗的一種浪費啊。
於是你會有這樣一種設想，瀏覽器Activity，可不可以作爲一個單獨的Task而存在，不管是來自那個Task的請求，瀏覽器的Task，都不會歸並過去。這樣，雖然瀏覽器Activity本身需要維繫的狀態更多了，但整體的開銷將大大的減少，這種舍小家爲大家的行爲，還是很值得歌頌的
standard”, “singleTop”, “singleTask”, “singleInstance”。
standard模式， 是默認的也是標準的Task模式，在沒有其他因素的影響下，使用此模式的Activity，會構造一個Activity的實例，加入到調用者的Task棧中去，對於使用頻度一般開銷一般什麼都一般的Activity而言，standard模式無疑是最合適的，因爲它邏輯簡單條理清晰，所以是默認的選擇。
而singleTop模式，基本上於standard一致，僅在請求的Activity正好位於棧頂時，有所區別。此時，配置成singleTop的Activity，不再會構造新的實例加入到Task棧中，而是將新來的Intent發送到棧頂Activity中，棧頂的Activity可以通過重載onNewIntent來處理新的Intent（當然，也可以無視…）。這個模式，降低了位於棧頂時的一些重複開銷，更避免了一些奇異的行爲（想象一下，如果在棧頂連續幾個都是同樣的Activity，再一級級退出的時候，這是怎麼樣的用戶體驗…），很適合一些會有更新的列表Activity展示。一個活生生的實例是，在Android默認提供的應用中，瀏覽器（Browser）的書籤Activity（BrowserBookmarkPage），就用的是singleTop。
singleTask，和singleInstance，則都採取的另闢Task的蹊徑。
標誌爲singleTask的Activity，最多僅有一個實例存在，並且，位於以它爲根的Task中。所有對該Activity的請求，都會跳到該Activity的Task中展開進行。singleTask，很象概念中的單件模式，所有的修改都是基於一個實例，這通常用在構造成本很大，但切換成本較小的Activity中。最典型的例子，還是瀏覽器應用的主Activity（名爲Browser…），它是展示當前tab，當前頁面內容的窗口。它的構造成本大，但頁面的切換還是較快的，於singleTask相配，還是挺天作之合的。
singleInstance顯得更爲極端一些。在大部分時候singleInstance與singleTask完全一致，唯一的不同在於，singleInstance的Activity，是它所在棧中僅有的一個Activity，如果涉及到的其他Activity，都移交到其他Task中進行。這使得singleInstance的Activity，像一座孤島，徹底的黑盒，它不關注請求來自何方，也不計較後續由誰執行。在Android默認的各個應用中，很少有這樣的Activity，在我個人的工程實踐中，曾嘗試在有道詞典的快速取詞Activity中採用過，
是因爲我覺得快速取詞入口足夠方便（從notification中點選進入），並且會在各個場合使用，應該做得完全獨立。
大的apk 拆成 很多小的apk
●Activity的android:affinity屬性
1.配置後 當啓動這個activity時就先去找有沒有activity的親和力屬性相同 有就加入這個
activity所在的任務中沒有就新開任務
2.affinity起作用需要的條件而者具備一個:
1.intent包含FLAG_ACTIVITY_NEW_TASK標記
2.activity元素啓用了allowTaskReparenting屬性.
