Activity-Hook填坑过程中温故而知新(2)，裸辞奋战25天三面美团-CSDN博客

本文链接：https://blog.csdn.net/2201_75604580/article/details/136956156

跳转过程中，只出现了onCreate onStart onResume, 照理说，跳转之后应该有 onPause onStop. 并且我回到这个Activity时，应该会有 onRestart onStart onResume, 但是也没有。

源码探索

为什么生命周期函数都不执行了？要找到这个原因，我必须先弄清楚一个问题: Activity的生命周期函数到底是由谁来调用的。

前期准备:

这里我不使用Demo工程，而是另外自己新建一个工程，写一个普通的startActivity跳转（这个我就不贴代码了）. 因为我们要观察的是正常跳转。

开工,进入源码（SDK 28 注意，app module的sdk也要28,必须用 androidStudio自带的AVD SDK 28模拟器才能 debug ）：
(为了确保源码探索的完整流程，我们从 startActivity开始 . )

这里产生2个分支，但是仔细观察之后，其实他们最终都走到了同一段逻辑：

Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, child,
intent, requestCode, options);
if (ar != null) {
mMainThread.sendActivityResult(
mToken, child.mEmbeddedID, requestCode,
ar.getResultCode(), ar.getResultData());
}

来解析这一段逻辑：

两句代码，一个是 mInstrumentation.execStartActivity

看来这一段并没有涉及到Activity生命周期函数的逻辑。
那么，看下一段：

mMainThread.sendActivityResult ，从 mInstrumentation.execStartActivity 执行之后，得到了一个ar，现在把这个ar 交给mMainThread（ActivityThread类的对象）,于是，进入 ActivityThread源码：

这里的 scheduleTransaction方法，在ActivityThread的父类ClientTransactionHandler中:
看到sendMessage，就怀疑，这里可能和Handler扯上关系了。
还记不记得 ActivityThread的父类ClientTransactionHandler scheduleTransaction()方法中 sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction); 用到了 ActivityThread.H.EXECUTE_TRANSACTION. 我们在H extends Handler中找到这个switch case的分支：

一共就两句代码可能和Activity的生命周期函数调用有关，那么我有理由怀疑就是这一段代码在执行生命周期函数. 那么 如何验证我的猜想是否成立？ 答： debug源码（前面之所以要源码版本，AVD模拟器版本，项目版本gradle SDK版本都写成28，就是为了这里debug）
加上断点之后，开始debug，按下跳转按钮, 我们发现了惊人的现象：

一次跳转，我们debug发现了3个可能和生命周期函数有关的细节：
PauseActivityItem ,ResumeActivityItem,StopActivityItem,这3个是不是分别对应了 Activity的3个生命周期函数？
继续探索：
找到 TransactionExecutor类的execute()方法:

我们需要跟踪的是transaction参数 (因为这里只有一个参数…不跟踪它跟踪谁呢)
然而，这里，使用到这个参数的是两个方法，executeCallbacks() 和 executeLifecycleState(),
而，在这两个方法中，我都找到了类似下面这样的代码：

final ActivityLifecycleItem finalStateRequest = transaction.getLifecycleStateRequest();
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);

推断出，生命周期函数一定和ActivityLifecycleItem的execute()和postExecute()有关,还记不记得之前我们debug出来的PauseActivityItem ,ResumeActivityItem,StopActivityItem . 这3个类就是ActivityLifecycleItem的子类，进去看看：

debug 一下：

发现了ActivityThread，自然就联想到它的 H extends Handler ,ok, 就快接近真相了，表激动，暂且压制一下，我们还没有找到真凭实据。
又是一个抽象方法，直接找他的子类ActivityThread,

终于接近真相了，这里已经很明显了，参数是Activity对象，并且执行了 activity.performPause().

真相大白，原来一个Activity的生命周期函数 onPause是这么调用的，绕了一大圈，最终我们重写的onPause()方法才被执行。

小结论

从我们startActivity开始，如果用一张图来展示 Activity生命周期函数如何被执行。无谓的绕绕绕去的省略中间环节，只展示重点环节，那就是这样。

解决方案

现在可以运行我的Demo工程，注意请切换到 git时间点： 945df9, 按照上面的步骤去debug一下，结果发现，
上一章节中图示的正常现象 PauseActivityItem ,ResumeActivityItem,StopActivityItem ，在这里并未看到，或者说，这里 EXECUTE_TRANSACTION 分支缺失了。肯定是因为我们hook的代码导致ActivityThread的 H mH = new H()，class H extends Handler 的void handleMessage(Message msg) 部分switch case 没有执行。

既然已经确定是 ActivityThread的 mH 有问题, 那么应该检查的，则是 hook mH的时候。

现在进入hook代码：回顾一下handler的责任链模式：
按照我通常的hook思路，mH通常执行的是第三级成员函数handlerMessage(msg)的逻辑，我hook一下，给mH的成员变量mCallback赋值。然后可以通过return 返回值来控制要不要继续执行原handlerMessage(msg)的逻辑。如果mCallback.handlerMessage(msg)返回了true，那么就没有后续了，handlerMessage(msg)永远不会执行。如果是return false，handlerMessage(msg) 仍会执行。