1. 程式人生 > >從Activity的啟動流程理解Binder

從Activity的啟動流程理解Binder

簡述

關於Activity啟動流程和Binder的文章很多,大多數是分開來講的,本文將二者結合起來,著重分析啟動流程中跨程序方面的細節,其實,啟動流程看似呼叫繁多,主要是複雜在Activity棧管理等方面,如果將其看作一個整體,整個啟動流程就簡單很多。在啟動流程中,App和AMS的跨程序呼叫是其中的重點,理解了這個,會加深對Binder和啟動流程的理解認知,也能窺到Framework層的冰山一角。另外我也發現,很多文章在講啟動流程的時候,關於ActivityMangagerService程序如何呼叫App程序的細節都沒有講清楚,這個問題也是我寫這篇文章的初衷。閱讀本文前建議瞭解一下AIDL,對Binder,Stub,Proxy等有一些印象。建議讀一下這篇文章寫給 Android 應用工程師的 Binder 原理剖析

Binder簡介

對於Binder,初學的人會對裡面的概念比較模糊,因為看起來確實有些繞,我在這兒寫幾點幫助理解。

  • 所謂的“跨程序”能力指的是兩個方面:一個是能夠作為客戶端呼叫遠端服務的能力,一個是能夠作為服務端接收客戶端程序訊息的能力,二者都是跨程序的一部分,分別對應transact和onTransact方法,而這兩個方法的實現,分別位於BinderProxy和Binder兩個類中,這兩個類都在Binder.java這個檔案中,讀者可以自行閱讀。
  • BinderProxy具有傳送訊息的能力,通過transact方法,呼叫底層binder驅動,服務端的Binder具有接收底層binder驅動傳過來的訊息的能力,當接收到訊息會呼叫onTransact方法。
  • 剛開始看AIDL的時候需要反覆記憶理解一下,否則看別的程式碼容易混淆。這裡說幾個比較容易記憶的點:一個類繼承了Stub類,表示這個類是遠端服務端,Stub類有個asInterface的靜態方法,這個方法用在拿到binder驅動傳過來的BinderProxy物件時,將該物件轉化成client端使用的本地代理xxxProxy,客戶端用它呼叫遠端service的方法。該代理跟service實現了同樣的介面,只不過一個是真實現,一個是假實現,這裡假實現指的是它通過Binder驅動呼叫S端方法,真正做工作的在Service端。簡言之,Stub代表service端,Proxy代表service在客戶端的代理。
  • 以AMS為例
public class ActivityManagerService extends IActivityManager.Stub

AMS繼承了Stub類,而Stub類一共實現了三個介面:IActivityManger,IBinder,IInterface,分別對應了三種能力,管理activity、跨程序,以及IInterface的asBinder,前兩者好理解,那麼這裡的asBinder能力是幹嘛的呢?這裡先賣個關子,等下講啟動流程的時候會說明。

啟動流程

有了Binder的基礎,我們去看啟動流程,AMS和APP跨程序的過程簡單說就是C端和S端分別通過二者在對方的代理去互相呼叫對方方法的過程。我們先從巨集觀角度思考,為什麼要跨程序呢?我自己在客戶端new一個Activity不行嗎?不可以的,因為Android的安全機制以及為了統一管理Activity(比如activity棧),需要有個大管家去進行所有Activity的管理和控制,而這個管家是執行在一個單獨程序的,因此App端如果想發起一個Activity的請求,需要先把“申請”提交給大管家,也就是AMS。AMS處理完這個請求之後,需要再次通過跨程序通知App端,去執行剩下的相應的工作。因此這裡的核心就在於兩者如何互相呼叫對方了。

App端如何呼叫AMS方法

下面看程式碼:使用者啟動一個頁面時,會依次呼叫activity的startActivity-->Instrumentation的executestartActivity-->execStartActivitiesAsUser,這幾個呼叫很容易找到,就簡單帶過,在最後這個方法裡,執行了遠端呼叫,即:

 int result = ActivityManager.getService()
                .startActivities(whoThread, who.getBasePackageName(), intents, resolvedTypes,
                        token, options, userId);

ActivityManager.getService獲取的是什麼?看ActivityMangaer.getService()這個程式碼裡面:

    public static IActivityManager getService() {
        return IActivityManagerSingleton.get();
    }

    private static final Singleton<IActivityManager> IActivityManagerSingleton =
            new Singleton<IActivityManager>() {
                @Override
                protected IActivityManager create() {
                    final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                    final IActivityManager am = IActivityManager.Stub.asInterface(b);
                    return am;
                }
            };

如果對Binder有所瞭解,應該很容易知道,這裡取得的是AMS在客戶端的代理,也就是程式碼中的最後一行返回的am。因為App要頻繁的呼叫AMS的方法,因此用單例模式快取在本地了一個AMS的本地代理,從單例的第一次獲取可以看到,AMS的Binder是通過ServiceManager.getService()獲取到的,那麼ServiceMangaer是個什麼東西,其實這個就是Android系統統一管理所有遠端服務的“大管家”,比如AMS,WMS等系統服務都在這裡註冊了,客戶端想呼叫任意一個服務,只需要知道名字就可以通過SM獲取到相應的Server的Binder。拿到Binder之後便可以通過asInterface靜態方法轉化成本地代理,從而呼叫server的方法了。因此第一次獲取AMS的Binder的過程實際上是客戶端跟ServiceManager的一次跨程序通訊。

AMS如何通知App程序

(1)AMS如何獲取到App程序的Binder的

從上面的分析知道,App獲取AMS的Binder實際上是通過ServiceManager這個大管家間接獲取的,那反過來AMS處理完activity的管理任務(棧操作等)之後又如何通知App的呢?
一個App總不可能像AMS那樣在ServiceManger中註冊吧,而且也沒這個必要。那麼到底是怎麼通知的呢?
答案就是:App跨程序呼叫AMS的方法時,還順便把App程序(這個時候App可以看作是服務端了)的Binder作為引數傳給了AMS,AMS拿到這個APP的Binder之後,通過asInterface方法轉化成在server端可以使用的代理,然後在需要回調App程序的時候通過這個代理來通知客戶端。其實跟App端邏輯是一致的,只不過C/S調了一下順序,C變成了S,S變成了C。下面我們從程式碼裡驗證:
我們以6.0之前版本的原始碼為例,新版本改成事務了,有些原始碼不容易看到,不如直接看老版本的,便於理解。
首先看APP呼叫startActivity時是如何把App程序的Binder引數傳過去的,剛才說了,startActivity實際上呼叫的是AMS本地代理的startActivity,而AMS本地代理是ActivityMangerProxy,這裡AMP是AIDL自動生成的

class ActivityManagerProxy implements IActivityManager
{
    public ActivityManagerProxy(IBinder remote)
    {
        mRemote = remote;
    }
    
    public IBinder asBinder()
    {
        return mRemote;
    }
    
    public int startActivity(IApplicationThread caller, Intent intent,
            String resolvedType, Uri[] grantedUriPermissions, int grantedMode,
            IBinder resultTo, String resultWho,
            int requestCode, boolean onlyIfNeeded,
            boolean debug, String profileFile, ParcelFileDescriptor profileFd,
            boolean autoStopProfiler) throws RemoteException {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeStrongBinder(caller != null ? caller.asBinder() : null);
        intent.writeToParcel(data, 0);
        data.writeString(resolvedType);
        data.writeTypedArray(grantedUriPermissions, 0);
        data.writeInt(grantedMode);
        data.writeStrongBinder(resultTo);
        data.writeString(resultWho);
        data.writeInt(requestCode);
        data.writeInt(onlyIfNeeded ? 1 : 0);
        data.writeInt(debug ? 1 : 0);
        data.writeString(profileFile);
        if (profileFd != null) {
            data.writeInt(1);
            profileFd.writeToParcel(data, Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
        } else {
            data.writeInt(0);
        }
        data.writeInt(autoStopProfiler ? 1 : 0);
        mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);
        reply.readException();
        int result = reply.readInt();
        reply.recycle();
        data.recycle();
        return result;
    }

startActivity方法的第一個引數caller,這個東西是IApplicationThread,這個IApplicationThread就是AMS去通知App做相應處理的介面,它跟IActivityManger配合組成了App和AMS互動的“協議”。那麼這個傳過來的IApplicationThread的是誰呢,通過看程式碼裡的呼叫鏈:

Instrumentation:
int result = ActivityManager.getService()
                .startActivityAsUser(whoThread, who.getBasePackageName(), intent,
                        intent.resolveTypeIfNeeded(who.getContentResolver()),
                        token, resultWho,
                        requestCode, 0, null, options, user.getIdentifier());


ContextImpl:
        mMainThread.getInstrumentation().execStartActivities(
                getOuterContext(), mMainThread.getApplicationThread(), null,
                (Activity) null, intents, options);

ActivityThread:
    public ApplicationThread getApplicationThread()
    {
        return mAppThread;
    }

可以查到,首先是instrumentation類裡傳入的whoThread,whoThread是ContextImpl傳進來的mMainThread.getApplicationThread(),而最後這個是mAppThread,這個東西就是ActivityThread這個類的內部類ApplicationThread,我們看程式碼:

 private class ApplicationThread extends IApplicationThread.Stub {

繼承自Stub,因此從AIDL語法看出,是一個服務端,對應的客戶端是誰呢?當然是AMS了,所以ApplicationThread這個類就是AMS向App程序發訊息時的服務端。

思路回到主線上,上面已經說明了,在客戶端呼叫Binder的時候把ApplicationThread引數傳給了AMP的startActivity方法,接下來會執行到:

data.writeStrongBinder(caller != null ? caller.asBinder() : null);

注意這裡的caller.asBinder,這個方法就解釋了前面遺留的問題,IInterface介面的方法asBinder就是在這個時候用的,即把S端(相對的)轉成一個binder,之後binder寫入到Parcel裡,然後通過transact方法呼叫底層Binder驅動傳給其他程序,這裡也要注意,transact方法呼叫的是mRemote的transact,而mRemote本質上是一個BinderProxy,千萬不要理解成Binder了,因為這兩個類都實現了IBinder介面,我們看程式碼的時候很可能會誤認為呼叫的Binder的transact。binderProxy的transact會呼叫transactNative函式,傳給jni層,將之前儲存在Parcel裡的資料data傳給Binder驅動,之後在傳給AMS。可以這樣理解,對於Binder驅動來說,它可以看成跨程序的一個“傳送帶”,從A程序傳遞給B程序,只要你實現了IInterface,就可以放到這個傳送帶上傳送(writeStrongBinder方法)。總結一下就是IInterface介面表明了這個類可以轉成一個binder從而在binder驅動中跨程序運輸,IBinder介面表明了類具有跨程序的能力,即可以通過呼叫transact方法“使用”Binder驅動。

(2)獲取到了Binder之後

上面的討論已經知道,AMS其實在App跨程序呼叫AMS的時候就把ApplicationThread轉成Binder傳過來了,傳過來以後,AMS如果要用,必須得拿到ApplicationThread的代理,怎麼拿到的呢?
剛才說了AMS的onTransact方法會監聽驅動傳過來的物件,我們看onTransact的程式碼:AMS繼承自IActivityManager.Stub,在原始碼中叫ActivityManagerNative:

    public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
            throws RemoteException {
        switch (code) {
        case START_ACTIVITY_TRANSACTION:
        {
            data.enforceInterface(IActivityManager.descriptor);
            IBinder b = data.readStrongBinder();
            IApplicationThread app = ApplicationThreadNative.asInterface(b);

可以看到:
IBinder b = data.readStrongBinder();客戶端將binder write到Parcel中,服務端從Parcel中讀了出來,然後通過asInterface轉換成ApplicationThread的代理ApplicationThreadProxy這個類。注意:Binder驅動過來的IBinder不是Binder,而是BinderProxy,但是為什麼我們之前傳的引數是ApplicationThread,這個類是一個binder,為什麼讀出來以後變成了BinderProxy了呢?答案就在這個readStrongBinder裡,看jni層的原始碼可以知道,系統在客戶端收到(readStrongBinder)IBinder以後,會儲存下來,通過Binder驅動傳給Service時,會通過之前儲存的Binder在底層建立BinderProxy,然後傳給上層,其實看framework的原始碼,BinderProxy沒有看到在java層的new方法,原來都在底層建立好了。
有了代理物件後接下來既可以直接用了:

int result = startActivity(app, intent, resolvedType,
                    grantedUriPermissions, grantedMode, resultTo, resultWho,
                    requestCode, onlyIfNeeded, debug, profileFile, profileFd, autoStopProfiler);

即進入到AMS對Activity啟動管理流程中了,經過複雜的跳轉,最後跑到ActivityStackSupervisor這個類的realStartActivityLocked方法中,裡面最終會執行到這行程式碼:

app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                    System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration),
                    r.compat, r.task.voiceInteractor, app.repProcState, r.icicle, r.persistentState,
                    results, newIntents, !andResume, mService.isNextTransitionForward(),
                    profilerInfo);

這裡的app.thread就是前面ApplicationThread在AMS中的代理,到了這裡大家應該理清楚了,接下來通過代理調起App程序的ApplicationThread裡的相應方法,即:scheduleLaunchActivity方法,這個方法會發送一個Message給主執行緒的handler :H,然後在handleMessage裡通過類載入器創建出一個Activity物件,並執行onCreate方法.balabala....

最後用圖片總結一下:

最後推薦一篇文章,目前發現的講的binder最詳細的,聽說你 Binder 機制學的不錯,來解決下這幾個問