Android | 如何搭建内存优化体系

2021-01-24  本文已影响0人  彭旭锐

点赞关注，不再迷路，你的支持对我意义重大！

🔥 Hi，我是丑丑。本文 「Android 路线」| 导读 —— 从零到无穷大 已收录，这里有 Android 进阶成长路线笔记 & 博客，欢迎跟着彭丑丑一起成长。（联系方式在 GitHub）

目录

前置知识

这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~

Java 路线

Android 路线

adj 进程优先级 （high）
Linux内核OOM killer机制：https://juejin.cn/post/6844903878178111502

1. 重新认识内存

“一切性能问题最终都会变成内存问题。” 举个例子，为了避免资源重复下载，可以缓存到本地存储，而从本地存储加载进内存又需要磁盘 I/O。为了避免重复磁盘 I/O，可以缓存的内存，缓存的数据越来越大，最后变成内存问题。

1.1 什么是内存？

现代 Android 手机内存分为 运行时内存 RAM & 非运行时内存 ROM：

提示：今天我们讨论的内存优化指 “运行内存优化”，而 “非运行内存优化” 我们将在 “存储优化” 专题中讨论。

更多内容：内存指标 —— Android | 内存指标与测量方法

1.2 内存优化的维度

分别针对上面提到的 RAM 和 ROM 两种内存，Android 内存优化是分为两方面的工作：

1.3 内存优化的误区

对内存优化的错误认识需要注意规避，主要有：

内存优化不完全是追求于降低内存占用，当系统内存较充足 / 机型较高端的时候，我们完全可以多使用一些内存来换取更好的体验；而当系统内存不足 / 机型较低端的时候，我们应该更保守，做到 “用时分配，及时释放”。

本地内存是不受 Java 堆大小限制，例如 Android 8.0 就重新把 Bitmap 的图片数据放在本地内存。但也不能滥用本地内存，主要原因是当系统物理内存不足时，LMK 机制也会开始杀进程，内存占用越高越可能被杀死。

1.4 内存优化的意义

优化内存的意义可以归结为如下三点：

需要注意的是，发生 OOM 的代码往往是 “压死骆驼的最后一棵稻草” ，但不一定是导致 OOM 的主要代码，完全可能只是刚好执行到这行代码发生 OOM。

1.5 内存优化到底要做什么？

理解了内存优化的重要性，现在我们来讨论内存优化到底要做什么呢，主要是优化三大问题：

内存抖动是因为高频率的内存分配与回收，在内存波动图上往往呈现锯齿状，并伴随着程序卡顿。具体见 第 4 节。

内存泄露简单来说就是没有回收不再使用的内存，导致内存占用居高不下，泄露的内存分为两种：Java 内存泄露 & Native 内存泄露。具体见 第 5 节。

内存溢出是引用内存申请超过了系统限制的最大堆内存，引发 OutOfMemoryError 异常。具体见 第 6 节。

2. Android 内存管理

LMK

3. 内存指标与分析方法

在进行具体的内存优化之前，我们应该掌握基本的 Android 内存指标和相应的分析方法，这部分内容我单独放在这篇文章里：《Android | 内存指标与分析方法》，请享用~

4. 内存抖动问题

内存抖动（memory thrashing）是因为高频率的内存分配与回收，在内存波动图上往往呈现锯齿状。由于高频率 GC 行为会频繁 stop-the-world，虽然暂停的时间很短，但终归是有成本的，程序整体会变得卡顿。此外还有可能进一步引发 OOM，这是更严重的情况。

这个问题在 Dalvik 虚拟机上会更加明显，而 ART 虚拟机在内存管理跟回收策略上都做了大量优化，内存分配和 GC 效率相比提升了 5~10 倍，出现内存抖动的概率会小很多。

出现内存抖动时，内存分配之后马上就回收了，为什么还可能引发 OOM 呢？

主要原因是虚拟机可能会采用了 “无整理功能” 的垃圾收集器，频繁创建对象时会导致堆中的碎片急剧增加，直到虚拟机在分配内存时无法找到足够大小的连续内存时，就会引发 OOM。

Dalvik 虚拟机主要使用标记清除算法，也可以选择使用拷贝算法。ART 也有多个不同的 GC 方案，默认方案是 CMS。

4.1 问题定位

代码 review 是避免程序发生内存抖动的有力保障，但是我们更倾向于使用工具来快速定位，因为有时候我们并不熟悉相关的源码。使用 Android Studio 中的 Profiler 工具 可以帮助我们。

首先使用 Profiler 工具录制一段时间的内存占用情况，如果发现内存波动图呈现明显的锯齿状，或者存在高频率的 GC 事件，说明存在内存抖动。例如：

既然内存抖动是由于频繁分配与回收内存导致的，那么我们就有两种排查思路：

既然某一些对象的分配和回收有能力导致内存抖动，那么说明这些对象一定是占据了比较高的内存，所以第一种思路就是找出占用内存最多的类。

步骤如下：

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    重复创建 String 数组对象
    handler = Handler {
        val array = Array(1000000) { "" }
        handler.sendEmptyMessageDelayed(0, 5);
        false
    }

    handler.sendEmptyMessageDelayed(0, 30);
}

程序会频繁分配内存的背后，其实也是在频繁调用分配内存的那个方法，所以第二种思路就是找出频繁调用的方法。

步骤如下：

由于程序中频繁调用的代码可能会比较多，而且方法频繁调用并不是内存抖动的充分条件，所以思路二没有思路一明显。

4.2 常见案例

在 View#onDraw()、循环等场景中的对象应提高到外部进行复用；

使用显式 StringBuilder 替代 + 号，因为后者编译后也是采用了前者的方式，会生成太多中间变量；

采用缓资源存池（例如对象缓存池、线程池、位图缓存池），以重用频繁申请的资源。需要注意在使用结束后手动释放资源。

5. 内存泄露问题

内存泄露（ memory leaks）简单来说就是没有回收不再使用的内存，导致内存占用居高不下，泄露的内存分为两种：

5.2 Android 内存泄露的案例

实际开发中内存泄漏的案例是非常多的，需要分门别类，根据我的总结主要有以下几类：

5.2.1 生命周期误用

大多数内存泄漏是因为 对象的生命周期误用而引发的，例如：

5.2.2 资源未释放

当资源无法使用时，应该及时释放，例如：

5.2.3 WebView

WebView 启动一次之后内核是不会释放的。可以用一个单独的进程承载 WebView，并使用 AIDL 与主进程通信。WebView 所在进程可以根据业务需要在合适的时候销毁。

5.2 Java 内存泄露监控

建立类似自动化检查方案，至少在 Activity 和 Fragment 泄漏时自动弹出对话框提醒开发者发现问题，类似 LeakCanary 方案。在线上环境上报需要优化 Hprof 内存快照文件大小，文件越小上传的成功率越高，主要方法是裁剪图片对应的 byte 数组。

有一个 “内存泄漏自动化链路分析组件 Probe”，

5.3 Native 内存泄露监控

高手课 下

6. 内存溢出问题

内存溢出（out of memory）是引用内存申请超过了系统限制的最大堆内存，引发 OutOfMemoryError 异常。Android 设备出厂后，最大堆内存就已经确定，相关的配置位于系统根目录/system/build.prop文件中的dalvik.vm.heapgrowthlimit。

MAT

重要概念

incoming references
outgoing references

内存指标

当前设备内存占用情况 / 当前应用内存占用情况

ViewRootImpl 是Activity与Window的桥梁

参考资料

创作不易，你的「三连」是丑丑最大的动力，我们下次见！

上一篇 下一篇

猜你喜欢

热点阅读