2.准备材料Activity启动流程虽然很多博客讲了很多次了,但是这一次是自己的亲身体会
1.前言debug需要gradle里面编译版本和官方模拟器api版本一致(这里源码是api25)
1.app里面一份稀松平常的跳转activity
代码
Intent intent = new Intent();
intent.setClass(MainActivity.this,Main2Activity.class);
startActivity(intent);
2.官方模拟器一份
3. 断点列表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类接收处理的
好了基本流程就到这里了
5.做个小总结吧:app的 AMP 发消息 给 系统进程的 AMN,系统进程的 AMN 用ApplicationThreadNative 发消息 给 app进程的 ApplicationThreadNative ,
app进程的 ApplicationThreadNative 负责发个msg 给 ActivityThread.H 的handleMsg方法处理。
热门评论
好奇你怎么attcha 上 AMS 的代码的?
我这里没有呢,只能attcha 上应用的代码