關於Android中的組件和應用，之前涉及，大都是靜態的概念。而當壹個應用運行起來，就難免會需要關心進程、線程這樣的概念。在Android中，組件的動態運行，有壹個最與眾不同的概念，就是Task，翻譯成任務，應該還是比較順理成章的。
Task的介入，最主要的作用，是將組件之間的連接，從進程概念的細節中剝離出來，可以以壹種不同模型的東西進行配置，在很多時候，能夠簡化上層開發人員的理解難度，幫助大家更好的進行開發和配置。
任務
在SDK中關於Task（guide/topics/fundamentals.html#acttask），有壹個很好的比方，說，Task就相當於應用（application）的概念。在開發人員眼中，開發壹個Android程序，是做壹個個獨門獨戶的組件，但對於壹般用戶而言，它們感知到的，只是壹個運行起來的整體應用，這個整體背後，就是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本身需要維系的狀態更多了，但整體的開銷將大大的減少，這種舍小家為大家的行為，還是很值得歌頌的。
如此值得歌頌的行為，Android當然會舉雙手支持的。在Android中，每壹個Activity的Task模式，都是可以由Activity提供方（通過配置文件...）和Activity使用方（通過Intent中的flag信息...）進行配置和選擇。當然，使用方對Activity的控制力，是限定在提供方允許的範疇內進行，提供方明令禁止的模式，使用方是不能夠越界使用的。
在SDK中（guide/topics/fundamentals.html#acttask），將兩者實現Task模式配置的方式，寫的非常清晰了，我再很絮叨挑選壹些來解釋壹下（完整可配置項，壹定要看SDK，下面只是其中常用的若幹項...）。提供方對組件的配置，是通過配置文件（Manifest）<activity>項來進行的，而調用方，則是通過Intent對象的flag進行抉擇的。相對於標準的Task棧的模式，配置的主要方向有兩個：壹則是破壞已有棧的進出規則，或樣式；另壹則是開辟新Task棧完成本應在同壹Task棧中完成的任務。
對於應用開發人員而言，<activity>中的launchMode屬性，是需要經常打交道的。它有四種模式："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。
singleTop模式，雖然破壞了原有棧的邏輯（復用了棧頂，而沒有構造新元素進棧...），但並未開辟專屬的Task。而singleTask，和singleInstance，則都采取的另辟Task的蹊徑。標誌為singleTask的Activity，最多僅有壹個實例存在，並且，位於以它為根的Task中。所有對該Activity的請求，都會跳到該Activity的Task中展開進行。singleTask，很象概念中的單件模式，所有的修改都是基於壹個實例，這通常用在構造成本很大，但切換成本較小的Activity中。在Android源碼提供的應用中，該模式被廣泛的采用，最典型的例子，還是瀏覽器應用的主Activity（名為Browser...），它是展示當前tab，當前頁面內容的窗口。它的構造成本大，但頁面的切換還是較快的，於 singleTask相配，還是挺天作之合的。
相比之下，singleInstance顯得更為極端壹些。在大部分時候singleInstance與singleTask完全壹致，唯壹的不同在於，singleInstance的Activity，是它所在棧中僅有的壹個Activity，如果涉及到的其他Activity，都移交到其他Task中進行。這使得singleInstance的Activity，像壹座孤島，徹底的黑盒，它不關註請求來自何方，也不計較後續由誰執行。在Android默認的各個應用中，很少有這樣的Activity，在我個人的工程實踐中，曾嘗試在有道詞典的快速取詞Activity中采用過，是因為我覺得快速取詞入口足夠方便（從notification中點選進入），並且會在各個場合使用，應該做得完全獨立。
除了launchMode可以用來調配Task，<activity>的另壹屬性taskAffinity，也是常常被使用。taskAffinity，是壹種物以類聚的思想，它傾向於將taskAffinity屬性相同的Activity，扔進同壹個Task中。不過，它的約束力，較之launchMode而言，弱了許多。只有當<activity>中的allowTaskReparen ting設置為true，抑或是調用方將Intent的flag添加FLAG_ACTIVITY_NEW_TASK屬性時才會生效。如果有機會用到Android的Notification機制就能夠知道，每壹個由notification進行觸發的Activity，都必須是壹個設成FLAG_ACTIVITY_NEW_TASK的Intent來調用。這時候，開發者很可能需要妥善配置taskAffinity屬性，使得調用起來的Activity，能夠找到組織，在同壹taskAffinity的Task中進行運行。
進程
在大多數其他平臺的開發中，每個開發人員對自己應用的進程模型都有非常清晰的了解。比如，壹個控制臺程序，妳可以想見它從main函數開始啟動壹個進程，到 main函數結束，進程執行完成退出；在UI程序中，往往是有壹個消息循環在跑，當接受到Exit消息後，退出消息循環結束進程。在該程序運行過程中，啟動了什麽進程，和第三方進程進行通信等等操作，每個開發者都是心如明鏡壹本帳算得清清楚楚。進程邊界，在這裏，猶如國界壹般，每壹次穿越都會留下深深的印跡。
在Android程序中，開發人員可以直接感知的，往往是Task而已。倍感清晰的，是組件邊界，而進程邊界變得難以琢磨，甚至有了進程托管壹說。Android中不但剝奪了手工鍛造內存權力，連手工處置進程的權責，也毫不猶豫的獨占了。
當然，Android隱藏進程細節，並不是刻意為之，而是自然而然水到渠成的。如果，我們把傳統的應用稱為面向進程的開發，那麽，在Android中，我們做得就是面向組件的開發。從前面的內容可以知道，Android組件間的跳轉和通信，都是在第三方介入的前提下進行，正由於這種介入，使得兩個組件壹般不會直接發生聯系（於Service的通信，是不需要第三方介入的，因此Android把它全部假設成為穿越進程邊界，統壹基於RPC來通信，這樣，也是為了掩蓋進程細節...），其中是否穿越進程邊界也就變得不重要。因此，如果這時候，還需要開發者關註進程，就會變得很奇怪，很費解，幹脆，Android將所有的進程壹並托管去了，上層無須知道進程的生死和通信細節。
在Android的底層，進程構造了底部的壹個運行池，不僅僅是Task中的各個Activity組件，其他三大組件Service、Content Provider、Broadcast Receiver，都是寄宿在底層某個進程中，進行運轉。在這裏，進程更像壹個資源池（概念形如線程池，上層要用的時候取壹個出來就好，而不關註具體取了哪壹個...），只是為了承載各個組件的運行，而各個組件直接的邏輯關系，它們並不關心。但我們可以想象，為了保證整體性，在默認情況下，Android肯定傾向於將同壹Task、同壹應用的各個組件扔進同壹個進程內，但是當然，出於效率考慮，Android也是允許開發者進行配置。
在Android中，整體的<application>（將影響其中各個組件...）和底下各個組件，都可以設置<process>屬性，相同<process>屬性的組件將扔到同壹個進程中運行。最常見的使用場景，是通過配置<application>的process屬性，將不同的相關應用，塞進壹個進程，使得它們可以同生***死。還有就是將經常和某個Service組件進行通信的組件，放入同壹個進程，因為與Service通信是個密集操作，走的是RPC，開銷不小，通過配置，可以變成進程內的直接引用，消耗頗小。
除了通過<process>屬性，不同的組件還有壹些特殊的配置項，以Content Provider為例（通過<provider>項進行配置...）。<provider>項有壹個mutiprocess的屬性，默認值為false，這意味著Content Provider，僅會在提供該組件的應用所在進程構造壹個實例，第三方想使用就需要經由RPC傳輸數據。這種模式，對於構造開銷大，數據傳輸開銷小的場合是非常適用的，並且可能提高緩存的效果。但是，如果是數據傳輸很大，抑或是希望在此提高傳輸的效率，就需要將mutiprocess設置成true，這樣，Content Provider就會在每壹個調用它的進程中構造壹個實例，避免進程通信的開銷。
既然，是Android系統幫助開發人員托管了進程，那麽就需要有壹整套紛繁的算法去執行回收邏輯。Android中各個進程的生死，和運行在其中的各個組件有著密切的聯系，進程們依照其上組件的特點，被排入壹個優先級體系，在需要回收時，從低優先級到高優先級回收。Android進程***分為五類優先級，分別是：Foreground Process, Visible Process, Service Process, Background Process, Empty Process。顧名思義不難看出，這說明，越和用戶操作緊密相連的，越是正與用戶交互的，優先級越高，越難被回收。具體詳情，參見：guide/topics/fundamentals.html#proclife。
有了優先級，還需要有良好的回收時機。回收太早，緩存命中概率低可能引起不斷的創造進程銷毀進程，池的優勢蕩然無存；回收的太晚，整體開銷大，系統運行效率降低，好端端的法拉利可能被糟蹋成壹枚QQ老爺車。Android的進程回收，最重要的是考量內存開銷，以及電量等其他資源狀況，此外每個進程承載的組件數量、單個應用開辟的進程數量等數量指標，也是作為衡量的壹個重要標識。另外，壹些運行時的時間開銷，也被嚴格監控，啟動慢的進程會很被強行kill掉。Android會定時檢查上述參數，也會在壹些很可能發生進程回收的時間點，比如某個組件執行完成後，來做回收的嘗試。
從用戶體驗角度來看，Android的進程機制，會有很可喜的壹面，有的程序啟動速度很慢，但是在資源充沛的前提下，妳反復的退出再使用，則啟動變得極其快速（進程沒死，只是從後臺弄到了前臺），這就是拜進程托管所賜的。當然，可喜的另壹面就是可悲了，Android的托管算法，還時不時的展現其幼稚的壹面，明明用戶已經明顯感覺到操作系統運行速度下降了，打開任務管理器壹看，壹票應用還生龍活虎的跳躍著，必須要手動幫助它們終結生命找到墳墓，這使得任務管理器基本成為Android的裝機必備軟件。
從開發角度上來看，Android這套進程機制，解放了開發者的手腳。開發人員不需要處心積慮的構造壹個後臺進程偷偷默默監聽某個時間，並嘗試用各種各樣的守護手段，把自己的進程鍛造的猶如不死鳥壹輝壹般，進程生死的問題，已經原理了普通開發人員需要管理的範疇內。但同時，於GC和人肉內存管理的爭議壹樣，所有開發人員都不相信算法能比自己做得效率更高更出色。但我壹直堅信壹點，所有效率的優勢都會隨著算法的不斷改良硬件的不斷提升而消失殆盡，只有開發模式的簡潔不會隨時間而有任何變化。
組件生命周期
任何架構上的變化，都會引起上層開發模式的變化，Android的進程模型，雖然使開發者不再需要密切關註進程的創建和銷毀的時機，但仍然需要關註這些時間點對組件的影響。比如，妳可能需要在進程銷毀之前，將寫到內存上的內容，持久化到硬盤上，這就需要關註進程退出前發生的壹些事件。
在Android中，把握這些時間點，就必須了解組件生命周期（Components Lifecycles）。所謂組件的生命在周期，就是在組件在前後臺切換、被用戶創建退出、被系統回收等等事件發生的時候，會有壹些事件通知到對應組件上，開發人員可以選擇性的處理這些事件在對應的時間點上來完成壹些附加工作。
除Content Provider，其他組件都會有生命周期的概念，都需要依照這個模型定時定點處理壹些狀況，全部內容參見：guide/topics/fundamentals.html#lcycles。在這裏，擒賊先擒王，還是拿Activity出來作楷模。
繼續偷圖，來自SDK。壹個自然的Activity生命旅途，從onCreate開始，到onDestroy消亡。但月有陰晴圓缺組件有禍福旦夕，在系統需要的時候且組件位於後臺時，所在的進程隨時可能為國捐軀被回收，這就使得知道切入後臺這個事情也變得很重要。
當組件進入棧頂，與用戶開始交互，會調用onResume函數，類似，當退出棧頂，會有onPause函數被呼喚。onResume和onPause可以處理很多事情，最常規的，就是做壹些文件或設置項的讀寫工作。因為，在該組件不再前臺運行的時候，可能別的組件會需要讀寫同樣壹份文件和設置，如果不再onResume做刷新工作，用的可能就是壹份臟數據了（當然，具體情況，還需要具體分析，如果文件不會被多頭讀寫，可以放到onCreate裏面去做讀工作）。
除了前述切入後臺會被其他組件騷擾的問題，另外，死無定因也是件很可怕的事情。在Android中，組件都有兩種常見的死法，壹種是自然消亡，比如，棧元素ABC，變成AB了，C組件就自然消亡了。這種死發輕如鴻毛，不需要額外關心。但另壹種情況，就是被系統回收，那是死的重如泰山，為國捐軀嘛。
但這種捐軀的死法，對用戶來說，比較費解。想象壹下，壹款遊戲，不能存盤，妳壹直玩啊玩，三天三夜沒合眼，這時候妳mm打來電話鼓勵壹下，妳精神抖擻的準備再接再厲，卻發現妳的遊戲進程，在切入後臺之後，被系統回收了，壹夜回到解放前三天努力成為壹場泡影，妳會不會想殺做遊戲的人，會不會會不會會不會，壹定會嘛。這時候，如果沒有Activity生命周期這碼事，遊戲程序員壹定是被冤死的，成了Android的替罪羊。但是，Android的組件是有生命周期的， 如果真的發生這樣情況，不要猶豫，去殺開發的程序員吧。
為了逃生，程序員們有壹塊免死金牌，那就是Android的state機制。所謂state，就是開發人員將壹些當前運行的狀態信息存放在壹個Bundle對象裏面，這是壹個可序列化鍵值對集合。如果該Activity組件所處的進程需要回收，Android核心會將其上Activity組件的Bundle對象持久化到磁盤上，當用戶回到該Activity時候，系統會重新構造該組件，並將持久化到磁盤上的Bundle對象恢復。有了這樣的持久化的狀態信息，開發人員可以很好的區分具體死法，並有機會的使得死而復生的Activity恢復到死前狀態。開發者應該做的，是通過onSaveInstanceState函數把需要維系的狀態信息（在默認的狀態下，系統控件都會自己保存相關的狀態信息，比如TextView，會保存當前的Text信息，這都不需要開發人員擔心...），寫入到Bundle對象，然後在onRestoreInstanceState函數中讀取並恢復相關信息（onCreate，onStart，也都可以處理...）。
線程
讀取數據，後臺處理，這些猥瑣的夥計，自然少不了線程的參與。在Android核心的調度層面，是不屑於考量線程的，它關註的只有進程，每壹個組件的構造和處理，都是在進程的主線程上做的，這樣可以保證邏輯的足夠簡單。多線程，往往都是開發人員需要做的。
Android的線程，也是通過派生Java的Thread對象，實現Run方法來實現的。但當用戶需要跑壹個具有消息循環的線程的時候，Android有更好的支持，來自於Handler和Looper。Handler做的是消息的傳送和分發，派生其handleMessage函數，可以處理各種收到的消息，和win開發無異。Looper的任務，則是構造循環，等候退出或其他消息的來臨。在Looper的SDK頁面，有壹個消息循環線程實現的標準範例，當然，更為標準的方式也許是構造壹個HandlerThread線程，將它的Looper傳遞給Handler。
在Android中，Content Provider的使用，往往和線程掛鉤，誰讓它和數據相關呢。在前面提到過，Content Provider為了保持更多的靈活性，本身只提供了同步調用的接口，而由於異步對Content Provider進行增刪改查是壹個常做操作，Android通過AsyncQueryHandler對象，提供了異步接口。這是壹個Handler的子類，開發人員可以調用startXXX方法發起操作，通過派生onXXXComplete方法，等待執行完畢後的回調，從而完成整個異步調用的流程，十分的簡約明了。
實現
整個任務、進程管理的核心實現，盡在ActivityManagerService中。上壹篇說到，Intent解析，就是這個ActivityManagerService來負責的，其實，它是壹個很名不副實的類，因為雖然名為Activity的Manager Service，但它管轄的範圍，不只是Activity，還有其他三類組件，和它們所在的進程。
在ActivityManagerService中，有兩類數據結構最為醒目，壹個是ArrayList，另壹個是HashMap。 ActivityManagerService有大量的ArrayList，每壹個組件，會有多個ArrayList來分狀態存放。調度工作，往往就是從壹個ArrayList裏面拿出來，找個方法調壹調，然後扔到另壹個ArrayList裏面去，當這個組件沒對應的ArrayList放著的時候，說明它離死不遠了。HashMap，是因為有組件是需要用名字或Intent信息做定位的，比如Content Provider，它的查找，都是依據Uri，有了HashMap，壹切都順理成章了。
ActivityManagerService用壹些名曰xxxRecord的數據結構，來表達各個存活的組件。於是就有了，HistoryRecord（保存Activity信息的，之所以叫History，是相對Task棧而言的...），ServiceRecord，BroadcastRecord，ContentProviderRecord，TaskRecord，ProcessRecord，等等。
值得註意的，是TaskRecord，我們壹直再說，Task棧這樣的概念，其實，真實的底層，並不會在TaskRecord中，維系壹個Activity 的棧。在ActivityManagerService中，各個任務的Activity，都以HistoryRecord的形式，集中存放在壹個 ArrayList中，每個HistoryRecord，會存放它所在TaskRecord的引用。當有壹個Activity，執行完成，從概念上的 Task棧中退出，Android是通過從當前HistoryRecord位置往前掃描同壹個TaskRecord的HistoryRecord來完成的。這個設計，使得上層很多看上去邏輯很復雜的Task體系，在實現變得很統壹而簡明，值得稱道。
ProcessRecord，是整個進程托管實現的核心，它存放有運行在這個進程上，所有組件的信息，根據這些信息，系統有壹整套的算法來決議如何處置這個進程，如果對回收算法感興趣，可以從ActivityManagerService的trimApplications函數入手來看。
對於開發者來說，去了解這部分實現，主要是可以幫助理解整個進程和任務的概念，如果覺得這塊理解的清晰了，就不用去碰ActivityManagerService這個龐然大物了。
================
這是轉載的 ，感覺比壹樓說的好
=============
壹下是自己的
服務（Service）需要配置 才能使用
線程 使用就不說了
hanler ，是用來進行消息隊列的壹個東東，handler 可以用來更新控件的顯示 ，以及線程之間的通信，
service只能啟動後臺，屬於應用組件之壹