androidhandler源碼

Ⅰ android: 關於Handler的Looper.loop()；為什麼休眠一段時間後，Handler接收不到消息了。。。求高手

把handleMessage 放到 run里試試
new Handler(
@Override

public boolean handleMessage(Message mGRCMessage) {
//...
}
}

Ⅱ android message傳遞數據到handler的問題

第一種思想是推薦使用的，任何函數在調用的時候，涉及到傳遞參數，都會降低效率。根據message的源碼setData(Bundle data)它的注釋：
Sets a Bundle of arbitrary data values. Use arg1 and arg1 members as a lower cost way to send a few simple integer values, if you can.意思是說，盡量使用arg1和arg2傳遞整型數據，降低開銷（lower cost）。因此你的第二種想法完全就是多此一舉，因為Handler的設計思想就是通知主線程更新數據，用最小的開銷去通知。

Ⅲ 有關Android的Handler的post方法

我們都知道Handler中的post方法，並且也是經常使用它
handler.post(new Runnable(){
@Override
public void run() {
//do something

}});
用它可以更新一個組件的內容，我們也知道Hanlder中也有一個handler.sendMessage(Message msg)方法，這兩個方法有什麼區別呢？先看一下Message類中定義一個私有的變數：Runnable callback;
再來看一下handler.post(Runnable callback)方法的源碼:
public final boolean post(Runnable r) {
return sendMessageDelayed(getPostMessage(r), 0);
}

再看一下sendMessageDelayed的源碼:
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

這裡面有個關鍵就是方法getPostMessage(r)這個方法，他將Runnable轉成一個Message，他內部到底幹了什麼呢？看一下他的源碼:
private final Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}

這裡面就是將Runnable轉化成一個Message，其他看他的代碼很簡單，就是先獲取一個空消息Message.obtain(),然後將Message中的callback的值設置成Runnable，這時候就了解到了Message中的callback的作用了！
同時也了解一下View.post(Runnable r)方法的作用：看一下實例代碼:
final Button btn = (Button)findViewById(R.id.btn);
btn.post(new Runnable(){
@Override
public void run() {
btn.setText("不是好人");
}
});
}

上面的代碼就是更新btn中的內容，同樣下面的代碼也可以達到這種效果:
Handler handler = new Handler();
final Button btn = (Button)findViewById(R.id.btn);
handler.post(new Runnable(){
@Override
public void run() {
btn.setText("不是好人");
}
});
}

不同是這個是用handler.post方法，一個是用View.post方法，現在來看一下View.post方法的源代碼:
public boolean post(Runnable action) {
Handler handler;
AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
handler = attachInfo.mHandler;
} else {
// Assume that post will succeed later
ViewRootImpl.getRunQueue().post(action);
return true;
}
return handler.post(action);
}

方法中主要的功能代碼就是attachInfo.mHandler,獲取當前線程的hanlder，和我們在一個線程中定義一個Handler的效果是一樣的。

Ⅳ Android Message和obtainMessage的區別

obtainMessage會比較快
原因是obtainMessage獲得的Message 不是new出來的,而是從MessagePool 拿的,省去了創建對象申請內存的開銷。
盡管Message的構造器是公開的，但是獲取Message對象的最好方法是調用Message.obtain()或者Handler.obtainMessage(), 這樣是從一個可回收對象池中獲取Message對象。

Ⅳ Android Handler機制 怎麼用

Handler對象與其調用者在同一線程中，如果在Handler中設置了延時操作，則調用線程也會堵塞。每個Handler對象都會綁定一個Looper對象，每個Looper對象對應一個消息隊列（MessageQueue）。如果在創建Handler時不指定與其綁定的Looper對象，系統默認會將當前線程的Looper綁定到該Handler上。
在主線程中，可以直接使用new Handler()創建Handler對象，其將自動與主線程的Looper對象綁定；在非主線程中直接這樣創建Handler則會報錯，因為Android系統默認情況下非主線程中沒有開啟Looper，而Handler對象必須綁定Looper對象。這種情況下，需先在該線程中手動開啟Looper（Looper.prepare()-->Looper.loop()），然後將其綁定到Handler對象上；或者通過Looper.getMainLooper()，獲得主線程的Looper，將其綁定到此Handler對象上。
Handler發送的消息都會加入到Looper的MessageQueue中。一說Handler包含兩個隊列：線程隊列和消息隊列；使用Handler.post()可以將線程對象加入到線程隊列中；使用Handler.sendMessage()可以將消息對象加入到消息隊列中。通過源碼分析證實，Handler只有一個消息隊列，即MessageQueue。通過post()傳進去的線程對象將會被封裝成消息對象後傳入MessageQueue。
使用post()將線程對象放到消息隊列中後，當Looper輪詢到該線程執行時，實際上並不會單獨開啟一個新線程，而仍然在當前Looper綁定的線程中執行，Handler只是調用了該線程對象的run()而已。如，在子線程中定義了更新UI的指令，若直接開啟將該線程執行，則會報錯；而通過post()將其加入到主線程的Looper中並執行，就可以實現UI的更新。
使用sendMessage()將消息對象加入到消息隊列後，當Looper輪詢到該消息時，就會調用Handler的handleMessage()來對其進行處理。再以更新UI為例，使用這種方法的話，就先將主線程的Looper綁定在Handler對象上，重載handleMessage()來處理UI更新，然後向其發送消息就可以了。

Ⅵ android中handler和service的區別是什麼

任務、進程和線程
關於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只能啟動後台，屬於應用組件之一

Ⅶ android中handler.post();和view.post();有經驗的開發者受累解答下~~~

AsyncTask 分前台任務和後台任務, 後台任務是通過線程池實現的, 運行時你可以通過ddms查看

handler 處理方式很單一, 就是個消息處理. 處理線程是調用loop()方法的那條.
就想了這么多了...

Ⅷ Android--Handler創建的問題

/**
*{@linkLooper}forthe
*currentthread.
*
*,thishandlerwon'tbeabletoreceivemessages
*soanexceptionisthrown.
*/
publicHandler(){
this(null,false);
}

貼一下Handler默認構造方法的源碼吧，方法注釋的意思是：默認構造方法把Handler和當前線程的Looper關聯起來。

再看你的代碼，Handler初始化的地方是在thread內部，當前線程是mThread，所以關聯的是mThread的Looper而不是UI線程的Looper

Ⅸ Android中Handler的post和sendMessage的區別

看源碼 根據參數的不同互相調用 public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); } /** * Sends a Message containing only the what value. * * @return Returns true if the message was successfully placed in to the * message queue. Returns false on failure, usually because the * looper processing the message queue is exiting. */ public final boolean sendEmptyMessage(int what) { return sendEmptyMessageDelayed(what, 0); }

Ⅹ Android在子線程用handler發送的消息，主線程是怎麼loop到的

因為你是在主線程創建的handler實例，比如你是這樣實例化handler
那麼我們進到handler源碼看一下
可以看到這里會調用重載的另外一個構造方法，我們再跟進
我們可以看到
mLooper=looper.myLooper();
這是獲取當前線程的looper實例，也就是主線程的looper。所以當發送消息的時候主線程就可以獲取到消息。往下看系統還會mLooper是否為空，如果為空就會拋出異常，意思是當前線程沒有looper實例，這也是我們在子線程中沒有創建looper的實例的時候創建handler會報錯的原因，主線程不會報錯是因為程序在啟動的時候在activitythread中的main方法就創建了looper實例，看系統源碼
然後調用looper.loop()；就開始了消息循環。這就是為什麼在主線程發消息住線程還能收到消息的原因。因為發送消息的實例是在主線程實例化的就有了主線程的looper。