鸿蒙最新记录一次开机内存分析的全过程(2)，2024年最新h5页面怎么适配各种机型

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

因此首先怀疑是业务X有自启动的Provider引入了启动逻辑导致这部分内存增长，因此我们需要查找增量ContentProvider。

2.1.1 方法1

通过解析apk中合并后的AndroidManifest文件，搜索provider标签声明的组件，发现由商业化广告sdk引入一个ContentProvider

2.1.2 方法2

这里除了通过查看Manifest文件以外，还可以通过"dumpsys package +包名"的方式进行查看已声明的组件。

2.1.3 方法3

使用MAT的OQL查询语句查询所有Provider实例，此方法比Profiler更准确，因为如果单纯使用Profiler的搜索功能无法识别名称不包含Provider的实例。

SELECT * FROM INSTANCEOF android.content.ContentProvider

2.1.3 排查结论

再结合Profiler查看确实有一个ProcessProvider在开机阶段被加载。

进一步需要排查该Provider的具体作用和对开机内存的影响范围，进一步咨询广告同事，通过排查这个ContentProvider中生命周期onCreate中是否有异常内存使用情况。

确认结论为：目前初始化基本不涉及业务内存占用。

2.2 BroadcastReceiver

静态广播在开机也会立即被注册，因此还需要排查是否有静态广告在开机后被初始化带动初始化了相关逻辑。

如果我们在用户未同意申明权限的情况 下，是不应该响应接收的功能的，这样也会间接引起内存的增长。

静态广播导致的开机内存增长的例子在我们项目中此前也出现过

因此我们同样使用上面Provider的排查方法发现也没有对应的Receiver起来，排除这个原因的可能性。

3.使用Profiler定向排查怀疑的包名和类

当有确定的怀疑目标的时候，直接使用AS的Profiler进行搜索会效率会更高，因此我搜索了我能想到的业务X的类，只找到了DI注入相关的必须类，没有相关业务加载。

3.1 Profiler基础

内存分析器是 Android Profiler 中的其中一个组件，可帮助识别可能会导致应用卡顿、冻结甚至崩溃的内存泄漏和内存抖动。它显示一个应用内存使用量的实时图表，可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。

这里只介绍如何利用Profiler查看内存堆转储文件的一些技巧，使用Profiler抓取内存文件或者获取hprof文件使用Profiler打开后就是以下界面。

4.使用Mat对比Heap变化

使用Profiler分析还是有一定局限，只能对已知怀疑的相关类进行逐一排查，对未知的类引入我还不是很确定，因此我进一步抓取了两份hprof使用MAT进行对比分析，试图找出具体的增量原因。

适合使用mat分析的场景包括：需要对比某个行为前后的内存，需要对比两个不同版本的内存等。

4.1 Mat基础和分析技巧

4.1.1 Histogram

MAT中Histogram的主要作用是查看一个instance的数量，一般用来查看自己创建的类的实例的个数，通过查看Object的个数，结合代码就可以找出存在内存泄露的类，Histogram中还可以对对象进行Group，更方便查看自己Package中的对象信息