• 挂得少

  “挂”指的是 Crash，假如一个满分的应用是 100 分，那么一个会 Crash 的应用在用户心里会扣掉 90 分。

  就像是我们在一家店吃到了一盘很难吃的小龙虾，哪怕别人说这家店再好吃，我们以后都不想吃这家店了。

  导致 Android 应用 Crash 的原因有很多种，而做内存优化就能让我们的应用避免由内存问题引起的 Crash。

  内存问题导致 Crash 的具体表现就是内存溢出异常 OOM，引起 OOM 的原因有多种，在后面我会对它们做一个更详细的介绍。

• 活得好

  活得好指的是使用流畅，Android 中造成界面卡顿的原因有很多种，其中一种就是由内存问题引起的。

  内存问题之所以会影响到界面流畅度，是因为垃圾回收（GC，Garbage Collection），在 GC 时，所有线程都要停止，包括主线程，当 GC 和绘制界面的操作同时触发时，绘制的执行就会被搁置，导致掉帧，也就是界面卡顿。

  关于 GC 的更多介绍，可以看我的上一篇文章。

• 活得久

  活得久指的是我们的应用在后台运行时不会被干掉。

  Android 会按照特定的机制清理进程，清理进程时优先会考虑清理后台进程。

  清理进程的机制就是低杀，关于低杀在后面会有更详细的介绍。

  假如现在有个用户小张想在我们的电商应用买一个商品，千辛万苦挑到了一个自己喜欢的商品后，当他准备购买时，小张的老婆叫他去给孩子换尿布，等小张再打开应用时，发现商品页已经被关闭了，也就是应用被干掉了，这时小张又想起了孩子的奶粉钱，可能就放弃这次购买了。

  用户在移动设备上使用应用的过程中被打断是很常见的，如果我们的应用不能活到用户回来的时候，要用户再次进行操作的体验就会很差。

要了解 Android 应用的内存管理机制，就要了解承载着 Android 应用的虚拟机 Dalvik，虽然 Android 现在是使用的 ART 来承载应用的执行，但是 ART 也是基于 Dalvik 优化而来的。

Dalvik 是 Dalvik Virtual Machine（Dalvik 虚拟机）的简称，是 Android 平台的核心组成部分之一，Dalvik 与 JVM 的区别有如下几个。

2.1 Dalvik 与 JVM 的区别

• 架构

  JVM 是基于栈的，也就是需要在栈中读取数据，所需的指令会更多，这样会导致速度慢，不适合性能优先的移动设备。

  Dalvik 是基于寄存器的，指令更紧凑和简洁。

  由于显式指定了操作数，所以基于寄存器的指令会比基于栈的指令要大，但是由于指令数的减少，总的代码数不会增加多少。

• 执行代码不同

  在 Java SE 程序中，Java 类会被编译成一个或多个 .class 文件，然后打包成 jar 文件，JVM 会通过对应的 .class 文件和 jar 文件获取对应的字节码。

  而 Dalvik 会用 dx 工具将所有的 .class 文件转换为一个 .dex 文件，然后会从该 .dex 文件读取指令和数据。

4.2.2 可见进程

可见进程（Visible Process）不含有任何前台组件，但用户还能再屏幕上看见它，当满足一下任一条件时，进程被认定是可见进程。

• Activity

  进程持有一个 Activity，这个 Activity 处于 pause 状态，比如前台 Activity 打开了一个对话框，这样后面的 Activity 就处于 pause 状态

• Service

  进程持有一个 Service 这个 Service 和一个可见的 Activity 绑定。

可见进程是非常重要的进程，除非前台进程已经把系统的可用内存耗光，否则系统不会终止可见进程。

4.2.3 服务进程

服务进程（Service Process）可能在播放音乐或在后台下载文件，除非系统内存不足，否则系统会尽量维持服务进程的运行。

当一个进程满足下面一个条件时，系统会认定它为服务进程。

• Service

  如果一个进程中运行着一个 Service，并且这个 service 是通过 startService 开启的，那这个进程就是一个服务进程。

4.2.4 后台进程

系统会把后台进程（Background Process）保存在一个 LruCache 列表中，因为终止后台进程对用户体验影响不大，所以系统会酌情清理部分后台进程。

你可以在 Activity 的 onSaveInstanceState() 方法中保存一些数据，以免在应用在后台被系统清理掉后，用户已输入的信息被清空，导致要重新输入。

当一个进程满足下面条件时，系统会认定它为后台进程。

• Activity

  当进程持有一个用户不可见的 Activity（Activity 的 onStop() 方法被调用），但是 onDestroy 方法没有被调用，这个进程就会被系统认定为后台进程。

4.2.5 空进程

当一个进程不包含任何活跃的应用组件，则被系统认定为是空进程。

系统保留空进程的目的是为了加快下次启动进程的速度。

5. 图片对内存有什么影响？

大部分 App 都免不了使用大量的图片，比如电商应用和外卖应用等。

图片在 Android 中对应的是 Bitmap 和 Drawable 类，我们从网络上加载下来的图片最终会转化为 Bitmap。

图片会消耗大量内存，如果使用图片不当，很容易就会造成 OOM。

下面我们来看下 Bitmap 与内存有关的一些内容。

5.1 获取 Bitmap 占用的内存大小

• Bitmap.getByteCount()

  Bitmap 提供了一个 getByteCount() 方法获取图片占用的内存大小，但是这个方法只能在程序运行时动态计算。

• 图片内存公式

  图片占用内存公式：宽 * 高 * 一个像素占用的内存。

  假如我们现在有一张 2048 * 2048 的图片，并且编码格式为 ARGB_8888，那么这个图片的大小为 2048 * 2048 * 4 = 16, 777, 216 个字节，也就是 16M。

  如果厂商给虚拟机设置的堆大小是 256M，那么像这样的图片，应用最极限的情况只能使用 16 张。

  我们的应用在运行时，不仅仅是我们自己写的代码需要消耗内存，还有库中创建的对象同样需要占用堆内存，也就是别说 16 张，多来几张应用就挂了。

5.2 Bitmap 像素大小

一张图片中每一个像素的大小取决于它的解码选项，而 Android 中能够选择的 Bitmap 解码选项有四种。

下面四种解码选项中的的 ARGB 分别代表透明度和三原色 Alpha、Red、Green、Blue。

• ARGB_8888

  ARGB 四个通道的值都是 8 位，加起来 32 位，也就是每个像素占 4 个字节

• ARGB_4444

  ARGB 四个通道的值都是 4 位，加起来 16 位，也就是每个像素占 2 个字节

• RGB_565

  RGB 三个通道分别是 5 位、6 位、5 位，加起来 16 位，也就是每个像素占 2 个字节

• ALPHA_8

  只有 A 通道，占 8 位，也就是每个像素占 1 个字节

5.3 Glide

如果服务器返回给我们的图片是 200 * 200，但是我们的 ImageView 大小是 100 * 100，如果直接把图片加载到 ImageView 中，那就是一种内存浪费。

但是使用的 Glide 的话，那这个问题就不用担心了，因为 Glide 会根据 ImageView 的大小把图片大小调整成 ImageView 的大小加载图片，并且 Glide 有三级缓存，在内存缓存中，Glide 会根据屏幕大小选择合适的大小作为图片内存缓存区的大小。

6. 什么是内存泄漏？

6.1 内存泄漏简介

内存泄漏指的是，当一块内存没有被使用，但无法被 GC 时的情况。

堆中一块泄漏的内存就像是地上一块扫不掉的口香糖，都很让人讨厌。

一个典型的例子就是匿名内部类持有外部类的引用，外部类应该被销毁时，GC 却无法回收它，比如在 Activity 中创建 Handler 就有可能出现这种情况。

内存泄漏的表现就是可用内存逐渐减少，比如下图中是一种比较严重的内存泄漏现象，无法被回收的内存逐渐累积，直到无更多可用内存可申请时，就会导致 OOM。

6.2.2 静态变量

1. 原因

   静态变量导致内存泄漏的原因是因为长生命周期对象持有了短生命周期对象的引用，导致短生命周期对象无法被释放。

   比如一个单例持有了 Activity 的引用，而 Activity 的生命周期可能很短，用户一打开就关闭了，但是单例的生命周期往往是与应用的生命周期相同的。

2. 解决

   如果单例需要 Context， 可以考虑使用 ApplicationContext，这样单例持有的 Context 引用就是与应用的生命周期相同的了。

6.2.3 资源未释放

• 忘了注销 BroadcastReceiver；
• 打开了数据库游标（Cursor）忘了关闭；
• 打开流忘了关闭；
• 创建了 Bitmap 但是调用 recycle 方法回收 Bitmap 使用的内存；
• 使用 RxJava 忘了在 Activity 退出时取消任务；
• 使用协程忘了在 Activity 退出时取消任务。
• ...

6.2.4 Webview

• 原因

  不同的 Android 版本的 Webview 会有差异，加上不同厂商定制 ROM 的 Webview 的差异，导致 Webview 存在很大的兼容问题。

  一般情况下，在应用中只要使用一次 Webview，它占用的内存就不会被释放。

• 解决

详见博文《webview内存泄漏终极解决方案》

7. 什么是内存抖动？

7.1 内存抖动简介

当我们在短时间内频繁创建大量临时对象时，就会引起内存抖动，比如在一个 for 循环中创建临时对象实例。

下面这张图就是内存抖动时的一个内存图表现，它的形状是锯齿形的，而中间的垃圾桶代表着一次 GC。

这个是 Memory Profiler 提供的内存实时图，后面会对 Memory Profiler 进行一个更详细的介绍。

8.1.2 Profiler 高级选项

开了高级选项后，我们在 Memory Profiler 中就能看到用一个白色垃圾桶表示的 GC 动作。

打开 Profiler 的方式：Run > Edit Configucation > Profiling > Enable advanced profiling

 

8.2 Memory Profiler 简介

Memory Profiler 是 Profiler 的其中一个功能，点击 Profiler 中蓝色的 Memory 面板，我们就进入了 Memory Profiler 界面。

 

8.3 堆转储

在堆转储（Dump Java Heap）面板中有 Instance View（实例视图）面板，Instance View 面板的下方有 References 和 Bitmap Preview 两个面板，通过 Bitmap Preview，我们能查看该 Bitmap 对应的图片是哪一张，通过这种方式，很容易就能找到图片导致的内存问题。

要注意的是，Bitmap Preview 功能只有在 7.1 及以下版本的设备中才能使用。

 

8.4 查看内存分配详情

在 7.1 及以下版本的设备中，可以通过 Record 按钮记录一段时间内的内存分配情况。

而在 8.0 及以上版本的设别中，可以通过拖动时间线来查看一段时间内的内存分配情况。

点击 Record 按钮后，Profiler 会为我们记录一段时间内的内存分配情况。在内存分配面板中，我们可以查看对象的分配的位置，比如下面的 Bitmap 就是在 onCreate 方法的 22 行创建的。

dependencies {
  // 使用 debugImplementation 是因为 LeakCanary 一般不用于发布版本
  debugImplementation ‘com.squareup.leakcanary:leakcanary-android:2.0-alpha-3‘
}

// 1. 在 Application 中定义一个 RefWatcher 的静态变量
companion object {
    val refWatcher = LeakSentry.refWatcher
}

// 2. 使用 RefWatcher 监控该对象
MyApplication.refWatcher.watch(object);

 ③ 配置监控选项

private fun initLeakCanary() {
    LeakSentry.config = LeakSentry.config.copy(watchActivities = false)
}

9.3.2 非 AndroidX 项目

 ① 添加依赖

dependencies {
  debugImplementation ‘com.squareup.leakcanary:leakcanary-android:1.6.3‘
  releaseImplementation ‘com.squareup.leakcanary:leakcanary-android-no-op:1.6.3‘
  // 只有在你使用了 support library fragments 的时候才需要下面这一项
  debugImplementation ‘com.squareup.leakcanary:leakcanary-support-fragment:1.6.3‘
}

 ② 初始化 LeakCanary

public class MyApplication extends Application {
  @Override public void onCreate() {
    super.onCreate();
    // 不需要在 LeakCanary 用来做堆分析的进程中初始化 LeakCanary
    if (!LeakCanary.isInAnalyzerProcess(this)) {
      LeakCanary.install(this);
      return;
    }
  }
}

  ③ 监控特定对象

// 1. 在 Application 中定义一个获取 RefWatcher 的静态方法
public static RefWatcher getRefWatcher() {
    return LeakCanary.installedRefWatcher();
}

// 2. 使用 RefWatcher 监控该对象
MyApplication.getRefWatcher().watch(object);

 ④ 配置监控选项

public class MyApplication extends Application {
    private void installLeakCanary() {
        RefWatcher refWatcher = LeakCanary.refWatcher(this)
          .watchActivities(false)
          .buildAndInstall();
    }
}

当安装完成，并且重新安装了应用后，我们可以在桌面看到 LeakCanary 用于分析内存泄漏的应用。

9.4 使用 LeakCanary 分析内存泄漏

 下面是一个静态变量持有 Activity 导致 Activity 无法被释放的一个例子。

public class MemoryLeakActivity extends AppCompatActivity {
   
    public static List<Activity> activities = new ArrayList<>();
   
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        activities.add(this);
    }
}

 我们可以在 Logcat 中看到泄漏实例的引用链。

点击这一项泄漏信息，我们可以看到一个泄漏信息概览页。

我们点击第一项 MemoryActivity Leaked，可以看到泄漏引用链的详情。

通过上面这些步骤，很简单地就能找到 LeakCanary 为我们分析的导致内存泄漏的地方。

10. 怎么获取和监听系统内存状态？

 1    import android.content.ComponentCallbacks2
 2    
 3    class MainActivity : AppCompatActivity(), ComponentCallbacks2 {
 4    
 5        /**
 6         * 当应用处于后台或系统资源紧张时，我们可以在这里方法中释放资源，
 7         * 避免被系统将我们的应用进行回收
 8         * @param level 内存相关事件
 9         */
10        override fun onTrimMemory(level: Int) {
11    
12            // 根据不同的应用生命周期和系统事件进行不同的操作
13            when (level) {
14    
15                // 应用界面处于后台
16                ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN -> {
17                    // 可以在这里释放 UI 对象
18                }
19    
20                // 应用正常运行中，不会被杀掉，但是系统内存已经有点低了
21                ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE,
22              
23                // 应用正常运行中，不会被杀掉，但是系统内存已经非常低了，
24                // 这时候应该释放一些不必要的资源以提升系统性能
25                ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW,
26              
27                // 应用正常运行，但是系统内存非常紧张，
28                // 系统已经开始根据 LRU 缓存杀掉了大部分缓存的进程
29                // 这时候我们要释放所有不必要的资源，不然系统可能会继续杀掉所有缓存中的进程
30                ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL -> {
31                    // 释放资源
32                }
33    
34                // 系统内存很低，系统准备开始根据 LRU 缓存清理进程，
35                // 这时我们的程序在 LRU 缓存列表的最近位置，不太可能被清理掉，
36                // 但是也要去释放一些比较容易恢复的资源，让系统内存变得充足
37                ComponentCallbacks2.TRIM_MEMORY_BACKGROUND,
38              
39                // 系统内存很低，并且我们的应用处于 LRU 列表的中间位置，
40                // 这时候如果还不释放一些不必要资源，那么我们的应用可能会被系统干掉
41                ComponentCallbacks2.TRIM_MEMORY_MODERATE,
42              
43                // 系统内存非常低，并且我们的应用处于 LRU 列表的最边缘位置，
44                // 系统会有限考虑干掉我们的应用，如果想活下来，就要把所有能释放的资源都释放了
45                ComponentCallbacks2.TRIM_MEMORY_COMPLETE -> {
46                    /*
47                     * 把所有能释放的资源都释放了
48                    */
49                }
50    
51                // 应用从系统接收到一个无法识别的内存等级值，
52                // 跟一般的低内存消息提醒一样对待这个事件
53                
54                else -> {
55                    // 释放所有不重要的数据结构。
56                }
57            }
58        }
59    }

10.2 ActivityManager.getMemoryInfo()

 1    fun doSomethingMemoryIntensive() {
 2        // 在做一些需要很多内存的任务前，
 3        // 检查设备是否处于低内存状态、
 4        if (!getAvailableMemory().lowMemory) {
 5            // 做需要很多内存的任务
 6        }
 7    }
 8    
 9    // 获取 MemoryInfo 对象
10    private fun getAvailableMemory(): ActivityManager.MemoryInfo {
11        val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
12        return ActivityManager.MemoryInfo().also { memoryInfo ->
13            activityManager.getMemoryInfo(memoryInfo)
14        }
15    }

作者：灯不利多
链接：https://juejin.im/post/5d3ada056fb9a07eb94fd1bc
来源：掘金