身為四大組件之一，Activity可以說是和我們開發(fā)人員打交道最多的組件了，大家平時開發(fā)時可能對這個組件都有一些疑惑，比如為什么啟動一個activity是一個重量級行為呢（因此好多人習(xí)慣使用fragment代替activity），activity的生命周期又是誰來調(diào)用的呢，等等問題本文會一一作答。

Activity啟動流程

網(wǎng)上目前有很多介紹activity啟動的文章，但基本上所有的文章都是通篇貼代碼，問題是Android系統(tǒng)中這塊的源碼調(diào)用太復(fù)雜，導(dǎo)致貼出來的代碼非常多，所以這里我不貼代碼，爭取結(jié)合圖文做介紹，讓大家認(rèn)識到具體流程即可。注意本文是基于分支 android-8.1.0_r53 的。

總體流程

這里，我們以最普通的在應(yīng)用內(nèi)部啟動一個activity為例，先看圖（該圖只畫出了大致的幾個角色，省略了很多參與的類）：

Activity總體啟動流程.png

整個activity的啟動流程從上圖看一目了然，這里不再文字重復(fù)。從上圖中，我們重點關(guān)注的是一次activity熱啟動（無需打開新應(yīng)用）需要進(jìn)行三次IPC調(diào)用，那么為何要這么設(shè)計呢？這里我們要重點談?wù)凙MS了。

什么是AMS

AMS全稱是ActivityManagerService,專門負(fù)責(zé)四大組件的管理，所以想要啟動一個新的activity必須通過它才行，然而AMS是一個單獨運行的進(jìn)程，這就必然涉及到了跨進(jìn)程通信 ，三次IPC也是不得已而為之。

startActivity請求發(fā)起

這里主要拆開分析 from activity 到AMS的調(diào)用過程，老規(guī)矩，不貼代碼，只看圖，了解大致流程即可：

Activity啟動之第一次IPC流程 (2).png

可以看到第一次IPC過程還是很簡單的，主要就是通過ActivityManager項AMS發(fā)起startActivity請求，這里就不在描述了。

AMS內(nèi)部處理

第二次IPC就是AMS處理Activity啟動請求的過程了，比較復(fù)雜，對于這個過程大家要靜下心來分析：

Activity啟動之第二次IPC流程 (3).png

從圖上看大家可能是一臉懵逼的，別著急，我們一步步來：

• 首先，AMS進(jìn)程主要干什么？
  整個AMS對Activity的調(diào)度管理核心集中在對Activity任務(wù)棧的管理上，換句話說所謂的第二次IPC過程核心就是對任務(wù)棧的管理過程。
• 其次，既然是對任務(wù)棧的管理，ActivityStarter,ActivityStackSupervisor這些類為什么存在？
  這里我們就得談一談軟件設(shè)計中的單一職責(zé)原則了，首先AMS是管理四大組件的，那么AMS直接管理Activity的一切合適嗎？所以有了ActivityStarter這個類，專門來負(fù)責(zé)啟動一個Activity。對于整個任務(wù)棧，我們肯定要一個類來保存所有的Activity記錄，于是ActivityStack應(yīng)運而生，但對于ActivityStack的操作肯定是很復(fù)雜的，這些代碼應(yīng)該放在ActivityStack中嗎？于是ActivityStackSupervisor出現(xiàn)了，負(fù)責(zé)操作Activity任務(wù)棧。有了這些基礎(chǔ)，大家應(yīng)該能更好的理解上圖了，至于ActivityStack具體如何管理的，我們下面再分析。
• ApplicationThread 是干什么的？
  整個Android的IPC都是基于binder的，ApplicationThread就是binder通信的接口而已，AMS可以通過它來和app進(jìn)程進(jìn)行交互

Activity的生成

在上一步中，AMS通知客戶端進(jìn)程開始啟動一一個新的activity實例了，具體啟動過程如圖：

Activity的實例生成 (1).png

這里同樣不再重復(fù)描述流程，大家重點注意下這里activity的實例化和各個生命周期的調(diào)用就可以了，另外，調(diào)用完onResume后會再發(fā)起一次IPC，告知AMS這個activity onResume成功了。

Activity銷毀流程

流程總覽

首先我們看下大致的銷毀流程，注意，此圖省略了很多中間調(diào)用：

Activity銷毀大致流程.png

有了上面啟動的流程基礎(chǔ)，這里應(yīng)該要好理解很多，和啟動不一樣，銷毀過程經(jīng)歷了至少5次IPC（至少是因為還有其他情況下也會進(jìn)行IPC通信，這里不考慮），之所以比啟動多兩次，是因為銷毀時，onPause方法和onStop+onDestroy方法分作了兩次進(jìn)行，之所以分開處理，是因為調(diào)用完onPause()方法后我們不能立即調(diào)用onStop()方法，因為這個時候我們需要先調(diào)用前一個頁面的onResume()方法（圖中未體現(xiàn)）,所以我們需要先切回到AMS進(jìn)程去處理。

onPause的執(zhí)行

首先，我們以手動調(diào)用Activity的finish()方法為例來看下第一次IPC過程：

Activity銷毀之第一次請求銷毀過程 (1).png

onStop和onDestroy的執(zhí)行

Activity銷毀之onStop和onDestroy的執(zhí)行.png

總結(jié)

以上其實都是一些時序圖，都是流程性的概念，大家有個大致的了解，知道生命周期是怎么調(diào)用的就可以了，不要陷入太深，有了這個流程基礎(chǔ)才可以繼續(xù)深入其他的內(nèi)容。注意，本文其實并沒有介紹核心的Activity任務(wù)棧，主要是任務(wù)棧還涉及到WMS的一些內(nèi)容，沒有相關(guān)基礎(chǔ)比較難以理解，可能后面介紹完了WMS其他內(nèi)容再回來寫一篇相關(guān)文章吧。