Android性能优化典范-管理应用内存

本文翻译自google官方开发文档管理应用内存

管理应用内存

随机存取存储器 (RAM) 在任何软件开发环境中都是一项宝贵资源，但在移动操作系统中，由于物理内存通常都有限，因此 RAM 就更宝贵了。虽然 Android 运行时 (ART) 和 Dalvik 虚拟机都执行例行的垃圾回收任务，但这并不意味着您可以忽略应用分配和释放内存的位置和时间。您仍然需要避免引入内存泄漏问题（通常因在静态成员变量中保留对象引用而引起），并在适当时间（如生命周期回调所定义）释放所有 Reference 对象。

本页面介绍了如何积极减少应用的内存使用量。如需了解 Android 操作系统如何管理内存，请参阅 Android 内存管理概览。

监控可用内存和内存使用量

您需要先找到应用中的内存使用问题，然后才能修复问题。Android Studio 中的内存性能剖析器可以通过以下方式帮助您查找和诊断内存问题：

1. 了解您的应用在一段时间内如何分配内存。内存分析器可以显示实时图表，说明应用的内存使用量、分配的 Java 对象数量以及垃圾回收事件发生的时间。
2. 发起垃圾回收事件，并在应用运行时拍摄 Java 堆的快照。
3. 记录应用的内存分配情况，然后检查所有分配的对象、查看每个分配的堆栈轨迹，并在 Android Studio 编辑器中跳转到相应代码。

释放内存以响应事件

如 Android 内存管理概览中所述，Android 可以通过多种方式从应用中回收内存，或在必要时完全终止应用，从而释放内存以执行关键任务。为了进一步帮助平衡系统内存并避免系统需要终止您的应用进程，您可以在

Activity

类中实现

ComponentCallbacks2

接口。借助所提供的

onTrimMemory()

回调方法，您的应用可以在处于前台或后台时监听与内存相关的事件，然后释放对象以响应指示系统需要回收内存的应用生命周期事件或系统事件。

例如，您可以实现

onTrimMemory()

回调以响应不同的与内存相关的事件，如下所示：

import android.content.ComponentCallbacks2;
// Other import statements ...

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code ...

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that was raised.
     */
    public void onTrimMemory(int level) {

        // Determine which lifecycle or system event was raised.
        switch (level) {

            case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN:

                /*
                   Release any UI objects that currently hold memory.

                   The user interface has moved to the background.
                */

                break;

            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL:

                /*
                   Release any memory that your app doesn't need to run.

                   The device is running low on memory while the app is running.
                   The event raised indicates the severity of the memory-related event.
                   If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
                   begin killing background processes.
                */

                break;

            case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
            case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
            case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:

                /*
                   Release as much memory as the process can.

                   The app is on the LRU list and the system is running low on memory.
                   The event raised indicates where the app sits within the LRU list.
                   If the event is TRIM_MEMORY_COMPLETE, the process will be one of
                   the first to be terminated.
                */

                break;

            default:
                /*
                  Release any non-critical data structures.

                  The app received an unrecognized memory level value
                  from the system. Treat this as a generic low-memory message.
                */
                break;
        }
    }
}
           

Android 4.0（API 级别 14）中添加了

onTrimMemory()

回调。对于早期版本，您可以使用

onLowMemory()

，此回调大致相当于

TRIM_MEMORY_COMPLETE

事件。

查看您应该使用多少内存

为了允许多个进程同时运行，Android 针对为每个应用分配的堆大小设置了硬性限制。设备的确切堆大小限制因设备总体可用的 RAM 多少而异。如果您的应用已达到堆容量上限并尝试分配更多内存，系统就会抛出

OutOfMemoryError

。

为了避免用尽内存，您可以查询系统以确定当前设备上可用的堆空间。您可以通过调用

getMemoryInfo()

向系统查询此数值。它将返回一个

ActivityManager.MemoryInfo

对象，其中会提供与设备当前的内存状态有关的信息，包括可用内存、总内存和内存阈值（如果达到此内存级别，系统就会开始终止进程）。

ActivityManager.MemoryInfo

对象还会提供一个简单的布尔值

lowMemory

，您可以根据此值确定设备是否内存不足。

以下代码段示例演示了如何在应用中使用

getMemoryInfo()

方法。

public void doSomethingMemoryIntensive() {

        // Before doing something that requires a lot of memory,
        // check to see whether the device is in a low memory state.
        ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

        if (!memoryInfo.lowMemory) {
            // Do memory intensive work ...
        }
    }

    // Get a MemoryInfo object for the device's current memory status.
    private ActivityManager.MemoryInfo getAvailableMemory() {
        ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
        ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
        activityManager.getMemoryInfo(memoryInfo);
        return memoryInfo;
    }
    
           

使用内存效率更高的代码结构

某些 Android 功能、Java 类和代码结构所使用的内存往往多于其他功能、类和结构。您可以在代码中选择效率更高的替代方案，以尽可能降低应用的内存使用量。

谨慎使用服务

在不需要某项服务时让其保持运行状态，是 Android 应用可能犯下的最严重的内存管理错误之一。如果您的应用需要某项服务在后台执行工作，请不要让其保持运行状态，除非其需要运行作业。请注意在服务完成任务后使其停止运行。否则，您可能会在无意中导致内存泄漏。

在您启动某项服务后，系统更倾向于让此服务的进程始终保持运行状态。这种行为会导致服务进程代价十分高昂，因为一旦服务使用了某部分 RAM，那么这部分 RAM 就不再可供其他进程使用。这会减少系统可以在 LRU 缓存中保留的缓存进程数量，从而降低应用切换效率。当内存紧张，并且系统无法维护足够的进程以托管当前运行的所有服务时，这甚至可能导致系统出现抖动。

您通常应该避免使用持久性服务，因为它们会对可用内存提出持续性的要求。我们建议您采用

JobSchedulerJobScheduler

等替代实现方式。要详细了解如何使用

JobScheduler

调度后台进程，请参阅后台优化。

如果您必须使用某项服务，则限制此服务的生命周期的最佳方式是使用

IntentService

，它会在处理完启动它的

intent

后立即自行结束。有关详情，请参阅在后台服务中运行。

使用经过优化的数据容器

编程语言所提供的部分类并未针对移动设备做出优化。例如，常规

HashMap

实现的内存效率可能十分低下，因为每个映射都需要分别对应一个单独的条目对象。

Android 框架包含几个经过优化的数据容器，包括

SparseArray

、

SparseBooleanArray

和

LongSparseArray

。 例如，

SparseArray

类的效率更高，因为它们可以避免系统需要对键（有时还对值）进行自动装箱（这会为每个条目分别再创建 1-2 个对象）。

如果需要，您可以随时切换到原始数组以获得非常精简的数据结构。

谨慎对待代码抽象

开发者往往会将抽象简单地当做一种良好的编程做法，因为抽象可以提高代码灵活性和维护性。不过，抽象的代价很高：通常它们需要更多的代码才能执行，需要更多的时间和更多的 RAM 才能将代码映射到内存中。因此，如果抽象没有带来显著的好处，您就应该避免使用抽象。

针对序列化数据使用精简版 Protobuf

协议缓冲区是 Google 设计的一种无关乎语言和平台，并且可扩展的机制，用于对结构化数据进行序列化。该机制与 XML 类似，但更小、更快也更简单。如果您决定针对数据使用

Protobuf

，则应始终在客户端代码中使用精简版

Protobuf

。常规

Protobuf

会生成极其冗长的代码，这会导致应用出现多种问题，例如 RAM 使用量增多、APK 大小显著增加以及执行速度变慢。

有关详情，请参阅 Protobuf 自述文件中的“精简版”部分。

避免内存抖动

如前所述，垃圾回收事件通常不会影响应用的性能。不过，如果在短时间内发生许多垃圾回收事件，就可能会快速耗尽帧时间。系统花在垃圾回收上的时间越多，能够花在呈现或流式传输音频等其他任务上的时间就越少。

通常，“内存抖动”可能会导致出现大量的垃圾回收事件。实际上，内存抖动可以说明在给定时间内出现的已分配临时对象的数量。

例如，您可以在 for 循环中分配多个临时对象。或者，您也可以在视图的

onDraw()

函数中创建新的

Paint

或

Bitmap

对象。在这两种情况下，应用都会快速创建大量对象。这些操作可以快速消耗新生代 (

young generation

) 区域中的所有可用内存，从而迫使垃圾回收事件发生。

当然，您必须先在代码中找到内存抖动较高的位置，然后才能进行修复。为此，您应该使用 Android Studio 中的内存分析器。

确定代码中的问题区域后，请尝试减少对性能至关重要的区域中的分配数量。您可以考虑将某些代码逻辑从内部循环中移出，或将其移到基于 Factory 的分配结构中。

移除会占用大量内存的资源和库

代码中的某些资源和库可能会在您不知情的情况下吞噬内存。APK 的总体大小（包括第三方库或嵌入式资源）可能会影响应用的内存消耗量。您可以通过从代码中移除任何冗余、不必要或臃肿的组件、资源或库，降低应用的内存消耗量。

缩减总体 APK 大小

您可以通过缩减应用的总体大小来显著降低应用的内存使用量。位图大小、资源、动画帧数和第三方库都会影响 APK 的大小。Android Studio 和 Android SDK 提供了可帮助您缩减资源和外部依赖项大小的多种工具。这些工具支持现代代码收缩方法，例如 R8 编译。（Android Studio 3.3 及更低版本使用 ProGuard，而不是 R8 编译。）

要详细了解如何缩减 APK 的总体大小，请参阅有关如何缩减应用大小的指南。

使用 Dagger 2 实现依赖注入

依赖注入框架可以简化您编写的代码，并提供一个可供您进行测试及其他配置更改的自适应环境。

如果您打算在应用中使用依赖注入框架，请考虑使用

Dagger 2

。Dagger 不使用反射来扫描您应用的代码。

Dagger

的静态编译时实现意味着它可以在 Android 应用中使用，而不会带来不必要的运行时代价或内存消耗量。

其他使用反射的依赖注入框架倾向于通过扫描代码中的注释来初始化进程。此过程可能需要更多的 CPU 周期和 RAM，并可能在应用启动时导致出现明显的延迟。

谨慎使用外部库

外部库代码通常不是针对移动环境编写的，在移动客户端上运行时可能效率低下。如果您决定使用外部库，则可能需要针对移动设备优化该库。在决定是否使用该库之前，请提前规划，并在代码大小和 RAM 消耗量方面对库进行分析。

即使是一些针对移动设备进行了优化的库，也可能因实现方式不同而导致问题。例如，一个库可能使用的是精简版 Protobuf，而另一个库使用的是 Micro Protobuf，导致您的应用出现两种不同的 Protobuf 实现。日志记录、分析、图像加载框架和缓存以及许多您意料之外的其他功能的不同实现都可能导致这种情况。

虽然 ProGuard 可以使用适当的标记移除 API 和资源，但无法移除库的大型内部依赖项。您所需要的这些库中的功能可能需要较低级别的依赖项。如果存在以下情况，这就特别容易导致出现问题：您使用某个库中的 Activity 子类（往往会有大量的依赖项）、库使用反射（这很常见，意味着您需要花费大量的时间手动调整 ProGuard 以使其运行）等。

此外，请避免仅针对数十个功能中的一两个功能使用共享库。您一定不希望产生大量您甚至根本用不到的代码和开销。在考虑是否使用某个库时，请查找与您的需求十分契合的实现。否则，您可以决定自己去创建实现。