Activity启动流程虽然很多博客讲了很多次了，但是这一次是自己的亲身体会

1.前言

debug需要gradle里面编译版本和官方模拟器api版本一致(这里源码是api25)

2.准备材料

1.app里面一份稀松平常的跳转activity代码

Intent intent = new Intent();
            intent.setClass(MainActivity.this,Main2Activity.class);
            startActivity(intent);

2.官方模拟器一份

模拟器使用带api的才有root权限

adb root
adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
adb reboot

#3. 断点列表

4.从startActivity(intent);开始debug吧！

attach上2个进程左边是app进程（8626）,右边是系统进程（8600）

接下来就是旅途开始的地方了

从 onClick开始 调用 startActivity,实际上是调用了 Activity类的startActivityForResult 方法，接着调用了 ActivityManagerNative 中内部类的 ActivityManagerProxy 的 startActivity。
核心就是 断点这句 mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);

看看这个transact方法是个什么鬼，居然调用了jni 的native方法

c++层不细说，毕竟不能暴露自己c++弱鸡的本质，但是可以教大家一个看通过native方法名查询对应c++源码的方法如下图：

接下来不要留恋c++层了 我继续走断点了

这里 看到 最底层的 Binder execTransact方法的注释

看这句注释，所有来自 binder.cpp的binder数据接收都会走到这里，发现了跨进程通信的秘诀了有木有(mRemote发完 execTransact收 )
刚刚 我们app进程 AMN的 mRemote发过来的数据 是在系统进程AMN接收的

系统进程里面接着往下走

系统进程里面接着往下走

如上图所示，又看见了熟悉的跨进程发消息的函数了，这次不是AMN发的，而是ApplicationThreadNative发的

既然发系统进程发了东西，接下来app进程就该收到快递了

系统的ApplicationThreadNative发过来的消息，还是app的ApplicationThreadNative接受的，和上面 app进程AMN发的消息还是系统进程的AMN收一样（真的是，自己约的那啥，跪着也要打完啊）
继续走 发现最终是掉了ApplicationThreadNative子类 ApplicationThread的方法了呀，事后还发了一个信息，每错就是 ActivityThread.H类接收处理的

好了基本流程就到这里了

5.做个小总结吧：

app的 AMP 发消息 给 系统进程的 AMN，系统进程的 AMN 用ApplicationThreadNative 发消息 给 app进程的 ApplicationThreadNative ， app进程的 ApplicationThreadNative 负责发个msg 给 ActivityThread.H 的handleMsg方法处理。