内存优化是Android性能优化的重点内容，一般来说，谈及性能优化，肯定避不开内存优化。虽然现在手机内存都很大，但并不意味着我们的App在使用内存时能“为所欲为”。这篇就简单地总结一下关于内存优化要注意的一些事项。
进程级别的内存策略
我们知道，Android 系统是一个基于 Linux 的开源系统，使用的是 Dalvik / Android Runtime 作为对应的虚拟机来执行代码。底层内存分配机制在这里就不详述了，只看 Application Framework 这一层。
首先，Android 中的内存分配由 ActivityManagerService 统一管理。这是一个很重要的类，除了内存管理之外，它还管理了 Activity 生命周期，启动行为，消息派发等功能。当用户点击应用的启动图标时， ActivityManagerService 会请求系统创建一个进程，当进程创建完成之后，绑定给 ActivityManagerService，这时才会开始 App 本身的生命周期。
而关于内存回收这块，Application Framework 给创建的进程规定了五个的回收类型优先级，即从最先被回收到最后被回收，分别是：
- Empty process 空进程
- Background process 后台进程
- Service process 服务进程
- Visible process 可见进程
- Foreground process 前台进程
然后在 ActivityManagerService 中，会对所有进程进行评分，并将评分同步到 Linux 内核中，最终由内核来执行内存回收
对象级别的内存策略
关于对象级别的内存管理策略，由于是应用程序自动管理内存分配以及内存回收（Java GC），能操作的有限，但是基本的概念还是要了解的，因为当你知道对象/变量在内存中是如何分配，以及分配到堆/栈/方法区的时候，在写代码的时候就会有意规避一些问题，达到内存优化的效果。
Android常见内存问题
内存泄漏
内存泄漏 Memory Leak，指的是内存申请并使用完毕以后，系统因为某些原因无法回收该内存块的情况。其实质也是长生命周期对象持有短生命周期的对象，导致短生命周期对象需要被回收时，由于长生命周期的对象持有无法被回收的现象。
在Android中，以下几个场景容易出现内存泄漏。
单例对象使用了非全局的 Context
这个是初学者容易犯的错误，在构造一个单例对象时，往往需要使用 Context 对象来初始化构造函数，并持有一个 Context对象，这时如果传入一个非全局的 Context ，会导致该 Context对象在 GC 时无法回收，造成内存泄漏。
解决方案：单例使用 ApplicationContext ，这个对象的生命周期是整个应用的生命周期，不会导致泄漏
匿名内部类 / 非静态内部类 / 异步线程 / Handler 持有外部类的引用
这也是常见的内存泄漏易于出现的场景。举例来说，我们现在经常使用 Rxjava + Retrofit + OkHttp 来构建网络请求。有时候会碰到网速过慢导致网络请求返回慢或者超时的情况。这时如果我们关闭了当前页面，网络请求结果仍然会被观察者接受并刷新UI。这时本来要被回收的UI对象由于被观察者持有，无法回收，就导致了内存泄漏。
解决方案：
- 使用静态内部类，并在需要的时候引入外部类，而不是直接在构造函数中引用
- 使用弱引用 WeakReference 来引用外部类实例（掌握Java的四种引用方式）
资源未关闭导致无法回收
这也是经常被提到的点，注册并使用后，忘记在生命周期结束时解绑，导致无法回收。
解决方案：BroadcastReceiver、ContentObserver、File、Bitmap、Timer、EventBus 等都是需要解绑或者清空的，要养成直觉
WebView不要在布局中定义
这个是网络上一篇文章里看到的，我想现在应该没有多少人会在布局里定义 WebView 吧（还有 Fragment ）
解决方案：在代码中构造WebView对象，创建时上下文使用 ApplicationContext
内存溢出
内存溢出 Out Of Memory ，是指应用的内存申请超出了当前所能申请的最大内存容量，导致应用出现一系列问题甚至被系统杀掉进程。在 Android 中出现内存溢出，主要是因为以下原因引起。
使用 Bitmap 并且未优化
Bitmap 是产生内存溢出的大户，如果没有经过任何优化，直接加载一个 Bitmap 的话，会导致该对象吃掉大量内存。
解决方案：
- 加载图片之前先计算出合适的缩放比例，按比例缩放。
- 选择合适的解码格式。不同的格式，内存占用在很大差异。
- Bitmap 不用时要及时回收，调用
recycle方法。
短时间创建大量对象
这个常见于列表组件的加载。加载列表时如果不优化，同一时间内创建了过多对象，就会造成内存溢出。
解决方案：
- 使用按需加载的方式加载内容（上拉加载更多）
- 常用对象做到尽量复用，并缓存常用对象。
其他内存溢出的场景和解决方案
- 捕获 OOM 异常，避免因为内存溢出而导致崩溃
- 使用优化的数据容器，合适的内存容器可以大幅度增加内存性能
- 使用 zipalign 对齐可以一定量优化内存性能（Google 官方推荐）
- 使用成熟的第三方框架，例如使用 Glide 处理图片
