Android任務,進程和線程

任務、進程和線程
關於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這個龐然大物了。