我们都知道在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。

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

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
eDv4vz-1715420319233)]

[外链图片转存中…(img-Z2TdsrIC-1715420319234)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！