简单解析Activity的启动过程今天再次查看了Activity的启动过程，这对于加强开发人员的内功是很有帮助的。但是有

今天再次查看了Activity的启动过程，这对于加强开发人员的内功是很有帮助的。但是有一点，由于Android的内部实现多数是比较复杂，在研究内部实现上应该更加侧重于对整体流程的把握，而不能深入代码细节不能自拔，太深入代码细节往往只会导致“只见树木不见森林”的状态。

这个过程设计到IPC的Binder机制，不清楚Binder机制的小伙伴莫慌，不影响本篇文章的阅读，先看完整个流程，对你有意向不到的收获。

从Activity的startActivity方法开始，最终会调用startActivityForResult方法，用伪代码如下

public class Activity {
    public ActivityThread mMainThread;
    public Instrumentation mInstrumentation;
    public void startActivity() {
        startActivityForResult();
    }
}

startActivityForResult方法中调用Instrumentation.execStartActivity()方法，这样启动流程就转移到Instrumentation类中了。

第一次转移启动流程转移到了Instrumentation类中，查看execStartActivity()方法， Instrumentation.execStartActivity()

方法调用了

ActivityManagerNative.getDefault().startActivity()

这样启动流程就转移到ActivityManagerNative.getDefault()类中了。

第二次转移 ActivityManagerNative是个抽象类，查看getDefault()方法返回实例对象。

public abstract class ActivityManagerNative {
    static public IActivityManager getDefault() {
        return ActivityManager.getService();
    }
}

接着追踪

public class ActivityManager {
    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;
                }
            };
    public static IActivityManager getService() {
        return IActivityManagerSingleton.get();
    }
}

追到最后其实就是调用了Singleton.create()方法创建的IActivityManager实例，其实就是AMS在客户端的代理对象，这里的涉及到了IPC调用Binder机制，AMS.startActivity()的调用就在Binder线程中执行了，客户端线程挂起，交给Binder线程来处理，但是这个过程是异步的并非同步，所以AMS.startActivity()方法会立刻返回，不会造成UI线程阻塞。 ActivityManagerService类是一个Binder类。

public class ActivityManagerService extends IActivityManager.Stub {
    
}

第三次转移由AMS来实现启动Activity，这个过程是在Binder线程中执行的。 ActivityManagerService.startActivity()

方法中调用

ActivityStackSupervisor.startActivityMayWait()

这样启动流程就转移到ActivityStackSupervisor类中了。

第四次转移 ActivityStackSupervisor.startActivityMayWait()

方法中调用

ActivityStackSuperVisor.startActivityLocked()

发放中调用

ActivityStackSuperVisor.startActivityUnckeckedLocked()

方法中调用了

ActivirtStack.resumeTopActivitiesLocked()

这样启动流程就转移到ActivirtStack类中了。

第五次转移 ActivirtStack.resumeTopActivitiesLocked()

方法中调用

ActivirtStack.resumeTopActivityInnerLocked()

方法中调用

ActivityStackSuperVisor.startSpecificActivityLocked()

流程再次交给了ActivityStackSupervisor类，这样启动流程就再次转移到ActivityStackSupervisor类中了。

第六次转移 ActivityStackSuperVisor.startSpecificActivityLocked()

方法中调用

ActivityStackSuperVisor.realStartActivityLocked()

就这样Activity的启动过程在ActivityStackSupervisor和ActivityStack之间传递。

ActivityStackSuperVisor.realStartActivityLocked()

方法中调用

ApplicationThread.scheduleLaunchActivity()，

即app.thread.scheduleLaunchActivity()，app.thread是IApplicationThread类型，IApplicationThread实现者是ActivityThread的内部类ApplicationThread。

private class ApplicationThread extends IApplicationThread.Stub {
    
    
}

ApplicationThread类是Binder类，再次涉及到IPC的Binder机制，把调用切回到了客户端Binder线程。

饶了一大圈Activity的启动过程最终回到了ApplicationThread类中，ApplicationThread.scheduleLaunchActivity()

方法中发送消息到ActivityThread线程的Handler，操作交给了UI线程来执行。

第七次转移 ActivityThread内部类H，H继承Handler，重写handleMessage()方法。 Handler.handleMessage()

方法中调用

ActivityThread.handleLaunchActivity()

这样启动流程就转移到调用ActivityThread类中了。

第八次转移 ActivityThread.handleLaunchActivity() { ActivityThread.performLaunchActivity()//方法最终完后Activity对象的创建和启动过程 ActivityThread.handleResumeActivity()//调用Activity的生命周期函数onResume() }
第九次转移 ActivityThread.performLaunchActivity()

方法做的事情比较多。

1.从ActivityClientRecord中获取待启动的Activity组件信息。

2.通过Instrumentation.newActivity()方法使用类加载器创建Activity对象。

3.调用LoadedApk.makeApplication()方法，makeApplication()方法中调用Instrumentation.newAppliction()来尝试创建Application对象。为什么收拾尝试呢，因为Application已经被创建过了，那么就不会再重复创建了。

4.创建ContextImpl对象并调用Activity.attach()方法来完成一些重要数据的初始化。

5.调用Activity生命周期方法onCreate()

这样就完后了一次Activity启动。