android線程通訊

1. android的handler機制的原理

Android的handler機制的原理分為非同步通信准備，消息發送，消息循環，消息處理。

1、非同步通信准備

在主線程中創建處理器對象(Looper)、消息隊列對象(Message Queue)和Handler對象。

2、消息入隊

工作線程通過Handler發送消息(Message) 到消息隊列(Message Queue)中。

3、消息循環

消息出隊: Looper循環取出消息隊列(Message Queue) 中的的消息(Message)。

消息分發: Looper將取出的消息 (Message) 發送給創建該消息的處理者(Handler)。

4、消息處理

處理者(Handler) 接收處理器(Looper) 發送過來的消息(Message)，根據消息(Message) 進行U操作。

handler的作用

handler是android線程之間的消息機制，主要的作用是將一個任務切換到指定的線程中去執行，（准確的說是切換到構成handler的looper所在的線程中去出處理）android系統中的一個例子就是主線程中的所有操作都是通過主線程中的handler去處理的。

Handler的運行需要底層的 messagequeue和 looper做支撐。

2. 22 AndroidBroadcast廣播機制

廣播(Broadcast)機制用於進程/線程間通信，廣播分為廣播發送和廣播接收兩個過程，其中廣播接收者BroadcastReceiver便是Android四大組件之一。

BroadcastReceiver分為兩類：

從廣播發送方式可分為三類：

廣播在系統中以BroadcastRecord對象來記錄, 該對象有幾個時間相關的成員變數.

廣播注冊，對於應用開發來說，往往是在Activity/Service中調用 registerReceiver() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。另外調用getOuterContext()可獲取最外層的調用者Activity或Service。

[ContextImpl.java]

其中broadcastPermission擁有廣播的許可權控制，scheler用於指定接收到廣播時onRecive執行線程，當scheler=null則默認代表在主線程中執行，這也是最常見的用法

[ContextImpl.java]

ActivityManagerNative.getDefault()返回的是ActivityManagerProxy對象，簡稱AMP.
該方法中參數有mMainThread.getApplicationThread()返回的是ApplicationThread，這是Binder的Bn端，用於system_server進程與該進程的通信。

[-> LoadedApk.java]

不妨令 以BroadcastReceiver(廣播接收者)為key，LoadedApk.ReceiverDispatcher(分發者)為value的ArrayMap 記為 A 。此處 mReceivers 是一個以 Context 為key，以 A 為value的ArrayMap。對於ReceiverDispatcher(廣播分發者)，當不存在時則創建一個。

此處mActivityThread便是前面傳遞過來的當前主線程的Handler.

ReceiverDispatcher(廣播分發者)有一個內部類 InnerReceiver ，該類繼承於 IIntentReceiver.Stub 。顯然，這是一個Binder服務端，廣播分發者通過rd.getIIntentReceiver()可獲取該Binder服務端對象 InnerReceiver ，用於Binder IPC通信。

[-> ActivityManagerNative.java]

這里有兩個Binder服務端對象 caller 和 receiver ，都代表執行注冊廣播動作所在的進程. AMP通過Binder驅動將這些信息發送給system_server進程中的AMS對象，接下來進入AMS.registerReceiver。

[-> ActivityManagerService.java]

其中 mRegisteredReceivers 記錄著所有已注冊的廣播，以receiver IBinder為key, ReceiverList為value為HashMap。

在BroadcastQueue中有兩個廣播隊列mParallelBroadcasts,mOrderedBroadcasts，數據類型都為ArrayList<broadcastrecord style="box-sizing: border-box;">：</broadcastrecord>

mLruProcesses數據類型為 ArrayList<ProcessRecord> ，而ProcessRecord對象有一個IApplicationThread欄位，根據該欄位查找出滿足條件的ProcessRecord對象。

該方法用於匹配發起的Intent數據是否匹配成功，匹配項共有4項action, type, data, category，任何一項匹配不成功都會失敗。

broadcastQueueForIntent(Intent intent)通過判斷intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 來決定是前台或後台廣播，進而返回相應的廣播隊列mFgBroadcastQueue或者mBgBroadcastQueue。

注冊廣播：

另外，當注冊的是Sticky廣播：

廣播注冊完, 另一個操作便是在廣播發送過程.

發送廣播是在Activity或Service中調用 sendBroadcast() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。

[ContextImpl.java]

[-> ActivityManagerNative.java]

[-> ActivityManagerService.java]

broadcastIntent()方法有兩個布爾參數serialized和sticky來共同決定是普通廣播，有序廣播，還是Sticky廣播，參數如下：

broadcastIntentLocked方法比較長，這里劃分為8個部分來分別說明。

這個過程最重要的工作是：

BroadcastReceiver還有其他flag，位於Intent.java常量:

主要功能：

這個過主要處於系統相關的10類廣播,這里不就展開講解了.

這個過程主要是將sticky廣播增加到list，並放入mStickyBroadcasts裡面。

其他說明：

AMS.collectReceiverComponents ：

廣播隊列中有一個成員變數 mParallelBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的並行廣播。</broadcastrecord>

動態注冊的registeredReceivers，全部合並都receivers，再統一按串列方式處理。

廣播隊列中有一個成員變數 mOrderedBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的有序廣播。</broadcastrecord>

發送廣播過程:

處理方式：

可見不管哪種廣播方式，都是通過broadcastQueueForIntent()來根據intent的flag來判斷前台隊列或者後台隊列，然後再調用對應廣播隊列的scheleBroadcastsLocked方法來處理廣播；

在發送廣播過程中會執行 scheleBroadcastsLocked 方法來處理相關的廣播

[-> BroadcastQueue.java]

在BroadcastQueue對象創建時，mHandler=new BroadcastHandler(handler.getLooper());那麼此處交由mHandler的handleMessage來處理：

由此可見BroadcastHandler採用的是」ActivityManager」線程的Looper

[-> BroadcastQueue.java]

此處mService為AMS，整個流程還是比較長的，全程持有AMS鎖，所以廣播效率低的情況下，直接會嚴重影響這個手機的性能與流暢度，這里應該考慮細化同步鎖的粒度。

3. Android可以讓主線程在其他子線程執行完後再執行嗎如果可以，該怎麼做

android中什麼時候會選擇用廣播來進行線程間的通信 Android 多線程 通信 線程中通信就不要用廣播了吧 進程中通信可以用廣播或者aidl 可是，這兩天看到的項目都是這么做的；然後，自己分析了下，覺得一下的理由也是可以成立的； 1.正常情況下我們選擇handler消息機制來進行單向的線程間的通信；（工作線程向主線程發送消息） 因為主線程有現成的handler，而工作線程沒有現成的handler，這樣的話，主線程將handler交給工作線程而讓工作線程將工作的結果交給主線程； 相反，工作線程中沒有現成的handler（事實上是沒有消息隊列，也就是handler沒有綁定到工作線程），那麼，如果開辟的話，代碼角度上是挺麻煩的（相對應廣播機制來說）； 2.廣播機制本身就是雙向的（工作線程向主線程發送廣播，主線程向工作線程發送廣播）； //另外，對於像一個activity中通過fragment來進行界面的處理； 我們大多數情況下是採用廣播的機制來實現fragment中adapter的數據的更新；這樣做主要是考慮到工作線程的任務載入完成，而具體的對應刷新的activity可能還沒有啟動； 另外，基於介面隔離原則，如果用handler進行通信的話，則不能很好的滿足這一原則； 你要是周期比較長 用廣播好些吧 應該與周期關系不是很密切。最主要的原因是兩條線成是雙向通信。 Handler類似於P2P的通信。 廣播則類似於一個server端，用來處理分發不同線程的請求，從控制器的角度來說用廣播更好一點。 一般使用Handler的，多用於子線程處理事務，完成時告知主線程這一類的情況。 而類似樓主所說的多條線程之間需要頻繁交互的話，廣播是個很好的選擇，並且結構清晰，只是不知道廣播的性能與handler相比會怎麼樣。

4. 每個Android 都應必須了解的多線程知識點~

進程是系統調度和資源分配的一個獨立單位。

在Android中，一個應用程序就是一個獨立的集成，應用運行在一個獨立的環境中，可以避免其他應用程序/進程的干擾。當我們啟動一個應用程序時，系統就會創建一個進程（該進程是從Zygote中fork出來的，有獨立的ID），接著為這個進程創建一個主線程，然後就可以運行MainActivity了，應用程序的組件默認都是運行在其進程中。開發者可以通過設置應用的組件的運行進程，在清單文件中給組件設置：android:process = "進程名";可以達到讓組件運行在不同進程中的目的。讓組件運行在不同的進程中，既有好處，也有壞處。我們依次的說明下。

好處：每一個應用程序（也就是每一個進程）都會有一個內存預算，所有運行在這個進程中的程序使用的總內存不能超過這個值，讓組件運行不同的進程中，可以讓主進程可以擁有更多的空間資源。當我們的應用程序比較大，需要的內存資源比較多時（也就是用戶會抱怨應用經常出現OutOfMemory時），可以考慮使用多進程。

壞處：每個進程都會有自己的虛擬機實例，因此讓在進程間共享一些數據變得相對困難，需要採用進程間的通信來實現數據的共享。

線程是進程的一個實體，是CPU調度和分派的基本單位，它是比進程更小的能獨立運行的基本單位。

在Android中，線程會有那麼幾種狀態：創建、就緒、運行、阻塞、結束。當應用程序有組件在運行時，UI線程是處於運行狀態的。默認情況下，應用的所有組件的操作都是在UI線程里完成的，包括響應用戶的操作（觸摸，點擊等），組件生命周期方法的調用，UI的更新等。因此如果UI線程處理阻塞狀態時(在線程里做一些耗時的操作，如網路連接等)，就會不能響應各種操作，如果阻塞時間達到5秒，就會讓程序處於ANR（application not response）狀態。

1.線程作用

減少程序在並發執行時所付出的時空開銷，提高操作系統的並發性能。

2.線程分類

守護線程、非守護線程（用戶線程）

2.1 守護線程

定義：守護用戶線程的線程，即在程序運行時為其他線程提供一種通用服務
常見：如垃圾回收線程
設置方式：thread.setDaemon(true);//設置該線程為守護線程

2.2 非守護線程（用戶線程）

主線程 & 子線程。

2.2.1 主線程（UI線程）

定義：Android系統在程序啟動時會自動啟動一條主線程
作用：處理四大組件與用戶進行交互的事情（如UI、界面交互相關）
因為用戶隨時會與界面發生交互，因此主線程任何時候都必須保持很高的響應速度，所以主線程不允許進行耗時操作，否則會出現ANR。

2.2.2 子線程（工作線程）

定義：手動創建的線程
作用：耗時的操作（網路請求、I/O操作等）

2.3 守護線程與非守護線程的區別和聯系

區別：虛擬機是否已退出，即
a. 當所有用戶線程結束時，因為沒有守護的必要，所以守護線程也會終止，虛擬機也同樣退出
b. 反過來，只要任何用戶線程還在運行，守護線程就不會終止，虛擬機就不會退出

3.線程優先順序

3.1 表示

線程優先順序分為10個級別，分別用Thread類常量表示。

3.2 設置

通過方法setPriority(int grade)進行優先順序設置，默認線程優先順序是5，即 Thread.NORM_PRIORITY。

4.線程狀態

創建狀態：當用 new 操作符創建一個線程的時候

就緒狀態：調用 start 方法，處於就緒狀態的線程並不一定馬上就會執行 run 方法，還需要等待CPU的調度

運行狀態：CPU 開始調度線程，並開始執行 run 方法

阻塞（掛起）狀態：線程的執行過程中由於一些原因進入阻塞狀態，比如：調用 sleep/wait 方法、嘗試去得到一個鎖等

結束（消亡）狀態：run 方法執行完 或者 執行過程中遇到了一個異常

（1）start()和run()的區別

通過調用Thread類的start()方法來啟動一個線程，這時此線程是處於就緒狀態，並沒有運行。調用Thread類調用run()方法來完成其運行操作的，方法run()稱為線程體，它包含了要執行的這個線程的內容，run()運行結束，此線程終止，然後CPU再調度其它線程。

（2）sleep()、wait()、yield()的區別

sleep()方法屬於Thread類，wait()方法屬於Object類。
調用sleep()方法，線程不會釋放對象鎖，只是暫停執行指定的時間，會自動恢復運行狀態；調用wait()方法，線程會放棄對象鎖，進入等待此對象的等待鎖定池，不調用notify()方法，線程永遠處於就緒（掛起）狀態。

yield()直接由運行狀態跳回就緒狀態，表示退讓線程，讓出CPU，讓CPU調度器重新調度。禮讓可能成功，也可能不成功，也就是說，回到調度器和其他線程進行公平競爭。

1.Android線程的原則

（1）為什麼不能再主線程中做耗時操作
防止ANR, 不能在UI主線程中做耗時的操作，因此我們可以把耗時的操作放在另一個工作線程中去做。操作完成後，再通知UI主線程做出相應的響應。這就需要掌握線程間通信的方式了。 在Android中提供了兩種線程間的通信方式：一種是AsyncTask機制，另一種是Handler機制。

（2）為什麼不能在非UI線程中更新UI 因為Android的UI線程是非線程安全的，應用更新UI，是調用invalidate()方法來實現界面的重繪，而invalidate()方法是非線程安全的，也就是說當我們在非UI線程來更新UI時，可能會有其他的線程或UI線程也在更新UI，這就會導致界面更新的不同步。因此我們不能在非UI主線程中做更新UI的操作。

2.Android實現多線程的幾種方式

3.為何需要多線程

多線程的本質就是非同步處理，直觀一點說就是不要讓用戶感覺到「很卡」。

4.多線程機制的核心是啥

多線程核心機制是Handler

推薦Handler講解視頻： 面試總被問到Handler？帶你從源碼的角度解讀Handler核心機制

根據上方提到的 多進程、多線程、Handler 問題，我整理了一套 Binder與Handler 機制解析的學習文檔，提供給大家進行學習參考，有需要的可以 點擊這里直接獲取！！！ 裡面記錄許多Android 相關學習知識點。

5. Android通信方式篇（七）-Binder機制（Native層（下））

本篇文章針對向ServiceManager注冊服務 和 獲取服務兩個流程來做總結。在這兩個過程中，ServiceManager都扮演的是服務端，與客戶端之間的通信也是通過Binder IPC。

在此之前先了解下Binder的進程與線程的關系：

用戶空間 :ProcessState描述一個進程，IPCThreadState對應一個進程中的一個線程。
內核空間 ：binder_proc描述一個進程，統一由binder_procs全局鏈表保存，binder_thread對應進程的一個線程。
ProcessState與binder_proc是一一對應的。

Binder線程池 ：每個Server進程在啟動時會創建一個binder線程池，並向其中注冊一個Binder線程；之後Server進程也可以向binder線程池注冊新的線程，或者Binder驅動在探測到沒有空閑binder線程時會主動向Server進程注冊新的的binder線程。對於一個Server進程有一個最大Binder線程數限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。對於所有Client端進程的binder請求都是交由Server端進程的binder線程來處理的。我的理解是：binder線程是進程進行binder ipc時的一條數據處理路徑。

MediaPlayerService向ServiceManager注冊過程如下：

相關類：

整個過程總結如下：
1 獲取BpServiceManager 與 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同時會創建ProcessState對象和BpBinder對象。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理。

2 BpBinder transact
Binder代理類調用transact()方法，真正工作還是交給IPCThreadState來進行transact工作。

3 通過IPCThreadState 包裝並轉換數據並進行transact事務處理
每個線程都有一個IPCThreadState，每個IPCThreadState中都有一對Parcel變數：mIn、mOut。相當於兩根數據管道：

最後執行talkWithDriver。

writeTransactionData：將BC Protocol + binder_transaction_data結構體 寫入mOut， 然後執行waitForResponse：

由talkWithDriver將數據進一步封裝到binder_write_read結構體，通過ioctl（BINDER_WRITE_READ）與驅動通信。同時等待驅動返回的接收BR命令，從mIn取出返回的數據。

mIn包裝的數據結構(注冊服務handle = 0 ，code 為ADD_SERVICE_TRANSACTION)：

4 Binder Driver
把binder_write_read結構體write_buffer里數據取出來，分別得到BC命令和封裝好數據的事務binder_transaction_data, 然後根據handler，在當前binder_proc中，找到相應的binder_ref，由binder_ref再找到目標binder_node實體，由目標binder_node再找到目標進程binder_proc。然後就是插入數據：當binder驅動可以找到合適的線程，就會把binder_transaction節點插入到servciemanager的線程的todo隊列中，如果找不到合適的線程，就把節點之間插入servciemanager的binder_proc的todo隊列。

5 ServiceManager
經過Binder Driver的處理，數據已經到了ServiceManager進程，在BR_TRANSACTION的引導下，在binder_loop（）中執行binder_parser（）取出數據，執行do_add_service（）操作，最終向 svcinfo 列表中添加已經注冊的服務（沒有數據的返回）。最後發送 BR_REPLY 命令喚醒等待的線程，通知注冊成功。結束MediaPlayerService進程 waitForResponse()的狀態，整個注冊過程結束。

獲取服務的過程與注冊類似，首先 ServiceManager 向 Binder 驅動發送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時獲取服務的線程進入等待狀態 waitForResponse()。Binder 驅動收到請求命令向 ServiceManager 的發送 BC_TRANSACTION 查詢已注冊的服務，會區分請求服務所屬進程情況。

查詢到直接響應 BR_REPLY 喚醒等待的線程。若查詢不到將與 binder_procs 鏈表中的服務進行一次通訊再響應。

以startService為例來簡單總結下執行流程：

3.1 從方法執行流程來看：

Client ：

1 AMP.startService 標記方法以及通過Parcel包裝數據；

2 BinderProxy.transact 實際調用native的 android_os_BinderProxy_transact 傳遞數據；

3 獲取BpServiceManager 與 BpBinder 同時會創建ProcessState。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理；

4 IPC.transact 主要執行writeTransactionData，將上層傳來的數據重新包裝成binder_transaction_data，並將BC Protocol + binder_transaction_data結構體 寫入mOut；

5 IPC waitForResponse talkWithDriver + 等待返回數據；

6 talkWithDriver 將數據進一步封裝成binder_write_read，通過ioctl（BINDER_WRITE_READ）與驅動通信；

Kernel :

7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；

8 binder_ioctl_write_read 把用戶空間數據ubuf拷貝到內核空間bwr；

9 binder_thread_write 當bwr寫緩存有數據，則執行binder_thread_write；當寫失敗則將bwr數據寫回用戶空間並退出；

10 binder_transaction 找到目標進程binder_proc並插入數據到目標進程的線程todo隊列，最終執行到它
時，將發起端數據拷貝到接收端進程的buffer結構體；

11 binder_thread_read 根據binder_transaction結構體和binder_buffer結構體數據生成新的binder_transaction_data結構體，寫入bwr的read_buffer，當bwr讀緩存有數據，則執行binder_thread_read；當讀失敗則再將bwr數據寫回用戶空間並退出；最後，把內核數據bwr拷貝到用戶空間ubuf。

12 binder_thread_write + binder_ioctl BR命令和數據傳遞

Server:

13 IPC.executeCommand 解析kernel傳過來的binder_transaction_data數據，找到目標BBinder並調用其transact()方法;

14 IPC.joinThreadPool 採用循環不斷地執行getAndExecuteCommand()方法, 處理事務。當bwr的讀寫buffer都沒有數據時,則阻塞在binder_thread_read的wait_event過程. 另外,正常情況下binder線程一旦創建則不會退出.

15 BBinder.transact 到Binder.exeTransact 調用 AMN.onTransact

16 AMN.onTransact 把數據傳遞到AMS.starService去執行

17 AMS.starService Server處理了Client的請求了

然後原路replay回去，talkWithDriver 到Kernel ，然後找到Client進程，把數據拷貝到read_buffer里，最終喚醒IPC，把反饋傳遞回AMP.startService。完成啟動服務。

3.2 從通信協議流程來看：

非oneWay:

oneway:

oneway與非oneway區別: 都是需要等待Binder Driver的回應消息BR_TRANSACTION_COMPLETE. 主要區別在於oneway的通信收到BR_TRANSACTION_COMPLETE則返回,而不會再等待BR_REPLY消息的到來. 另外，oneway的binder IPC則接收端無法獲取對方的pid.

3.3 從數據流來看

從用戶空間開始：

進入驅動後：

回到用戶空間：

參考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/

6. android 後台怎麼向ui主線程中發送消息

據我所知android提供了以下幾種方法，用於實現後台線程與UI線程的交互。

1、handler

2、Activity.runOnUIThread(Runnable)

3、View.Post(Runnable)

4、View.PostDelayed(Runnabe,long)

5、AsyncTask

方法一：handler

handler是android中專門用來在線程之間傳遞信息類的工具。

要講明handler的用法非常簡單，但是我在這里會少許深入的講一下handler的運行機制。

為了能夠讓handler在線程間傳遞消息，我們還需要用到幾個類。他們是looper，messageQueue，message。

這里說的looper可不是前段時間的好萊塢大片環形使者，他的主要功能是為特定單一線程運行一個消息環。一個線程對應一個looper。同樣一個looper對應一個線程。這就是所謂的特定單一。一般情況下，在一個線程創建時他本身是不會生產他特定單一的looper的（主線程是個特例）。因此我們需要手動的把一個looper與線程相關聯。其方法只需在需要關聯的looper的線程中調用Looper.prepare。之後我們再調用Looper.loop啟動looper。

說了這么多looper的事情，到底這個looper有什麼用哪。其實之前我們已經說到了，他是為線程運行一個消息環。具體的說，在我們將特定單一looper與線程關聯的時候，looper會同時生產一個messageQueue。他是一個消息隊列，looper會不停的從messageQuee中取出消息，也就是message。然後線程就會根據message中的內容進行相應的操作。

那麼messageQueue中的message是從哪裡來的哪？那就要提到handler了。在我們創建handler的時候，我們需要與特定的looper綁定。這樣通過handler我們就可以把message傳遞給特定的looper，繼而傳遞給特定的線程。在這里，looper和handler並非一一對應的。一個looper可以對應多個handler，而一個handler只能對應一個looper（突然想起了一夫多妻制，呵呵）。這里補充一下，handler和looper的綁定，是在構建handler的時候實現的，具體查詢handler的構造函數。

在我們創建handler並與相應looper綁定之後，我們就可以傳遞message了。我們只需要調用handler的sendMessage函數，將message作為參數傳遞給相應線程。之後這個message就會被塞進looper的messageQueue。然後再被looper取出來交給線程處理。

這里要補充說一下message，雖然我們可以自己創建一個新的message，但是更加推薦的是調用handler的obtainMessage方法來獲取一個message。這個方法的作用是從系統的消息池中取出一個message，這樣就可以避免message創建和銷毀帶來的資源浪費了（這也就是算得上重復利用的綠色之舉了吧）。

突然發現有一點很重要的地方沒有講到，那就是線程從looper收到message之後他是如何做出響應的嘞。其實原來線程所需要做出何種響應需要我們在我們自定義的handler類中的handleMessage重構方法中編寫。之後才是之前說的創建handler並綁定looper。

好吧說的可能喲點亂，總結一下利用handler傳遞信息的方法。

假設A線程要傳遞信息給B線程，我們需要做的就是

1、在B線程中調用Looper.prepare和Looper.loop。（主線程不需要）

2、 編寫Handler類，重寫其中的handleMessage方法。

3、創建Handler類的實例，並綁定looper

4、調用handler的sentMessage方法發送消息。

7. Android中的線程狀態 - AsyncTask詳解

在操作系統中，線程是操作系統調度的最小單元，同時線程又是一種受限的系統資源，即線程不可能無限制地產生，並且 線程的創建和銷毀都會有相應的開銷。 當系統中存在大量的線程時，系統會通過會時間片輪轉的方式調度每個線程，因此線程不可能做到絕對的並行。

如果在一個進程中頻繁地創建和銷毀線程，顯然不是高效的做法。正確的做法是採用線程池，一個線程池中會緩存一定數量的線程，通過線程池就可以避免因為頻繁創建和銷毀線程所帶來的系統開銷。

AsyncTask是一個抽象類，它是由Android封裝的一個輕量級非同步類（輕量體現在使用方便、代碼簡潔），它可以在線程池中執行後台任務，然後把執行的進度和最終結果傳遞給主線程並在主線程中更新UI。

AsyncTask的內部封裝了 兩個線程池 (SerialExecutor和THREAD_POOL_EXECUTOR)和 一個Handler (InternalHandler)。

其中 SerialExecutor線程池用於任務的排隊，讓需要執行的多個耗時任務，按順序排列 ， THREAD_POOL_EXECUTOR線程池才真正地執行任務 ， InternalHandler用於從工作線程切換到主線程 。

1.AsyncTask的泛型參數

AsyncTask是一個抽象泛型類。

其中，三個泛型類型參數的含義如下：

Params： 開始非同步任務執行時傳入的參數類型；

Progress： 非同步任務執行過程中，返回下載進度值的類型；

Result： 非同步任務執行完成後，返回的結果類型；

如果AsyncTask確定不需要傳遞具體參數，那麼這三個泛型參數可以用Void來代替。

有了這三個參數類型之後，也就控制了這個AsyncTask子類各個階段的返回類型，如果有不同業務，我們就需要再另寫一個AsyncTask的子類進行處理。

2.AsyncTask的核心方法

onPreExecute()

這個方法會在 後台任務開始執行之間調用，在主線程執行。 用於進行一些界面上的初始化操作，比如顯示一個進度條對話框等。

doInBackground(Params...)

這個方法中的所有代碼都會 在子線程中運行，我們應該在這里去處理所有的耗時任務。

任務一旦完成就可以通過return語句來將任務的執行結果進行返回，如果AsyncTask的第三個泛型參數指定的是Void，就可以不返回任務執行結果。 注意，在這個方法中是不可以進行UI操作的，如果需要更新UI元素，比如說反饋當前任務的執行進度，可以調用publishProgress(Progress...)方法來完成。

onProgressUpdate(Progress...)

當在後台任務中調用了publishProgress(Progress...)方法後，這個方法就很快會被調用，方法中攜帶的參數就是在後台任務中傳遞過來的。 在這個方法中可以對UI進行操作，在主線程中進行，利用參數中的數值就可以對界面元素進行相應的更新。

onPostExecute(Result)

當doInBackground(Params...)執行完畢並通過return語句進行返回時，這個方法就很快會被調用。返回的數據會作為參數傳遞到此方法中， 可以利用返回的數據來進行一些UI操作，在主線程中進行，比如說提醒任務執行的結果，以及關閉掉進度條對話框等。

上面幾個方法的調用順序：

onPreExecute() --> doInBackground() --> publishProgress() --> onProgressUpdate() --> onPostExecute()

如果不需要執行更新進度則為onPreExecute() --> doInBackground() --> onPostExecute(),

除了上面四個方法，AsyncTask還提供了onCancelled()方法， 它同樣在主線程中執行，當非同步任務取消時，onCancelled()會被調用，這個時候onPostExecute()則不會被調用 ，但是要注意的是， AsyncTask中的cancel()方法並不是真正去取消任務，只是設置這個任務為取消狀態，我們需要在doInBackground()判斷終止任務。就好比想要終止一個線程，調用interrupt()方法，只是進行標記為中斷，需要在線程內部進行標記判斷然後中斷線程。

3.AsyncTask的簡單使用

這里我們模擬了一個下載任務，在doInBackground()方法中去執行具體的下載邏輯，在onProgressUpdate()方法中顯示當前的下載進度，在onPostExecute()方法中來提示任務的執行結果。如果想要啟動這個任務，只需要簡單地調用以下代碼即可：

4.使用AsyncTask的注意事項

①非同步任務的實例必須在UI線程中創建，即AsyncTask對象必須在UI線程中創建。

②execute(Params... params)方法必須在UI線程中調用。

③不要手動調用onPreExecute()，doInBackground(Params... params)，onProgressUpdate(Progress... values)，onPostExecute(Result result)這幾個方法。

④不能在doInBackground(Params... params)中更改UI組件的信息。

⑤一個任務實例只能執行一次，如果執行第二次將會拋出異常。

先從初始化一個AsyncTask時，調用的構造函數開始分析。

這段代碼雖然看起來有點長，但實際上並沒有任何具體的邏輯會得到執行，只是初始化了兩個變數，mWorker和mFuture，並在初始化mFuture的時候將mWorker作為參數傳入。mWorker是一個Callable對象，mFuture是一個FutureTask對象，這兩個變數會暫時保存在內存中，稍後才會用到它們。 FutureTask實現了Runnable介面，關於這部分內容可以看這篇文章。

mWorker中的call()方法執行了耗時操作，即result = doInBackground(mParams);,然後把執行得到的結果通過postResult(result);,傳遞給內部的Handler跳轉到主線程中。在這里這是實例化了兩個變數，並沒有開啟執行任務。

那麼mFuture對象是怎麼載入到線程池中，進行執行的呢？

接著如果想要啟動某一個任務，就需要調用該任務的execute()方法，因此現在我們來看一看execute()方法的源碼，如下所示：

調用了executeOnExecutor()方法,具體執行邏輯在這個方法裡面：

可以 看出，先執行了onPreExecute()方法，然後具體執行耗時任務是在exec.execute(mFuture)，把構造函數中實例化的mFuture傳遞進去了。

exec具體是什麼？

從上面可以看出具體是sDefaultExecutor，再追溯看到是SerialExecutor類，具體源碼如下：

終於追溯到了調用了SerialExecutor 類的execute方法。SerialExecutor 是個靜態內部類，是所有實例化的AsyncTask對象公有的，SerialExecutor 內部維持了一個隊列，通過鎖使得該隊列保證AsyncTask中的任務是串列執行的，即多個任務需要一個個加到該隊列中，然後執行完隊列頭部的再執行下一個，以此類推。

在這個方法中，有兩個主要步驟。

①向隊列中加入一個新的任務，即之前實例化後的mFuture對象。

②調用 scheleNext()方法，調用THREAD_POOL_EXECUTOR執行隊列頭部的任務。

由此可見SerialExecutor 類僅僅為了保持任務執行是串列的，實際執行交給了THREAD_POOL_EXECUTOR。

THREAD_POOL_EXECUTOR又是什麼？

實際是個線程池，開啟了一定數量的核心線程和工作線程。然後調用線程池的execute()方法。執行具體的耗時任務，即開頭構造函數中mWorker中call()方法的內容。先執行完doInBackground()方法，又執行postResult()方法，下面看該方法的具體內容：

該方法向Handler對象發送了一個消息，下面具體看AsyncTask中實例化的Hanlder對象的源碼：

在InternalHandler 中，如果收到的消息是MESSAGE_POST_RESULT，即執行完了doInBackground()方法並傳遞結果，那麼就調用finish()方法。

如果任務已經取消了，回調onCancelled()方法，否則回調 onPostExecute()方法。

如果收到的消息是MESSAGE_POST_PROGRESS，回調onProgressUpdate()方法，更新進度。

InternalHandler是一個靜態類，為了能夠將執行環境切換到主線程，因此這個類必須在主線程中進行載入。所以變相要求AsyncTask的類必須在主線程中進行載入。

到此為止，從任務執行的開始到結束都從源碼分析完了。

AsyncTask的串列和並行

從上述源碼分析中分析得到，默認情況下AsyncTask的執行效果是串列的，因為有了SerialExecutor類來維持保證隊列的串列。如果想使用並行執行任務，那麼可以直接跳過SerialExecutor類，使用executeOnExecutor()來執行任務。

四、AsyncTask使用不當的後果

1.）生命周期

AsyncTask不與任何組件綁定生命周期，所以在Activity/或者Fragment中創建執行AsyncTask時，最好在Activity/Fragment的onDestory()調用 cancel(boolean)；

2.)內存泄漏

3.) 結果丟失

屏幕旋轉或Activity在後台被系統殺掉等情況會導致Activity的重新創建，之前運行的AsyncTask（非靜態的內部類）會持有一個之前Activity的引用，這個引用已經無效，這時調用onPostExecute()再去更新界面將不再生效。

自己是從事了七年開發的Android工程師，不少人私下問我，2019年Android進階該怎麼學，方法有沒有？

沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想進階提升Android開發，卻又不知道怎麼進階學習的朋友。【 包括高級UI、性能優化、架構師課程、NDK、Kotlin、混合式開發（ReactNative+Weex）、Flutter等架構技術資料 】，希望能幫助到您面試前的復習且找到一個好的工作，也節省大家在網上搜索資料的時間來學習。

8. android線程間通信有哪些方式

進程：是具有一定獨立功能的程序關於某個數據集合上的一次運行活動，進程是系統進行資源分配和調度的一個獨立單位。
  線程：是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位。線程自己基本上不擁有系統資源,只擁有一些在運行中必不可少的資源(如程序計數器,一組寄存器和棧)，但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源。
  區別：
  （1）、一個程序至少有一個進程，一個進程至少有一個線程；
  （2）、線程的劃分尺度小於進程，使得多線程程序的並發性高；
  （3）、進程在執行過程中擁有獨立的內存單元，而多個線程共享內存，但線程之間沒有單獨的地址空間，一個線程死掉就等於整個進程死掉。
---------------------
一、Android進程間通信方式
1.Bundle
  由於Activity，Service，Receiver都是可以通過Intent來攜帶Bundle傳輸數據的，所以我們可以在一個進程中通過Intent將攜帶數據的Bundle發送到另一個進程的組件。
  缺點：無法傳輸Bundle不支持的數據類型。
2.ContentProvider
  ContentProvider是Android四大組件之一，以表格的方式來儲存數據，提供給外界，即Content Provider可以跨進程訪問其他應用程序中的數據。用法是繼承ContentProvider，實現onCreate,query,update,insert,delete和getType方法，onCreate是負責創建時做一些初始化的工作，增刪查改的方法就是對數據的查詢和修改，getType是返回一個String，表示Uri請求的類型。注冊完後就可以使用ContentResolver去請求指定的Uri。
3.文件
  兩個進程可以到同一個文件去交換數據，我們不僅可以保存文本文件，還可以將對象持久化到文件，從另一個文件恢復。要注意的是，當並發讀/寫時可能會出現並發的問題。
4.Broadcast
  Broadcast可以向android系統中所有應用程序發送廣播，而需要跨進程通訊的應用程序可以監聽這些廣播。
5.AIDL方式
  Service和Content Provider類似，也可以訪問其他應用程序中的數據，Content Provider返回的是Cursor對象，而Service返回的是Java對象，這種可以跨進程通訊的服務叫AIDL服務。
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
6.Messenger
  Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
  雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
7.Socket
  Socket方法是通過網路來進行數據交換，注意的是要在子線程請求，不然會堵塞主線程。客戶端和服務端建立連接之後即可不斷傳輸數據，比較適合實時的數據傳輸
二、Android線程間通信方式
  一般說線程間通信主要是指主線程（也叫UI線程）和子線程之間的通信，主要有以下兩種方式：
1.AsyncTask機制
  AsyncTask，非同步任務，也就是說在UI線程運行的時候，可以在後台的執行一些非同步的操作；AsyncTask可以很容易且正確地使用UI線程，AsyncTask允許進行後台操作，並在不顯示使用工作線程或Handler機制的情況下，將結果反饋給UI線程。但是AsyncTask只能用於短時間的操作（最多幾秒就應該結束的操作），如果需要長時間運行在後台，就不適合使用AsyncTask了，只能去使用Java提供的其他API來實現。
2.Handler機制
  Handler，繼承自Object類，用來發送和處理Message對象或Runnable對象；Handler在創建時會與當前所在的線程的Looper對象相關聯(如果當前線程的Looper為空或不存在，則會拋出異常，此時需要在線程中主動調用Looper.prepare()來創建一個Looper對象)。使用Handler的主要作用就是在後面的過程中發送和處理Message對象和讓其他的線程完成某一個動作（如在工作線程中通過Handler對象發送一個Message對象，讓UI線程進行UI的更新，然後UI線程就會在MessageQueue中得到這個Message對象（取出Message對象是由其相關聯的Looper對象完成的），並作出相應的響應）。
三、Android兩個子線程之間通信
  面試的過程中，有些面試官可能會問Android子線程之間的通信方式，由於絕大部分程序員主要關注的是Android主線程和子線程之間的通信，所以這個問題很容易讓人懵逼。
  主線程和子線程之間的通信可以通過主線程中的handler把子線程中的message發給主線程中的looper，或者，主線程中的handler通過post向looper中發送一個runnable。但looper默認存在於main線程中，子線程中沒有Looper，該怎麼辦呢？其實原理很簡單，把looper綁定到子線程中，並且創建一個handler。在另一個線程中通過這個handler發送消息，就可以實現子線程之間的通信了。
  子線程創建handler的兩種方式：
  方式一：給子線程創建Looper對象：
new Thread(new Runnable() {
public void run() {
Looper.prepare(); // 給這個Thread創建Looper對象，一個Thead只有一個Looper對象
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
Looper.loop(); // 不斷遍歷MessageQueue中是否有消息
};
}).start();
---------------------
方式二：獲取主線程的looper，或者說是UI線程的looper：
new Thread(new Runnable() {
public void run() {
Handler handler = new Handler(Looper.getMainLooper()){ // 區別在這！！！
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
};
}).start();