debug方式看Activity启动流程小记

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

1.前言

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

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

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

2.官方模拟器一份

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

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

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

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

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

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

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

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

系统进程里面接着往下走

系统进程里面接着往下走

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

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

系统的ApplicationThreadNative发过来的消息，还是app的ApplicationThreadNative接受的，和上面 app进程AMN发的消息还是系统进程的AMN收一样（真的是，自己约的那啥，跪着也要打完啊）<br>
继续走

发现最终是掉了ApplicationThreadNative子类 ApplicationThread的方法了呀，事后还发了一个信息，每错就是 ActivityThread.H类接收处理的

好了基本流程就到这里了

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