Android - AMS源碼分析

標籤：end   nat   回調   靜態   觀察   ide   png   androi   server   

Android核心分析之AMS

 

 

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

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

 

開啟一個APPLauncher

Launcher負責案頭表徵圖的顯示和控制，本質上也是一個應用程式，和我們的App一樣，也是繼承自Activity

以雙擊開啟一個APP為例：

不管在哪裡點擊表徵圖，都會調用

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

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

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

 

InstrumentationInstrumentation，每一個應用程式只有一個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許可權

 

Service

Service是什麼

    Service是Android系統的組件之一，和Activity，Broadcast，Conent Provider並稱Android四大組件，Service是不可見的，是沒有介面的，是在後台啟動並執行，Service一般處理比較耗時以及長時間啟動並執行操作

Service的啟動有兩種方式：

 1. startService主要用於啟動一個服務執行背景工作，不進行通訊，停止服務使用stopService

 2. bindService該方法啟動的服務可以獲得該service的狀態，停止服務使用unbindService

 

Android - AMS源碼分析