Android - AMS源碼分析

本文轉載自查看原文 2017-08-06 21:54 2262 AMS/ Android

Android核心分析之AMS

App和AMS(SystemServer進程)還有zygote進程分屬於三個獨立的進程

App與AMS通過Binder進行IPC通信，AMS(SystemServer進程)與zygote通過Socket進行IPC通信。

打開一個APP

Launcher

Launcher負責桌面圖標的顯示和控制，本質上也是一個應用程序，和我們的App一樣，也是繼承自Activity

以雙擊打開一個APP為例：

不管在哪里點擊圖標，都會調用

mLauncher.startActivitySafely(v, appInfo.intent, appInfo);

這個方法，最后調用startActivityForResult()

而startActivityForResult()調用的是mInstrumentation.execStartActivity()。

Instrumentation

Instrumentation，每一個應用程序只有一個Instrumentation對象，每個Activity內都有一個對該對象的引用。Instrumentation可以理解為應用進程的管家，ActivityThread要創建或暫停某個Activity時，都需要通過Instrumentation來進行具體的操作。

AMS是董事會，負責指揮和調度的，ActivityThread是老板，雖然說家里的事自己說了算，但是需要聽從AMS的指揮，而Instrumentation則是老板娘，負責家里的大事小事，但是一般不拋頭露面，聽一家之主ActivityThread的安排。

AMS和ActivityThread之間的Binder通信

mInstrumentation.execStartActivity()接下來調用了這個方法

ActivityManagerNative.getDefault()
                .startActivity

這里的ActivityManagerNative.getDefault返回的就是ActivityManagerService的遠程接口，即ActivityManagerProxy。

再看ActivityManagerProxy.startActivity()，在這里面做的事情就是IPC通信，利用Binder對象，調用transact()，把所有需要的參數封裝成Parcel對象，向AMS發送數據進行通信。

ActivityManagerNative源碼：

public abstract class ActivityManagerNative extends Binder implements IActivityManager
{

//從類聲明上，我們可以看到ActivityManagerNative是Binder的一個子類，而且實現了IActivityManager接口
 static public IActivityManager getDefault() {
        return gDefault.get();
    }

 //通過單例模式獲取一個IActivityManager對象，這個對象通過asInterface(b)獲得
 private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };
}


//最終返回的還是一個ActivityManagerProxy對象
static public IActivityManager asInterface(IBinder obj) {
        if (obj == null) {
            return null;
        }
        IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            return in;
        }

     //這里面的Binder類型的obj參數會作為ActivityManagerProxy的成員變量保存為mRemote成員變量，負責進行IPC通信
        return new ActivityManagerProxy(obj);
    }


}

很清楚看到ActivityManagerNative繼承Binder，是Binder本地對象。IActivityManager是遠程接口，代表AMS能提供的功能。

ActivityManagerProxy是AMS的遠程代理對象，Activity可以通過代理對象調用AMS提供的接口中方法。

所以App與AMS通過Binder進行IPC通信

AMS向ActivityThread通信

以上解釋了activity向AMS通信的方法，

如果AMS想要通知ActivityThread做一些事情，應該咋辦呢？

還是通過Binder通信，不過是換了另外一對，換成了ApplicationThread和ApplicationThreadProxy。

private class ApplicationThread extends ApplicationThreadNative {}

  public abstract class ApplicationThreadNative extends Binder implements IApplicationThread{}

  class ApplicationThreadProxy implements IApplicationThread {}

AMS接收到客戶端的請求之后，會如何開啟一個Activity？

可以看上面那個圖，大致就是AMS得到activity棧的引用，然后根據啟動模式添加到棧中，最后回調applicationThread執行原activity的pause

廣播

為什么需要廣播

廣播是操作系統framework層對觀察者模式(observer)最常用的實現方式

一個軟件系統常常要求在某一個對象的狀態發生變化的時候，某些其它的對象做出相應的改變。做到這一點的設計方案有很多，但是為了使系統能夠易於復用，應該選擇低耦合度的設計方案。減少對象之間的耦合有利於系統的復用，但是同時設計師需要使這些低耦合度的對象之間能夠維持行動的協調一致，保證高度的協作。觀察者模式是滿足這一要求的各種設計方案中最重要的一種。

廣播發送的api有：

•sendBroadcast

•sendOrderBroadcast

•sendStickyBroadcast

•

監聽廣播的方式有：

•動態注冊使用registerReceiver方式

•靜態注冊在AndroidManifest.xml中定義BroadcastReceiver類並實現

廣播有哪幾種

廣播有無序廣播、有序廣播和粘性廣播，其中粘性廣播需要有BROADCAST_STICKY權限