Android系统的内存与崩溃优化

作者: 追那个小女孩 | 来源:发表于2021-04-04 14:25 被阅读0次

Android优化

题记：当你看到一堆让你摸不着头脑的崩溃堆栈，夹杂着若干OOM崩溃的时候，那就是在告诉你——是时候优化内存了。

最近这段时间一直在跟进安卓崩溃的问题，跟了有三个月了，虽然有一些进展，但是目前也还没有彻底解决，想起自己已经有一年没有写过博客了，所以打算把最近学到的东西，都好好整理一下。

看到这个标题，就能知道我最近解决的崩溃问题都是内存导致的了，内存问题相比于普通的崩溃难度要高一些，因为内存崩溃的堆栈都不能直接反馈问题，有些只是压死骆驼的最后一根稻草，崩溃点也是五花八门。所以要解决内存的问题，首先就要对内存有一个全面切清晰的认识，你才知道要从哪里入手。

内存的相关概念——弄懂大Boss

虚拟内存和物理内存

物理内存，顾名思义，就是实际分配到内存条中的内存；虚拟内存，也称逻辑内存，是存在于数据结构中的。在32位操作系统中，Linux进程的虚拟内存大小是4G，32位系统的最大寻址空间大小正好是4G（2^32）。在这4G里面，其中1G是内核态内存，每个Linux进程共享这一块内存，在高地址；3G是用户态内存，这部分内存进程间不共享，在低地址。内存的分布图如下：

而用户态又被切分为很多个部分，从低地址往上分别是：

Text Segment ：存放二进制可执行代码的位置；
Data Segment：存放静态常量；
BSS Segment ：存放未初始化的静态变量；
Heap：堆是往高地址增长的，是用来动态分配内存的区域，malloc 就是在这里面分配的；
Memory Mapping Segment：这块地址可以用来把文件映射进内存用的，如果二进制的执行文件依赖于某个动态链接库，就是在这个区域里面将 so 文件映射到了内存中；
Stack：主线程的函数调用的函数栈就是用这里的。

虚拟内存的分布，在进程中是有数据结构来记录的，所有进程内申请内存的动作，无论是java的new，还是c++的malloc，首先都是申请的虚拟内存，要等到实际发生内存访问的时候，会发生缺页中断，然后在物理内存中分配内存。

这个步骤比较繁琐，涉及的知识点比较多，后面我会整理这中间学到的Linux内存相关知识，再给大家分享。

Dalvik内存和native内存

要搞清楚这两个概念，首先要搞清楚Dalvik和Linux的关系。也就是说，每个安卓上的进程，都会启动一个Dalvik虚拟机，Java申请的内存，就是Linux进程可以分配给Dalvik虚拟机的内存，安卓系统内有一项配置：dalvik.vm.heapsize，定义了这台手机上每个dalvik能申请的最大内存，也就是系统能给虚拟机分配的最大内存。高端的手机一般能分配到512M的最大内存，低端机一般是256M。

而Native内存，是脱离于Dalvik虚拟机，直接在系统层面申请的内存，只要虚拟内存和物理内存没用完，就能一直申请，这也是为什么，android 4.x之后，Bitmap的内存会直接在native中分配的缘故，就是因为看上了Native比Dalvik大。

VSS, USS, PSS和RSS

这几个概念，是另外一套用来描述进程内存现状的，要理解这几个概念，首先要理解系统内存的分配方式，也就是虚拟内存是通过什么样的机制分配到物理内存中去的。在android系统中，使用的分配方式是分页，这也是Linux内最常用的分配内存方式。

简单来说，分页就是将系统内存分成一页页，每页的内存大小是4K，然后系统会跟踪所有的内存页面，如下图：

image.png

在确定应用使用的内存量时，系统必须考虑共享的页面。访问相同服务或库的应用将共享内存页面。例如，Google Play 服务和某个游戏应用可能会共享位置信息服务。这样便很难确定属于整个服务和每个应用的内存量分别是多少。

image.png

图 6. 由两个应用共享的页面（中间）

如需确定应用的内存占用量，可以使用以下任一指标：

常驻内存大小 (RSS)：应用使用的共享和非共享页面的数量
按比例分摊的内存大小 (PSS)：应用使用的非共享页面的数量加上共享页面的均匀分摊数量（例如，如果三个进程共享 3MB，则每个进程的 PSS 为 1MB）
独占内存大小 (USS)：应用使用的非共享页面数量（不包括共享页面）

如果操作系统想要知道所有进程使用了多少内存，那么 PSS 非常有用，因为页面只会统计一次。计算 PSS 需要花很长时间，因为系统需要确定共享的页面以及共享页面的进程数量。RSS 不区分共享和非共享页面（因此计算起来更快），更适合跟踪内存分配量的变化。

查看PSS的方式比较简单，安卓有直接的adb命令可以查看，命令如下：

dengzongrongdeMacBook-Pro-3:~ RoyDeng$ adb shell dumpsys meminfo com.dianyun.pcgo
Applications Memory Usage (in Kilobytes):
Uptime: 407897842 Realtime: 816330794

** MEMINFO in pid 11779 [com.dianyun.pcgo] **
                   Pss  Private  Private  SwapPss     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap   120337   120164        0      298   157172   148680     8491
  Dalvik Heap    32207    32164        0       57    41412    20706    20706
 Dalvik Other     8297     8296        0        0
        Stack       84       84        0        0
       Ashmem      158       72        0        0
      Gfx dev    26632    26632        0        0
    Other dev      204        0      204        0
     .so mmap    68401     3140    54180       12
    .jar mmap     4384        0     1220        0
    .apk mmap     2751      152     1516        0
    .ttf mmap     4402        0     1172        0
    .dex mmap    66430    55992    10096        0
    .oat mmap     2480        0      516        0
    .art mmap     5450     4680        0       33
   Other mmap    12593     1396     7544        0
      Unknown    12874    12852        0        8
        TOTAL   368092   265624    76448      408   198584   169386    29197

 App Summary
                       Pss(KB)
                        ------
           Java Heap:    36844
         Native Heap:   120164
                Code:   127984
               Stack:       84
            Graphics:    26632
       Private Other:    30364
              System:    26020

               TOTAL:   368092       TOTAL SWAP PSS:      408

查看进程内存分布

Linux将进程的内存分布写在一个文件里面，可以通过以下命令查看内存情况：

$ cat /proc/[pid]/maps

其中vm_size这一行，就是表示进程的虚拟内存大小，这个数据目前只能通过读取/proc/[pid]/maps文件来获得，是我们在内存优化中，非常重要的一项指标。

OOM崩溃——第一只拦路虎

说到内存问题，第一想到的应该就是OOM崩溃了。以前我碰到OOM问题都会选择性过滤，认为这个崩溃没那么好解，要等到后续专门针对内存做统一优化；现在，能碰到OOM，真是一种幸福😄。

我们碰到的OOM崩溃主要有以下两种：

832503 java.lang.OutOfMemoryError: Failed to allocate a 9936012 byte allocation with 4745096 free bytes and 4MB until OOM
269867 java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again

第一种崩溃比较简单，原因就是给dalvik分配的最大内存超过限制了，这块内存分配不了，然后系统就报错了。解法有两种：

简单解法：一般报错的地方都是申请内存比较频繁或者比较大的地方，可以直面这个堆栈，想办法绕过去，比如说把一张大图用.9图来代替等等。

不过这个方法有个坏处，就是不彻底，因为有可能堆栈反应的问题，只是压死骆驼的最后一根稻草，要想彻底解决这个问题，安卓提供了一个非常好的工具，就是hprof。
彻底解法：就是想办法拿到崩溃场景下的hprof文件，这样就能看到崩溃前到底是什么东西占用着内存。因为导出hprof需要时间，并且dump的过程中app会被冻结，所以在用户环境上不是很好导出。最好的方法，是观察用户行为日志，一边借助内存检测工具（我们使用的是perfDog），来重现崩溃场景。

快手最近有开源一款解决dump过程中app冻结的内存导出方案——KOOM，我们还没有在项目中实际投入使用，有兴趣的可以了解一下：https://github.com/KwaiAppTeam/KOOM

第二种崩溃，是java在创建线程的时候发生的崩溃。从堆栈可以看出，崩溃点发生在native层，所以和虚拟机内存限制无关。通过在网上查资料——《Android 创建线程源码与OOM分析》，发现出现这个问题的原因有两种，一种是虚拟内存不足，第二种是文件描述符超出限制，究竟是因为哪个呢？

为了定位这个问题，我们做了一套崩溃收集方案，目的不是为了收集崩溃，而是收集崩溃时候的机器状态，包括内存、线程、文件描述符、activityStack等等，在灰度的过程中，我们也在看其他的那些比oom更加棘手的问题。

乱七八糟的Native崩溃——真正的大Boss

OOM问题，有简单的，有复杂的，不过真正把我们难倒的，不是OOM，而是一堆乱七八糟的native崩溃，其中TOP1崩溃的堆栈，看上去很短，但是很让人摸不着头脑：

1   #00 pc 00056c62 /apex/com.android.runtime/lib/bionic/libc.so (abort+165) [armeabi-v8]
2   #01 pc 00005aad /system/lib/liblog.so (__android_log_assert+176) [armeabi-v8]
3   #02 pc 001f78f7 /system/lib/libhwui.so [armeabi-v8]
4   #03 pc 001f6abd /system/lib/libhwui.so [armeabi-v8]
5   #04 pc 001f6011 /system/lib/libhwui.so [armeabi-v8]
6   #05 pc 002041e9 /system/lib/libhwui.so [armeabi-v8]
7   #06 pc 00204041 /system/lib/libhwui.so [armeabi-v8]
8   #07 pc 0000da1f /system/lib/libutils.so (android::Thread::_threadLoop(void*)+214) [armeabi-v8]
9   #08 pc 000a109b /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+20) [armeabi-v8]
10 #09 pc 00058113 /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) [armeabi-v8]

崩溃的原因是abort，一般出现这种问题的原因，是系统没办法了，然后自杀了，而这个没办法的原因，让我猜到了和内存可能有关，但是不能确定。通过客户端收集到的log，也没办法定位到问题，因为客户端只收集自己打印的log。眼看就要没办法之际，一次偶然的机会，看到了bugly上收集到的短暂的logcat日志，竟然每一条都有这样同样的log输出：

10-24 00:05:20.046 13795 14043 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
10-24 00:05:20.048 13795 14043 E Adreno-GSL: <gsl_memory_alloc_pure:2297>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
10-24 00:05:20.055 13795 14043 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
10-24 00:05:20.056 13795 14043 E Adreno-GSL: <gsl_memory_alloc_pure:2297>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
10-24 00:05:20.057 13795 14043 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
10-24 00:05:20.058 13795 14043 E Adreno-GSL: <gsl_memory_alloc_pure:2297>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
10-24 00:05:20.059 13795 14043 E OpenGLRenderer: GL error: Out of memory!

得嘞，问题就是你了，GL error：Out of Memory，对应的代码是在这里：

bool GLUtils::dumpGLErrors() {
    bool errorObserved = false;
    GLenum status = GL_NO_ERROR;
    while ((status = glGetError()) != GL_NO_ERROR) {
        errorObserved = true;
        switch (status) {
            case GL_INVALID_ENUM:
                ALOGE("GL error:  GL_INVALID_ENUM");
                break;
            case GL_INVALID_VALUE:
                ALOGE("GL error:  GL_INVALID_VALUE");
                break;
            case GL_INVALID_OPERATION:
                ALOGE("GL error:  GL_INVALID_OPERATION");
                break;
            case GL_OUT_OF_MEMORY:
                ALOGE("GL error:  Out of memory!");
                break;
            default:
                ALOGE("GL error: 0x%x", status);
        }
    }
    return errorObserved;
}

从上面的创建线程OOM和GL OOM两个问题，已经大概猜到这次碰到的问题就是内存问题了，但是要证明是内存问题，还是需要有证据。对此，我们的方法是在崩溃回调的接口中，搜集当时的数据，包括java内存、native内存、虚拟内存、文件描述符、线程数等等，搜集到的数据会在log中打印，并且上报给崩溃后台，通过收集一轮数据，我们发现我们的猜想是正确的：崩溃的原因，就是虚拟内存不足导致，同文件描述符、线程数、java内存大小等其他指标无关。

GL OOM——挑战大Boss

不管是虚拟内存还是物理内存，要解决内存问题的思路都是一样的：首先就是要找到问题出在哪，只要找到了问题根源，解决问题就不是一件麻烦事。但是问题就在于，怎么样才能找到内存问题的大头在哪呢？为此，我们做了一套比较完整的内存交控方案，具体策略如下：

在Activity跳转的过程中添加内存信息打印，打印的时间点包括：
1. Activity.onStart()
2. Activity.onStop()
3. 在同一个Activity的停留时间每超过一分钟
这样我们就得到了一份内存数据增长曲线，通过收集内存问题崩溃用户的log，最终定位到有三个Activity有严重的内存泄露问题
我们碰到的内存问题都是偶现问题，所以要想解决问题，同时验证解决方案是否生效，必须要做的一件事情就是想办法重现问题。所以我们开发同学配合测试同学，一起搭建了一套自动化测试框架，辅助性能分析工具perfDog，成功找出了问题所在。

找到了问题根源，解决问题就简单很多，因为涉及到项目问题，在这里就不透露解决问题的方案。

问题的原因主要有两点：

在我们的业务场景中，有一个场景，用户会频繁连接和断开音视频直播流，这个过程每发生一次，就会造成20M的内存泄露。下面是自动化脚本模拟该业务场景的内存增长曲线：

重连直播流内存泄漏

X5框架内存在内存堆积，堆积点是用户退出网页之后，jsapi会继续持有X5WebViewAdapter，继而持有Activity，导致内存堆积，堆栈如下：

X5内存泄露

知道了上面两个问题，解决方案就可以顺藤摸瓜了：

直播流内存泄露问题，找到了原因是很多析构函数没有找到，问题已修复；
web内存堆积问题，解决方案是做web子进程改造，这也是微信采用的解决方案，目前正在开发中。

经验分享

经过这次崩溃优化，自己总结了一些方法论，如果要解决内存相关的崩溃问题，要做的事情分三步：

确认崩溃和内存相关。这一步需要开发者有扎实的理论功底，能够理解安卓内存模型，并且要通过分析崩溃堆栈，得到该崩溃是否是内存问题的结论。
找到内存问题原因。这一步需要开发者有侦察能力和足够的耐心，能够通过log发现用户操作的共性，然后谨慎的重现问题，只要重现了问题，后面的事情就好办了。这一步也是最重要的一步。
优化内存问题点。这一步需要开发者有丰富的开发经验，要得出最小成本的解决方案。

以上就是我在最近崩溃优化中所总结出来的一些经验，感谢您的阅读，希望能对你有帮助，有问题欢迎留言讨论！

Android系统的内存与崩溃优化

内存的相关概念——弄懂大Boss

OOM崩溃——第一只拦路虎

乱七八糟的Native崩溃——真正的大Boss

GL OOM——挑战大Boss

经验分享

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读