聊一聊：内存优化的目的是什么？
在开始之前需要先搞明白一个问题，为什么要做内存优化？或者说做内存优化的目的是什么？
内存优化的主要目的是提高应用程序运行的效率和性能，并减少应用程序由于内存问题导致的崩溃或者卡顿情况。当一个应用程序运行时，它需要通过系统申请一部分内存空间来存储程序数据，但是如果这部分内存空间使用过多，就会导致整个系统内存的不稳定以及其他应用程序的运行受到影响。
因此，通过对Android应用程序内存空间的管理和优化，可以使得应用程序运行更加顺畅，提高应用程序的响应速度和性能，并且可以避免由于内存不足导致的崩溃或者卡顿情况。同时，对于低端设备或者内存较小的设备，内存优化也能够提高设备的稳定性和流畅度，提高设备的用户体验。
一、因内存造成的问题有哪些？
1. 内存大的进程会被优先回收
Android 是基于 Linux 内核实现的。Linux的内存管理哲学是：Free memory is wasted memory。即内存没有得到充分利用就是在浪费内存。因此 Linux 希望尽可能多的使用内存，较少磁盘 IO 。Android 系统继承了 Linux 的优点，同样是尽最大限度使用原则。但与Linux不同的是 Android 侧重于可能多的缓存进程以提高应用启动和切换速度。即，Android系统会在内存中尽量的长时间的保持应用进程，直到系统分配内存不足时才会去根据进程优先级、内存代销等条件回收进程。这些保留在内存中的进程通常不会影响系统整体的运行速度，反而会在用户再次激活这些进程时，加快进程的启动速度。
当Android系统需要为其他应用分配更多内存是，如果发现内存不足，便会根据条件关闭某些后台进程以回收内存。
- 在Android 7之后（之前是oom_adj）的系统中有一个oom_score_adj的值表示应用的优先级，oom_score_adj越大，进程的优先级越低，越容易被回收。
- 系统会使用LRU算法来优先从最近最少使用的进程开始遍历，因此最近最少使用的进程被回收的概率比较高。
- 系统还会考虑使用内存较多的进程优先回收。
概括来说，当系统分配内存时发现内存不足，则会根据进程优先级、最近最少使用、进程占用内存等条件综合评判进行进程回收。显然低内存的进程被回收的可能性比较低，因此，为了保证用户体验应该尽可能的减少进程占用的内存。
2. 单个进程使用的内存是有限的。
Android 系统的java虚拟机会对单个进程使用的最大内存做限制，这个属性值定义在/system/build.prop文件中，厂商一般会根据设备自身内存大小来设定这个值，因此，不同的设备分配给APP的最大可用内存是不相同的。当进程启动时，系统会先为APP分配一定的内存空间，当分配的内存快要耗尽时，系统会再次为App 分配更多的内存，但是每个APP都有内存使用上限，一旦进程分配了最大可用内存后，内存依然不足则会直接抛出OOM异常，终止程序的运行。
因此，占用较大内存的APP会导致OOM异常的可能性，基于这点更需要我们针对性的做内存优化，避免OOM。
3. GC 时 STW 影响程序性能
当进程使用内存达到设定的阈值时，就会触发虚拟机的GC机制，无论是java的Hotspot虚拟机还是Android的Dalvik 或者ART虚拟机，在进行垃圾回收时都会存在暂停其他线程的问题，被称作Stop The World（简称SWT）。当发生SWT时，所有的其他线程都会被停止运行，等待GC结束后才会再次执行。虽然JDK中的较新的垃圾收集器向ZGC、Shenandoha以及ART自身的垃圾收集器等已经将STW的时间减小，但还是STW还是不能避免。
当内存不足或者出现内存抖动时都会频繁的出发GC机制进行垃圾回收。而由于频繁的GC导致频繁的的STW，进而导致严重的程序的性能问题。因此，为了提升程序性能，有必要进行内存优化。
二、内存优化策略
内存优化可以考虑从两个方面入手，一方面是大对象的优化，应该想办法减小大对象占用的内存；另一方面则是从内存泄漏及内存抖动等方面去优化内存。
1. Bitmap等大对象的优化策略
APP中的内存问题多半是因为Bitmap引起的。因此，解决Bitmap的问题就解决了一半的内存问题。要解决Bitmap的内存首先要知道Bitmap占用的内存是如何计算的。Bitmap的内存计算公式如下：
Bitmap占用内存 = 分辨率 * 单个像素点的内存
比如说一个 1920 * 1080 的图片，它所占用的内存就是1920 * 1080 * 单个像素点内存。因此，对于Bitmap的优化就可以从分辨率和单个像素点两个方面来进行优化。
(1) 优化Bitmap分辨率
通常APP加载一张图片时候，ImageView的大小是确定的，比如一个ImageView的大小设置为 100 * 100 ，但是被加载的Bitmap的分辨率是 200 * 200，那么就可以通过采样压缩将该 ‘Bitmap’ 的分辨率压缩到 ‘100 * 100’。通过这一压缩操作可以直接减少4倍的内存大小。代码如下：
val options = BitmapFactory.Options()
options.inSampleSize = 2 // 设置采样率为2，则会每两个像素点采一个像素，最终分辨率宽高变为原来的 1/2
val bitmap = BitmapFactory.decodeResource(resources, R.drawable.image, options)
(2) 优化单个像素点内存
计算机中的图像一般都是由 红、绿、蓝 三个通道加上一个透明通道组成的，因此，一般来说一个像素点也是由红、绿、蓝，以及一个透明通道组成，对应到内存就是通过byte来表示，比如用两个 byte 来存储一个像素点，那么每个通道就占用 4 bit 的内存，而如果用 4 个 byte 来存储一个像素点，那么每个通道就占用 1 个byte。4 字节的像素点，相比2字节的像素点可以表示的色彩会更加丰富，因此四字节的像素点组成的图像质量也更加清晰。
在 Android 的 Bitmap 中单个像素点占用的内存与 Bitmap 的 inPreferredConfig 参数配置有关系，这个参数的可选值如下表所示：
| Config | 占用内存（byte） | 说明 |
|---|---|---|
| ALPH_8 | 1 | 只包含一个透明通道,透明通道占用 8bit，即 1byte |
| RGB_565 | 2 | 包含R/G/B三个颜色通道，不包含透明通道，三个通道占用的内存分别为5bit/6bit/5bit |
| ARGB_4444 | 2 | 已废弃，包含A/R/G/B四个颜色通道，每个通道占用4bit |
| ARGB_8888 | 4 | 24位真彩色，Android默认配置，每个通道占用 8bit |
| RGBA_F16 | 8 | Android 8.0 新增，每个通道占用16bit，即两个字节 |
在Android系统中 Bitmap 的默认色彩模式为 ARGB_8888, 即每个像素占用了4byte,那么在默认情况下，一张分辨率为1920 * 1080 的图片,加载到内存后占用的内存大小为1920 * 1080 * 4 = 7.91M
可以通过设置 inPreferredConfig 参数来设置对应的色彩模式，例如，一个不包含透明通道的图片，我们可以将其设置为RGB_565，即保证了图片的质量，又减少了内存的占用。代码如下：
val options = BitmapFactory.Options()
options.inPreferredConfig = Bitmap.Config.RGB_565 // 设置 bitmap 的色彩模式为 RGB_565
val bitmap = BitmapFactory.decodeResource(resources, R.drawable.image, options)
此时，一张 1920 * 1080 的图片加载到内存后的内存大小为 1920 * 1080 * 2 = 3.955M，比默认情况下的内存占用减小了一半。
(3) Bitmap的缓存策略
通过缓存策略也可以一定程度上的优化内存占用问题，比如 Glide 框架中采用了三级本地缓存策略来实现Bitmap的优化，通过设置活动缓存、LRU内存缓存和本地缓存。对于相同参数的ImageView，在内存中只保存一份，以此来减少内存大小。
(4) drawable资源选择合适的drawable文件夹存放
例如我们只在 hdpi 的目录下放置了一张 100 * 100 的图片，那么根据换算关系，分辨率匹配到 xxhdpi 的手机去引用这张图片时就会被拉伸到 200*200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到 assets 或者 nodpi 的目录下。
(5) 其他大对象的优化
可以使用更加轻量级的数据结构。例如，我们可以考虑使用 ArrayMap/SparseArray 而不是 HashMap 等传统数据结构，相比起 Android 系统专门为移动操作系统编写的 ArrayMap 容器，在大多数情况下，HashMap 都显示效率低下，更占内存。另外，SparseArray更加高效在于，避免了对key与value的自动装箱，并且避免了装箱后的解箱。
(6) 避免内存抖动
内存抖动是指在短时间内突然创建大量的对象，频繁的引发GC回收，造成内存波动的情况。在开发中应该避免频繁的创建对象，来避免内存抖动。因为内存抖动会频繁触发 GC，而GC又会引起 STW 问题，直接影响程序的性能。
比如在绘制自定义View的时候一定要避免在onDraw或者onMeasure中创建对象。
2. 避免内存泄漏
Java的内存泄漏是指问题是指在对象使用结束后，由于一些地方持有该对象，虽然已经无用，但是无法被GC正常回收的情况。内存泄漏会引起很严重的性能问题，比如内存泄漏引起内存紧张，从而频繁的出发GC，而GC由于存在STW问题，又会引发更严重的性能问题。最终在分配新的对象时无法获得足够的内存空间时导致OOM的产生。
常见的内存泄漏
在实践操作当中，可以从四个方面着手减小内存使用，首先是减小对象的内存占用，其次是内存对象的重复利用，然后是避免对象的内存泄露，最后是内存使用策略优化。
(1) 单例模式引起的内存泄漏（Singleton）
为了完美解决我们在程序中反复创建同一对象的问题，我们选用了单例模式，单例在我们的程序中随处可见，但是由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，一不小心让单例无限制的持有Activity的强引用就会导致内存泄漏。
(2) Handler引起的内存泄漏
Handler引起的内存泄漏在我们开发中最为常见的。我们知道Handler、Message、MessageQueue都是相互关联在一起的，万一Handler发送的Message尚未被处理，那么该Message以及发送它的Handler对象都会被线程MessageQueue一直持有。
(3) 匿名内部类在异步线程中的使用
它们方便却暗藏杀机。Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的
由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的，因此这种实现方式很难保证跟Activity的生命周期一直，所以很容易无法释放内存。
(4) static引起的内存泄漏
从前面的介绍我们知道，static修饰的变量位于内存的静态存储区，此变量与App的生命周期一致
这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。
这里修复的方法是：
不要在类初始时初始化静态成员。可以考虑lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。
(5) 非静态内部类引起的内存泄漏
非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
(6) 线程引起的内存泄漏
警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit()才不会泄露。
(7) 其他原因引起的内存泄漏
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。
3.使用系统提供的API来释放内存
Android系统提供了一些回调来通知当前应用的内存使用情况，比如下边的两个方法：
-
onLowMemory() 通常来说，当所有的Background应用都被kill掉的时候，forground应用会收到onLowMemory()的回调。在这种情况下，需要尽快释放当前应用的非必须的内存资源，从而确保系统能够继续稳定运行。尤其是要释放Glide中缓存的Bitmap资源，通过调用Glide.onLowMemory方法进行资源回收。
-
onTrimMemory() Android系统从4.0开始还提供了onTrimMemory()的回调，当系统内存达到某些条件的时候，所有正在运行的应用都会收到这个回调，同时在这个回调里面会传递以下的参数，代表不同的内存使用情况，收到onTrimMemory()回调的时候，需要根据传递的参数类型进行判断，合理的选择释放自身的一些内存占用，一方面可以提高系统的整体运行流畅度，另外也可以避免自己被系统判断为优先需要杀掉的应用。例如调用Glide.onTrimMemory()来进行bitmap的回收。
三、常用排查内存问题的工具
（1）LeakCanary监测内存泄漏
在debug模式下会一直开着LeakCanary来检测内存泄漏问题，根据LeanCannary提供的引用连可以快速定位到内存泄漏的位置。
（2）通过Proflier监控内存
在一个功能开发完成后可以通过Profiler来检测APP的内存使用情况。反复的打开关闭页面，然后触发GC，内存是否能够减少。
（3）通过MAT工具排查内存泄漏
MAT提供了很强大的功能，可以查看对象的深堆、浅堆的内存大小等。
如果你想要完全精通性能优化中的奥秘，只搞懂内存优化还不够，因为性能优化中包含了以下内容：
1.启动优化：通过减少应用启动时间，提高应用体验。例如，通过使用启动页和推迟初始化等方式来提高启动速度。
2.布局优化：优化布局可以提高UI渲染速度和流畅度。例如，使用ConstraintLayout来减少布局嵌套，缓存布局渲染等。
3.内存优化：内存是Android中最宝贵的资源之一，优化内存可以提高应用的性能和稳定性。例如，使用谷歌官方提供的工具分析内存使用情况，避免内存泄漏等。
4.网络优化：在移动应用中，网络传输速度往往是瓶颈，优化网络性能可以提高应用的响应速度和用户体验。例如，使用缓存技术和多线程下载等方式来提高网络传输速度。
5. GPU优化: 使用硬件加速提升UI渲染性能和流畅度，例如采用OpenGL ES等图形API进行GPU优化。
6. 电量优化(省电)：优化应用耗电量也是性能优化的一个方向，可以通过减少不必要的后台任务和资源占用等方式减少耗电。
7.代码逻辑优化：通过优化代码逻辑来提高应用性能，并减少占用内存和处理时间等。例如，使用线程池来处理异步任务，避免过度嵌套循环等。
8.体积包优化
9.……
总之，Android性能优化是一项综合性较强的工作，需要从多个方面入手，同时也需要根据具体应用特点进行有针对性的优化。
如果想要精进性能优化这项技术，那这《Android 性能优化核心笔记》必定少不了，因为它将性能优化中间包含的知识点解析都记录在内了，所以是一份非常不错的学习文档：https://qr18.cn/FVlo89
Android 性能优化核心笔记：
