Android Note - 内存优化

我们知道，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对象由于被观察者持有，无法回收，就导致了内存泄漏。

资源未关闭导致无法回收

这也是经常被提到的点，注册并使用后，忘记在生命周期结束时解绑，导致无法回收。

解决方案：BroadcastReceiver、ContentObserver、File、Bitmap、Timer、EventBus 等都是需要解绑或者清空的，要养成直觉

WebView不要在布局中定义

这个是网络上一篇文章里看到的，我想现在应该没有多少人会在布局里定义 WebView 吧（还有 Fragment ）

解决方案：在代码中构造WebView对象，创建时上下文使用 ApplicationContext

内存溢出

内存溢出Out Of Memory ，是指应用的内存申请超出了当前所能申请的最大内存容量，导致应用出现一系列问题甚至被系统杀掉进程。在 Android 中出现内存溢出，主要是因为以下原因引起。

使用 Bitmap 并且未优化

Bitmap 是产生内存溢出的大户，如果没有经过任何优化，直接加载一个 Bitmap 的话，会导致该对象吃掉大量内存。

recycle

短时间创建大量对象

这个常见于列表组件的加载。加载列表时如果不优化，同一时间内创建了过多对象，就会造成内存溢出。

其他内存溢出的场景和解决方案

1. 捕获 OOM 异常，避免因为内存溢出而导致崩溃
2. 使用优化的数据容器，合适的内存容器可以大幅度增加内存性能
3. 使用 zipalign 对齐可以一定量优化内存性能（Google 官方推荐）
4. 使用成熟的第三方框架，例如使用 Glide 处理图片