Android应用程序启动流程之从startActivity开始

1.简介:

Android系统中,应用程序是由框架创建的。通过startAcitivty函数可以启动一个应用程序,那么,startActivity到底做了些什么,以至于这样一个简单的几行代码就能调用起一个应用程序。本节分析startActivity的执行流程。

2.从Activity的startActivity开始:

当调用startActivity函数时,通过Android Binder机制, 调用到ActivityManagerService.再由ActivityManagerService去创建Java层的Process。
并且最终通过Zygote的fork去真正的创建出一个进程,当然,这个进程可以在adb终端使用ps命令列出来。

当点击一个桌面app图标时,会调用startActivityForResult,然后,会调用到Instrumentation.execStartActivity,并且最终调用到ActivityMangerService的startActivity中,整个流程如下:

 2.1 startActiivy时序图如下:

Android应用程序启动流程之从startActivity开始_第1张图片

这样,代码就进入到ActivityManagerService中了,如下图:

Android应用程序启动流程之从startActivity开始_第2张图片

可见,ActivityStack对activity进行了管理。

在1.9startSpecificActivityLocked中,会判断app创建没有,如果创建了,就调用

realStartActivityLocked,

否则,就会调用startProcessLocked。

2.2 分支一:realStartActivityLocked函数分析:

最关键的就是:

app.thread.scheduleLaunchActivity

方法的调用。这个app.thread类型是

IApplicationThread

所以,这里通过Binder调用到了ApplicationThreadNative的scheduleLaunchActivity,然后,又调用到了ActivityThread的“scheduleLaunchActivity”。

ActivityThread的scheduleLaunchActivity方法:

queueOrSendMessage(H.LAUNCH_ACTIVITY, r);   ->

    mH.sendMessage(msg);

->

H.handleMessage()中,有:

case LAUNCH_ACTIVITY: {
     Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
     ActivityClientRecord r = (ActivityClientRecord)msg.obj;

     r.packageInfo = getPackageInfoNoCheck(
                     r.activityInfo.applicationInfo, r.compatInfo);
     handleLaunchActivity(r, null);
     Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}


handleLaunchActivity方法调用了

performLaunchActivity

,在这个方法中,创建了Activity(终于,Activity创建):

//performLaunchActivity方法的实现:
        Activity activity = null;
        try {
            java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
            StrictMode.incrementExpectedActivityCount(activity.getClass());
            r.intent.setExtrasClassLoader(cl);
            if (r.state != null) {
                r.state.setClassLoader(cl);
            }
        } 

        ......

        Application app = r.packageInfo.makeApplication   

        ......

        activity.attach

        ......

        mInstrumentation.callActivityOnCreate(activity, r.state);

这样,通过mInstrumentation 创建了Activity,并且执行attach后,再执行

callActivityOnCreate

就进入到Activity的OnCreate生命周期了。

2.3 分支二:startProcessLocked的执行

在执行到startProcessLocked时,代码由ActivityStack进入到ActivityManagerService中,继续执行,如下图:

Android应用程序启动流程之从startActivity开始_第3张图片

在Process.java中,有

            argsForZygote.add("--runtime-init");
            argsForZygote.add("--setuid=" + uid);
            argsForZygote.add("--setgid=" + gid);

            ......
    
            zygoteSendArgsAndGetResult(argsForZygote)

 openZygoteSocketIfNeeded函数的实现:

try {
                sZygoteSocket = new LocalSocket();

                sZygoteSocket.connect(new LocalSocketAddress(ZYGOTE_SOCKET, 
                        LocalSocketAddress.Namespace.RESERVED));

                sZygoteInputStream
                        = new DataInputStream(sZygoteSocket.getInputStream());

                sZygoteWriter =
                    new BufferedWriter(
                            new OutputStreamWriter(
                                    sZygoteSocket.getOutputStream()),
                            256);

                Log.i("Zygote", "Process: zygote socket opened");

                sPreviousZygoteOpenFailed = false;
                break;
            } catch (IOException ex) {
                ......
            }

分析:

创建一个LocalSocket sZygoteSocket,作为client通过调用sZygoteSocket.connect 去连接socket,而作为服务端的socket,就是在Zygote初始化时在runSelectLoop中进行监听的套接字,然后,在Zygote中去真正地用fork创建进程。

参见:

Android系统的心脏-Zygote进程如何fork一个新的应用进程

 这样,进程就创建好了。

进程创建好之后,代码回到Process.java中,继续执行。保存进程状态,然后,去创建ActivityThread。(在Process.start时,就将ActivityThread这个类名传递过来了)。

3. ActivityThread:

我们继续分析Application的创建过程(即“分支二:startProcessLocked的执行”的继续执行)

在ActivityThread的main函数中,主要功能:

1)创建Thread;并调用attach方法;

2)进行Application的attach;

3)进行Handler的创建和message的处理;

4)AsyncTask的初始化。

3.1 ActivityThread中的main函数

直接看ActivityThread中的main函数:

public static void main(String[] args) {

        ......

        Looper.prepareMainLooper();

        if (sMainThreadHandler == null) {
            sMainThreadHandler = new Handler();
        }

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        AsyncTask.init();

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

 thread.attach()的实现:

IActivityManager mgr = ActivityManagerNative.getDefault();
    mgr.attachApplication(mAppThread);

3.2 attachApplication方法的执行序列(通过Binder机制实现):

1) 从Client端到Server端:

注意,这里的mgr是ActiivtyManagerProxy的实例,而ActiivtyManagerProxy是Binder机制中的Client端,是服务端AMS(ActivityManagerService)的代理。

再通过Binder IPC机制调用到AMS的对应的方法中,调用序列如下:

1. client端:

ActivityManagerNative.getDefault://获取ActivityManagerProxy

ActivityManagerProxy.attachApplication -> mRemote.transact, 如下:

    public void attachApplication(IApplicationThread app) throws RemoteException
    {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeStrongBinder(app.asBinder());
        mRemote.transact(ATTACH_APPLICATION_TRANSACTION, data, reply, 0);
        reply.readException();
        data.recycle();
        reply.recycle();
    }

这样,通过Binder机制就执行到了ActivityManagerService中了。

2. server端:

在ActivityManagerNative中,有对ATTACH_APPLICATION_TRANSACTION的处理(这时,已经是在Service执行这个case了):

case ATTACH_APPLICATION_TRANSACTION: {
            data.enforceInterface(IActivityManager.descriptor);
            IApplicationThread app = ApplicationThreadNative.asInterface(
                    data.readStrongBinder());
            if (app != null) {
                attachApplication(app);
            }
            reply.writeNoException();
            return true;
        }

而这里的attachApplication方法就在ActivityManagerService中有实现,代码如下:

    public final void attachApplication(IApplicationThread thread) {
        synchronized (this) {
            int callingPid = Binder.getCallingPid();
            final long origId = Binder.clearCallingIdentity();
            attachApplicationLocked(thread, callingPid);
            Binder.restoreCallingIdentity(origId);
        }
    }

调用到server端:ActivityManagerNative  ->ActivityManagerService。

继续AMS的attachApplication的分析,就执行到AMS中的对应的

attachApplicationLocked

方法中了,这个方法非常重要,接下来分析一下。

2)AMS中attachApplicationLocked方法的分析:

在attachApplicationLocked方法中,关键调用了下面这个方法:

thread.bindApplication(processName, appInfo, providers,...)//省略若干参数

说明:

这里的thread是IApplicationThread类型,而且thread是Client端,真正类型是ApplicationThreadProxy,即服务端的代理。而这个ApplicationThreadProxy是在ApplicationThreadNative中定义的。

所以,我们来分析ApplicationThreadProxy的bindApplication方法的实现。

继续分析,ApplicationThreadProxy的bindApplication方法的实现:

public final void bindApplication(String packageName, ApplicationInfo info,
            ......) throws RemoteException {

        Parcel data = Parcel.obtain();
        data.writeInterfaceToken(IApplicationThread.descriptor);
        data.writeString(packageName);
        info.writeToParcel(data, 0);

        ...... //都是data.write方法
        
        
        mRemote.transact(BIND_APPLICATION_TRANSACTION, data, null,
                IBinder.FLAG_ONEWAY);
        data.recycle();
}

mRemote.transact最终调用到ApplicationThreadNative中,即Service端。

3)服务端对BIND_APPLICATION_TRANSACTION的处理:

mRemote是IBinder类型,而真正的实例是ActivityThread。

原因如下:

ApplicationThreadNative是抽象类,无法实例化;

ActivityThread是继承自ApplicationThreadNative的具体类;

所以,mRemote其实是ActivityThread的实例。

然后,就是BIND_APPLICATION_TRANSACTION的处理:

mRemote.transact通过binder机制,调用到ApplicationThreadNative中去处理。

代码如下:

case BIND_APPLICATION_TRANSACTION:
        {
            data.enforceInterface(IApplicationThread.descriptor);
            String packageName = data.readString();
            ApplicationInfo info =
                ApplicationInfo.CREATOR.createFromParcel(data);
            
            ......
            
            bindApplication(packageName, info,
                            providers, testName, profileName, profileFd, autoStopProfiler,
                            testArgs, testWatcher, testMode, openGlTrace, restrictedBackupMode,
                            persistent, config, compatInfo, services, coreSettings);
            return true;
        }

这里的bindApplication是在ApplicationThread中实现的。前面已经分析过,ApplicationThread是ApplicationThreadNative的子类。所以在ApplicationThreadNative中的代码调用,其实就是ApplicationThread的代码的执行。

4)ApplicationThread的bindApplication方法:

在ApplicationThread的bindApplication方法中,最后一条语句

queueOrSendMessage(H.BIND_APPLICATION, data);

发送了message,在H 这个handler类中,对message的处理如下:

case BIND_APPLICATION:
                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
                    AppBindData data = (AppBindData)msg.obj;
                    handleBindApplication(data);
                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                    break;

接着,我们看

handleBindApplication

5) handleBindApplication的分析:

好像看到一些曙光了。再次说明一下,我们分析这部分代码的目的是:为了分析清楚一个App是如何被创建和初始化的。也就是说,Application的onCreate函数是如何被执行的。

在handleBindApplication中,关键点如下:

1. mInstrumentation的创建;

 mInstrumentation = new Instrumentation(); //如果已经创建,就不需要new了

2. Application的创建;

Application app = data.info.makeApplication(data.restrictedBackupMode, null);

3. 通过mInstrumentation的

callApplicationOnCreate

来启动App:

        mInstrumentation.callApplicationOnCreate(app);

Instrumentation.callApplicationOnCreate的实现:

到了这里,只需要一句代码即可:

public void callApplicationOnCreate(Application app) {
        app.onCreate();
}

这样,就调用到了app的onCreate()方法了。

至此,整个分析流程结束。

4. 总结:

1. 一系列的startActivity的调用;

2. AMS(ActivityManagerService)相关的关键组件:

ActivityManager //可以认为是对ActivityManagerProxy的封装

ActivityManagerProxy //作为客户端;

ActivityManagerNative //抽象类,无法实例化;

ActivityManagerService //继承自ActivityManagerNative,具体类,作为服务端;

3. ApplicationThread相关的关键的组件:

ApplicationThreadProxy //作为客户端;

ApplicationThreadNative //抽象类,无法实例化;

ApplicationThread //继承自ApplicationThreadNative,具体类,作为服务端;

4. Instrumentation //Activity和Application的启动,都要由它来触发。

可见,从binder的角度来看,AMS和ApplicationThread的组件架构几乎一样。这是Android系统服务中典型的服务实现方式。


你可能感兴趣的:(Android系统源码分析,zygote,Android,zygote,应用启动流程,startActivity,android,进程)