支付宝客户端 OOM 专项优化实践（安卓篇）


一、背景：

作为一名Android程序开发者，在日常的代码开发工作中可能不会过多关注自己业务对内存的使用是否合理，通常情况下Android系统的内存管理机制帮我们处理好了内存的分配和回收。然而在一些异常场景下不合理的内存占用不仅会使用户应用程序运行卡顿、ANR、黑屏，在极端情况下还会发生 OOM（Out Of Memory）崩溃，极大影响用户体验造成用户流失。通常我们在对待线上的的Out of Memory的闪退都会被当做小概率事件没有被有效重视和系统分析，本文将结合支付宝线上OOM真实案例详细的介绍下常见OOM问题的根因分析和优化实践。

在支付宝应用架构的不断演进中用户支付场景已经是最基础的使用场景，随着小程序生态的引入森林庄园等复杂h5/小程序的使用比例不断增长，同时理财、本地生活等重度业务也运行在支付宝这艘航母上，并且在每年的大促活动像双11、618、新春五福活动上线后让本就不富裕的内存空间又雪上加霜，在2020年之前支付宝的内存问题一直未被重点关注，从一组数据可以看到在过去的19-20财年中，客户端OOM闪退率暴涨了近一倍，占整体客户端闪退的45%以上，内存水位则涨幅在300M左右，按照这个趋势20年底的OOM闪退率会涨幅50%。那到底是什么原因导致的支付宝OOM问题如此严重呢？这里先抛出几个问题：

  1. 线上低端机的OOM问题是否真的比高端机更严重呢？
  2. 线上的OOM真的全是由于Java内存泄漏导致的堆内存紧张导致的吗？
  3. 线上OOM有没有可能在App堆内存宽裕，设备物理内存也宽裕的情况下发生？

二、OOM问题根因分析

2.1 OOM分类

通过以下数据我们可以看到在支付宝32位包的OOM闪退中9-11系统的占比远远超过6.x以下机器，并且在对闪退时内存统计中发现5.x以上机器闪退时端上整体内存值还有大量剩余，而虚拟内存空间几乎达到了2^32=4GB。

众所周知32位应用程序的虚拟内存寻址上限只有 2^32=4GB，无论高端机还是低端机只要虚拟内存寻址达到这个上限就会触发系统OOM闪退，通常在logcat日志中会看到"OutOfMemoryError: pthread_create (1040KB stack) failed: Try again", "libc++abi: terminating with uncaught exception of type St9bad_alloc: std::bad_alloc"，"Could not mmap handle 0x67ae34d0 fd=652 (Out of memory)"等。因此按照不同的成因我们总结了OOM问题分类，只有对线上OOM问题清晰的认识和分类才能更好的感知问题变化和有针对性的治理

2.2 虚拟内存地址指标量化

下面将会从虚拟内存结构入手详细地讲解一下导致虚拟内存寻址空间不足的原因，从下图内存结构看出去系统占据的1G外剩下3GB内存都是如何分配？通常我们在写 Native 代码的时候，并不会直接调用内核的 API 去申请物理内存，而是使用 malloc 族的函数进行内存申请，这时候返回的指针是指向虚拟内存中的地址空间，之后在这部分地址空间真的被使用的时候，才会发生缺页中断触发真实的物理内存分配，所以通常是两层分配结构，用户态的代码申请的内存来自于内存分配器的二次分配，常见的内存分配器有 JeMalloc、TcMalloc、PtMalloc 等等。这里也解答了上面的问题，手机物理内存或javaheap内存只使用不到50%的情况下，虚拟内存可能已经打满同样会触发OOM闪退。

三、线上监控&问题感知

那么虚拟内存的使用应该如何度量呢？简单的方式是直接从/proc/{pid}/status文件读取vmsize数据，但如果要做到能感知线上内存水位变化并快速定位问题还需要更细粒度的分类。如上图所示，通过对/proc/{pid}/maps地址文件的内存分配标记进行分类可量化成20+个细粒度内存指标，在支付宝启动后的内存空间分析中可以看到在支付宝启动后留给业务的内存空间大概在1-2G左右，如果没有有效的内存监控释放手段，随着应用使用时长的增加，内存地址空间会被迅速耗尽。下面会介绍线上主要的几个内存监控方式。

3.1 支付宝全局虚拟内存水位监控

基于虚拟内存的水位监控主要作用是感知活动或者开关变更导致的内存上涨，同时能确定业务维度的内存水位变化，通过制定告警阈值，让线上问题定位达到分钟级别。

3.1.1 典型案例：首页氛围图和腰封 Lottie 动画

大促活动期间首页氛围图或腰封上线lottie动图引起的Libcmalloc上涨约涨20-50M，导致OOM闪退率上涨30%，相比业务上线活动首页氛围和腰封的变更影响是全局的基础水位，对OOM闪退率影响较大。下图为某次活动0点发布氛围后支付宝整体内存水位上涨40M。针对这一问题我们对所有lottie上线资源做了动态的内存检测，超过阈值则被禁止上线，同时通过线下的内存检测结果可预估lottie上线后对线上闪退率的影响

0点活动上线内存水位上涨

线上闪退率预估

3.1.2 典型案例：大促活动

随着渲染技术迭代新春五福，双11活动的页面动画特效复杂度越来越高，已经不再局限于2D动画，并且活动页会为支付宝内其他业务引流，当用户不断跳转页面访问时内存可能不会及时释放，导致短时间的内存叠加效应引起内存水位升高同时OOM闪退率上涨。针对这一问题，支付宝活动都会针对渲染特效设计几种降级方式，在内存水位变化幅度超过阈值或OOM闪退率上涨情况下可以对业务进行统一降级，动画->静态图，3D->2D等


3.1.3 典型案例：Dexpatch

Dexpatch发布引起的端整体Public-File水位上涨50M左右，由于Dexpatch本身的实现方式要在native解包和替换，导致mmap了大量内存，目前在32位包已经不再使用Dexpatch热修复。下图是线下测试结果：

3.1.4 典型案例：uc内核解压

uc压缩内核推动动态bundle，通过用户日志可以发现so解压后出现错误，导致用户重复进行初始化进而导致Public-Files内存上涨后触发OOM闪退。在推送回滚后，整体崩溃率下降。

3.1.5 典型案例：蚂蚁庄园

蚂蚁庄园3周年活动，生活号文章插入超大gif动图导致Gpu增幅超过300M引起线上OOM闪退告警，暴露了目前对于h5/小程序中的大图、视频和动图没有提前发现的能力。基于这个问题在对业务准入的时候增加图片视频的静态尺寸检测和动态内存检测，避免类似问题再次发生。

小程序/H5中资源与内存使用关系梳理：高清大图内存主要分配在gpu上，随便下载了一些文章详情的图片发现大小都在1MB以内，这是因为图片都是有压缩的，但是在手机中图片显示是完全解压状态，正常情况图片的内存计算方式：


3.2 运行时业务维度内存异常监控

在监控内存水位的同时，我们还要掌握每个业务生命周期内分配的内存空间是否合理，目前做法是通过开关配置一组内存指标异常值，当业务单次采样间隔内存分配超过阈值时上报相关数据，概数据帮助我们在线下推动业务对内存使用优化，同时配合线上告警机制保证业务内存使用变化时能快速感知到。

典型案例：

线上监控到某选图打印的小程序单次的Libcmalloc增幅超过300M，导致该应用OOM闪退率是正常业务的20倍，主要原因有2点：

    1. 用户在使用小程序时会选择一张手机图片，在多媒体选图组件做图片预览和大图展示时为了加快图片展示提前加载了选图前后2张，由于图片加载内存全部分配在Native导致Libcmalloc内存大幅上涨，个别用户涨幅超过1G
    2. 多媒体组件没有监听小程序退出事件，因此没有及时做内存回收导致缓存的图片数据长时间在内存中保存

3.3 闪退时刻的端上运行环境数据记录在内存问题排查中至关重要

支付宝微镜平台提供了闪退issue的查看和分析能力，我们只需在客户端闪退时按照一定格式将端上运行时数据记录到埋点即可在平台查看到聚合后的数据

Moudles
  Moudles-Ashmem
  Moudles-JavaVM
  Moudles-Native-Anonymous
  Moudles-Native-Bss
  Moudles-Native-LibcMalloc
  Moudles-Native-Other
  Moudles-Other
Public
  Public-Devices
  Public-Files
  Public-Gpu
  Public-Threads
U4Core
  U4Core-BlinkGC
  U4Core-PartitionAlloc
  U4Core-SharedMemory
  U4Core-UCMalloc
  U4Core-V8 Heap

典型案例：

  1. MIUI Android 10 系统字体重复占用虚拟内存，导致支付宝 App 可用的虚拟内存变少，更容易发生崩溃（发生OOM）。支付宝在20年的双十一活动的 OOM 中，小米+红米机型占比 43%，高于小米手机的市占率
  2. 某外卖小程序在使用v8 worker的时候调用message port发给render进程大量消息并使用了sharedmemory导致闪退率上涨

四、内存诊断&治理

4.1 Native内存问题治理

支付宝是一个汇集了扫码，端智能，AR，小程序容器，音视频播放等 native 代码非常多的大型应用，据不完全统计有100个so在支付宝内运行，每个 native 代码相关的模块背后都有一个专业团队在高速迭代，Java 堆内存因为有比较成熟的工具和方法论，加上 hprof 快照作为补充，定位和治理都很方便，native 内存问题一直缺乏高效稳定的工具导致问题治理难度非常大。事实上，单纯的native内存泄漏问题相对较少，更多的是因为业务逻辑不合理带来的内存使用问题，需要工具渗透到 App 运行的过程中进行监控，对工具性能和稳定性提出更高的要求。

因此对于支付宝的 native 内存泄漏监控工具的诉求主要有以下几个方面：

  1. 接入成本：无需额外适配Android 版本，无需 root
  2. 稳定性：几乎不影响业务的稳定性问题，可以满足灰度版本开启即可
  3. 性能层面：对业务运行和启动都没有明显劣化影响，无卡顿和ANR问题
  4. 监控范围：不局限于 malloc/calloc/realloc/memalign/free，至少还能覆盖 mmap/mmap64/munmap
  5. 支撑广度：内存监控，内存泄漏，野指针检测等

1. 工具调研

维度产品

SoAOP（支付宝）

malloc debug

AddressSanitizer

memhook(UC)

Native Finder(手淘)

是否需要root

不需要

需要

需要

需要

否

功能支撑广度

内存泄漏、So内存值监控、堆破坏、野指针

内存泄漏、堆破坏、野指针

内存泄漏、堆破坏、野指针、缓冲区溢出

内存泄漏检测

内存泄漏、堆破坏、野指针

堆栈能力

有

有

有

有

有

性能

好

差

好

较好

好

接入成本

低

高

高

高

较高

2. 技术方案

支付宝的 native 内存泄漏监控工具主要包含三部分：代理实现、栈回溯和缓存管理，其中代理实现是对malloc/calloc/realloc/memalign/free和 mmap/mmap64/munmap等函数的hook，决定了hook的准确程度至关重要，这里我们选择了比较成熟的PLT hook 工具代表 xHook，该方案已经在业内多个内存线上方案中使用，其稳定性可以达到上线标准。在栈回溯上使用了性能更好的libudf方案兼具了性能要求和回溯成功率，为了提高线上的使用场景，我们在使用时通过开关限制栈回溯频次

方案细节：

    1. 首先客户端在启动后会初始化注入hook相关的服务。
    2. 通过轮询扫描proc/self/maps获取支付宝包内的实时so数据，并添加so管理。
    3. hook的malloc/free/mmap/munmap/mmap64/pthread_exit/calloc/realloc
    4. 监听方法回调，根据内存指针通过malloc_usable_size方法获取对应的内存和so数据，进行统计内存。

目前线下方案通过动态bundle的方式可以扫码实时加载到支付宝客户端中，通过悬浮窗的方式展示内存数据和栈回溯信息，同时也支持接口和Logcat日志方式查看数据

3. 典型案例

  1. 搜索引擎使用文件缓存聊天词汇提高搜索效率，在灰度版本中出现较多的索引文件导致虚拟内存异常升高，其中（/lib/arm/libclient_searcher.so malloc= 103M） + （/files/search/alipay_search/allin/idx_0 mmap = 188M）= 291M内存使用

可以从maps的地址空间看到多个mmap的文件信息

  1. cube上层业务社交商家群页面如果快速进出页面未及时调用释放接口导致cube native内存泄漏，cube业务本身缺少运行时的内存监控，对上游业务方的使用充分信任，导致这个灰度版本问题，在业务优化后修复

4.2 FD内存问题治理

技术方案

__FD_SET_chk 问题大多出现在 Android 7.1.2 及之前版本原因是FD 总数超过 1024 个导致，如下图所示大多在闪退堆栈中能看到__FD_SET_chk 标识。

线上的FD的主要监控方式是在FD总数超过900后通过/proc/{pid}/fd采集所有fd数据进行上报，并对FD名称进行聚合，以issue的形式在微镜平台展示，这样在某一类FD异常pv变化时就能找到相关变更点

线下通过shell脚本方式可以进行测试

# 注：如遇到 command not found，需要使用 homebrew 安装相应命令
export PKG=com.eg.android.AlipayGphone

function apid() {
    echo $(adb shell pidof $PKG)
}

# Mac 上 watch 命令需要使用 homebrew 安装（brew install watch）
watch -n0.2 -d "adb shell run-as $PKG ls -l /proc/$(apid)/fd/ | cut -d' ' -f10 | sed -E 's/[0-9a-fA-F]{4,}/xxx/g' | sort | uniq -c | sort -nr | head -10"

典型案例

  1. Gpu独立进程使用的 Surface 对象未主动释放，在部分手机出现FD泄漏导致闪退率上涨

主进程 anon_inode:sync_file FD 泄漏的 pv 从 1 月 24 日 9k 上涨到 2 月 3 日 50.7 万，并且持续未恢复，sync_fence 和 sync_fence_mali_fence 的issue趋势相同。

    1. 使用 NDK 提供的 API sync_file_info/sync_get_fence_info 发现了关键字 :gpu_process，SurfaceTexture。
    2. 线下测试关闭 GPU 独立进程后（开关 h5_uc_gpu_process_mode=0）不再出现泄漏
    3. issue 上涨趋势大致与开启 GPU 独立进程的节奏同步

Gpu 进程使用的 Surface 对象，其内部的 SurfaceTexture 来自 TextureView，很多手机的实现都需要主动执行 Surface.release() 才能释放这个 SurfaceTexture 资源（待 Surface 对象被 gc finalize 也会释放），原生实现未执行主动 release 导致 SurfaceTexture 泄漏，其 native 实现有申请 sync_file 等对象，导致 fd 泄漏。

4.3 CloseGuard资源泄露检测

CloseGuard 介绍

系统代码预埋了一些检测点，检测需要手动释放却未释放的资源。分配资源时获取调用栈，并记录对应的关闭方法的名称，GC 回收时在finalize() 方法里检测是否释放过，没有释放则上报异常（不会 crash）。原理可参考系统说明文档 CloseGuard。

常见的可以检测的资源泄漏：

  1. 各种 InputStream/OutputStream 未 close
  2. android.view.Surface 未 release
  3. android.database.Cursor 未 close
  4. android.app.usage.NetworkStats 未 close

可以检测的资源依赖系统代码预埋。Android R 起系统开放了接入接口，可以将自定义的资源纳入检测

手动回收必要性

系统在 finalize 里会回收，为什么还有手动回收？finalize 回收是系统做的兜底，时机不确定，回收不及时会抬高内存峰值，当虚拟内存峰值接近 4GB，再申请内存就会 crash，即使以后能回收也晚了。未回收的资源背后可能是 java healp 内存, C/C++分配的内存，FD，mmap，GPU，Bitmap 等，不止会造成内存问题，还可能导致 FD 超限等问题

线上监控

目前已经将检测结果和缺陷平台打通，可以在版本灰度期间卡住新增的泄漏问题

典型案例

  1. ZApacheSSLSocketFactory socket 泄露导致 pipe FD 泄露
2021-05-14 14:29:12:801 E/mynet_HttpWorker:[5761:HttpManager.HttpWorker#h5#14] processException,exceptionName = IOException,code=[6] canRetry=[false] e=[java.net.SocketException: Socket closed] java.net.SocketException: Socket closed
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
    at com.android.org.conscrypt.NativeSsl.doHandshake(NativeSsl.java:387)
    at com.android.org.conscrypt.ConscryptFileDescriptorSocket.startHandshake(ConscryptFileDescriptorSocket.java:226)
    at com.alipay.mobile.common.transport.ssl.ZApacheSSLSocketFactory.createSocket(ZApacheSSLSocketFactory.java:100079)
    at com.alipay.mobile.common.transport.http.ZClientConnectionOperator.connect(ZClientConnectionOperator.java:100221)
    at com.alipay.mobile.common.transport.http.ZClientConnectionOperator.openConnectionCustome(ZClientConnectionOperator.java:100108)
    at com.alipay.mobile.common.transport.http.ZClientConnectionOperator.openConnection(ZClientConnectionOperator.java:100193)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:170)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:124)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:366)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:587)
    at com.alipay.mobile.common.transport.http.AndroidHttpClient.execute(AndroidHttpClient.java:100002)
	at com.alipay.mobile.common.transport.http.HttpWorker.doExecuteRequestByHttpClient(HttpWorker.java:100017)

sslSocket.startHandshake 中抛出异常导致 sslSocket 对象没有机会关闭

public class ZApacheSSLSocketFactory implements LayeredSocketFactory {
    @Override
    public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException {
        SSLSocket sslSocket = (SSLSocket) ZCustSSLSocketFactory.getSSLSocketFactory().createSocket(
                socket,
                host,
                port,
                autoClose
        );
        // ...省略部分代码
        int soTimeout = socket.getSoTimeout();
        try {
            sslSocket.startHandshake();
        } finally {
            setSoTimeout(socket, soTimeout);
        }
        return sslSocket;
    }
}
  1. Inflater/okhttp.GzipSource/HttpURLConnection.getResponseCode
java.lang.Throwable: Explicit termination method 'end' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:221)
    at java.util.zip.Inflater.(Inflater.java:114)
    at com.android.okhttp.okio.GzipSource.(GzipSource.java:62)
    at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:473)
    at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:648)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:471)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:407)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:538)
    at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
    at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:26)
	at com.alipay.android.msp.framework.helper.FileHelper.a(FileHelper.java:43)

原因：HttpURLConnection的getInputStream 未 close

  1. Deflater/GZIPOutputStream.
java.lang.Throwable: Explicit termination method 'end' not called
	at dalvik.system.CloseGuard.open(CloseGuard.java:221)
	at java.util.zip.Deflater.(Deflater.java:181)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:90)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:109)
	at com.alipay.mobile.mascanengine.imagetrace.ImageTracer.trace(ImageTracer.java:2161)

原因： GZIPOutputStream未close导致Deflater未 end

  1. GZIPOutputStream 设计问题导致无法关闭 Deflater
java.lang.Throwable: Explicit termination method 'end' not called
	at dalvik.system.CloseGuard.open(CloseGuard.java:237)
	at java.util.zip.Deflater.(Deflater.java:189)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:90)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:109)
	at org.nanohttpd.protocols.http.response.Response.a(Unknown Source:29)
	at org.nanohttpd.protocols.http.response.Response.send(Unknown Source:291)

原因：GZIPOutputStream 构造函数往 socket 写数据异常，导致 Deflater 没机会关闭

java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:141)
	at org.nanohttpd.protocols.http.response.ChunkedOutputStream.write(Unknown Source:25)
	at org.nanohttpd.protocols.http.response.ChunkedOutputStream.write(Unknown Source:2)
	at org.nanohttpd.protocols.http.response.MyOutputStream.write(Unknown Source:6)
	at java.util.zip.GZIPOutputStream.writeHeader(GZIPOutputStream.java:182)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:94)
	at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:109)
	at org.nanohttpd.protocols.http.response.Response.a(Unknown Source:29)
	at org.nanohttpd.protocols.http.response.Response.send(Unknown Source:291)


解决方案：

public class GzipOutputStreamWrap extends GZIPOutputStream {

    public GzipOutputStreamWrap(OutputStream outputStream, int size) throws IOException {
        super(new OutputStreamWrap(outputStream), size);
        if (this.out instanceof OutputStreamWrap) {
            OutputStreamWrap wrap = (OutputStreamWrap) this.out;
            wrap.mCacheException = false;
            if (wrap.mCachedException != null) {
                this.def.end();
                throw wrap.mCachedException;
            }
        }
    }

    static class OutputStreamWrap extends FilterOutputStream {

        private boolean mCacheException = true;
        private IOException mCachedException = null;

        public OutputStreamWrap(OutputStream out) {
            super(out);
        }

        @Override
        public void write(int b) throws IOException {
            if (mCacheException) {
                try {
                    super.write(b);
                } catch (IOException e) {
                    mCachedException = e;
                }
            } else {
                super.write(b);
            }
        }

        @Override
        public void write(byte[] b, int off, int len) throws IOException {
            if (mCacheException) {
                try {
                    super.write(b, off, len);
                } catch (IOException e) {
                    mCachedException = e;
                }
            } else {
                super.write(b, off, len);
            }
        }

        @Override
        public void write(byte[] b) throws IOException {
            if (mCacheException) {
                try {
                    super.write(b);
                } catch (IOException e) {
                    mCachedException = e;
                }
            } else {
                super.write(b);
            }
        }
    }
}

五、内存优化方案

在对内存问题治理的同时我们也在尝试进行支付宝运行时的内存优化，主要思路是通过内存监控进行全端的内存水位通知，让监听的业务方能结合自身情况给主进程释放更多的空间

5.1 全局内存通知降级

客户端MemoryNotice监听查询

final AbnormalReq abnormalReq = new AbnormalReq();
abnormalReq.type = MemoryNotice.class;
Stability.getAbnormalDCApi().registerAbnormalListener(new ADCApi.AbnormalListener() {

  private final Set request = Collections.singleton(abnormalReq);

  @Override
  public Set accepts() {
    return request;
  }

  @Override
  public void onAbnormal(Abnormal abnormal) {
    if (abnormal instanceof MemoryNotice) {
      int memoryLevel = ((MemoryNotice) abnormal).getMemoryLevel();
      switch (memoryLevel) {
        case MemoryNotice.MemoryLevel.Critical:
              // 释放内存。
              // 回调不在主线程执行
          break;
      }
    }
  }
});

主要监听业务：

  1. 多媒体图片缓存服务，在内存紧张时可降低已缓存的图片内存数据
  2. Lottie内存释放，在首页腰封等展位通常使用Lottie动画展示动图，在内存紧张情况下可在首页不可见时降低缓存数据
  3. 小程序容器会在Critical内存等级时提示用户当前使用的小程序可能出现异常，引导用户关闭小程序释放内存空间，避免主进程闪退
  4. Art mainspace内存空间释放监听了内存通知，当内存超过一定阈值时会触发内存压缩（详见下文）
  5. 小程序业务统一降级，支付宝大促活动通常会接入统一降级能力，通过开关可直接对线上活动页的动画，特效，渲染方式等做降级，在端上内存不足时会触发统一降级的自动降级，达到降低业务内存使用的目的

5.2 Art Mainspace空间压缩

技术方案：

通常情况下，我们的应用都会开启 largeHeap，来获得更大的内存上限，因为默认可用的空间只有 192M，这是由参数 dalvik.vm.heapgrowthlimit 决定的，对于大部分集团应用来说显然是不够的，但是开启 largeHeap 之后实际可用则可达到 512M = 1024 / 2 ,这也导致了应用启动的时候就会申请 1G 的地址空间，同样对于大部分应用来说，直到 abort 或者应用被杀死，都不会使用如此多的地址空间

释放前Mainspace占有1G 释放后Mainspace占有500M

效果：

500M内存对于32位包的OOM问题降低有非常大的作用，在线上的闪退率监控中使用Mainspace释放后的版本闪退率降低了30%

5.3 Gpu独立进程

技术方案：

1、剥离驱动兼容性问题到子进程，不要让他影响主进程

2、降低内核渲染对主进程的资源依赖，降低主进程oom


效果：

在gpu独立进程全量开启后，线上日均8K的OOM闪退类型：GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed和sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory几乎清零。在2021年五福项目期间GPU独立进程使得支付宝Android整体闪退率下降了 65% 73%

六、总结

支付宝内存从2020年初开始治理优化，OOM闪退率从最开始的万分之0.84降低到万分之0.14，在线上问题感知上，内存水位和业务异常内存变化可在5分钟内感知到，在问题诊断定位上可达到半小时内定位具体业务和问题根因代码，H5/小程序可在1天内修复好迭代发版。在新春五福红包等大促活动中峰值OOM闪退率也从万分之2降低到万分之0.3左右，极大的降低了客户端故障风险。

内存优化实践大图


同时我们总结了一套完整的内存优化实践方法论，本文主要针对线上能力和案例进行了分析，其实线下的问题定位和卡劣能力建设同样非常重要。

1. 线下IDE工具和泄漏检测工具建设

线下定位和复现工具建设，包括线下的内存水位曲线监控工具，泄漏检测工具，端上实时内存数据展示等，能帮助我们在线下快速定位到问题根因，帮助业务修复

2. 版本发布内存劣化卡口

在版本发布周期内对每日构建包进行大版本间的内存水位对比和泄漏检测，在版本发布维度将问题卡在线

3. H5/小程序及动画资源变更卡口

制定业务资源和内存使用标准在业务开发阶段引入检测手段发现异常点并提示给前端开发。在H5/小程序、Lottie等发布上线环节增加卡劣检测措施，提前发现内存问题

目前支付宝在最近几个大版本平稳过渡到了64位包，64 位应用的虚拟内存地址空间上限是 2^39=512GB，理论上看彻底解决了32位包的虚拟内存地址不足的问题，但是线上32位包用户占比仍有约10%左右，短时间内都将保持双包并存，因此32位包用户的体验问题仍然不能放手不管。同时64位包升级后的Java堆内存不足问题和线程超限问题同样需要关注。面对支付宝庞大的线上用户和复杂的线上问题，64位升级远远不是终态，前方面临的挑战还有很多，时刻不松懈才能守住内存的底线。

七、参考文献

【手淘稳定性】Native治理利器——Native Finder

Android 32 位应用 Native Crash Top1 Abort 的探索和解决

链接2019年双十一Android U4内核OOM问题总结

西瓜视频稳定性治理体系建设二：Raphael 原理及实践

GPU独立进程（进程隔离）


八、本文作者

安晴、推敲


转自支付宝质量开放平台AnTest：

https://antest.alipay.com/ecoquality/tblog/01bwwe/03eyb2

展开阅读全文

页面更新：2024-04-21

标签：水位   专项   客户端   进程   分配   内存   案例   业务   程序   数据   用户   图片

1 2 3 4 5

扎克伯格的元宇宙冲锋面临多重“障碍”

Meta尚未证明，其每年100亿美金押注沉浸式虚拟世界将取得成功。不久前9月初，扎克伯格因为他“不成熟”的卡通头像自拍在网络上疯传，被广泛嘲笑。这仅仅是扎克伯格面临的障碍之一，比较小的一个。英国《金融时报》9月的一份

「Android面试题」JVM的垃圾回收之判断哪些内存需要回收

我们只有在程序运行期间才知道创建了哪些对象，这部分的内存的分配和回收是动态的。垃圾回收也是关注这部分的内存。了解内存回收我们主要从这几个方面入手：1.哪些内存需要回收。2.什么时候回收。3.怎么回收。也是说who,

新的“拐点”出现，台积电再秀肌肉，苹果也扛不住了

大家都知道，在芯片代工领域，台积电可谓是一家独大的存在，就算三星早一步实现了3nm制程芯片的量产，但仍然撼动不了台积电的地位，原因无他，只因台积电拥有超高的芯片产能和良品率。然而，由于全球半导体行业的不景气，再加上人工

念奴娇•生命的意义

人生一世，七十稀，劳苦奔波游戏。酒色财气，福禄禧，拼命争夺熙熙。有人欢喜，有人悲泣，到头来空兮。活着意义，谁能说得明晰？道家无为而治，道法自然了，自然何依？佛陀苦悟，参智慧，智慧可是本体？九流人士，只要能谋钱，万物可弃。造物上帝，道路

心灵相通，方可相守

人逢爱情精神爽，月到仲秋分外明。心灵相通似知己，仲秋桂花别样香。大自然，最美的景是山水相依，人世间，最美的爱，是心灵相通；一辈子，最美的情，是相惜而行。心中有爱爱如山，坚如磐石，无须多言，心中有情情似水，上善若水，勿须多语。心

夜读丨秋落

。作者丨赖丽芳主播丨沈 文山后住着的那轮月亮，像有了醉意，摇摇晃晃、忽明忽暗地钻出树隙。田野里，大片大片的稻浪如温过的米酒般翻滚着，风一吹，就醉倒了山脚下的农家人。月光拓印出了村坊瓦房的轮廓。屋后的溪水，给遇到的

得到未必是福，失去未必是祸

人生有两大憾事：一是得不到，二是已失去。很多时候，我们总是在为了自己所想要的人生而疲于追逐。然而生活的残酷之处就在于：你越在乎的事，越容易落空；越在意的人，越容易离开。你很清楚，你已经足够努力用心去做了，却怎么也达不成

文案：成年人谈感情，不是靠牵手拥抱就能满足对方

1、当你一身泥泞，再怎么献殷勤，都是别人眼中无关紧要的存在。当你光芒万丈，无需刻意讨好，别人也会想尽办法主动靠过来。不要去追一匹马，用追马的时间种草。2、因为自己一直没有很稳的墙可以靠，所以我就觉得自己要当那座山。

七律·寒露感怀

文/钱塘雨艽霜凝玉露沁秋深，夜长寒晖扫暗金。淡著残枝烟笼岭，浓描老叶火燎林。云中啼雁乡思满，楼上吹箫故梦沉。落尽天涯家万里，一花一叶寄冰心。（王雨艽诗词原创2022.10.8.）

看清本质

你的是你的，我的是我的，你的永远不可能成为我的。哪怕你说你的全部都属于我。但事实上，归根究底，你的最终还是只会属于你自己。所以我还是得靠我自己，也必须靠我自己。只有靠自己本身得到的才能真真切切，实实在在的握在自己

有钱能让人抬狗

在过去，人们说“有钱能使鬼推磨。”在现在，我们说：“有钱能让人抬狗。”鬼推磨，鬼是为了钱。人抬狗，人也是为了钱。人们对金钱的渴望，已让人分不清哪是人，哪是狗。这是一只普通的狗，这是一只不普通的狗。说这只狗普通，是因为这

好句摘录

人这辈子千万不要马虎两件事：一是找对爱人，二是找对事业。因为太阳升起时要投身事业，太阳落山时要与爱人相拥的。——《人民日报》我相信，路虽远行则可至，事虽难做则可成.无论生活怎样，希望你保持自律保持热爱。昨日之深渊

国庆假期多地发放消费券 假日经济更加红火

央视网消息：今年国庆假期，各地在做好疫情防控的同时，采取发放消费券等方式促消费，让假日经济更加红火。 河南郑州：消费券化为消费力 假日经济持续升温 国庆期间，河南省郑州市各大景区推出优惠套票、夜场特惠、延长营业时间，

兰州最南端 榆中县龙泉乡骡子滩村

水家坡堡子发展养殖业洋芋宴扫码看视频兰州最南端为地处南山的榆中县龙泉乡骡子滩村，与属于北山地区的高家渠相比，这里地势较为平缓，气候温润，是发展种养殖业的天赐之地；这里文脉绵长，有千年古寺龙泉寺，附近有保存完整的兰州

浙江一家到西安农家乐，点“7菜2酒”只花360块，临走直言：真值

国庆节快要结束了，上班族也到了收心的时候了，但也有个别旅友依旧游玩在外，沉浸在旅游的快感中。然而，和以前的截然不同的是，如今有不少人抱怨外面的消费太大了！这倒也是事实，究其原因，主要还是受到了“YQ”的影响。出门在外，吃
上滑加载更多 ↓
推荐阅读：

「Android面试题」JVM的垃圾回收之判断哪些内存需要回

《用户标签体系的搭建SOP》完整版，收藏学习

大数据会如何扫黄呢？私下浏览网站也会被查吗？你还敢看吗

大数据分析培训就业和发展前景

苹果 iPhone 14 原装数据线采用 C91M 连接器

羊了个羊“山寨”版纷至沓来 小程序游戏藏着复杂生意

新闻+服务！“壹点帮办”小程序重磅上线，四大功能给您全

华为监事会副主席丁耘去世，曾任两大主营业务一把手

湖北十一旅游数据：花300元住五星酒店，“反向旅游”成关

为什么不建议选512GB内存手机？有人给出这4个理由，你怎么

友情链接：
更多：

本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828  

© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号

Top