Android内存优化--OOM

Android内存优化是性能优化很重要的一部分，而如何避免OOM又是内存优化的核心。       

Android内存管理机制

        Android系统的Dalvik虚拟机扮演了常规的内存垃圾自动回收的角色，Android系统没有为内存提供交换区，它使用paging与memory-mapping（mmapped）的机制来管理内存，简要概述一些Android系统中重要的内存管理基础概念。

共享内存

        Android系统通过下面几种方式来实现共享内存：

        （1）、Android应用的进程都是从一个叫做Zygote的进程fork出来的。Zygote进程在系统启动，并载入通用的framework的代码与资源之后开始启动。为了启动一个新的程序进程，系统会fork Zygote进程生产一个新的进程，然后在新的进程中加载并运行应用程序的代码。这就使得大多数的RAM pages被用来分配给framework的代码，同时促使RAM资源能够在应用的所有进程之间进行共享。

        （2）、大多数的static的数据被mmapped到一个进程中。这不仅仅让同样的数据能够在进程间进行共享，而且使得它能够在需要的时候被paged out。常见的static数据包括Dalvik Code、app resources、so文件等；

        （3）、大多数情况下，Android通过显式的分配共享内存区域（譬如ashmem或gralloc）来实现动态RAM区域能够在不同进程之间进行共享的机制。例如，Cursor Buffers在Content Provider与Clients之间共享内存。

分配与回收内存

        （1）、每个进程的Dalvik Heap都反应了使用内存的占用范围，Dalvik Heap Size，可以根据需要进行增长，但是系统有一个上限。

        （2）、HeapSize跟实际的物理内存大小是不对等的，PSS记录了应用程序自身占用以及和其他进程共享的内容。

        （3）、Android不会堆Heap空闲区域进行碎片整理。系统仅仅在新的内存分配之前判断Heap的尾端剩余空间是否足够，不够就会触发gc操作，从而腾出更多空闲的空间。在Android的高级系统版本里面针对Heap空间有一个Generational Heap Memory的模型，最近分配的对象会存放在Young Generation区域。当这个对象在该区域停留的时间达到一定程度，它会被移动到Old Generation，最后累积一定时间再移动到Permanent Generation区域。系统会根据内存中不同的内存数据类型分别执行不同的GC操作。例如，刚分配到Young Generation区域的对象通常更容易被销毁回收，同时在Young Generation区域的GC操作速度会比Old Generation区域的GC操作速度更快。

        每一个Generation的内存区域都有固定的大小。随着新的对象陆续被分配到此区域，当对象总的大小临近这一级别内存区域的阀值时，会触发GC操作，以便腾出空间来存放其他新的对象。

        通常情况下，GC发生的时候，所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系，Young Generation中的每次GC操作时间是最短的，Old Generation其次，Permanent Generation最长。执行时间的长短也和当前Generation中的对象数量有关，遍历树结构查找20000个对象比起遍历50个对象自然是要慢很多的。

        查看本机的Heap size：

ActivityManager manager = (Activity) getSystemService(Context.ACTIVITY_SERVICE); 
int heapsize = manager.getMemoryClass();

限制应用的内存

        （1）、为了整个系统内存控制需要，Android系统为每一个应用程序都设置一个硬性的Dalvik Heap Size最大限制阀值，Dalvik Heap size因不同设备的RAM不同而有所差异，应用占用内存接近这个阀值，再尝试分配内存就会引起OutOfMemoryError异常。

        （2）、ActivityManager.getMemoryClass()方法可以用来查询当前应用的Heap Size阀值，该方法返回一个整数，表明应用的Heap Size阀值是多少MB。

应用切换操作

        Android系统不会在用户切换应用的时候进行交换内存的操作，而是把不包含foreground组件的应用进程放到LRUCache中，比如用户启动一个应用，系统会为它创建一个进程，但是当用户离开这个应用，此进程不会被立即销毁而是会放到一个Cache中，当用户切换回来能够快速的恢复。

        如果你的应用中有一个被缓存的进程，这个进程会占用一定的内存空间，它会堆系统的整体性能有影响。因此，当系统开始进入Low Memory的状态时，它会由系统根据LRU的规则与应用的优先级，内存占用情况以及其他因素的影响综合评估之后决定是否被杀掉。

OOM（OutOfMemory）

查看内存使用情况

        （1）、使用命令查看：adb shell dumpsys meminfo -a ***（package name）

        （2）、AndroidStudio中Memory Monitor工具查看内存中Dalvik Heap的实时变化。

发生OOM的条件

        通过不同的内存分配方式（malloc/mmap/JNIEnv/etc）对不同的对象（Bitmap/etc）进行操作，会因为Android系统版本的差异而产生不同的行为，对Native Heap与Dalvik Heap以及OOM的判断条件都会有所影响。那么，到底如何判断会发生OOM呢？

        Android 4.x的系统废除了external的计数器，类似Bitmap的分配改到Dalvik的Java Heap中申请。只要allocated + 新分配的内存 >= getMemoryClass()的时候就会发生OOM。

如何避免OOM总结

        前面介绍了一些基础的内存管理机制以及OOM的基础知识，那么在实践操作当中，有哪些指导性的规则可以参考呢？归纳下来，可以从四个方面着手，首先是减小对象的内存占用，其次时内存对象的重复利用，然后时避免对象的内存泄露，最后是内存使用策略优化。

减小对象的内存占用

        避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。

使用更加轻量的数据结构

        例如，我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。下图演示了HashMap的简要工作原理，相比起Android专门为移动操作系统编写的ArrayMap容器，在大多数情况下，都显示效率低下，更占内存。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效，在于他们避免了对key与value的自动装箱，并且避免了装箱后的解箱。（关于更多ArrayMap/SparseArray的讨论，请参考《 Android性能优化典范（三）》的前三个段落。）

避免在Android里面使用Enum

        Android官方文档指出，枚举作为静态常量通常需要多于两倍的内存空间，在Android中我们应该避免使用枚举类。

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

        另外使用枚举相对于使用普通static常量效率更加低下，运行时还会产生额外的内存，因此，官方强烈建议不要在Android中使用枚举。

减小Bitmap对象的内存占用

        Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常有两个措施：

        （1）、imSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。

        （2）、decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。

使用更小的图片

        在涉及给到资源图片时，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片。尽量使用更小的图片不仅可以减少内存的使用，还能避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。

内存对象的重复利用

        大多数对象的复用，最终实施的方案都是利用对象池技术，一种是在编写代码时显式地在程序里创建对象池，然后处理好复用的实现逻辑；另一种就是利用系统框架既有的某些复用特性，减少对象的重复创建，从而降低内存的分配与回收。

        在Android上面最常用的一个缓存算法是LRU(Least Recently Use)。

复用系统自带的资源

        Android系统本身内置了很多的资源，比如字符串、颜色、图片、动画、样式以及简单布局等，这些资源都可以在应用程序中直接引用。这样做不仅能减少应用程序的自身负重，减小APK的大小，还可以在一定程度上减少内存的开销，复用性更好。但是也有必要留意Android系统的版本差异性，对那些不同系统版本上表现存在很大差异、不符合需求的情况，还是需要应用程序自身内置进去。

注意在ListView/GridView等出现大量重复子组件的试图里对ConvertView的复用

Bitmap对象的复用

        在ListView与GridView等显示大量图片的控件里，需要使用LRU的机制来缓存处理好的Bitmap。如下左图所示，

        利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率。使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小，如上右图所示。

        使用inBitmap需要注意的几个限制条件：

        （1）、在SDK 11 -> 18之间，重用的Bitmap大小必须是一致的。例如给inBitmap赋值的图片大小为100-100，那么新申请的Bitmap必须也为100-100才能够被重用。从SDK 19开始，新申请的Bitmap大小必须小于或者等于已经赋值过的Bitmap大小。

         （2）、新申请的Bitmap与旧的Bitmap必须有相同的解码格式。例如大家都是8888的，如果前面的Bitmap是8888，那么就不能支持4444与565格式的Bitmap了。我们可以创建一个包含多种典型可重用Bitmap的对象池，这样后续的Bitmap创建都能够找到合适的“模板”去进行重用，如下图所示。

避免在onDraw方法里执行对象的创建

        类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动。

StringBuilder

        在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”。

避免对象的内存泄露

        对象的内存泄露，会导致一些不再使用的对象无法及时释放，这样一方面占用了内存空间，容易导致后续分配内存的时候，空闲空间不足而出现OOM。显然，这还使得每级Generation的内存区域可用空间变小，GC就会更容易被触发，容易出现内存抖动，从而引起性能问题。

        最新的LeakCanary开源控件，可以很好的帮助我们发现内存泄露的情况，更多关于LeakCanary的介绍，请看https://github.com/square/leakcanary（ 中文使用说明：https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/）。另外也可以使用传统的MAT工具查找内存泄露。

注意Activity的泄露

        通常来说，Activity的泄露是内存泄露里面最严重的问题，它占用的内存多，影响面广，我们需要特别注意以下两种情况导致的Activity泄漏：

        （1）、内部类引用导致的Activity泄露

            最典型的场景是Handler导致的Activity泄露，如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄露。此时的引用关系链是Looper->MessageQueue->Message->Handler->Activity。

            为了解决这个问题，可以在UI退出之前，执行remove Handler消息队列中的消息与runnable对象。或者是使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的（被弱引用关联的对象只能生存到下一次垃圾回收之前，垃圾收集器工作之后，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。）。

        （2）、Activity Context被传递到其他实例中，这可能导致自身被引用而发生泄露。

        内部类引起的泄露不仅仅会发生在Activity上，其他任何内部类出现的地方，都需要特别留意！我们可以考虑尽量使用static类型的内部类，同时使用WeakReference的机制来避免因为互相引用而出现的泄露。

考虑使用Application Context而不是Activity Context

        对于大部分非必须使用Activity Context的情况（Dialog的Context就必须是Activity Context），我们都可以考虑使用Application Context而不是Activity的Context，这样可以避免不经意的Activity泄露。

注意临时Bitmap对象的及时回收

        虽然在大多数情况下，我们会对Bitmap增加缓存机制，但是在某些时候，部分Bitmap是需要及时回收的。例如临时创建的某个相对比较大的bitmap对象，在经过变换得到新的bitmap对象之后，应该尽快回收原始的bitmap，这样能够更快释放原始bitmap所占用的空间。

        需要特别留意的是Bitmap类里面提供的createBitmap()方法：

    /**
     * Returns an immutable bitmap from the specified subset of the source
     * bitmap. The new bitmap may be the same object as source, or a copy may
     * have been made. It is initialized with the same density as the original
     * bitmap.
     */
    public static Bitmap createBitmap(Bitmap source, int x, int y, int width, int height) {
        ......
    }

        这个函数返回的bitmap有可能和source bitmap是同一个，在回收的时候，需要特别检查source bitmap与return bitmap的引用是否相同，只有在不等的情况下，才能够执行source bitmap的recycle方法。

注意监听器的注销

        在Android程序里面存在很多需要register与unregister的监听器，我们需要确保在合适的时候及时unregister那些监听器。自己手动add的listener，需要记得及时remove这个listener。

注意缓存容器中的对象泄漏

        有时候，我们为了提高对象的复用性把某些对象放到缓存容器中，可是如果这些对象没有及时从容器中清除，也是有可能导致内存泄漏的。

注意WebView的泄漏

        Android中的WebView存在很大的兼容性问题，不仅仅是Android系统版本的不同对WebView产生很大的差异，另外不同的厂商出货的ROM里面WebView也存在着很大的差异。更严重的是标准的WebView存在内存泄露的问题。所以通常根治这个问题的办法是为WebView开启另外一个进程，通过AIDL与主进程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

注意Cursor对象是否及时关闭

        在程序中我们经常会进行查询数据库的操作，但时常会存在不小心使用Cursor之后没有及时关闭的情况。这些Cursor的泄露，反复多次出现的话会对内存管理产生很大的负面影响，我们需要谨记对Cursor对象的及时关闭。

内存使用策略优化

谨慎使用large heap

        正如前面提到的，Android设备根据硬件与软件的设置差异而存在不同大小的内存空间，他们为应用程序设置了不同大小的Heap限制阈值。你可以通过调用getMemoryClass()来获取应用的可用Heap大小。在一些特殊的情景下，你可以通过在manifest的application标签下添加largeHeap=true的属性来为应用声明一个更大的heap空间。然后，你可以通过getLargeMemoryClass()来获取到这个更大的heap size阈值。然而，声明得到更大Heap阈值的本意是为了一小部分会消耗大量RAM的应用(例如一个大图片的编辑应用)。不要轻易的因为你需要使用更多的内存而去请求一个大的Heap Size。只有当你清楚的知道哪里会使用大量的内存并且知道为什么这些内存必须被保留时才去使用large heap。因此请谨慎使用large heap属性。使用额外的内存空间会影响系统整体的用户体验，并且会使得每次gc的运行时间更长。在任务切换时，系统的性能会大打折扣。另外, large heap并不一定能够获取到更大的heap。在某些有严格限制的机器上，large heap的大小和通常的heap size是一样的。因此即使你申请了large heap，你还是应该通过执行getMemoryClass()来检查实际获取到的heap大小。

综合考虑设备内存阀值与其他因素设计合适的缓存大小

        例如，在设计ListView或者GridView的Bitmap LRU缓存的时候，需要考虑以下几点：

        应用程序剩下了多少可用的内存空间?

        有多少图片会被一次呈现到屏幕上？有多少图片需要事先缓存好以便快速滑动时能够立即显示到屏幕？

        设备的屏幕大小与密度是多少? 一个xhdpi的设备会比hdpi需要一个更大的Cache来hold住同样数量的图片。

        不同的页面针对Bitmap的设计的尺寸与配置是什么，大概会花费多少内存？

        页面图片被访问的频率？是否存在其中的一部分比其他的图片具有更高的访问频繁？如果是，也许你想要保存那些最常访问的到内存中，或者为不同组别的位图(按访问频率分组)设置多个LruCache容器。

onLowMemory()与onTrimMemory（）

        Android用户可以随意在不同的应用之间进行快速切换。为了让Background的应用能够迅速的切换到forground，每一个Background的应用都会占用一定的内存。Android系统会根据当前的系统的内存使用情况，决定回收部分Background的应用内存。如果Background的应用从暂停状态直接被恢复到forground，能够获得较快的恢复体验，如果background应用是从Kill的状态进行恢复，相比之下就显得稍微有点慢。

        onLowMemory()：Android系统提供了一些回调来通知当前应用的内存使用情况。当系统内存不足，所有后台程序（优先级为Background的进程，不是指后台运行的进程）都被kill掉的时候，forground应用会收到onLowMemory()的回调。在这种情况下，需要尽快释放当前应用的非必须的内存资源，从而确保系统能够继续稳定运行。

        onTrimMemory(int)：当系统内存达到某些条件的时候，所有正在运行的应用都会收到这个回调，同时在这个回调里面会传递以下的参数，代表不同的内存使用情况。收到onTrimMemory()回调的时候，需要根据传递的参数进行类型判断，合理的选择释放自身的一些内存占用，一方面可以提高系统的整体运行流畅度，另外也可以避免自己被系统判断为优先需要杀掉的应用。

        在内存紧张的时候，会回调OnLowMemory/OnTrimMemory，需要在回调方法中编写释放资源的代码。可以在资源紧张的时候，释放UI使用的资源：Bitmap、数组、控件资源。

        TRIM_MEMORY_UI_HIDDEN：你的应用程序的所有UI界面被隐藏了，即用户点击了Home键或者Back键退出应用，导致应用的UI界面完全不可见。这个时候应该释放一些不可见的时候非必须的资源。

        当程序正在前台运行的时候，可能会接收到从onTrimMemory()中返回的下面的值之一：

       TRIM_MEMORY_RUNNING_MODERATE：你的应用正在运行并且不会被列为可杀死的。但是设备此时正运行于低内存状态下，系统开始触发杀死LRU Cache中的Process的机制。

       TRIM_MEMORY_RUNNING_LOW：你的应用正在运行且没有被列为可杀死的。但是设备正运行于低内存的状态下，你应该释放不用的资源来提升系统性能。

       TRIM_MEMORY_RUNNING_CRITICAL：你的应用仍在运行，但是系统已经把LRU Cache中的大多数进程都已经杀死，因此你应该立即释放所有非必须的资源。如果系统不能回收到足够的RAM数量，系统将会清除所有的LRU缓存中的进程，并且开始杀死那些之前被认为不应该杀死的进程，例如那个包含了一个运行态Service的进程。

        当应用进程退到后台正在被Cached的时候，可能会接收到从onTrimMemory()中返回的下面值之一：

       TRIM_MEMORY_BACKGROUND：系统正运行于低内存状态并且你的进程正处于LRU缓存名单中最不容易杀掉的位置。尽管你的应用进程并不是处于被杀掉的高危险状态，系统可能已经开始杀掉LRU缓存中的其他进程了。你应该释放那些容易恢复的资源，以便于你的进程可以保留下来，这样当用户回退到你的应用的时候才能够迅速恢复。

        TRIM_MEMORY_MODERATE: 系统正运行于低内存状态并且你的进程已经接近LRU名单的中部位置。如果系统开始变得更加内存紧张，你的进程是有可能被杀死的。

        TRIM_MEMORY_COMPLETE: 系统正运行于低内存的状态并且你的进程正处于LRU名单中最容易被杀掉的位置。你应该释放任何不影响你的应用恢复状态的资源。

资源文件需要选择合适的文件夹进行存放

        我们知道hdpi/xhdpi/xxhdpi等等不同dpi的文件夹下的图片在不同的设备上会经过scale的处理。例如我们只在hdpi的目录下放置了一张100100的图片，那么根据换算关系，xxhdpi的手机去引用那张图片就会被拉伸到200200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到assets或者nodpi的目录下。

Try catch某些大内存分配的操作

        在某些情况下，我们需要事先评估那些可能发生OOM的代码，对于这些可能发生OOM的代码，加入catch机制，可以考虑在catch里面尝试一次降级的内存分配操作。例如decode bitmap的时候，catch到OOM，可以尝试把采样比例再增加一倍之后，再次尝试decode。

谨慎使用static对象

        因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏，在Android中应该谨慎使用static对象。

特别留意单例对象中不合理的持有

        虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。

珍惜Services资源

        如果你的应用需要在后台使用service，除非它被触发并执行一个任务，否则其他时候Service都应该是停止状态。另外需要注意当这个service完成任务之后因为停止service失败而引起的内存泄漏。当你启动一个Service，系统会倾向为了保留这个Service而一直保留Service所在的进程。这使得进程的运行代价很高，因为系统没有办法把Service所占用的RAM空间腾出来让给其他组件，另外Service还不能被Paged out。这减少了系统能够存放到LRU缓存当中的进程数量，它会影响应用之间的切换效率，甚至会导致系统内存使用不稳定，从而无法继续保持住所有目前正在运行的service。建议使用IntentService，它会在处理完交代给它的任务之后尽快结束自己。

优化布局层次，减少内存消耗

        越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的。

谨慎使用“抽象”编程

        很多时候，开发者会使用抽象类作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象类会导致一个显著的额外内存开销：他们需要同等量的代码用于可执行，那些代码会被mapping到内存中，因此如果你的抽象没有显著的提升效率，应该尽量避免他们。

谨慎使用多进程

        使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术。

        一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。

使用ProGuard来剔除不需要的代码

        ProGuard（http://blog.csdn.net/ljd2038/article/details/51308768）能够通过移除不需要的代码，重命名类，域与方法等等对代码进行压缩，优化与混淆。使用ProGuard可以使得你的代码更加紧凑，这样能够减少mapping代码所需要的内存空间。

总结

        设计风格很大程度上会影响到程序的内存与性能，相对来说，如果大量使用类似Material Design的风格，不仅安装包可以变小，还可以减少内存的占用，渲染性能与加载性能都会有一定的提升。

        内存优化并不就是说程序占用的内存越少就越好，如果因为想要保持更低的内存占用，而频繁触发执行gc操作，在某种程度上反而会导致应用性能整体有所下降，这里需要综合考虑做一定的权衡。

        Android的内存优化涉及的知识面还有很多：内存管理的细节，垃圾回收的工作原理，如何查找内存泄漏等等都可以展开讲很多。OOM是内存优化当中比较突出的一点，尽量减少OOM的概率对内存优化有着很大的意义。

参考：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0920/3478.html