七猫免费小说 APP 内存优化实践（一）

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方案解析