如何正確使用Android線程詳解

前言

對於移動開發者來說，“將耗時的任務放到子線程去執行，以保證UI線程的流暢性”是線程編程的第一金科玉律，但這條鐵則往往也是UI線程不怎麼流暢的主因。我們在督促自己更多的使用線程的同時，還需要時刻提醒自己怎麼避免線程失控。

多線程編程之所以復雜原因之一在於其並行的特性，人腦的工作方式更符合單線程串行的特點。一個接著一個的處理任務是大腦最舒服的狀態，頻繁的在任務之間切換會產生“頭痛”這類系統異常。人腦的多任務和計算機的多任務性能差異太大導致我們在設計並行的業務邏輯之時，很容易犯錯。

另一個復雜點在於線程所帶來的副作用，這些副作用包括但不限於：多線程數據安全，死鎖，內存消耗，對象的生命周期管理，UI的卡頓等。每一個新開的線程就像扔進湖面的石子，在你忽視的遠處產生漣漪。

把抽象的東西具像化是我們認知世界的主要方式。線程作為操作系統世界的“公民”之一，是如何被調度獲取到CPU和內存資源的，又怎麼樣去和其他“公民”互通有無進而實現效益最大化？把這些實體和行為具像到大腦，像操作系統一樣開“上帝視角”，才能正確掌控線程這頭強大的野獸。

進程優先級（Process Priority）

線程寄宿在進程當中，線程的生命周期直接被進程所影響，而進程的存活又和其優先級直接相關。在處理進程優先級的時候，大部分人靠直覺都能知道前台進程（Foreground Process）優先級要高於後台進程（Background Process）。但這種粗糙的劃分無法滿足操作系統高精度調度的需求。無論Android還是iOS，系統對於Foreground，Background進程有進一步的細化。

Foreground Process

Foreground一般意味著用戶雙眼可見，可見卻不一定是active。在Android的世界裡，一個Activity處於前台之時，如果能采集用戶的input事件，就可以判定為active，如果中途彈出一個Dialog，Dialog變成新的active實體，直接面對用戶的操作。被部分遮擋的activity盡管依然可見，但狀態卻變為inactive。不能正確的區分visible和active是很多初級程序員會犯的錯誤。

Background Process

後台進程同樣有更細的劃分。所謂的Background可以理解為不可見（invisible）。對於不可見的任務，Android也有重要性的區分。重要的後台任務定義為Service，如果一個進程包含Service（稱為Service Process），那麼在“重要性”上就會被系統區別對待，其優先級自然會高於不包含Service的進程（稱為Background Process），最後還剩一類空進程（Empty Process）。Empty Process初看有些費解，一個Process如果什麼都不做，還有什麼存在的必要。其實Empty Process並不Empty，還存在不少的內存占用。

在iOS的世界裡，Memory被分為Clean Memory和Dirty Memory，Clean Memory是App啟動被加載到內存之後原始占用的那一部分內存，一般包括初始的stack, heap, text, data等segment，Dirty Memory是由於用戶操作所改變的那部分內存，也就是App的狀態值。系統在出現Low Memory Warning的時候會首先清掉Dirty Memory，對於用戶來說，操作的進度就全部丟失了，即使再次點擊App圖標，也是一切從頭開始。但由於Clean Memory沒有被清除，避免了從磁盤重新讀取app數據的io損耗，啟動會變快。這也是為什麼很多人會感覺手機重啟後，app打開的速度都比較慢。

同理Android世界當中的Empty Process還保存有App相關的Clean Memory，這部分Memory對於提升App的啟動速度大有幫助。顯而易見Empty Process的優先級是最低的。

綜上所述，我們可以把Android世界的Process按優先級分為如下幾類：

進程的優先級從高到低依次分為五類，越往下，在內存緊張的時候越有可能被系統殺掉。簡而言之，越是容易被用戶感知到的進程，其優先級必定更高。

線程調度（Thread Scheduling）

Android系統基於精簡過後的linux內核，其線程的調度受時間片輪轉和優先級控制等諸多因素影響。不少初學者會認為某個線程分配到的time slice多少是按照其優先級與其它線程優先級對比所決定的，這並不完全正確。

Linux系統的調度器在分配time slice的時候，采用的CFS（completely fair scheduler）策略。這種策略不但會參考單個線程的優先級，還會追蹤每個線程已經獲取到的time slice數量，如果高優先級的線程已經執行了很長時間，但低優先級的線程一直在等待，後續系統會保證低優先級的線程也能獲取更多的CPU時間。顯然使用這種調度策略的話，優先級高的線程並不一定能在爭取time slice上有絕對的優勢，所以Android系統在線程調度上使用了cgroups的概念，cgroups能更好的凸顯某些線程的重要性，使得優先級更高的線程明確的獲取到更多的time slice。

Android將線程分為多個group，其中兩類group尤其重要。一類是default group，UI線程屬於這一類。另一類是background group，工作線程應該歸屬到這一類。background group當中所有的線程加起來總共也只能分配到5～10%的time slice，剩下的全部分配給default group，這樣設計顯然能保證UI線程繪制UI的流暢性。

有不少人吐槽Android系統之所以不如iOS流暢，是因為UI線程的優先級和普通工作線程一致導致的。這其實是個誤會，Android的設計者實際上提供了background group的概念來降低工作線程的CPU資源消耗，只不過與iOS不同的是，Android開發者需要顯式的將工作線程歸於background group。

new Thread(new Runnable() {
   @Override
   public void run() {
     Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
   }
}).start();

所以在我們決定新啟一個線程執行任務的時候，首先要問自己這個任務在完成時間上是否重要到要和UI線程爭奪CPU資源。如果不是，降低線程優先級將其歸於background group，如果是，則需要進一步的profile看這個線程是否造成UI線程的卡頓。

雖說Android系統在任務調度上是以線程為基礎單位，設置單個thread的優先級也可以改變其所屬的control groups，從而影響CPU time slice的分配。但進程的屬性變化也會影響到線程的調度，當一個App進入後台的時候，該App所屬的整個進程都將進入background group，以確保處於foreground，用戶可見的新進程能獲取到盡可能多的CPU資源。用adb可以查看不同進程的當前調度策略。

$ adb shell ps -P

當你的App重新被用戶切換到前台的時候，進程當中所屬的線程又會回歸的原來的group。在這些用戶頻繁切換的過程當中，thread的優先級並不會發生變化，但系統在time slice的分配上卻在不停的調整。

是否真的需要新線程？

開線程並不是提升App性能，解決UI卡頓的萬金油。每一個新啟的線程會消耗至少64KB的內存，系統在不同的線程之間switch context也會帶來額外的開銷。如果隨意開啟新線程，隨著業務的膨脹，很容易在App運行的某個時間點發現幾十個線程同時在運行。後果是原本想解決UI流暢性，卻反而導致了偶現的不可控的卡頓。

移動端App新啟線程一般都是為了保證UI的流暢性，增加App用戶操作的響應度。但是否需要將任務放入工作線程需要先了解任務的瓶頸在哪，是i/o，gpu還是cpu？UI出現卡頓並不一定是UI線程出現了費時的計算，有可能是其它原因，比如layout層級太深。

盡量重用已有的工作線程（使用線程池）可以避免出現大量同時活躍的線程，比如對HTTP請求設置最大並發數。或者將任務放入某個串行的隊列（HandlerThread）按順序執行，工作線程任務隊列適合處理大量耗時較短的任務，避免出現單個任務阻塞整個隊列的情況。

用什麼姿勢開線程？

new Thread()

這是Android系統裡開線程最簡單的方式，也只能應用於最簡單的場景，簡單的好處卻伴隨不少的隱患。

new Thread(new Runnable() {
  @Override
  public void run() {
 
  }
}).start();

這種方式僅僅是起動了一個新的線程，沒有任務的概念，不能做狀態的管理。start之後，run當中的代碼就一定會執行到底，無法中途取消。

Runnable作為匿名內部類還持有了外部類的引用，在線程退出之前，該引用會一直存在，阻礙外部類對象被GC回收，在一段時間內造成內存洩漏。

沒有線程切換的接口，要傳遞處理結果到UI線程的話，需要寫額外的線程切換代碼。

如果從UI線程啟動，則該線程優先級默認為Default，歸於default cgroup，會平等的和UI線程爭奪CPU資源。這一點尤其需要注意，在對UI性能要求高的場景下要記得

Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);

雖說處於background group的線程總共只能爭取到5～10%的CPU資源，但這對絕大部分的後台任務處理都綽綽有余了，1ms和10ms對用戶來說，都是快到無法感知，所以我們一般都偏向於在background group當中執行工作線程任務。

AsyncTask

一個典型的AsyncTask實現如下：

public class MyAsyncTask extends AsyncTask {
 
   @Override
   protected Object doInBackground(Object[] params) {
      return null;
   }
 
   @Override
   protected void onPreExecute() {
     super.onPreExecute();
   }
 
   @Override
   protected void onPostExecute(Object o) {
     super.onPostExecute(o);
   }
}

和使用Thread()不同的是，多了幾處API回調來嚴格規范工作線程與UI線程之間的交互。我們大部分的業務場景幾乎都符合這種規范，比如去磁盤讀取圖片，縮放處理需要在工作線程執行，最後繪制到ImageView控件需要切換到UI線程。

AsyncTask的幾處回調都給了我們機會去中斷任務，在任務狀態的管理上較之Thread()方式更為靈活。值得注意的是AsyncTask的cancel()方法並不會終止任務的執行，開發者需要自己去檢查cancel的狀態值來決定是否中止任務。

AsyncTask也有隱式的持有外部類對象引用的問題，需要特別注意防止出現意外的內存洩漏。

AsyncTask由於在不同的系統版本上串行與並行的執行行為不一致，被不少開發者所诟病，這確實是硬傷，絕大部分的多線程場景都需要明確任務是串行還是並行。

線程優先級為background，對UI線程的執行影響極小。

HandlerThread

在需要對多任務做更精細控制，線程切換更頻繁的場景之下，Thread()和AsyncTask都會顯得力不從心。HandlerThread卻能勝任這些需求甚至更多。

HandlerThread將Handler，Thread，Looper，MessageQueue幾個概念相結合。Handler是線程對外的接口，所有新的message或者runnable都通過handler post到工作線程。Looper在MessageQueue取到新的任務就切換到工作線程去執行。不同的post方法可以讓我們對任務做精細的控制，什麼時候執行，執行的順序都可以控制。HandlerThread最大的優勢在於引入MessageQueue概念，可以進行多任務隊列管理。

HandlerThread背後只有一個線程，所以任務是串行執行的。串行相對於並行來說更安全，各任務之間不會存在多線程安全問題。

HandlerThread所產生的線程會一直存活，Looper會在該線程中持續的檢查MessageQueue。這一點和Thread()，AsyncTask都不同，thread實例的重用可以避免線程相關的對象的頻繁重建和銷毀。

HandlerThread較之Thread()，AsyncTask需要寫更多的代碼，但在實用性，靈活度，安全性上都有更好的表現。

ThreadPoolExecutor

Thread(),AsyncTask適合處理單個任務的場景，HandlerThread適合串行處理多任務的場景。當需要並行的處理多任務之時，ThreadPoolExecutor是更好的選擇。

public static Executor THREAD_POOL_EXECUTOR
= new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

線程池可以避免線程的頻繁創建和銷毀，顯然性能更好，但線程池並發的特性往往也是疑難雜症的源頭，是代碼降級和失控的開始。多線程並行導致的bug往往是偶現的，不方便調試，一旦出現就會耗掉大量的開發精力。

ThreadPool較之HandlerThread在處理多任務上有更高的靈活性，但也帶來了更大的復雜度和不確定性。

IntentService

不得不說Android在API設計上粒度很細，同一樣工作可以通過各種不同的類來完成。IntentService又是另一種開工作線程的方式，從名字就可以看出這個工作線程會帶有service的屬性。和AsyncTask不同，沒有和UI線程的交互，也不像HandlerThread的工作線程會一直存活。IntentService背後其實也有一個HandlerThread來串行的處理Message Queue，從IntentService的onCreate方法可以看出：

@Override
public void onCreate() {
  // TODO: It would be nice to have an option to hold a partial wakelock
  // during processing, and to have a static startService(Context, Intent)
  // method that would launch the service & hand off a wakelock.
 
  super.onCreate();
  HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
  thread.start();
 
  mServiceLooper = thread.getLooper();
  mServiceHandler = new ServiceHandler(mServiceLooper);
}

只不過在所有的Message處理完畢之後，工作線程會自動結束。所以可以把IntentService看做是Service和HandlerThread的結合體，適合需要在工作線程處理UI無關任務的場景。

總結

Android開線程的方式雖然五花八門，但歸根到底最後還是映射到linux下的pthread，業務的設計還是脫不了和線程相關的基礎概念范疇：線程的執行順序，調度策略，生命周期，串行還是並行，同步還是異步等等。摸清楚各類API下線程的行為特點，在設計具體業務的線程模型的時候自然輕車熟路了，線程模型的設計要有整個app視角的廣度，切忌各業務模塊各玩各的。以上就是本文的全部內容，希望對大家開發Android能有所幫助，如果有疑問歡迎大家留言討論。