Android 性能优化 ---- 内存优化 中说到在内存使用过程中使用不当或者超过heap size limit的时候就会出现OOM，那一般OOM 是怎么产生的，会导致什么样的结果呢？

OOM全称为Out of memory，解释为内存溢出。

关于Native Heap，Dalvik Heap，Pss等内存管理机制比较复杂，这里不展开描述。简单的说，通过不同的内存分配方式（malloc/mmap/JNIEnv/etc）对不同的对象（bitmap，etc）进行操作会因为Android系统版本的差异而产生不同的行为，对Native Heap与Dalvik Heap以及OOM的判断条件都会有所影响。在2.x的系统上，我们常常可以看到Heap Size的total值明显超过了通过getMemoryClass()获取到的阈值而不会发生OOM的情况，那么针对2.x与4.x的Android系统，到底是如何判断会发生OOM呢？

前面介绍了OOM 的基础知识，那么在实践中有什么方法来减少OOM的出现呢？总结下来大概分下面几个方面：

1、使用更轻量级的数据结构

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

下图是HashMap 的工作原理：

下面是ArrayMap的delete 原理：

两者是有区别的，详细可以看下：Android性能优化典范 - 第3季

2、避免在Android 中使用enum

Android 官方的Training 中有这样一句话“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”

关于enum的效率，请看下面的讨论。假设我们有这样一份代码，编译之后的dex大小是2556 bytes，在此基础之上，添加一些如下代码，这些代码使用普通static常量相关作为判断值：

增加上面那段代码之后，编译成dex的大小是2680 bytes，相比起之前的2556 bytes只增加124 bytes。假如换做使用enum，情况如下：

使用enum之后的dex大小是4188 bytes，相比起2556增加了1632 bytes，增长量是使用static int的13倍。不仅仅如此，使用enum，运行时还会产生额外的内存占用，如下图所示：

Android官方强烈建议不要在Android程序里面使用到enum。

3、减小Bitmap对象的内存占用

Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用是很重要的，通常来说有下面2个措施：

4、使用更小的图片

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

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

1、复用系统自带的资源

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

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

3、Bitmap对象的复用

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

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

5、StringBuilder

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

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

最新的LeakCanary开源控件，可以很好的帮助我们发现内存泄露的情况，更多关于LeakCanary的介绍，请看这里https://github.com/square/leakcanary(中文使用说明http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/)。另外也可以使用传统的MAT工具查找内存泄露，请参考这里http://android-developers.blogspot.pt/2011/03/memory-analysis-for-android.html（便捷的中文资料http://androidperformance.com/2015/04/11/AndroidMemory-Usage-Of-MAT/）

1、注意Activity 的泄漏

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

最典型的场景是Handler导致的Activity泄漏，如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄漏。此时的引用关系链是Looper -> MessageQueue -> Message -> Handler -> Activity。为了解决这个问题，可以在UI退出之前，执行remove Handler消息队列中的消息与runnable对象。或者是使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。

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

2、考虑使用Application Context而不是Activity Contex

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

3、Bitmap 对象的及时回收

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

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

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

4、注意监听器的注销

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

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

有时候，我们为了提高对象的复用性把某些对象放到缓存容器中，可是如果这些对象没有及时从容器中清除，也是有可能导致内存泄漏的。例如，针对2.3的系统，如果把drawable添加到缓存容器，因为drawable与View的强应用，很容易导致activity发生泄漏。而从4.0开始，就不存在这个问题。解决这个问题，需要对2.3系统上的缓存drawable做特殊封装，处理引用解绑的问题，避免泄漏的情况。

6、注意WebView的泄漏

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

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

1、Try catch 某些大内存的操作

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

2、谨慎使用static 对象

static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。   不少程序员喜欢用static这个关键字修饰变量，因为他使得变量的生命周期大大延长啦，并且访问的时候，也极其的方便，用类名就能直接访问，各个资源间 传值也极其的方便，所以，它经常被我们使用。但如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。

以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放，并且，如果该activity里面再持有一些资源，那就糟糕了。

上面是直接的引用泄露，我们再看google文档中的一个例子：

sBackground, 是一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable与View连接之后，Drawable就将View 设置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：     Drawable->TextView->Context 所以，最终该Context也没有得到释放，也发生了内存泄露。 那我们如何的避免这种泄露的发生呢？

该部分的详细内容也可以参考Android文档中Article部分。

3、特别留意单例模式的不合理持有

4、珍惜service 资源

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

5、优化布局层次，减少内存消耗 越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的。 6、谨慎使用“抽象”编程 很多时候，开发者会使用抽象类作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的额外内存开销：他们需要同等量的代码用于可执行，那些代码会被mapping到内存中，因此如果你的抽象没有显著的提升效率，应该尽量避免他们。

参考：

https://blog.csdn.net/Easyhood/article/details/104618673