android 内存优化笔记

Android 内存优化是开发中的核心课题，它直接关系到应用的稳定性、流畅度以及用户的留存率。内存占用过高，可能导致应用被系统强制回收（LMK），甚至引发 OutOfMemoryError（OOM）导致崩溃。据统计，内存占用超过200MB的应用，其卸载率高达47%。

下面，我将从理论基础、诊断工具、核心优化策略 以及高阶实践这几个方面，为你详细讲解Android内存优化。

1.后台 lmk 如何监控

从android 11开始，通过getHistoricalProcessExitReasons在下次启动时候可以查询被强制"杀掉"的信息。

kotlin 复制代码

// 1. 获取 ActivityManager 实例
val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager

// 2. 调用 API 获取退出信息列表
// 参数说明：
// - getPackageName(): 你的应用包名
// - 0: 指定进程ID，0 表示不限定特定进程，返回包名下所有进程的记录
// - 5: 希望获取的最大记录条数
val exitReasons: List<ApplicationExitInfo> = activityManager.getHistoricalProcessExitReasons(getPackageName(), 0, 5)

// 3. 遍历并处理退出信息
for (exitInfo in exitReasons) {
    val reason = exitInfo.reason // 获取退出原因码
    val timestamp = exitInfo.timestamp // 获取退出时间
    val description = exitInfo.description // 获取可读的描述（可能为null）

    // 根据原因码进行判断
    when (reason) {
        ApplicationExitInfo.REASON_CRASH -> {
            Log.w(TAG, "应用因Java崩溃退出，时间：$timestamp")
            // 可以在这里上报崩溃信息
        }
        ApplicationExitInfo.REASON_ANR -> {
            Log.e(TAG, "应用因ANR退出，时间：$timestamp")
            // ANR时，可以尝试获取Trace信息（Android 11+）
            val traceInputStream: InputStream? = exitInfo.traceInputStream
            // 注意：读取该流需要谨慎，且仅在需要时（如ANR或原生崩溃）使用
        }
        ApplicationExitInfo.REASON_LOW_MEMORY -> {
            Log.i(TAG, "应用因低内存被系统杀死，时间：$timestamp")
        }
        // ... 处理其他原因
    }
}

是否为低物理内存设备

ini 复制代码

    boolean lowRamDevice = activityManager.isLowRamDevice();
    //当物理内存小于1GB的时候返回true

一、内存优化的必要性：为什么它如此重要？

在移动设备上，内存是稀缺资源。做好内存优化主要带来三方面收益：

降低崩溃率 ：有效避免因OutOfMemoryError（OOM）导致的应用闪退，这是最常见的用户差评来源之一。
提升流畅度：减少因内存不足而触发的频繁垃圾回收（GC）。GC会暂停应用线程，导致界面卡顿、掉帧。
提高后台存活率 ：应用占用内存越小，在系统后台被Low Memory Killer（LMK）回收的概率就越低，从而保证应用的连续性和功能（如消息推送）的正常运行。

二、Android内存管理机制（知其所以然）

在动手优化前，理解系统如何管理内存至关重要。

内存限制 ：每个应用都有其堆内存上限（Heap Limit）。这个值因设备而异，低端机可能只有128MB，而旗舰机可能高达512MB甚至更多。
Low Memory Killer (LMK) ：当系统内存紧张时，LMK会根据进程的优先级（oom_adj值）来杀死进程以回收内存。优先级最低的空闲进程（如后台不活动的应用）会最先被杀死。
内存回收（GC） ：Android的垃圾回收器负责回收不再使用的Java对象。然而，如果存在内存泄漏（即不再使用的对象仍被引用），GC就无法回收它们，导致可用内存持续减少。
内存类型 ：除了Java堆内存，还需要关注Native堆 （用于C/C++代码）和显存（GPU内存，用于纹理、帧缓冲等）。Bitmap数据在Android 8.0之后主要存放在Native堆中，但其大小依然会计入应用总内存。

三、诊断工具：找到内存问题的"病灶"

解决问题前，先要精准定位问题。以下是几个常用的内存分析工具：

Memory Profiler (Android Studio)：实时监控应用内存使用情况的利器。它能帮助你发现内存抖动（锯齿状图形）、内存泄漏（内存只增不减）和频繁GC等问题。
LeakCanary：一个强大的自动化内存泄漏检测库。只需集成，它就能在发生内存泄漏时自动弹出通知，并给出详细的引用链，帮助开发者快速定位泄漏源头。
Android系统命令 ：通过adb shell dumpsys meminfo <package_name>可以查看应用详细的内存占用情况。而adb shell dumpsys gfxinfo则能分析GPU渲染和帧率问题，辅助定位显存压力。
StrictMode：开发阶段的"纪律委员"。可以帮助你检测主线程中的磁盘IO、网络操作以及未关闭的SQLite对象等潜在问题。

四、核心优化策略：实战指南

4.1 图片与Bitmap优化（内存占用的"大头"）

图片往往是内存占用的罪魁祸首，优化空间也最大。

采样加载 ：绝不要在ImageView显示缩略图时加载原始图片。使用BitmapFactory.Options的inSampleSize参数进行采样，按比例缩小图片尺寸。

java 复制代码

// 计算合适的采样率
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true; // 仅解析图片宽高，不加载到内存
BitmapFactory.decodeResource(getResources(), R.drawable.my_image, options);
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight); // 计算采样率
options.inJustDecodeBounds = false; 
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.my_image, options);

选择合适像素格式 ：如果图片不需要透明度，使用Bitmap.Config.RGB_565替代默认的ARGB_8888，可以减少一半的内存占用（每个像素从4字节变为2字节）。
使用图片加载库 ：如Glide 或Picasso。它们内部实现了复杂的缓存策略、内存管理和生命周期感知，能极大简化开发并提升性能。
及时回收 ：对于不再使用的Bitmap，尤其是在代码中创建的Bitmap对象，确保及时调用bitmap.recycle()（在Android 3.0以前）或让其失去引用以便GC回收。

4.2 内存泄漏的检测与修复

内存泄漏是导致OOM的元凶，常见场景及解决方案如下：

静态变量持有Context/View ：静态变量生命周期与应用进程相同，如果持有Activity或View的引用，会导致整个Activity无法回收。解决方案是使用WeakReference，或是在onDestroy()中将静态变量置空。
内部类/匿名类（如Handler、AsyncTask） ：非静态内部类会隐式持有外部类的引用。例如，一个未完成的任务持有Activity的引用，导致Activity无法回收。
- Handler ：将Handler定义为静态内部类，并使用WeakReference持有Activity；同时在onDestroy()中移除所有消息和回调handler.removeCallbacksAndMessages(null)。
- AsyncTask ：推荐使用协程或HandlerThread替代。
未取消注册的监听器 ：在onCreate()中注册的广播接收器、传感器监听器等，必须在onDestroy()中取消注册。
WebView ：WebView内存占用大且不易释放。建议为WebView单独分配一个进程，或者在使用完的onDestroy()中调用webView.destroy()并清空历史记录。

4.3 UI与代码优化

减少布局层级 ：使用ConstraintLayout减少嵌套，避免过度绘制（Overdraw），从而减少UI渲染时的内存和计算开销。
优化数据结构 ：使用SparseArray系列替代HashMap<Integer, Object>，因为前者比后者更省内存。
使用对象池：对于频繁创建和销毁的对象（如消息实体、短时使用的集合），可以考虑复用对象池技术。

4.4 生命周期感知的资源释放

实现ComponentCallbacks2接口，在onTrimMemory()回调中根据不同的内存级别释放缓存或不重要的资源。

java 复制代码

@Override
public void onTrimMemory(int level) {
    super.onTrimMemory(level);
    if (level >= TRIM_MEMORY_MODERATE) {
        imageCache.evictAll(); // 清除所有图片缓存
    } else if (level >= TRIM_MEMORY_BACKGROUND) {
        // 降低缓存中的图片质量或缩小部分缓存
    }
}

五、显存（GPU内存）的协同优化

对于图形密集型应用（如游戏、视频、AR），显存优化同样关键。

理解显存：显存用于存储纹理、顶点数据等GPU需要处理的资源。在统一内存架构（UMA）的设备上，显存和主存共享物理内存。
纹理压缩 ：使用硬件支持的压缩格式，如ETC2 或ASTC，可以大幅减少纹理在显存中的占用。
资源按需加载 ：对于大图，使用BitmapRegionDecoder只加载当前屏幕可见区域，避免一次性加载超大图片到显存。
动态降级：当系统内存不足时，动态降低纹理分辨率或切换为低精度渲染模式。

六、建立优化闭环：从治理到预防

内存优化不是一次性任务，而是一个持续的过程。

监控：利用Firebase Performance Monitoring或自建Metrics监控平台，收集线上应用的内存使用数据。
治理：当发现某个版本内存异常时，结合工具定位问题，并制定修复方案。
预防：将内存检测机制集成到CI/CD流水线中，确保新代码不会引入内存问题。同时，建立团队的内存安全编码规范。

总结

Android内存优化是一个系统工程，需要开发者对系统机制有深入理解，并善用各种诊断工具。优化的核心思路可以概括为：减少内存占用、及时释放无用资源、监控并预防内存问题。希望这份讲解能为你提供清晰的方向和实用的方法，助你打造出更加稳定流畅的应用。