2022年以来，七猫客户端基础组加强了对内存问题的重视，对于内存优化做了很多工作。通过线上及线下的监控手段，有效的解决了已有的线上问题，同时能够尽早发现尽早解决新增的内存问题。本文主要阐述我们团队做了哪些工作，为什么做以及如何做的（侧重于安卓端）。
一、我们为什么要做内存优化？
通过对免费小说APP线上崩溃及卡顿问题的分析，很多问题是由于内存占用过高引起的。单独的几处内存不合理占用也许不会有问题，但是随着使用时间的累积，复杂的用户场景越来越多， 内存情况就会越来越差，会发生 OOM、卡顿、黑屏的可能性也会随之升高。加之阅读类 APP 平均使用时间更长，问题也就尤为突出。
二、内存问题的表现形式及优化方案
1、内存抖动
内存抖动是指在短时间内有大量的对象被创建或回收。内存抖动的频繁，会导致垃圾回收机制频繁运行，从而造成系统卡顿。
（1）容易被忽视的可能会造成内存抖动的代码写法：
String str = "";
for (int i = 0; i < 100; i++) {
str + = "abc";
}
上述代码看起来并没有频繁创建对象，但是，实际上每次执行 str + = "abc" 等同于执行了如下代码：
new StringBuilder().append(str).append("abc").toString();
这样问题就显而易见了，每次循环都会创建一个StringBuilder对象。与之类似的，有时为了排查问题，会在循环中写如下日志：
Log.i("TAG",arg1 +"——"+ args2);
这样一行日志看起来无足轻重，但是如果写在循环中，频繁创建的StringBuilder对象还是可能会引起内存抖动的。
在自定义View时，onDraw方法创建对象也是项目中比较常见的错误写法：
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
Paint paint = new Paint();
}
这种错误的写法在刚入门安卓开发时由于经验不足比较常见，因为此处没有循环，和高频创建好像并不沾边，但是，在安卓的页面绘制流程中onDraw方法是会被多次调用的，因此在这里创建对象也应该是明令禁止的。
（2）解决方案
内存抖动更多的是代码规范的问题，因此更多是依赖于代码 Review 过程中，对循环，onDraw等方法格外注意，避免错误的写法产生。此外可以使用Android Profiler的内存监控工具，对内存抖动的情况进行线下监控。
图1
通过上图1可以发现内存已出现明显的抖动，垃圾回收也在频繁的进行，通过对具体页面代码的分析，我们可以进一步定位问题。
2、内存泄漏
内存泄漏问题，是我们要解决的重点问题，因为时间积累，泄漏的内存会越来越多，引发的问题也会更加严重。
（1）常见的导致内存泄漏的场景
- 静态持有
public class test {
static List list = new ArrayList<>();
public void leak() {
Object object = new Object();
list.add(object);
}
}
object 被 static 持有，如不主动移除则会造成泄漏。
- 单例模式
和静态持有导致内存泄露的原因类似，因为单例生命周期和整个APP的生命周期一样长，所以如果单例对象持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。
- 内部类持有外部类
非静态内部类默认会包含外部类的引用，如果内部类的生命周期长于外部类，则会造成内存泄漏。如：
public class MemoryTest {
private void doSth(){};
public class MyThread extends Thread{
@Override
public void run() {
super.run();
MemoryTest.this.doSth();
}
}
}
正确的写法应为：
public class MemoryTest {
private void doSth(){};
public static class MyThread extends Thread{
WeakReference<MemoryTest> memoryTestWeakReference;
public MyThread(MemoryTest memoryTest){
memoryTestWeakReference = new WeakReference<>(memoryTest);
}
@Override
public void run() {
super.run();
MemoryTest memoryTest = memoryTestWeakReference.get();
if(memoryTest!=null){
memoryTest.doSth();
}
}
}
}
- IO 未关闭
当进行文件读写，网络等 IO 操作时，需要及时将连接关闭，否则 GC 不会回收该对象，从而造成内存泄漏。
InputStream is = null;
BufferedReader in = null;
try {
is = context.getAssets().open(assetFileName);
in = new BufferedReader(new InputStreamReader(is));
...
} catch (IOException e) {
return "";
} finally {
//在finally中确保所有的io操作被关闭
try {
if (is != null) {
is.close();
}
if (in != null) {
in.close();
}
} catch (Throwable ignore) {
}
}
对于内存泄漏而言，如果泄漏的较少用户是无感知的，更多时候我们写代码时要避免出现内存泄漏的场景。线下内存泄漏检测可以使用LeakCanary等工具进行检测。对于线上问题，内存泄漏导致最严重的后果就是内存溢出，下面着重说下我们遇到的内存溢出问题及解决方案。
3、内存溢出（OOM）
如果说内存抖动和泄漏对于用户来说还是无感知或者轻微感知的，那么 OOM 会直接导致 APP 闪退，严重影响用户体验。通过 bugly 的崩溃分析，我们遇到的OOM主要分为如下几类：
图2
针对以上几点我们进行了如下的几项优化或监控：
- Bitmap 显示格式由 ARGB8888 改为 RGB565 ，图片占用内存减小为原来的一半。
- 进行大图治理，与服务端沟通，将返回的图片尺寸改为更适合 View 大小的尺寸。客户端加载图片时设置宽高，减少不必要的内存浪费
- 进行线程数监控（之前团队成员已进行过详细介绍）。
- 进行线上 OOM 用户 hprof 获取。
- FD 泄漏监控（建设中）。
- Native 内存监控（建设中）。
其中，线上 OOM 用户hprof文件的获取，对我们分析线上问题提供了极大的帮助，下面举例说明。
1、堆内存单次分配过大举例：
图3
由图3可以看到，单次申请内存超过了 100M，因为 Java 堆常见的最大可用内存为 256M 或 512M ,由此可判断本次 OOM 发生的原因为单次内存申请过大导致的。此类问题较为容易解决，因为申请内存的调用方法栈是明确的，可以直接排查代码解决问题。但是本次问题线上偶现的，通过排查代码无法找到明确的问题。我们通过获取线上出现问题用户的 hprof 文件。通过分析排查到了如图4中所示的问题--KMAdSlot中token长度过大。
图4
通过这个线索，结合代码与三方沟通，进一步定位到了申请对象过大的原因是百青藤 SDK 获取 oaid 过大导致的。我们线上的 hprof 文件获取的方案建设极大有效的推进了该问题的解决。
2、堆内存累计分配过大举例：
图5
由图5可以看到，单次申请内存为 3M 多时就发生了内存溢出，由此可见，此次的内存申请只是“压死骆驼的最后一棵稻草”，对于此类问题，单单依靠崩溃时的堆栈是不易解决的。我们通过获取线上问题用户的 hprof 文件可以分析具体的内存使用状况，可以帮助我们更快的定位问题。如图6所示，定位到该问题是由于穿山甲MediaPlayer创建过多，没有释放导致的。
图6
由上述可见线上hprof获取方案的建设对于内存优化，起着至关重要的作用。
三、线上hprof文件获取
线上的堆转储文件（hprof）获取我们使用的是快手的 KOOM 方案。通过 MAT 工具分析该文件，可以获取 OOM 发生时所有 Java 堆中的对象，引用链及大小。线上获取 hprof 文件需要解决如下几个问题：
- 采集 hprof 的常用方案会使应用卡死几秒钟的时间，虽然免费小说 APP 是在OOM 发生时才进行 dump ，但是同样会造成很大的影响，此时 bugly 正在进行问题采集上报等操作都会受到影响。
- 采集到的hprof文件通常有几百兆大小，这样对用户的流量及上报的成功率都会产生巨大的影响。
快手的KOOM方案很好的提供了以上两点问题的解决方案：
针对问题1:
KOOM利用COW(Copy-on-write,写时复制)机制，在dump内存镜像前先暂停虚拟机，然后fork子进程来执行dump操作，父进程在fork完成后立刻恢复虚拟机的运行。整个过程父进程卡顿的时间仅有几毫秒，这对用户来说是可以接受的。
关键dump代码流程如下：
public boolean dump(String path) {
...
// 适配 Android 11 ，和下面流程差不多
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.Q) {
return dumpHprofDataNative(path);
}
...
try {
// 调用 native 方法，挂起当前的主进程，并 for 出子进程，该挂起仅仅只是更改 ThreadList 变量的线程状态为 suspend
int pid = trySuspendVMThenFork();
if (pid == 0) {
// 子进程开始 dump hprof
Debug.dumpHprofData(path);
// 结束子进程
exitProcess();
} else {
// 恢复挂起的主进程
resumeVM();
// 等待子进程的 dump
dumpRes = waitDumping(pid);
}
} catch (IOException e) {
e.printStackTrace();
}
return dumpRes;
}
针对问题2
相对于问题1来说，问题2的解决方案较为简单，我们仅需要对 hprof 文件进行裁剪，只保留分析 OOM 的必需数据。如对于所有的 Bitmap 对象的像素均设为0，所有的字符串的 byte 均设置为0，这样我们仅保留了对象的大小，可以使压缩后的文件由几百兆缩减为了几兆。同时裁剪也是对数据进行脱敏，对于数据的具体内容不进行传输和上报，这样极好的保护的用户的隐私。同时为了提高文件上报的成功率，我们还对文件进行了分割处理，将一整个大文件，分割成几个小文件分别进行上传。整体的hprof文件的获取分析流程如下。
图5
通过近期的一系列内存优化手段，线上OOM问题已经得到了有效的改善，对于新出现的Java内存问题也能够及时监控分析。目前我们Native的内存分析监控正在开展，通过对Native层的内存分析优化，会进一步提高我们APP的稳定性及分析解决问题的能力。
参考：
快手KOOM方案解析