如果扩容次数多了，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
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
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导致的内存泄露解决方案:单进程方式或者反射破坏引用链.