原生Android C++应用内存不足崩溃处理与优雅退出方案问询

我的C++原生Android应用在仅配备768MB RAM的设备上会周期性因内存不足崩溃，崩溃发生在malloc或dlmalloc_real调用时。以下是Google Play Console上报的其中一份堆栈跟踪：

#00 pc 00000000000225ac /system/lib/libc.so (tgkill+12)
#01 pc 00000000000130b1 /system/lib/libc.so (pthread_kill+48)
#02 pc 00000000000132c5 /system/lib/libc.so (raise+10)
#03 pc 0000000000011ff9 /system/lib/libc.so
#04 pc 0000000000021e60 /system/lib/libc.so (abort+4)
#05 pc 0000000000012ae1 /system/lib/libc.so
#06 pc 000000000000f205 /system/lib/libc.so
#07 pc 000000000001010d /system/lib/libc.so (dlmalloc+604)
#08 pc 000000000000dce7 /system/lib/libc.so (malloc+10)
#09 pc 00000000000cf8d1 /system/lib/libGAL.so (gcoOS_AllocateMemory+8)
#10 pc 00000000000cf943 /system/lib/libGAL.so (gcoOS_Allocate+46)
#11 pc 0000000000029d65 /system/lib/egl/libGLESv2_MRVL.so (__eglMalloc+16)
#12 pc 00000000000284a3 /system/lib/egl/libGLESv2_MRVL.so (__glGetDrawable+338)
#13 pc 0000000000029cfb /system/lib/egl/libGLESv2_MRVL.so
#14 pc 00000000000083a9 /system/lib/egl/libEGL_MRVL.so (_ApiMakeCurrent+32)
#15 pc 0000000000009987 /system/lib/egl/libEGL_MRVL.so (veglMakeCurrent+1838)
#16 pc 0000000000009dcb /system/lib/egl/libEGL_MRVL.so (eglMakeCurrent+54)
#17 pc 000000000000d459 /system/lib/libEGL.so (android::egl_display_t::makeCurrent(android::egl_context_t*, android::egl_context_t*, void*, void*, void*, void*, void*, void*)+84)
#18 pc 000000000000fbc5 /system/lib/libEGL.so (eglMakeCurrent+240)
#19 pc 0000000000073569 /data/data/net.my.app/qt-reserved-files/plugins/platforms/android/libqtforandroid.so

请问是否有办法处理内存不足场景，让应用优雅退出并向用户提示消息？另外，这样做是否有意义？目前不清楚崩溃率是否会影响Google Play应用评分。

Great question! Let's break this down into actionable solutions and their value:

1. 能否实现优雅退出并提示用户？ #

可以，但存在一些局限性——你的崩溃起源于系统库（比如libc.so的malloc），当触发abort时，进程已经处于不稳定状态。以下是最实用的解决思路：

a. 提前监控内存并释放资源（最优方案） #

这是从根源避免崩溃最有效的方式。Android会在内存不足时发送信号，你可以利用这些信号提前处理：

• Java层：在你的Application类中重写onTrimMemory()和onLowMemory()方法。系统在内存不足时会调用这些方法，你可以通过JNI通知C++层立即释放非关键资源——比如缓存的OpenGL纹理、闲置的对象池、临时缓冲区或离线渲染资源。
• C++层：对于你直接控制的内存分配，务必检查malloc()（或new）的返回值。如果返回NULL，触发可控的资源清理流程，尝试恢复，或者通知Java层显示提示后优雅退出。

b. 捕获终止信号触发优雅退出 #

你的堆栈跟踪显示崩溃最终调用了abort()，这会发送SIGABRT信号。你可以在C++代码中安装信号处理器来捕获这个信号：

#include <signal.h>
#include <jni.h>

// 提前获取Java方法的引用（在应用初始化时完成）
static jmethodID showLowMemoryPrompt = nullptr;
static JavaVM* gJvm = nullptr;

void sigabrtHandler(int signum) {
    // 这里只能执行最小化操作——绝对不能分配内存！
    JNIEnv* env;
    if (gJvm->GetEnv((void**)&env, JNI_VERSION_1_6) == JNI_OK) {
        jclass appClass = env->FindClass("com/your/app/YourApplication");
        env->CallStaticVoidMethod(appClass, showLowMemoryPrompt);
    }
    // 执行完自定义操作后，让默认处理器继续处理信号
    signal(signum, SIG_DFL);
    raise(signum);
}

// 在应用启动时注册处理器（比如在JNI_OnLoad中）
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) {
    gJvm = vm;
    signal(SIGABRT, sigabrtHandler);
    // ... 其他JNI初始化逻辑
    return JNI_VERSION_1_6;
}

注意：信号处理器有严格的限制——你不能调用任何可能分配内存的函数（比如printf或大部分JNI辅助方法），因为此时堆内存已经耗尽。务必让处理器尽可能简洁。

c. 需要注意的局限性 #

对于起源于系统库的崩溃（比如你堆栈中的libGAL.so分配失败），你无法直接控制这些分配操作。唯一的预防方式是在系统达到OOM阈值前主动释放内存。

2. 这样做有意义吗？绝对有——原因如下： #

• 用户体验：显示清晰的提示（比如“内存不足，请关闭其他应用后重试”）比突然闪退要好得多。用户会明白问题所在，而不是认为你的应用不稳定。
• Google Play评分：是的，崩溃率直接影响应用的曝光度和评分。Google Play会将崩溃指标作为质量信号的一部分——崩溃率高的应用在搜索结果中排名更低，也更容易收到用户的负面评价。减少崩溃（哪怕是替换为优雅退出）有助于维持或提升应用的口碑。

3. 额外建议：从根源减少OOM的长期方案 #

优雅退出只是权宜之计，解决内存使用的核心问题才能带来更大的改善：

• 使用adb shell dumpsys meminfo <你的包名>分析应用的内存使用情况，查找原生代码中的内存泄漏或过度分配问题。
• 对于基于OpenGL的应用（你的堆栈涉及EGL/GLES），确保在资源不再需要时正确释放纹理、帧缓冲区和着色器程序。
• 在C++代码中实现对象池，减少频繁的malloc/free操作，避免内存碎片化。

内容的提问来源于stack exchange，提问作者Dmitriano