Android AMS服務

繼續來研究Android Framework層相關的一些東東，這裏是以Android8.0版本的源碼進行梳理的，關注的仍是其核心流程，不是完全分析，瞭解了核心流程是爲了了期其大概的原理。

Android系統啓動：

這裏具體就不分析代碼了，由於重點是來分析AMS相關的代碼，這裏以流程圖的方式來展示一下整個的啓動，畢境對於一個組件的啓動得要創建在整個Android系統啓動基礎之上的，另外這塊的具體源碼也不敢看，還沒達到這種能直接分析底層的能力，因此先從大局觀來了解其流程，下面開始：

 接着就啓動Linux內核了：

 而後再啓動init進程：

接着則啓動我們熟知的Zygote進程了：

接下來則啓動各類服務了：

而其中當啓動了AMS服務以後，則就會啓動Launch應用程序了，以下：

咱們知道以上服務最終都獲得ServiceManager進行註冊，由於其實都是一個Binder通訊的過程，因此再來複習一下ServiceManager的啓動流程。

Binder機制ServiceManager啓動：

 

那知道了ServiceManager什麼時候啓動的，接下來重點來看一下我們此次要研究的AMS（ActivityManagerService）它是怎麼註冊ServiceManager上的。

AMS註冊流程：

其中ServiceManager就是一個服務端的角色，而AMS則是一個客戶端的角色。

應用程序啓動：

在知道了AMS服務器註冊過程以後，接下來則看一下一個Android應用是如何啓動的，先來貼一張流程圖：

好，接下來分析一下相關的源碼，看一下是否如流程圖所示，這裏仍是採用在線的androidxref.com上來進行源碼分析，我電腦本地木有下載，省點事：

首先來看一下Zygote進程的啓動：

而後它裏面有一個main主入口函數：

也就是以前Android系統啓動流程圖這塊所示：

最後則開啓死循環來等待Ams的請求，以下：

其實也就是對應這個流程：

好，接下來再來分析一個應用是如何啓動的，按流程圖上的來：

 那就定位到AMS中：

而後：

其中能夠看到裏面會傳要啓動應用的各類信息：

而後跟進去瞅一眼：

也就是到了這一步：

流程也就到了這：

其中能夠看到設置了一系列的參數：

而後再下一步：

對應代碼：

 

 

注意上面是「Zygote主模式」，好，若是這個條件不匹配，則會繼續往下執行，以下：

 

好，若是鏈接成功，則流程會走到了：

而最終的代碼在這：

此時咱們所熟知的ActivityThread的main()方法就會被調用了，而後整個應用就啓動了。

Activity啓動：

根Activity啓動：

這裏先回顧一下整個Android系統啓動流程的這一步，串一下：

此時咱們點擊Launch應用中的某個圖標，則會啓動該應用的根Activity，其整個流程先看一下流程圖：

好，依據此流程來看一下對應的源代碼：

此時就會建立Application：

 

 最終會調到這：

 

走進去瞅一下它的細節：

 

而後再跟進去：

而對於一些Activity的其它生命週期的啓動都是經過ActivityThread中的Handler來實現的:

普通Activity啓動：

Intrumentation.execStartActivity()【未跨進程】：

對於Activity的啓動咱們確定得要調用startActivity()方法，因此我們就從這個方法爲入口逐一來剖析其裏面的機理，仍是很複雜的，下面開始：

 

因此接下來看一下Instrumentation的啓動細節：

ActivityManagerProxy.startActivity()【未跨進程】：

而這個ActivityManagerNative在以前https://www.cnblogs.com/webor2006/p/11811650.html分析Binder機制見過，以下：

其實它也是一個典型的AIDL的Binder通訊，打開再來瞅一下：

 

而後它裏面還有一個Proxy：

此時就會調用到Proxy中的startActivity()方法進行Binder通信了：

此時就會經過Binder驅動調用它的Stub的onTransact()的方法，以下：

ActivityManagerService.startActivity()【開始跨進程了】：

此時就會調用ActivityManagerService的startActivity方法，由於它是ActivityManagerNative的具體實現類：

此時，就到了跨進程訪問了，在這以前都是在本進程的邏輯，好接下來繼續分析：

ActivityStackSupervisor.startActivityMyWait()：

其中看註釋說明，是切換到用戶app的棧了，咱們知道Android的Activity是以棧的形式來管理的，因此它是比較核心的了，能夠大體看一下它裏面有一些棧的管理：

這個棧的管理在以後的分析中還會有說起到，先有個大體印象，先來關注主流程：

而其實又是一個AIDL的過程，進去稍看一下它的細節：

而看一下它具體的實現：

就是從ServiceManager中來找到package相關的服務，標準的AIDL的調用過程，那IPackageManager的具體實現類是哪一個呢？實際上是這個，也就是繼承了IPackageManager中的抽象類Stub的實現類，實際上是它：

PackageManagerService.resolveIntent()：掃描app，註冊組件

那看一下它的resolveIntent()方法：

查看一下這個方法的細節：

而後回到resolveIntent()方法來，則會看到有一個根據優先級來選擇最佳的ResolveInfo，以下：

 

好，這裏還得再來講一下PackageManagerService這個很重要的服務，主要是管理包的一些信息，咱們知道在apk安裝到系統中時，會在/data/app之類的系統目錄下存在，而該服務則會掃描註冊在清單中的一些包信息，那麼看一下構造方法就能找到一些相關的信息，以下：

 

因此能夠看到該服務器就是來掃描一些包的信息用的，而這構造函數的調用是在這裏：

因此這也是爲啥在以前這塊能夠看到拿服務就是用的"package"這個key，回憶下：

其實Android的不少核心服務都是這樣會往ServiceManager去註冊的。

ActivityStackSupervisor.startActivityLocked()：驗證intent、Class、Permission等，保存將要啓動的Activity的Record

好，接下來接着主流程繼續：

那看一下它的細節，能夠看到各類異常檢測，這裏截其中一小部分：

最終生成一個ActivityRecord對像來保存相關信息：

 

 

ActivityStackSupervisor.startActivityUncheckedLocked()：檢查將要啓動的Activity的launchMode和啓動Flag，根據launcheMode和Flag配置task

該方法的實現代碼也比較多，就瞅一下它的大體細節既可：

 

 

裏面真的是很是之複雜，也看不懂，有個大致的瞭解，重點是瞭解整個主流程的過程，好繼續，直接跳到這方法的最後：

ActvityStack.startActivityLocked：任務棧歷史棧配置

它是專門來維護任務棧的進出的，而上面的ActivityStackSupervisor是維護各個棧的信息，職責不同，那下面來看一下該方法的細節：

 

在最後：

此時又回到了ActivityStackSupervisor了，以下：

也就是以下：

ActivityStack.resumeTopActivityInnerLocked()：查找要進入暫停的Activity

這個裏面實現的代碼理很是之多，只看核心的，在要跳轉到新的Activity以前，先會把一些Activity給暫停了，瞅一下這塊的核心流程：

 

而後在跳到新Activity以前，會先暫停當前的Activity，以下：

ActivityStack.startPausingLocked()：經過ipc告訴要暫停的Activity進入暫停

此時看一下這個方法的細節：

而prev.app.thread其實就是ActivityThread，而它裏面實際上是一個IPC的過程，以下：

 

此時就會到了ActivityThread中的消息處理中心了，以下：

ActivityThread.handlePauseActivity()：

下面具體看一下它的實現：

一、正式讓以前的Activity暫停：

 

 

二、告訴AMS已經暫停完成：

回到這個方法繼續執行，就會發現：

而最終會調到ActivityManagerService，以下：

ActivityManagerService.activityPaused()：

而後就會調用到ActivityStack.activityPausedLocked()方法。

ActivityStack.activityPausedLocked()：

其中這個方法有一個resumeNext參數，傳的true，這裏想想就明白其意思，暫停了當前顯示的Activity以後，那確定得要將要跳轉的Activity給顯示呀，而這個參數就是控制要顯示跳轉的Activity的邏輯的，以下：

ActivityStackSuperVisor.resumeTopActivitiesLocked()：

ActivityStack.resumeTopActivityLocked()：驗證是否該啓動的Activity所在進程和app是否存在，若存在，直接啓動，不然，準備建立該進程。

而後在這個方法裏面則會有一個關鍵的邏輯判斷，在啓動新的Activity時，先判斷是否該Activity是在同一個進程：

若是爲ture則代碼要啓動的Activity爲同一個進程，這裏就不細看了，若是條件不知足則表明進程不存在，須要建立進程，這裏瞅一下，以下：

ActivityStackSuperVisor.startSpecificActivityLocked()：該進程不存在，建立進程

好，又回到了這個棧管理類了，看一下它的細節：

ActivityManagerService.startProcessLocked()：經過Process.start(「android.app.ActivityThread」)啓動進程

  

  

ActivityThread.main()：

當進程被啓動以後，則該進程的ActivityThread.main()方法就會被執行，這塊就比較熟了。主要是建立一個Looper。 

ActivityThread.attach()：

IActivityManager.attachApplication()：

而上面的attach的具體實現：

會調用IActivityManager.attachApplication()方法了，此時就會調用ActivityServiceManager.attachApplication()，以下：

而後往這個方法找一下，會有以下核心代碼：

ActivityStackSuperVisor.attachApplicationLocked()：準備啓動應用，先查找MainActivity

此時又回到了這個棧管理大管家，瞅下：

ActivityStackSuperVisor.realStartActivityLocked()：IPC通知ActivityThread

ActivityThread.scheduleLaunchActivity()：

 

其中performLaunchActivity方法就是來建立要啓動的Activity，稍微看一下細節：

至此關於Activity的啓動的主流程就分析完了，太TM複雜了。。能夠看到Android底層的代碼有不少C/S架構、分模塊的思想，真的是博大精深。。

Service啓動：

接下來再來分析Android的另外一大組件的啓動---Service，先來貼一下大致的主流程圖：

 

好，下面來瞅一下源碼：

具體細節就不看了，最終會調到ActivityThread的這塊：

還有其它相關的一些跟服務相關的東東在裏面，大體貼一下：