Android内存优化

发表于 | 分类于 | 本文总阅读量 次

本章参考google官方文档，总结了android开发过程中内存优化的方法，同时，结合实际开发过程中遇到的OOM，总结了部分经验。不当之处，请随时提出。

Random-access memory (RAM) is a valuable resource in any software development environment,
but it’s even more valuable on a mobile operating system where physical memory is often constrained.
Although both the Android Runtime (ART) and Dalvik virtual machine perform routine garbage collection,
this does not mean you can ignore when and where your app allocates and releases memory

随机存取存储器（RAM）是任何软件开发环境中的宝贵资源，但在物理内存通常受限制的移动操作系统上更为有价值。
尽管Android Runtime（ART）和Dalvik虚拟机都执行常规垃圾收集，但这并不意味着您可以忽略应用程序分配和释放内存的时间和位置

查看内存使用情况

  • 1 使用android studio自带的 Memory Monitor查看
    该工具显示可用和分配的Java内存随时间的图，包括垃圾回收事件

  • 2 使用android studio自带的allocation Tracker tool

分配跟踪器记录应用程序的内存分配，并列出分析快照中的所有已分配对象。您可以使用此工具来跟踪分配太多对象的部分代码

优化内存的方案

1 使用onTrimMemory在应用UI隐藏时释放UI资源来释放内存

请注意：这个玩意不同于onStop，你的应用仅仅会在所有UI组件的被隐藏的时候接收到onTrimMemory()的回调并带有参数TRIM_MEMORY_UI_HIDDEN。这与onStop()的回调是不同的，onStop会在activity的实例隐藏时会执行，

例如当用户从你的app的某个activity跳转到另外一个activity时前面activity的onStop()会被执行。
因此你应该实现onStop回调，并且在此回调里面释放activity的资源，例如释放网络连接，注销监听广播接收者。除非接收到onTrimMemory(TRIM_MEMORY_UI_HIDDEN))的回调，否者你不应该释放你的UI资源。这确保了用户从其他activity切回来时，你的UI资源仍然可用，并且可以迅速恢复activity。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
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;
	    //你的app正在运行并且不会被列为可杀死的。但是设备此时正运行于低内存状态下，系统开始触发杀死LRU Cache中的Process的机制
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:	
		break;
	    //你的app正在运行且没有被列为可杀死的。但是设备正运行于更低内存的状态下，你应该释放不用的资源用来提升系统性能（但是这也会直接影响到你的app的性能）。
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
		break;
	    //你的app仍在运行，但是系统已经把LRU Cache中的大多数进程都已经杀死，因此你应该立即释放所有非必须的资源。如果系统不能回收到足够的RAM数量，
		//系统将会清除所有的LRU缓存中的进程，并且开始杀死那些之前被认为不应该杀死的进程，例如那个包含了一个运行态Service的进程。
            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;
	    //系统正运行于低内存状态并且你的进程正处于LRU缓存名单中最不容易杀掉的位置。尽管你的app进程并不 是处于被杀掉的高危险状态，
	    //系统可能已经开始杀掉LRU缓存中的其他进程了。你应该释放那些容易恢复的资源，以便于你的进程可以保留下来，这样当用户回退到你的app的时候才能够迅速恢复。
            case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
		break;
	    //系统正运行于低内存状态并且你的进程已经已经接近LRU名单的中部位置。如果系统开始变得更加内存紧张，你的进程是有可能被杀死的
            case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
		break;
	    //系统正运行与低内存的状态并且你的进程正处于LRU名单中最容易被杀掉的位置。你应该释放任何不影响你的app恢复状态的资源
            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;
        }
    }
}

这个回调支持API14以上，要兼容14以下可以使用 onLowMemory()

2 谨慎使用services,可以选择intentservice 代替service

它会在处理完交代给它的intent任务之后尽快结束自己

3 使用ArrayMap/SparseArray代替hashmap等传统数据结构

4 注意代码抽象，少用enum

抽象的代价是巨大的：一般来说，它们需要更多的代码需要执行，需要更多的时间和更多的RAM才能将该代码映射到内存中

For example, enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android

5 谨慎使用第三方库，移除内存使用大的库和资源文件

你的代码中的一些资源和库可以在不知道的情况下消除内存。
您的APK的总体尺寸（包括第三方库或嵌入式资源）可能会影响应用程序消耗多少内存。
您可以通过从代码中删除任何冗余的，不必要的或膨胀的组件，资源或库来提高应用程序的内存消耗

6 减小APk大小

您可以通过减少应用程序的总体大小来显着降低应用程序的内存使用量。
位图大小，资源，动画框架和第三方库都可以帮助您的APK的大小。
Android Studio和Android SDK提供多种工具来帮助您减少资源和外部依赖关系的大小
example Reduce APK Size

7 如果项目必须需要用到依赖注入框架，推荐使用Dragger2(官方推荐)

Dagger不使用反射来扫描您的应用程序的代码。 Dagger的静态编译时实现意味着它可以在Android应用程序中使用，而无需运行时费用或内存使用。

8 使用LeakCanary开源控件，可以很好的帮助我们发现内存泄露的情况

具体的使用请查看官方Github或者中文资料
当然还可以使用MAT

以上参考自android官方性能优化资料

总结

  • LeakCanary值得推荐，用于监听项目中的内存泄露。
    监听会发现除了官方SDK中的方法导致的内存泄露外，大部分都是静态变量的引用未及时销毁导致的。

  • 加载大图，及易产生OOM。
    因此在加载图片的时候，需要我们对图片进行压缩处理（图片的大小，质量压缩），选择合适尺寸的图片进行加载。同时，需要及时recycle临时图片。

  • 减少不必要的全局变量（官方文档给出了同样的建议），避免静态变量引用消耗更多的资源。

  • 减少枚举类型的使用。

  • 在使用SQLite时及时销毁cursor。

以上为项目中遇到的内存优化方案，其他方案若有遗漏会及时补充。

插一句：虽然现在手机内存慢慢在变大，必要的时候，我们可以使用空间换时间，但是在自己能力范围内，不断的优化内存使用，应该算是我们的职业道德吧👍。

虽然我现在是渣渣，但是五年后呢？嘻嘻