Android性能优化-内存篇(其实内存优化也就这回事)

一.引言

今天来聊一聊Android中内存优化的一些手段。
首先问问自己为什么要内存优化呢?
（1）：App消耗内存过大，导致手机内存低于内存警戒线的时候，Low Memory Killer机制就会触发，App占用内存越多，被处理掉的机会就越大。
（2）：受虚拟机堆内存限制，出现OOM,内存溢出，程序出现crash。
（3）：频繁的GC会导致内存抖动，并发GC伴随着stop-the-world。GC for Allow 当内存不足以分配给新的对象时触发，它的stop-the-world的时间会很长，导致卡顿。

掌握内存优化的一些手段是很有必要的，让我们可以在编码时就能做到一些内存上的优化，而不是等到程序开发完成了或者后期程序规模越来越大了才去发现内存问题，那时候恐怕就为时已晚了。

二.编码时就能做到的内存优化

下面就来说说我们能够在编码时就能做到的内存优化：
（1）：尽量不要在调用频繁的生命周期或者方法中去创建对象。
例如View的onDraw方法。

当我们在自定义View，在onDraw方法里创建了一个对象时，发现系统会给我们提示，让我们不要在onDraw（）方法里面去创建对象，因为onDraw方法会频繁的被调用，为了避免频繁的GC，所以我们应该尽量避免在调用频繁的方法中去创建对象。

（2）：使用合适的数据结构（ 例如使用ArrayMap和SparseArray替代HaspMap）
ArrayMap和SparseArray都是基于二分法的原理，查询效率比起HashMap要略低，但是使用的内存比HashMap要更少。

HashMap：默认容量16，每次都是扩容都是原来数组大小的两倍。
下图为HashMap的扩容代码，左移以为其实就是乘以2，只是由于位运算的效率比较高，系统采用的是位运算的方式。

ArrayMap ：默认初始化两个空数组，扩容为已存储个数的两倍的1.5倍。BASE_SIZE == 8。

SparseArray:默认容量为10，扩容为已存储个数的1.5倍。int值作为key时不会拆装箱。

public SparseArray() {
      this(10);
    }

public static int growSize(int currentSize) {
      return currentSize <= 4 ? 8 : currentSize * 2;
 }

下面展示三张图片：



以上三张图是我做的一个小实验，我创建了十万个对象分别使用HashMap，ArrayMap，SparseArray去存储，key值位int，等到内存稳定时，我们去观察App占用内存的大小。第一张图：使用HashMap占用的内存最大，第二张图ArrayMap占用的内存第二，第三张图SparseArray占用的内存最少。HashMap与ArrayMap的key只能为Object，所以在存储key值为int型的对象时，会我们去做一次装箱的操作，把int转为Integer对象，对象占用的内存肯定是比我们int型的值占用的内存更大。这也就能解释，当key值为int时，SparseArray为什么能比ArrayMap占用更少的内存了。

（3）：使用集合时可以使用带参数的构造方法可以减少数组扩容的次数
List，Map，StringBuilder等等内部通过数组实现类。

//最好为2的整数次幂
Map map = new HashMap(32);
List list = new ArrayList(100);
StringBuilder sb = new StringBuilder(100);

我们都知道在Java中，数组是不可变的，所以一些类底部的实现机制如果是通过数组来实现的话，它还是可变的，那么必定便随着数组扩容的操作。
什么时是数组扩容呢？
简单的说就是如果一个数组的容量不够了，就去创建一个更大的数组，然后把原来数组中存储的值，一个个移到新创建的更大的数组中去。
如果扩容次数多了，GC的次数也会频繁的增多。
如果我们预先能够知道需要，存储多少个元素，或者大概多少个元素，我们可以使用带参数的构造方法来创建出这个大小的数组，来减少数组扩容的次数。

（4）：for循环中不要使用“+”号拼接字符串
“+”底层还是通过StringBuilder实现的，每一次for循环都会创建一个StringBuilder对象。

当我们使用for循环外部创建StringBuilder，内部使用它拼接字符串，内存图形很平稳。

for循环内部使用+号拼接字符串，图形抖动（内存抖动），一直在GC。

（5）：尽可能少的使用枚举
使用 ENUM 将会增大 DEX 大小，并会增大运行时的内存分配大小。为了弥补 Android 平台不建议使用枚举的缺陷，官方推出了两个注解，IntDef和StringDef，用来提供编译期的类型检查。

枚举本质上是通过普通的类来实现的，只是编译器为我们进行了处理。每个枚举类型都继承自java.lang.Enum，并自动添加了values和valueOf方法。而每个枚举常量是一个静态常量字段，使用内部类实现，该内部类继承了枚举类。所有枚举常量都通过静态代码块来进行初始化，即在类加载期间就初始化。

（6）：ListView复用，对象复用
这个就不多少了，我相信每个Android开发者都知道。

（7）：减少布局的层级
减少View的个数，减少测量的时间（View显示在前台，经过三个阶段测量，布局和绘制）。能够减轻内存，CPU的负担。

（8）：序列化可以使用Protobuf
Protobuf是谷歌推出的一款平台无关，语言无关，可扩展的序列化和反序列化技术。有兴趣的朋友可以自行了解一个，这里就不多说了。

（9）：数据库减少使用AUTOINCREMENT关键字
AUTOINCREMENT关键字的作用保证主键是严格单调递增的。

  public static final String CREATE_BOOK = "create table book ("

+ "id integer primary key autoincrement, "//大多数情况下可以去掉

+ "author text, "

+ "price real, "

+ "pages integer, "

+ "name text)";


db.execSQL(CREATE_BOOK);

如果指定使用AUTOINCREMENT来创建表，会创建sqlite_sequence的内部表来记录该表使用的最大行号，UPDATE，INSERT和DELETE语句可能会修改sqlite_sequence的内容。会带来额外的开销。
SQLite官网：AUTOINCREMENT关键词会增加CPU，内存，磁盘空间和磁盘I/O
的负担，所以尽量不要使用，除非必需。通常情况下非必需。

（10）：Bitmap优化
讲到内存优化必不可少的都要提及BitMap优化。因为Bitmap真的是内存占用的大头。

我们的Bitmap占用多大内存呢？下面介绍两个系统提供的api：

bitmap.getAllocationByteCount();
bitmap.getByteCount();

一般情况下两者是相等的；
如果通过复用Bitmap来解码图片，被复用的Bitmap的内存比待分配内存的Bitmap大,那么getByteCount()表示新解码图片占用内存的大小（并非实际内存大小,实际大小是复用的那个Bitmap的大小），getAllocationByteCount()表示被复用Bitmap真实占用的内存大小。

下面我们在说说BitMap的内存分配：
2.3 ~ 7.1：Bitmap的内存是分配在， 虚拟机的 java堆上。受系统分配的虚拟机的内存限制。超出限制OOM，应用程序crash。
8.0以后：内存分配在 native堆，不需要用户主动回收。不受系统分配的虚拟机的内存限制。
超出系统可用内存，进程直接挂掉，无crash弹窗,不会出现OOM。（不能因为内存分配在native上就肆无忌惮的使用图片。）
Android8.0之后源码里通过NativeAllocationRegistry这个类来回收Native层的内存，从而可以实现把bitmap的像素数据放到Native内存中并及时回收。

Java Heap，这部分的内存区域是由虚拟机管理，通过Java中 new 关键字来申请一块新内存。这块区域的内存是由GC直接管理，能够自动回收内存。这块内存的大小会受到系统限制，当内存超过APP最大可用内存时会OOM。

Native Heap，这部分内存区域是在C++中申请的，它不受限于APP的最大可用内存限制，而只是受限于设备的物理可用内存限制。它的缺点在于没有自动回收机制，只能通过C++语法来释放申请的内存。

8.0以前，我们也可以通过特殊的手段将Bitmap的内存分配移至native内存。

Fresco：将Bitmap内存分配至Ashmem内存。
Ashmem（Android匿名共享内存），这部分内存类似于Native内存区，但是它是受Android系统底层管理的，当Android系统内存不足时，会回收Ashmem区域中状态是 unpin 的对象内存块，如果不希望对象被回收，可以通过 pin 来保护一个对象

BitmapFactory.Options = new BitmapFactory.Options();
options.inPurgeable = true;(被废弃)
Bitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);

说完上面的我们说说在加载Bitmap的时候，我们通常要做的几个事：
1.计算合适的inSampleSize对图片进行压缩
设置BitmapFactory.Options类的inJustDecodeBounds属性为true，可在Bitmap不被加载到内存的前提下，获取Bitmap的原始宽高。然后通过原始宽高和需要显示控件的宽高计算出合适的inSampleSize（取2的整数次幂，如果不是的话，向下取得最大的2的整数次幂）。对图片进行压缩。

2.设置合适的inPreferredConfig 值
这里我只介绍三个属性：
ALPHA_8：每个像素点仅表示alpha的值，它不会存储任何颜色信息，占8位。
RGB_565：每个像素用5位R/6位G/5位G来表示，占16位。
ARGB_8888：每个像素分别用8位存储ARGB，占32位

如何设置呢？
png图片使用ARGB_8888。(不设置默认使用ARGB_8888)
jpg(24位，32位)使用RGB_565
jpg(8位)使用ALPHA_565
注意了并不是设置RGB_565解码的Bitmap所占用的内存就一定比ARGB_8888小。
下面我们做个小实验，找三张图片分别使用不同的值，去加载这个张图片

png图片在设置三种不同的值所占内存的大小

jpg(24位，32位)图片在设置三种不同的值所占内存的大小

jpg(8位)图片在设置三种不同的值所占内存的大小

第一行是使用ALPHA_565，第二行使用RGB_565，第三行使用ARGB_8888。看完三张图，在看看我上面说的，我相信就已经可以理解了。

3.图片放在合适的文件夹下

    目录名称                                Density
res/drawable                       默认密度(跟随ROM)
res/drawable-hdpi                         240
res/drawable-ldpi                         120
res/drawable-mdpi                         160
res/drawable-xhdpi                        320
res/drawable-xxhdpi                       480

Android系统在加载这些图片时，会先一步得到当前设备的显示密度，然后到相匹配的drawable的目录下寻找图片资源。如果不存在，会就近获取图片资源，然后将其所在的目录所代表的的密度与当前设备的密度相比，以这个比例来缩放图片。

获取屏幕密度方式：
DisplayMetrics dm = context.getResources().getDisplayMetrics();
int dpi = dm.densityDpi
如果一张大图放在了mdpi目录，而当前设备显示器为480dpi的超高密屏幕。
这时Android就会按照3倍大小来缩放这张图片，将它载入内存。

如果拿不准放入哪个目录，推荐使用Drawable.createFromStream替换getResources().getDrawable来加载，可以绕过Android上面说的默认规则。

4.设置inBitmap属性

4.4之前的版本inBitmap只能够重用相同大小的Bitmap内存区域。简单而言，被重用的Bitmap需要与新的Bitmap规格完全一致，否则不能重用。

4.4之后的版本系统不再限制旧Bitmap与新Bitmap的大小，只要保证旧Bitmap的大小是大于等于新Bitmap大小即可。

使用inBitmap前，每创建一个bitmap需要独占一块内存。

使用inBitmap后，多个bitmap会复用同一块内存。

5.缓存策略LruCache
LruCache 顾名思义就是使用LRU缓存策略的缓存，那么LRU是什么呢? 最近最少使用到的（least recently used），就是当超出缓存容量的时候，就优先淘汰链表中最近最少使用的那个数据。

enryRemoved方法：超出缓存容量的时候，调用的方法。
sizeOf：计算大小的方法。

6.淘汰掉的Bitmap的缓存池BitmapPool
可以使用软引用包装那些被淘汰的对象装载到一个集合中（被淘汰的对象不会被立马回收掉）。可以进行复用。
下面用一张图简单说明一下，图画的不好还请见谅：

（11）：避免OOM
AndroidManifest文件配置largeHeap = true , 使用多进程（需衡量利弊）让应用占用更多的内存，使用jni在native heap上申请空间,使用显存(使用 OpenGL textures 等 API ， texture memory 不受虚拟机 heapsize 限制)，避免OOM。

三.常见内存泄漏的处理方案

说到内存优化，不得不提的就是内存泄漏，在编码过程中，我应该尽量去避免内存泄漏的场景。由于考虑篇幅的原因，下面我列举一个常见的内存泄漏场景，并且给出相应的解决方案。

1.非静态内部类导致的泄露的统一解决方案:使用静态内部类.持有外部类的弱引用.（Handler，AsyncTask,Thread,Timer等等）
2.静态对象持有Activity上下文解决方案:使用全局的上下文 getApplcationContext().
3.静态View导致的内存泄露解决方案:在Activity中onDestory中将View置为null.
4.WebView导致的内存泄露解决方案:单进程方式或者反射破坏引用链.
5.经典Mvp导致的内存泄露解决方案:在Activity（Fragment） onDestory时 Presenter与View进行解绑。
6.注册监听器的泄漏（广播的绑定与解绑,EventBus的绑定与解绑）.
7.IO流,数据库导致的内存泄露(OutputStream、 InputStream以及相关的子类需要在finally块中进行及时关闭释放资源。数据库主要是Cursor游标、数据库的关闭).
8.集合框架导致的内存泄露 (不用的对象即时移除掉,否则只要集合被引用,集合内添加的元素就不能被回收).
9.Android系统导致的内存泄漏 InputMethodManager(在15<=API<=23中都存在) TextLine，AudioManger（6.0以下），android.os.Message等。

LeakCanary列出的已知的系统内存泄漏场景：
https://github.com/square/leakcanary/blob/9e74a8529ca94287fe0c3b02b7a6b39d51ecd704/leakcanary-android/src/main/java/com/squareup/leakcanary/AndroidExcludedRefs.java

四.总结

以上就是我们能够在编码时，就能够做到的一些内存优化，其实所有的方法，无外乎减少GC次数，对象复用，转移内存分配的地点，压缩减少内存分配的大小,不用的对象即时释放，相比以上的方案，我觉得思想的学习是最重要的，希望大家都能写出高性能的app。
对待已经存在的内存问题，那我们如何去发现呢？内存监控的问题，我们留到下次再说。今天就先说到这里，如果文章对你有帮助的话，希望可以来个赞哦。