2. 程式人生 > >Android解析ActivityManagerService（一）AMS啟動流程和AMS家族

Android解析ActivityManagerService（一）AMS啟動流程和AMS家族

阿新 • • 發佈：2019-01-30

前言

此前在Android系統啟動流程、應用程序以及深入四大元件這三個系列文章中，都提及到了AMS，但都沒有系統的來講解它，本文就以AMS為主來進行講解，其中會有一些知識點與這些系列文章有所重合，這裡會儘量做到詳盡講解。閱讀此文章前，最好閱讀相關文章中列出的系列文章，否則我不敢保證這篇文章你能看的懂。

1.概述

AMS是系統的引導服務，應用程序的啟動、切換和排程、四大元件的啟動和管理都需要AMS的支援。從這裡可以看出AMS的功能會十分的繁多，當然它並不是一個類承擔這個重責，它有一些關聯類，這在文章後面會講到。AMS的涉及的知識點非常多，這篇文章主要會講解AMS的以下幾個知識點：

  • AMS的啟動流程。
  • AMS與程序啟動。
  • AMS家族。

2.AMS的啟動流程

AMS的啟動是在SyetemServer程序中啟動的，在Android系統啟動流程（三）解析SyetemServer程序啟動過程這篇文章中提及過，這裡從SyetemServer的main方法開始講起：
frameworks/base/services/java/com/android/server/SystemServer.java

public static void main(String[] args) {
       new SystemServer().run();
   }

main方法中只調用了SystemServer的run方法，如下所示。
frameworks/base/services/java/com/android/server/SystemServer.java

private void run() {
       ...
           System.loadLibrary("android_servers");//1
       ...
           mSystemServiceManager = new SystemServiceManager(mSystemContext);//2
           LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);
       ...    
        try {
           Trace.traceBegin(Trace.TRACE_TAG_SYSTEM_SERVER, "StartServices"
 
);
           startBootstrapServices();//3
           startCoreServices();//4
           startOtherServices();//5
       } catch (Throwable ex) {
           Slog.e("System", "******************************************");
           Slog.e("System", "************ Failure starting system services", ex);
           throw ex;
       } finally {
           Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
       }
       ...
   }

在註釋1處載入了動態庫libandroid_servers.so。接下來在註釋2處建立SystemServiceManager，它會對系統的服務進行建立、啟動和生命週期管理。在註釋3中的startBootstrapServices方法中用SystemServiceManager啟動了ActivityManagerService、PowerManagerService、PackageManagerService等服務。在註釋4處的startCoreServices方法中則啟動了BatteryService、UsageStatsService和WebViewUpdateService。註釋5處的startOtherServices方法中啟動了CameraService、AlarmManagerService、VrManagerService等服務。這些服務的父類均為SystemService。從註釋3、4、5的方法可以看出，官方把系統服務分為了三種類型，分別是引導服務、核心服務和其他服務，其中其他服務是一些非緊要和一些不需要立即啟動的服務。系統服務總共大約有80多個，我們主要來檢視引導服務AMS是如何啟動的，註釋3處的startBootstrapServices方法如下所示。

frameworks/base/services/java/com/android/server/SystemServer.java

   private void startBootstrapServices() {
        Installer installer = mSystemServiceManager.startService(Installer.class);
        // Activity manager runs the show.
        mActivityManagerService = mSystemServiceManager.startService(
                ActivityManagerService.Lifecycle.class).getService();//1
        mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
        mActivityManagerService.setInstaller(installer);
      ...
    }

在註釋1處呼叫了SystemServiceManager的startService方法，方法的引數是ActivityManagerService.Lifecycle.class：
frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

  @SuppressWarnings("unchecked")
    public <T extends SystemService> T startService(Class<T> serviceClass) {
        try {
           ...
            final T service;
            try {
                Constructor<T> constructor = serviceClass.getConstructor(Context.class);//1
                service = constructor.newInstance(mContext);//2
            } catch (InstantiationException ex) {
              ...
            }
            // Register it.
            mServices.add(service);//3
            // Start it.
            try {
                service.onStart();//4
            } catch (RuntimeException ex) {
                throw new RuntimeException("Failed to start service " + name
                        + ": onStart threw an exception", ex);
            }
            return service;
        } finally {
            Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
        }
    }

startService方法傳入的引數是Lifecycle.class，Lifecycle繼承自SystemService。首先，通過反射來建立Lifecycle例項，註釋1處得到傳進來的Lifecycle的構造器constructor，在註釋2處呼叫constructor的newInstance方法來建立Lifecycle型別的service物件。接著在註釋3處將剛建立的service新增到ArrayList型別的mServices物件中來完成註冊。最後在註釋4處呼叫service的onStart方法來啟動service，並返回該service。Lifecycle是AMS的內部類，程式碼如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

   public static final class Lifecycle extends SystemService {
        private final ActivityManagerService mService;
        public Lifecycle(Context context) {
            super(context);
            mService = new ActivityManagerService(context);//1
        }
        @Override
        public void onStart() {
            mService.start();//2
        }
        public ActivityManagerService getService() {
            return mService;//3
        }
    }

上面的程式碼結合SystemServiceManager的startService方法來分析，當通過反射來建立Lifecycle例項時，會呼叫註釋1處的方法建立AMS例項，當呼叫Lifecycle型別的service的onStart方法時，實際上是呼叫了註釋2處AMS的start方法。在SystemServer的startBootstrapServices方法的註釋1處，呼叫瞭如下程式碼：

 mActivityManagerService = mSystemServiceManager.startService(
                ActivityManagerService.Lifecycle.class).getService();

我們知道SystemServiceManager的startService方法最終會返回Lifecycle型別的物件，緊接著又呼叫了Lifecycle的getService方法，這個方法會返回AMS型別的mService物件，見註釋3處，這樣AMS例項就會被建立並且返回。

3.AMS與程序啟動

在Android系統啟動流程（二）解析Zygote程序啟動過程這篇文章中，我提到了Zygote的Java框架層中，會建立一個Server端的Socket，這個Socket用來等待AMS來請求Zygote來建立新的應用程式程序。要啟動一個應用程式，首先要保證這個應用程式所需要的應用程式程序已經被啟動。AMS在啟動應用程式時會檢查這個應用程式需要的應用程式程序是否存在，不存在就會請求Zygote程序將需要的應用程式程序啟動。Service的啟動過程中會呼叫ActiveServices的bringUpServiceLocked方法，如下所示。
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

  private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
            boolean whileRestarting, boolean permissionsReviewRequired)
            throws TransactionTooLargeException {
  ...
  final String procName = r.processName;//1
  ProcessRecord app;
  if (!isolated) {
            app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);//2
            if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
                        + " app=" + app);
            if (app != null && app.thread != null) {//3
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.versionCode,
                    mAm.mProcessStats);
                    realStartServiceLocked(r, app, execInFg);//4
                    return null;
                } catch (TransactionTooLargeException e) {
              ...
            }
        } else {
            app = r.isolatedProc;
        }
 if (app == null && !permissionsReviewRequired) {//5
            if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                    "service", r.name, false, isolated, false)) == null) {//6
              ...
            }
            if (isolated) {
                r.isolatedProc = app;
            }
        }
 ...     
}

在註釋1處得到ServiceRecord的processName的值賦值給procName ，其中ServiceRecord用來描述Service的android:process屬性。註釋2處將procName和Service的uid傳入到AMS的getProcessRecordLocked方法中，來查詢是否存在一個與Service對應的ProcessRecord型別的物件app，ProcessRecord主要用來記錄執行的應用程式程序的資訊。註釋5處判斷Service對應的app為null則說明用來執行Service的應用程式程序不存在，則呼叫註釋6處的AMS的startProcessLocked方法來建立對應的應用程式程序，
具體的過程請檢視Android應用程式程序啟動過程（前篇）。

4.AMS家族

ActivityManager是一個和AMS相關聯的類，它主要對執行中的Activity進行管理，這些管理工作並不是由ActivityManager來處理的，而是交由AMS來處理，ActivityManager中的方法會通過ActivityManagerNative（以後簡稱AMN）的getDefault方法來得到ActivityManagerProxy(以後簡稱AMP)，通過AMP就可以和AMN進行通訊，而AMN是一個抽象類，它會將功能交由它的子類AMS來處理，因此，AMP就是AMS的代理類。AMS作為系統核心服務，很多API是不會暴露給ActivityManager的，因此ActivityManager並不算是AMS家族一份子。
為了講解AMS家族，這裡拿Activity的啟動過程舉例，Activity的啟動過程中會呼叫Instrumentation的execStartActivity方法，如下所示。
frameworks/base/core/java/android/app/Instrumentation.java

public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
      ...
        try {
            intent.migrateExtraStreamToClipData();
            intent.prepareToLeaveProcess(who);
            int result = ActivityManagerNative.getDefault()
                .startActivity(whoThread, who.getBasePackageName(), intent,
                        intent.resolveTypeIfNeeded(who.getContentResolver()),
                        token, target != null ? target.mEmbeddedID : null,
                        requestCode, 0, null, options);
            checkStartActivityResult(result, intent);
        } catch (RemoteException e) {
            throw new RuntimeException("Failure from system", e);
        }
        return null;
    }

execStartActivity方法中會呼叫AMN的getDefault來獲取AMS的代理類AMP。接著呼叫了AMP的startActivity方法，先來檢視AMN的getDefault方法做了什麼，如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java

 static public IActivityManager getDefault() {
        return gDefault.get();
    }
    private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");//1
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);//2
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }+
    };
}

getDefault方法呼叫了gDefault的get方法，我們接著往下看，gDefault 是一個Singleton類。註釋1處得到名為”activity”的Service引用，也就是IBinder型別的AMS的引用。接著在註釋2處將它封裝成AMP型別物件，並將它儲存到gDefault中，此後呼叫AMN的getDefault方法就會直接獲得AMS的代理物件AMP。註釋2處的asInterface方法如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java

static public IActivityManager asInterface(IBinder obj) {
    if (obj == null) {
        return null;
    }
    IActivityManager in =
        (IActivityManager)obj.queryLocalInterface(descriptor);
    if (in != null) {
        return in;
    }
    return new ActivityManagerProxy(obj);
}

asInterface方法的主要作用就是將IBinder型別的AMS引用封裝成AMP，AMP的構造方法如下所示。

frameworks/base/core/java/android/app/ActivityManagerNative.java

class ActivityManagerProxy implements IActivityManager
{
    public ActivityManagerProxy(IBinder remote)
    {
        mRemote = remote;
    }
...
 }

AMP的構造方法中將AMS的引用賦值給變數mRemote ，這樣在AMP中就可以使用AMS了。
其中IActivityManager是一個介面，AMN和AMP都實現了這個介面，用於實現代理模式和Binder通訊。
再回到Instrumentation的execStartActivity方法，來檢視AMP的startActivity方法，AMP是AMN的內部類，程式碼如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java

public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
           String resolvedType, IBinder resultTo, String resultWho, int requestCode,
           int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException {
     ...
       data.writeInt(requestCode);
       data.writeInt(startFlags);
     ...
       mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);//1
       reply.readException();+
       int result = reply.readInt();
       reply.recycle();
       data.recycle();
       return result;
   }

首先會將傳入的引數寫入到Parcel型別的data中。在註釋1處，通過IBinder型別物件mRemote（AMS的引用）向服務端的AMS傳送一個START_ACTIVITY_TRANSACTION型別的程序間通訊請求。那麼服務端AMS就會從Binder執行緒池中讀取我們客戶端發來的資料，最終會呼叫AMN的onTransact方法，如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java

   @Override
   public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
           throws RemoteException {
       switch (code) {
       case START_ACTIVITY_TRANSACTION:
       {
       ...
           int result = startActivity(app, callingPackage, intent, resolvedType,
                   resultTo, resultWho, requestCode, startFlags, profilerInfo, options);
           reply.writeNoException();
           reply.writeInt(result);
           return true;
       }
   }

onTransact中會呼叫AMS的startActivity方法，如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

 @Override
 public final int startActivity(IApplicationThread caller, String callingPackage,
         Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
         int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
     return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
             resultWho, requestCode, startFlags, profilerInfo, bOptions,
             UserHandle.getCallingUserId());
 }

startActivity方法會最後return startActivityAsUser方法，如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

 @Override
 public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
         Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
         int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
     enforceNotIsolatedCaller("startActivity");
     userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
             userId, false, ALLOW_FULL_ONLY, "startActivity", null);
     return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent,
             resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
             profilerInfo, null, null, bOptions, false, userId, null, null);
  }

startActivityAsUser方法最後會return ActivityStarter的startActivityMayWait方法，這一呼叫過程已經脫離了本節要講的AMS家族，因此這裡不做介紹了，具體的呼叫過程可以檢視Android深入四大元件（一）應用程式啟動過程（後篇）這篇文章。

在Activity的啟動過程中提到了AMP、AMN和AMS，它們共同組成了AMS家族的主要部分，如下圖所示。

AMS家族(7).png

AMP是AMN的內部類，它們都實現了IActivityManager介面，這樣它們就可以實現代理模式，具體來講是遠端代理：AMP和AMN是執行在兩個程序的，AMP是Client端，AMN則是Server端，而Server端中具體的功能都是由AMN的子類AMS來實現的，因此，AMP就是AMS在Client端的代理類。AMN又實現了Binder類，這樣AMP可以和AMS就可以通過Binder來進行程序間通訊。

ActivityManager通過AMN的getDefault方法得到AMP，通過AMP就可以和AMN進行通訊，也就是間接的與AMS進行通訊。除了ActivityManager，其他想要與AMS進行通訊的類都需要通過AMP，如下圖所示。

相關推薦

Android解析ActivityManagerService（一）AMS啟動流程和AMS家族

前言 此前在Android系統啟動流程、應用程序以及深入四大元件這三個系列文章中，都提及到了AMS，但都沒有系統的來講解它，本文就以AMS為主來進行講解，其中會有一些知識點與這些系列文章有所重合，這裡會儘量做到詳盡講解。閱讀此文章前，最好閱讀相關文章中

Android原始碼解析之（十）-->Launcher啟動流程

上一篇文章中我們講解了關於SystemServer程序相關的知識，我們知道SystemServer程序主要用於啟動系統的各種服務，二者其中就包含了負責啟動Launcher的服務，LauncherAppService。具體更多關於SystenServer的啟動

Android效能優化（一）App啟動原理分析及啟動時間優化

一、啟動原理解析 Android是基於Linux核心的，當手機啟動，載入完Linux核心後，會由Linux系統的init祖先程序fork出Zygote程序，所有的Android應用程式程序以及系統服務程序都是這個Zygote的子程序（由它fork出來的）。其中最重要的一個就

Android解析ActivityManagerService（二）ActivityTask和Activity棧管理

前言 關於AMS，原計劃是隻寫一篇文章來介紹，但是AMS功能繁多，一篇文章的篇幅遠遠不夠。這一篇我們接著來學習與AMS相關的ActivityTask和Activity棧管理。 1.ActivityStack ActivityStack從名稱

Android面試題（31）-App啟動流程

先貼個連結，總結的挺全面 在看這篇文章之前，希望先看完我的之前的部落格 android面試（6）-Binder機制，因為關於App啟動流程設計很多Binder通訊； 先將“三個程序”，“六個大類”進行介紹： 三個程序： Launcher程序：整個App啟動流程的起點，

【系統解讀】SystemUI篇（一）SystemUI啟動流程

前言        SystemUI是系統啟動中第一個使用者肉眼可見的應用，其功能包羅永珍，比如開機後看到的鎖屏介面，充電時充電介面，狀態列，導航欄，多工欄等，都是與Android手機使用者息息相關的功能。所以不止SystemUI開發者，普通的應用開發者也很有必要去了解

Android框架原始碼解析之（一）Volley

前幾天面試CVTE，HR面掛了。讓內部一個學長幫我查看了一下面試官評價，發現二面面試官的評價如下： 廣度OK，但缺乏深究能力，深度與實踐不足 原始碼：只能說流程，細節程式碼不清楚，retrofit和volley都是。 感覺自己一方面：自己面試技巧有待提高吧（框

Android 建立與解析XML（一）—— 概述

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

Android進階（一）： Launcher啟動過程

1.前言 最近一直在看 《Android進階解密》 的一本書，這本書編寫邏輯、流程都非常好，而且很容易看懂，非常推薦大家去看看（沒有收廣告費，單純覺得作者寫的很好）。 今天就將 Launcher 系統啟動過程 總結一下（基於Android 8.0 系統）。 文章

Android 創建與解析XML（一）—— 概述

四種 stream 大小 ora rda roc default 關系 建立 Android 是最常用的智能手機平臺，XML 是數據交換的標準媒介，Android 中可以使用標準的XML生成器、解析器、轉換器 API，對 XML 進行解析和轉換。 XML，相關有DOM

Android事件匯流排（一）EventBus3.0用法全解析

前言 EventBus是一款針對Android優化的釋出/訂閱事件匯流排。簡化了應用程式內各元件間、元件與後臺執行緒間的通訊。優點是開銷小，程式碼更優雅，以及將傳送者和接收者解耦。如果Activity和Activity進行互動還好說，如果Fragmen

Android動畫解析（一）-----逐幀動畫和補間動畫

今天專案又用到了動畫，發現之前掌握的那些又遺忘了不少，趁著有時間，再重新捋順一邊。 Android中的動畫分為 逐幀動畫，補間動畫，屬性動畫 三種. 逐幀動畫（Frame Animation） 逐幀動畫：就像GIF圖片一樣，通過一系列的Drawab

Android面試題（一）——Activity的生命週期和啟動模式

引言 這份面試題系列文章旨在查漏補缺，通過常見的面試題發現自己在Android基礎知識上的遺漏和欠缺，驗證所學是否紮實。 這是系列的第一章，後面我會根據安卓知識模組分類併網羅分析各種常見面試題。 面試題： Activity的生命週期 答

Android 建立與解析XML（一）---- SAX方式

 @Override  public String serialize(List<Book> books) throws Exception {   SAXTransformerFactory factory = (SAXTransformerFactory) TransformerFactory

Nginx實用教程（一）：啟動、停止、重載配置

style 負載 繼續 local con doc lin 配置文件的修改 tex Nginx是一個功能強大的web服務器和負載均衡軟件，由俄羅斯人開發。Nginx包括一個master進程和數個worker進程，master進程用於讀取、解析配置文件和管理worker進程，

Android 插件（一）之類加載器

load ron 概念 基本概念 android oid ont 基本上 style 1、類加載器基本概念 　　類加載器（class loader）用來加載 Java 類到 Java 虛擬機中。一般來說，Java 虛擬機使用 Java 類的方式如下：Java 源程序（.j

Linux故障處理（一）系統啟動類故障

侯良金 啟動故障 mbr修復 grub修復 Linux故障處理（一）系統啟動類故障在Linux系統的啟動過程中，涉及MBR主引導記錄、GRUB啟動菜單、系統初始化配置文件等各方面，其中任何一個環節出現故障都可能會導致系統啟動的失常，因此一定要註意做好相關文件的備份工作。（本實驗環境為RHEL6

Android View動畫（一） --- scale

for -- 縮放 記錄 1.0 使用 tco 關於 mod 在我們做apk開發的過程中，如果要吸引用戶，就需要要做出來一個非常炫的界面，當然動畫是必不可少的，接下來就記錄和學習動畫相關…… 接下來就把平時的一些東西，慢慢的上傳上來，做一下記錄和保存 今天要講解的第一個

Android系統架構（一）

查詢 核心 手機 例如 ava 模塊 api 操作系統 運行 　　一、Android系統版本簡介 　　Android操作系統已占據了手機操作系統的大半壁江山，截至本文寫作時，Android操作系統系統版本及其詳細信息，已發生了變化，具體信息見下表，當然也可以訪問https:

Android內存優化（一）Dalvik虛擬機和ART虛擬機對比

參考 -a 會有 font google 都是 http -s 轉換成 1.概述　　Android4.4以上開始使用ART虛擬機，在此之前我們一直使用的Dalvik虛擬機，那麽為什麽Google突然換了Android運行的虛擬機呢？答案只有一個：ART虛擬機更優秀。 2.D