浅谈Android内存优化

今天咱们来聊一聊Android 内存优化，这篇文章原本很早就应该写了，但由于小游戏开发太吸引人了，因此这个就拖到了如今才开始，不过我以为也不晚😁

这篇文章主要经过以下三个方面对Android内存优化进行介绍：

1. Android内存分配与回收机制
2. Android经常使用的内存优化方法
3. Android内存分析与监控

文章不会涉及到native内存的优化，由于普通App开发中涉及的较少，若是想了解能够参考极客时间张绍文老师的Android开发高手课。

1、Android内存分配与回收机制

想要优化Android内存，一些必备的基础知识是不能少的。因此在第一部分，咱们先从Application Framework、Dalvik/Art、Linux内核三个部分由浅入深来说解关于Androd内存相关的知识。

Application Framework

首先来看下进程的优先级：

前台进程：用户当前操做所必需的进程。

可见进程：没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。

服务进程：正在运行已使用 startService() 方法启动的服务。（后台播放音乐，网络下载数据）

后台进程：对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）

空进程：不含任何活动应用组件的进程。保留这种进程的的惟一目的是用做缓存，以缩短下次在其中运行组件所需的启动时间

进程生命周期：Android 系统将尽可能长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终须要移除旧进程来回收内存。 为了肯定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每一个进程放入“重要性层次结构”中。 必要时，系统会首先消除重要性最低的进程，而后是重要性略高的进程，来回收系统资源。（通常状况下前台进程就是与用户交互的进程了,若是连前台进程都须要回收那么此时系统几乎不可用了）。由此也衍生了不少进程保活的方法（提升优先级，互相唤醒，native保活等等），出现各类杀不死的进程的APP。

最后咱们须要知道：Android中由ActivityManagerService 类集中管理全部进程的内存资源分配，咱们能够查看其源码来具体分析实现过程。

Dalvik/Art 虚拟机

Android Dalvik Heap

简介：Android Dalvik Heap与原生Java同样，将堆的内存空间分为三个区域，Young Generation新生代，Old Generation年老代， Permanent Generation持久代。

对象分配过程：最近分配的对象会存放在新生代区域，新生代区域分为eden区（伊甸园，圣经中指上帝为亚当夏娃创造的生活乐园）、so区和s1区，s1和s0区也被称为from区和to区（合称Survivor区），他们是两块大小相等而且能够互换角色的空间，绝大多数状况下,对象首先分配在eden区，在一次新生代回收后，若是对象还存活会进入s0或者s1区，以后每一次gc，存活的对象年龄都会相应增长，当达到必定年龄则会进入老年代，最后累积必定时间再移动到持久代区域。系统会根据内存中不一样的内存数据类型分别执行不一样的gc操做。

问题：GC发生的时候，全部的线程都是会被暂停的。执行GC所占用的时间和它发生在哪个Generation也有关系，新生代中的每次GC操做时间是最短的，年老代其次，持久代最长。GC时会致使线程暂停、界面卡顿的问题在Android Art中获得了优化。

Dalvik虚拟机执行模式

Dalvik垃圾回收过程：GC会去标记和查找全部可访问到的活动对象，这个时候整个程序的线程就会挂起，而且虚拟机内部的全部线程也会同时挂起(左下图) 。之因此要挂起全部线程是确保：全部程序没有进行任何变动，与此同时GC会隐藏全部处理过的对象，最终确保标记了全部须要回收的对象后，GC才会恢复全部线程，并释放空间。

大内存对象分配：当发现须要给一个较大的对象(蓝色方块)分配空间时，发现可用空间仍是够的，但没有这么大的连续空间供新对象使用，这个时候就不得不进行一次GC回收（红色方块，右下图），为大对象腾出较大而且连续的空间。这就是咱们在分配一个较大对象的时候很是容易引发丢帧和卡顿的缘由之一，因此Android5.0之前你们都认为Android卡顿是由于Darvik虚拟机的效率低下致使的。

总结：Dalvik虚拟机的三个问题

1. GC时挂起全部线程
2. 大而连续的空间紧张
3. 内存碎片化严重

ART虚拟机的优化

GC过程：在ART中GC会要求程序在分配空间的时候标记自身的堆栈，这个过程很是短，不须要挂起全部程序的线程.这样就节约了很大一部分时间去查找活动对象。

大内存对象分配：ART里会有一个独立的LOS供Bitmap使用，从而提升了GC的管理效率和总体性能.

内存碎片化在ART里还会有一个moving collector来压缩活动对象(绿色方块)，使得内存空间更加紧凑。

总结 ：Google在ART里对GC作了很是大的优化(更高效的回收算法),使ART内存分配的效率提升了10倍，GC的效率提升了2-3倍（可见原来效率有多低），不过主要仍是优化中断和阻塞的时间，频繁的GC仍是会致使卡顿。

Linux内核

Lowmemorykiller：ActivityManagerService中trimApplications() 函数中会执行一个叫作 updateOomAdjLocked() 的函数，updateOomAdjLocked 将针对每个进程更新一个名为 adj 的变量，（用来表示发生内存不足时杀死进程的优先级顺序）并将其告知 Linux 内核，内核一样维护一个包含 adj 的数据结构（即进程表），并经过 lowmemorykiller 检查系统内存的使用状况，在内存不足时，遍历全部进程，选出低优先级的进程杀死，最终由内核去完成真正的内存回收。

Oom_killer ：若是上述各类方法都没法释放出足够的内存空间，那么当为新的进程分配内存时将发生 Out of Memory 异常，OOM_killer 将尽最后的努力杀掉一些进程来释放空间。Android 中的oom_killer一样会遍历进程，并计算全部进程的 badness 值，选择 badness 最大的那个进程将其杀掉。

Oom的条件：只要allocated + 新分配的内存 >= dalvik heap(堆内存) 最大值的时候就会发生OOM（Art运行环境的统计规则仍是和dalvik保持一致）

内存不优化会致使哪些问题？

上面介绍了Android内存分配从应用层到Linux层的一些知识，因此我总结出上图内存会致使的一些问题，可是上图只是列出了一些常见状况，先后并无绝对的因果关系，最后来讲下内存抖动。

内存抖动：Memory Churn，内存抖动是由于在短期内大量的对象被建立又立刻被释放。瞬间产生大量的对象会严重占用内存区域，当达到阀值，剩余空间不够的时候，会触发GC从而致使刚产生的对象又很快被回收。即便每次分配的对象占用了不多的内存，可是他们叠加在一块儿会增长Heap的压力，从而触发更多其余类型的GC。这个操做有可能会影响到帧率，并使得用户感知到性能问题。

2、Android经常使用的内存优化方法

在Android中内存优化的方式实在是太多了，往细了说，到你写的每一行代码其实都和内存优化相关。在这里我从三个方面来讲下Android内存优化的方法：

1. 下降运行时内存
2. 代码优化
3. 内存泄漏优化

在实际开发中咱们能够先考虑下降应用的运行时内存，而后针对代码写的很差的地方着重优化，最后经过规避一些可能致使内存泄漏的编码方式，去提早避免内存泄漏的问题。

下降运行时内存

下降运行时内存能够分为减少APK的体积和Bitmap优化两部分：

• 减少APK体积

1. 去除无用的资源和代码，经过合理使用git，一些因为业务变动而基本不会用到的代码，该删除的毫不能手软。即便之后要用到，经过git也能找回。同时一些图片资源未用到的也应该删除，由于即便gradle配了sharkresource选项，发布的时候这些没有用到的图片依然会被打包到你的apk。
2. 尽可能复用资源，其实这是一种比较好的编码习惯。
3. 对应用的启动图引导页图片进行压缩，每每这些图片占据了大部分空间，压缩后能够起到很好的效果。平时开发中对于分辨率大雨100*100的图片基本上都会进行压缩，不少好的压缩算法常常能够减小一半的大小，而感官上基本看不出有任何改变。

• Bitmap优化

1. 统一的bitmap加载器，选择Glide、Fresco、Picasso中的一个做为图片加载框架。实际开发中加载到view的图片的大小不该该超过view的大小，图片加载框架默认会对图片进行缓存，按view实际大小加载。在开发中为了减小apk的大小，通常只放一套3X图片，可是这些图片在小分辨率的手机上直接加载就会出现内存浪费。统一的bitmap加载器就能够很好的解决该问题。
2. 图片存在像素浪费，对于.9图，美工可能在出图时在拉伸与非拉伸区域都有大量的像素重复。而这些图片是能够缩小，但并不影响显示效果。
3. inSampleSize:缩放比例，在把图片载入内存以前，咱们须要计算一个合适的缩放比例，避免没必要要的大图载入。
4. 选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差别。
5. inBitmap：这个参数用来实现Bitmap内存的复用，但复用存在一些限制，具体体如今：在Android 4.4以前只能重用相同大小的Bitmap的内存，而Android 4.4及之后版本则只要后来的Bitmap比以前的小便可。使用inBitmap参数前，每建立一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap能够复用一块内存，这样能够提升性能。

参考：

Android 官网文档Managing Bitmap Memory、Handling bitmaps

代码优化

这里介绍一些好的编码习惯：

1. 考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，由于HashMap须要一个额外的实例对象来记录Mapping的操做。而SparesArray高效的避免了key和value的自动装箱，并且避免了装箱后的解箱。详细参考Android性能优化典范

2. 在onDraw这种频繁调用的方法要避免对象的建立操做，由于他会迅速增长内存的使用，引发频繁的gc，甚至内存抖动。

3. SoftReference(软引用)、WeakReference(弱引用)、PhantomReference(虚引用)

   SoftReference：若是一个对象只具备软引用，则内存空间足够，垃圾回收器就不会回收它；若是内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就能够被程序使用。软引用可用来实现内存敏感的高速缓存。

   WeakReference：与软引用的区别在于：只具备弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程当中，一旦发现了只具备弱引用的对象，无论当前内存空间足够与否，都会回收它的内存。不过，因为垃圾回收器是一个优先级很低的线程，所以不必定会很快发现那些只具备弱引用的对象。

   PhantomReference：虚引用”顾名思义，就是形同虚设，与其余几种引用都不一样，虚引用并不会决定对象的生命周期。若是一个对象仅持有虚引用，那么它就和没有任何引用同样，在任什么时候候均可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，若是发现它还有虚引用，就会在回收对象的内存以前，把这个虚引用加入到与之 关联的引用队列中。

4. 谨慎使用large heap，android设备因为软硬件的差别，heap阀值不一样，特殊状况下能够在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。可是要谨慎使用，由于额外的空间会影响到系统总体的用户体验，切换任务时性能大打折扣，对于oom异常是治标不治本的一种作法。

5. 谨慎使用多进程，使用多进程能够把应用中的部分组件运行在单独的进程当中，这样能够扩大应用的内存占用范围，可是这个技术必须谨慎使用，绝大多数应用都不该该贸然使用多进程，一方面是由于使用多进程会使得代码逻辑更加复杂，另外若是使用不当，它可能反而会致使显著增长内存。当你的应用须要运行一个常驻后台的任务，并且这个任务并不轻量，能够考虑使用这个技术，一个典型的例子是建立一个能够长时间后台播放的Music Player。若是整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法获得释放。相似这样的应用能够切分红2个进程：一个用来操做UI，另一个给后台的Service。

6. 考虑第三方库的大小，若是会和现有的代码或其余库的代码重复，考虑不要真个引入而是把库的代码精简以后再引入。

内存泄漏优化

内存泄漏的缘由有不少，下面介绍一些常见的，咱们须要在开发中多注意：

1. Activity调用了finish，可是引用Activity的对象未被释放(生命周期没有结束)，Activity Context被传递到其余实例中，可能致使自身被引用而发生泄露，建议使用weakReferce。

2. 除必须使用Activity Context的状况(Dialog的context必须是Activity),咱们可使用Application Context来避免Activity泄露。

3. 大多数状况下，咱们对Bitmap对象增长缓存机制，可是有时候部分bitmap须要及时回收。好比咱们临时建立的摸个相对大的bitmap对象，变换获得新的bitmap对象后，尽快回收原始的bitmap，及时释放原来的空间。

4. webview引发的内存泄漏主要是由于org.chromium.android_webview.AwContents 类中注册了component callbacks，可是未正常反注册而致使的。让onDetachedFromWindow先走，在主动调用destroy()以前，把webview从它的parent上面移除掉(Basewebfragment onDestroy())

5. 虽然单例模式简单实用，提供了不少便利性，可是由于单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。

6. 咱们在对数据库进行操做时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响。

7. 谨慎使用static对象，由于static的生命周期过长，和应用的进程保持一致，使用不当极可能致使对象泄漏。

总结：在实际的线上环境中发现，大部份内存泄漏是由于被调用的对象生命周期不一样步致使，生命周期不一样步不只仅会致使内存泄漏，更会出现异常，崩溃等更严重的问题。

作好上面说的一、二、3就够了吗？

前面咱们已经从系统级别了解了Android Framework、Darlvik/Art虚拟机、Linux在内存分配上的原理，接着又在代码级别分别从减小内存占用、避免内存泄漏和代码优化三个方面介绍了如何避免内存问题，再加上当前科技发展是如此迅速，4GB内存已是很常见的手机配置。LPDDR4X的高速闪存也愈来愈被普遍的使用。对于内存优化咱们是否是就已经能够高枕无忧了，有上面这些就够了吗？

我想即便咱们再了解内存，写的代码再好，用户的手机再先进，总仍是有出错的时候，那么过后的内存分析和监控是必不可少的了！

3、Android内存分析与监控

Android内存分析和监控主要介绍以下四种方式：

1. 查看GC日志
2. 查看内存使用状况
3. 经过LeakCanary监控内存 泄漏
4. 线上监控

查看GC日志

GC的类型：

Concurrent： 不会暂停应用线程的并发垃圾回收。此垃圾回收在后台线程中运行，并且不会阻止分配。

Alloc： 您的应用在堆已满时尝试分配内存引发的垃圾回收。在这种状况下分配线程中发生了垃圾回收。

Explicit：由应用明确请求的垃圾回收，例如，经过调用system.gc()。与 Dalvik 相同，在 ART 中，最佳作法是您应信任垃圾回收并避免请求显式垃圾回收（若是可能）。不建议使用显式垃圾回收，由于它们会阻止分配线程并没必要要地浪费 CPU 周期。若是显式垃圾回收致使其余线程被抢占，那么它们也可能会致使卡顿（应用中出现间断、抖动或暂停）

NativeAlloc：原生分配（如位图或 RenderScript 分配对象）致使出现原生内存压力，进而引发的回收。

查看垃圾回收日志

在AndroidStudio Logcat过滤GC，而后操做App一段时间后会出现上图的GC内容：

垃圾回收缘由+垃圾回收的名称+释放对象+释放对象大小+释放大型对象的大小+堆统计数据+暂停时间

LOS objects是前面所说到的Art虚拟机新增的

着重关注最后面的暂停时间，超过16ms会影响界面，通常大于700ms会影响体验，Android Vitals 将连续丢帧超过 700 毫秒定义为冻帧，也就是42帧

查看内存使用状况

经过查看内存使用状况来分析App的内存占用是很是必要的，下面分别介绍以下两种方式：

1. adb shell
2. Profiler

查看内存使用状况

详细的使用请参考AndroidDeveloper调查RAM使用状况

使用Profiler分析内存

AndroidStudio的Profiler功能愈来愈强大，不只集成了内存分析，还有电量、CPU、网络等数据的分析。

如何经过Profiler进行内存的分析，如何找到内存泄漏请查看

使用 Memory Profiler 查看 Java 堆和内存分配

这里要说下，Android官网的不少文章都被翻译成了中文，这对国内的开发者来讲愈来愈有好了，但要注意中文翻译的文章会比较滞后，最新版通常都是英文。

使用LeakCanary监控内存泄漏

LeakCanary名字的由来：Canary是煤矿中金丝雀表达的参考，暗示了矿工将随身携带进入矿井隧道的笼养金丝雀（鸟类）。若是在矿井中收集到一氧化碳等危险气体，这些气体会在杀死矿工以前杀死金丝雀，从而提供警告当即离开隧道。

原理：LeakCanary经过ApplicationContext统一注册监听的方式，经过application.registerActivityLifecycleCallbacks来绑定Activity生命周期的监听，从而监控全部Activity; 在Activity执行onDestroy时，开始检测当前页面是否存在内存泄漏，并分析结果。KeyedWeakReference与ReferenceQueue联合使用，在弱引用关联的对象被回收后，会将引用添加到ReferenceQueue；清空后，能够根据是否继续含有该引用来断定是否被回收；断定回收， 手动GC, 再次断定回收，采用双重断定来确保当前引用是否被回收的状态正确性；若是两次都未回收，则肯定为泄漏对象。

LeakCanary的问题：LeakCanary也有必定的不肯定性，通常同一个地方反复泄漏5次，算是一个泄漏，同时不建议用在线上环境。

详细查看 Github

线上监控

线上的内存监控通常都是一些大公司在作，例如美团的Probe还有微信最近开源的Matrix，我的以为这个能够去了解下，大公司用户数多时会用到，小公司App接入必要性不是很大，通常来讲把上面的介绍的部分作好了就足够了。

发表与 2019-01-11

原文连接