在我当前的实现中，我只能拦截一些Class初始化方法的Method_Entry事件，包括：
*.<init> or *.<cinit>
* stands for any Class
缺少用Java应用程序编写的所有方法。
目前，我在以下地方插入了“fprintf（）”：
stack.cpp: dvmCallMethod()
stack.cpp: dvmCallMethodV()
stack.cpp: dvmCallMethodA()
stack.cpp: dvmInvokeMethod()
Interp.cpp: dvmInterpret()
Mterp.cpp: dvmMterpStd()
当执行DVM的这些位置时，我将在我的日志文件中打印一条消息。但是，只有类初始化函数触发了我的println（）代码。换句话说，看起来应用程序方法的执行没有经过DVM的上述位置。我不知道DVM的哪个部分负责应用程序的方法执行。谁能给我一个线索？
答案 0 :(得分：2)
了解事情如何运作的最简单方法是查看方法分析的工作原理。每次调用方法时，性能分析都会在日志文件中添加一个条目。密钥文件是dalvik/vm/Profile.h，它定义了像TRACE_METHOD_ENTER这样的宏。 （在姜饼中，这就是你需要寻找的全部内容。当调试，分析和JIT编译之间的交互得到重新设计时，ICS的情况发生了很大的变化。而KitKat将＆＃34;采样＆＃34;分析器添加到了现在它变得更加曲折，还有一些其他功能需要注意，比如dvmFastMethodTraceEnter()。）
您在问题中确定的入口点用于反射和调用本机代码。通过更新堆栈和程序计数器来处理解释代码之间的调用，并继续循环解释器。您可以在line 3928 in the portable interpreter找到此信息。
非显而易见的部分是FINISH()宏，在第415行定义。这会调用dvmCheckBefore()，行1692 in Interp.cpp。此函数检查subMode字段以查看是否有任何有趣的事情要做;你可以在定义line 50 in InterpState.h中找到各种含义。简而言之，标志用于各种分析，调试和JIT编译功能。
您可以在方法调用处理中看到对line 3916 in the portable interpreter的subMode检查。它在Interp.cpp中调用dvmReportInvoke()，调用TRACE_METHOD_ENTER宏。
如果您每次调用任何方法时都试图让某些事情发生，那么您应该将其连接到配置文件系统中，因为它已经做了您想要的事情。如果您不需要方法分析功能，只需将其替换为代码即可。