Android中Task任務棧的分配，androidtask任務
首先我們來看下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棧（粗體為棧頂組件） |
| 點開Email應用，進入收件匣（Activity A） |
A |
| 選中一封郵件，點擊查看詳情（Activity B） |
AB |
| 點擊回複，開始寫新郵件（Activity C） |
ABC |
| 寫了幾行字，點擊選擇連絡人，進入選擇連絡人介面（Activity D） |
ABCD |
| 選擇好了連絡人，繼續寫郵件 |
ABC |
| 寫好郵件，發送完成，回到原始郵件 |
AB |
| 點擊返回，回到收件匣 |
A |
| 退出Email程式 |
null |
如上表所示，是一個執行個體。從使用者從進入郵箱開始，到回複完成，退出應用整個過程的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屬性.
