手把手带你了解内存抖动和泄漏的优化

学到老活到老，路漫漫其修远兮。与众君共勉 !，和我一起当个CV工程师吧，手动滑稽

正文大纲

• jvm内存管理常识
• 检测以及处理内存抖动
• 检测以及处理内存泄漏

正文

jvm内存管理常识

LMK （LowMemoryKill）机制 android底层会在系统内存告急的时候，按照一定规则杀死一些进程来满足其他进程的内存需要。其中 消耗内存的高低就是其中一项指标，所以，优化app的内存占用，能够有效降低app被系统杀死的概率。
GC STW机制 GC，垃圾回收进程，在GC线程执行任务的时候，会存在一个 STW (stop the world) 机制，他就会把其他所有线程都挂起。如果GC非常频繁地调用，那就会导致主线程不流畅，给用户的感觉就是 卡顿。
内存抖动频繁引起OOM 内存抖动太频繁，导致大量对象频繁创建和销毁，会产生大量不连续的内存空间，如果此时有一个大对象需要申请内存，就有可能申请失败，导致 OOM内存溢出
一句话解释 内存泄漏长 生命周期的对象持有 短生命周期对象的强引用，在 短生命周期对象需要回收的时候发现 不能被回收，视为泄漏
GC回收 可达性分析
GC线程判定 一个对象是不是可以回收，是根据可达性分析算法，计算 GcRoot，从 GcRoot向下搜索，把 GcRoot没有直接关联的对象全部作为垃圾来回收。
强软弱虚四大引用 强和虚自不必说。强 最常见，没有特殊处理的都是强引用(包括，匿名内部类会持有外部类的强引用)。虚引用没什么用，不予讨论。软引用，用来定义一些还有用，但是不是必须的对象，使用 SoftRefrence<T>修饰，在内存紧张的时候,GC回收之后，使用 SoftRefrence<T>修饰,如果系统还有足够的内存可用，那么软引用关联的对象就不会被回收。如果不足，则回收软引用关联的对象。弱引用( WeakRefrence<T>)，比软引用更弱一些，只要GC触发，弱引用关联的对象就会被回收。
注意: 使用软和弱引用，要判定关联对象是否为空。

检测以及处理内存抖动
我们使用s开发，平时我们运行app，一般会点 RunApp，但是还有另一个选择， 那就是 profileApp, 运行app起来之后，会在as下方看到profile 窗点击之后，as下方会出现profile，图中会显示网络，内存和cpu使用情况

如果内存的图中抖动得非常明显，比如像这样的心电图一样：

那就说明非常明显存在内存抖动，急需处理: 点击内存图形区域之后,就能看到详细的内存变化情况，以及内存分配情况：

这里有个坑：

如果你从图形中观察到，内存走势平稳，并没有出现上满模拟抖动的图中那么夸张，是不是就不存在内存抖动呢？并不是。因为我们的gc，是在内存不可用的情况下才会去回收内存，如果app占用内存一直比较少，没有触及gc的临界值，那么就不会出现 断崖式下跌. 那么这样就观察不出内存抖动了，怎么办呢？

解决方法 在8.0以下的安卓手机上，在下方的位置上会出现一个Record按钮(如果是8.0以上，你可以直接用拖拽的方式来截取一段内存record)：

点击它，一段时间之后，再点一下：你就能在下方发现一张表格：

这张表格代表的是，你Record这段时间之内创建的对象,点击一下第二列 Allocations,对创建的数量进行排序，找出创建次数最多的对象:

然后，点击排行第一的String之后，会在右方看到

然后点击其中的一个，又会看到一个新的窗口:

此为止，就找到了 创建对象 的 元凶，以这个为线索，找到你们自己包名下的类和方法，确定是我们自己的代码在不合理地创建对象.

再往后，就是根据各自的业务代码去做优化了，记住一个宗旨：不要让代码干多余的事。 如果是我们调用了系统的api导致了不合理地大量对象的创建，那么就要考虑这个系统API为什么会这样创建对象，有没有其他方法避免吗，从业务代码层来合理使用这个api，实在不行再考虑自定义api或者换个系统api。

在我们做了一次优化之后，再profile运行一次app，再重复上面的过程。以此类推，直到内存抖动达到理想状态。

总结

优化内存抖动，核心就是防止频繁创建对象。常见的反面教材就是：循环中创建对象，大量调用的api中创建对象。而优化的主要手段，就是对象复用，常见的手段是：对象池，像是 Handler的Message 单链表池，Glide的bitmap池等。

检测以及处理内存泄漏

经典案例： 处理 handler异步任务导致的内存泄漏方法

• 在Activity的onDestroy中移除所有的任务

@Override
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(null);//移除所有任务
}

• 使用静态内部类 + Activity弱引用的方式

MyHandler handler = new MyHandler(this);
private static class MyHandler extends Handler {
WeakReference activityWeakReference;
MyHandler(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
//在执行任务的时候，判断弱引用所关联的对象是否为空，能在对象已经被回收的情况下
switch (msg.what) {
case 1:
if (activityWeakReference.get() !=null) {
//T0D0
}
}
}
}

工具的使用

依然是 profileApp,先用 profile看出内存的变化情况。

问：如何判断内存泄漏？

答：内存泄漏是精细功夫，不能全盘观察，只能凭借profile的内存变化来推测。比如，打开app之后内存一路飙升，直到超出app能够使用的最大内存，app崩溃,，这是最明显的。又比如，你反复打开关闭某一个界面，发现内存的稳定线( 内存稳定之后，内存占用值)随着每一次的打开关闭，都在提高，这说明，这一个界面上存在泄漏，有对象无法被回收。

上一章节使用 profile 最多是了解到 哪些对象的创建和回收引起了内存抖动，但是，涉及到泄漏，只通过profile尚且 不能知道是 哪个类持有了希望被回收的对象的强引用. 这里就要借助另外一款工具,他的名字叫做 EclipseMat (自行百度)

先回到刚才的 profile

点一下，然后再点一下，界面会自动跳转：


点击上面的保存按钮，将文件存到本地;

然后：

但是这个文件是无法直接在mat打开的

找到SDK目录下的要 hprof-conv.exe：

使用cmd命令，对文件进行转换，命令为：hprof-conv[源文件名][目标文件名]如 hprof-conv1.hprof2.hprof 回车

将得到的 2.hprof利用刚才下载的Mat工具打开：

这里有很多指标，但是检查内存泄漏，我们只需要关注这个直方图按钮即可：

这个图中会列出你dump的这一段内存中的所有对象，包括framework层的，也包括我们自己代码创建的对象

案例模拟

我模拟了一个经典案例，也就是前面提到的 Handler延时任务导致 Activity不能被释放，核心代码如下

public class SecondActivity extends AppComatActivity {
Handler handler = new Handler();
//创建一个强引用Activity的handler对象
@Override
protected void onCreate (Bundle savedInstancestate) {
super.onCreate(saveInstanceState);
setContentView(R.layout.activity_second);
handler.postDelayed(new Runnable() {
@Override
public void run() {

}
}, Integer.MAX_VALUE);
//我让任务永远在这里
}

我就用一个非常普通的方式创建了一个 handler对象，并且用它来执行一段延时任务，只不过，延时任务的延时时间是 Integer的最大值，也就是说，任务要很久以后才会执行。之后，我反复进出这一个 Activity，然后按照上面的方式 dump了一段 hprof，经过 hprof-conv 转化，然后用 Mat打开：结果如下

我填写过滤信息: SecondActivity 回车

在我们最终退出 SecondActivity之后，内存中依然保留了 18个无用的对象。

那么是不是我们这18个都是泄漏的呢？
不一定

前文讲过，只有不合理的强引用，才会导致内存泄漏，所以我们要按照上面的方式排除软弱虚引用。之后我们能看到下面的界面,把能展开的信息尽数展开

了解 Handler源码的同志们应该一眼就看明白了， handler引起了内存泄漏，是因为存在不合理地强引用链， 上图中可以看出，最终是callback对象持有了 SecondActivity对象。

如何优化内存泄漏

我们刚才已经看到了Handler的不合理使用导致了内存泄漏，那么如果在 onDestroy中移除所有的任务

@Override
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(token.null):
}
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

【Android 详细知识点思维脑图（技能树）】

我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

最后，赠与大家一句话，共勉！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

最后，赠与大家一句话，共勉！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！