hprof是什么文件怎么产生的（dump.hprof是什么文件）

编程日记 • 2025-02-19 19:51 • 阅读 13

背景：

hi，粉丝朋友们大家好！我们学习android framework实战开发过程中经常会用到一些辅助的shell命令，比如最经典就是我们常见的dumpsys啦，还记我给大家讲解的入门课，实战课，跨进程专题课其实都用用到这个命令；当时我只是给大家讲解怎么使用这种dumpsys一些命令，并没有给大家讲解它的一个原理，但是对于对android系统充满好奇小伙伴们，肯定不满足与简单使用，还是想搞明白他到到底什么原理，那么搞懂它到底有什么好处么？那当然是好处多多，我这里给大家主要罗列一下几点： 1、分析出dumpsys实现原理，可以知道他是怎么实现的整套系统各个调试运作，方便我们以后自己取实现新调试系统的参考 2、可以分析dumpsys架构源码，推断出要dump某个类信息时候是使用哪个命令，而不是现在的完全靠经验记住几个常用dumpsys命令 3、在自己开发模块过程中也可以自己借助dump来多打印一些自己的调试信息。。。。

好了大概有以上几点的好处，其他不一一列举，我相信以上3点就对大家非常非常有用了，毕竟你已经和不懂dumpsys的小伙伴已经差距拉开了，好了下面开始我们的分析dumpsys之旅。

1 首先来看看dumpsys这里命令源码在哪里？

路径：frameworks/native/cmds/dumpsys/

里面有如下几个文件：

android 系统dump一张图_android

这里其实核心就是dumpsys.cpp

可以看到dumpsys会根据传递来的参数调用startDumpThread(serviceName, args)方法，这里serviceName就是我们跨进程中有讲到的ServiceManager中的serviceName，这里核心其实也就是 startDumpThread方法：

这里其实就干了2件事： 1、ServiceManager获取到对应的IBinder代理，这里其实跨进程里面也有讲解大家都知道 2、然后调用IBinder对应的dump方法，这里dump方法就会调用到我们对应service的dump，比如dumpsys activity就会调用到ActivityManagerSerivice的dump方法，但是为什么呢？凭啥调用一下IBinder native层面的dump就会调用到Java层面的dump，如果是C++层面的我们都还可以理解，这直接就到Java层面那就有点难理解了，那么我们就来看看 dumpsys发起binder调用时候，它实际是BpBinder的角色，即客户端，它调用dump，看看BpBinder的dump实现： // 路径：frameworks/native/libs/binder/BpBinder.cpp

这里可以看到其实他是transact了code为DUMP_TRANSACTION的数据，到此dumpsys作为客户端就已经非常清楚了，本质就是通过binder给服务段发送了一个code为DUMP_TRANSACTION的数据。

接下来看服务端接受部分：在跨进程通讯就讲解过，Java中的Binder对象实现其实在底层也有一个类似的BBinder对象，他就是我们的JavaBBinder类： //路径：frameworks/base/core/jni/android_util_Binder.cpp

所以这里其实binder驱动传递数据后后就是会到这个native的JavaBBinder类里面的onTransact方法，这个方法就完全没有什么自己业务，就是立即jni调用到了Java层面的onTransact： frameworks/base/core/java/android/os/Binder.java

这里就可以看出来Java层面的onTransact里面会调用到dump方法，到此我们就清楚了dumpsys的dump怎么一步步调用到我们的Java层面的dump，这里我们以AMS为例子来看看dump方法： //路径frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

好了那最后总结一下把，给大家画一幅图方便记忆：

android 系统dump一张图_#include_02

hprof是什么文件 怎么产生的（dump.hprof是什么文件）

相关推荐

hprof是什么文件怎么产生的（dump.hprof是什么文件）