前言
我们来关注应用开发中的另一个重要、严重、非常重要的性能问题了，那就是内存性能优化分析。Android其实就是嵌入式设备，嵌入式设备核心关注点之一就是内存资源；有人说现在的设备都在堆硬件配置（譬如国产某米的某兔跑分手机、盒子等），所以内存不会再像以前那么紧张了，其实这句话听着没错，但为啥再高配置的Android设备上有些应用还是越用系统越卡呢？这里面的原因有很多，不过相信有了这一章下面的内容分析，作为一个移动开发者的你就有能力打理好自己应用的那一亩三分地内存了，能做到这样就足以了。
正文
Android内存管理原理
系统级内存管理：
Android系统内核是基于Linux，所以说Android的内存管理其实也是Linux的升级版而已。Linux在进程停止后就结束该进程，而Android把这些停止的进程都保留在内存中，直到系统需要更多内存时才选择性的释放一些，保留在内存中的进程默认（不包含后台service与Thread等单独UI线程的进程）不会影响整体系统的性能（速度与电量等）且当再次启动这些保留在内存的进程时可以明显提高启动速度，不需要再去加载。
再直白点就是说Android系统级内存管理机制其实类似于Java的垃圾回收机制，这下明白了吧；在Android系统中框架会定义如下几类进程、在系统内存达到规定的不同level阈值时触发清空不同level的进程类型。
可以看见，所谓的我们的Service在后台跑着跑着挂了，或者盒子上有些大型游戏启动起来就挂，有一个直接的原因就是这个阈值定义的太大，导致系统一直认为已经达到阈值，所以进行优先清除了符合类型的进程。所以说，该阈值的设定是有一些讲究的，我们主要是针对应用层内存分析的，系统级内存回收了解这些就基本够解释我们应用在设备上的一些表现特征了。
应用级内存管理：
在说应用级别内存管理原理时大家先想一个问题，假设有一个内存为1G的Android设备，上面运行了一个非常非常吃内存的应用，如果没有任何机制的情况下是不是用着用着整个设备会因为我们这个应用把1G内存吃光然后整个系统运行瘫痪呢？
其实Google的工程师才不会这么傻的把系统设计这么差劲。为了使系统不存在我们上面假想情况且能安全快速的运行，Android的框架使得每个应用程序都运行在单独的进程中（这些应用进程都是由Zygote进程孵化出来的，每个应用进程都对应自己唯一的虚拟机实例）；如果应用在运行时再存在上面假想的情况，那么瘫痪的只会是自己的进程，不会直接影响系统运行及其他进程运行。
既然每个Android应用程序都执行在自己的虚拟机中，那了解Java的一定明白，每个虚拟机必定会有堆内存阈值限制（值得一提的是这个阈值一般都由厂商依据硬件配置及设备特性自己设定，没有统一标准，可以为64M，也可以为128M等；它的配置是在Android的属性系统的/system/build.prop中配置dalvik.vm.heapsize=128m即可，若存在dalvik.vm.heapstartsize则表示初始申请大小），也即一个应用进程同时存在的对象必须小于阈值规定的内存大小才可以正常运行。
接着我们运行的App在自己的虚拟机中内存管理基本就是遵循Java的内存管理机制了，系统在特定的情况下主动进行垃圾回收。但是要注意的一点就是在Android系统中执行垃圾回收（GC）操作时所有线程（包含UI线程）都必须暂停，等垃圾回收操作完成之后其他线程才能继续运行。这些GC垃圾回收一般都会有明显的log打印出回收类型，常见的如下：
GC_MALLOC——内存分配失败时触发；
GC_CONCURRENT——当分配的对象大小超过一个限定值（不同系统）时触发；
GC_EXPLICIT——对垃圾收集的显式调用(System.gc()) ；
GC_EXTERNAL_ALLOC——外部内存分配失败时触发；
通过上面这几点的分析可以发现，应用的内存管理其实就是一个萝卜一个坑，坑都一般大，你在开发应用时要保证的是内存使用同一时刻不能超过坑的大小，否则就装不下了。
Android内存泄露性能分析
有了关于Android的一些内存认识，接着我们来看看关于Android应用开发中常出现的一种内存问题—内存泄露。
Android应用内存泄露概念
众所周知，在Java中有些对象的生命周期是有限的，当它们完成了特定的逻辑后将会被垃圾回收；但是，如果在对象的生命周期本来该被垃圾回收时这个对象还被别的对象所持有引用，那就会导致内存泄漏；这样的后果就是随着我们的应用被长时间使用，他所占用的内存越来越大。如下就是一个最常见简单的泄露栗子（其它的泄露不再一一列举了）：
public final class MainActivity extends Activity {
private DbManager mDbManager;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//DbManager是一个单例模式类，这样就持有了MainActivity引用，导致泄露
mDbManager = DbManager.getInstance(this);
}
}
可以看见，上面例子中我们让一个单例模式的对象持有了当前Activity的强引用，那在当前Acvitivy执行完onDestroy()后，这个Activity就无法得到垃圾回收，也就造成了内存泄露。
内存泄露可以引发很多的问题，常见的内存泄露导致问题如下：
应用卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC）;
应用被从后台进程干为空进程（上面系统内存原理有介绍，也就是超过了阈值）；
应用莫名的崩溃（上面应用内存原理有介绍，也就是超过了阈值OOM）；
造成内存泄露泄露的最核心原理就是一个对象持有了超过自己生命周期以外的对象强引用导致该对象无法被正常垃圾回收；可以发现，应用内存泄露是个相当棘手重要的问题，我们必须重视。
Android应用内存泄露察觉手段
知道了内存泄露的概念之后肯定就是想办法来确认自己的项目是否存在内存泄露了，那该如何察觉自己项目是否存在内存泄露呢？如下提供了几种常用的方式：
| 察觉方式 | 场景 |
|---|---|
| AS的Memory窗口 | 平时用来直观了解自己应用的全局内存情况，大的泄露才能有感知。 |
| DDMS-Heap内存监测工具 | 同上，大的泄露才能有感知。 |
| dumpsys meminfo命令 | 常用方式，可以很直观的察觉一些泄露，但不全面且常规足够用。 |
| leakcanary | 比较强大，可以感知泄露且定位泄露；实质是MAT原理，只是更加自动化了，当现有代码量已经庞大成型，且无法很快察觉掌控全局代码时极力推荐；或者是偶现泄露的情况下极力推荐。 |
AS的Memory窗口如下，详细的说明这里就不解释了，很简单很直观（使用频率高）：
DDMS-Heap内存监测工具窗口如下，详细的说明这里就不解释了，很简单（使用频率不高）：
dumpsys meminfo命令如下（使用频率非常高，非常高效，我的最爱之一，平时一般关注几个重要的Object个数即可判断一般的泄露；当然了，adb shell dumpsys meminfo不跟参数直接展示系统所有内存状态）：
leakcanary使用这里先不说，下文会专题介绍。有了这些工具的定位我们就能很方便的察觉我们App的内存泄露问题，察觉到以后该怎么定位分析呢，继续往下看。
Android应用内存泄露leakcanary工具定位分析
leakcanary是一个开源项目，一个内存泄露自动检测工具，是著名的GitHub开源组织Square贡献的，它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心，缺点在于还存在一些bug，不过正常使用百分之九十情况是OK的，其核心原理与MAT工具类似。
PS：之前在优化性能时发现我们有一个应用有两个界面退出后Activity没有被回收（dumpsys meminfo发现一直在加），所以就怀疑可能存在内存泄露。但是问题来了，这两个Activity的逻辑十分复杂，代码也不是我写的，相关联的代码量也十分庞大，更加郁闷的是很难判断是哪个版本修改导致的，这时候只知道有泄露，却无法定位具体原因，使用MAT分析解决掉了一个可疑泄露后发现泄露又变成了概率性的。可以发现，对于这种概率性的泄露用MAT去主动抓取肯定是很耗时耗力的，所以决定直接引入leakcanary神器来检测项目，后来很快就彻底解决了项目中所有必现的、偶现的内存泄露。
总之一点，工具再强大也只是帮我们定位可能的泄露点，而最核心的GC ROOT泄露信息推导出泄露问题及如何解决还是需要你把住代码逻辑及泄露核心概念去推理解决。
Android应用内存泄露MAT工具定位分析
Eclipse Memory Analysis Tools是一个专门分析Java堆数据内存引用的工具，我们可以使用它方便的定位内存泄露原因，核心任务就是找到GC ROOT位置即可。
PS：这是开发中使用频率非常高的一个工具之一，麻烦务必掌握其核心使用技巧，虽然Android Studio已经实现了部分功能，但是真的很难用，遇到问题目前还是使用Eclipse Memory Analysis Tools吧。
Android应用开发规避内存泄露建议
有了上面的原理及案例处理其实还不够，因为上面这些处理办法是补救的措施，我们正确的做法应该是在开发过程中就养成良好的习惯和敏锐的嗅觉才对，所以下面给出一些应用开发中常见的规避内存泄露建议：
Context使用不当造成内存泄露；不要对一个Activity Context保持长生命周期的引用（譬如上面概念部分给出的示例）。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换（原理我前面有一篇关于Context的文章有解释）。
非静态内部类的静态实例容易造成内存泄漏；即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
不要在执行频率很高的方法或者循环中创建对象，可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
避免代码设计模式的错误造成内存泄露。
Android内存溢出OOM性能分析
上面谈论了Android应用开发的内存泄露，下面谈谈内存溢出（OOM）；其实可以认为内存溢出与内存泄露是交集关系，具体如下图：
Android应用内存溢出OOM概念
上面我们探讨了Android内存管理和应用开发中的内存泄露问题，可以知道内存泄露一般影响就是导致应用卡顿，但是极端的影响是使应用挂掉。前面也提到过应用的内存分配是有一个阈值的，超过阈值就会出问题，这里我们就来看看这个问题—–内存溢出（OOM–OutOfMemoryError）。
内存溢出的主要导致原因有如下几类：
应用代码存在内存泄露，长时间积累无法释放导致OOM；
应用的某些逻辑操作疯狂的消耗掉大量内存（譬如加载一张不经过处理的超大超高清图片等）导致超过阈值OOM；
可以发现，无论哪种类型，导致内存溢出（OutOfMemoryError）的核心原因就是应用的内存超过阈值了。
Android应用内存溢出OOM性能分析
通过上面的OOM概念和那幅交集图可以发现，要想分析OOM原因和避免OOM需要分两种情况考虑，泄露导致的OOM，申请过大导致的OOM。
内存泄露导致的OOM分析：
这种OOM一旦发生后会在logcat中打印相关OutOfMemoryError的异常栈信息，不过你别高兴太早，这种情况下导致的OOM打印异常信息是没有太大作用，因为这种OOM的导致一般都如下图情况（图示为了说明问题数据和场景有夸张，请忽略）：
从图片可以看见，这种OOM我们有时也遇到，第一反应是去分析OOM异常打印栈，可是后来发现打印栈打印的地方没有啥问题，没有可优化的余地了，于是就郁闷了。其实这时候你留心观察几个现象即可，如下：
留意你执行触发OOM操作前的界面是否有卡顿或者比较密集的GC打印；
使用命令查看下当前应用占用内存情况；
确认了以上这些现象你基本可以断定该OOM的log真的没用，真正导致问题的原因是内存泄露，所以我们应该按照上节介绍的方式去着手排查内存泄露问题，解决掉内存泄露后红色空间都能得到释放，再去显示一张0.8M的优化图片就不会再报OOM异常了。
不珍惜内存导致的OOM分析：
上面说了内存泄露导致的OOM异常，下面我们再来看一幅图（数据和场景描述有夸张，请忽略），如下：
可见，这种类型的OOM就很好定位原因了，一般都可以从OOM后的log中得出分析定位。
如下例子，我们在Activity中的ImageView放置一张未优化的特大的（30多M）高清图片，运行直接崩溃如下：
//抛出OOM异常
10-10 09:01:04.873 11703-11703/? E/art: Throwing OutOfMemoryError "Failed to allocate a 743620620 byte allocation with 4194208 free bytes and 239MB until OOM"
10-10 09:01:04.940 11703-11703/? E/art: Throwing OutOfMemoryError "Failed to allocate a 743620620 byte allocation with 4194208 free bytes and 239MB until OOM"
//堆栈打印
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: FATAL EXCEPTION: main
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: Process: com.example.application, PID: 11703
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.application/com.example.myapplication.MainActivity}: android.view.InflateException: Binary XML file line #21: Error inflating class <unknown>
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2610)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2684)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.app.ActivityThread.access$800(ActivityThread.java:177)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1542)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:111)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.os.Looper.loop(Looper.java:194)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:5743)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at java.lang.reflect.Method.invoke(Method.java:372)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:988)
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:783)
//出错地点，原因是21行的ImageView设置的src是一张未优化的31M的高清图片
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: Caused by: android.view.InflateException: Binary XML file line #21: Error inflating class <unknown>
10-10 09:01:04.958 11703-11703/? E/AndroidRuntime: at android.view.LayoutInflater.createView(LayoutInflater.java:633)
通过上面的log可以很方便的看出来问题原因所在地，那接下来的做法就是优化呗，降低图片的相关规格即可（譬如使用BitmapFactory的Option类操作等）。
PS：应用所属的内存是区分Java堆和native堆的！
Android应用规避内存溢出OOM建议
还是那句话，等待OOM发生是为时已晚的事，我们应该将其扼杀于萌芽之中，至于如何在开发中规避OOM，如下给出一些我们应用开发中的常用的策略建议：
时刻记得不要加载过大的Bitmap对象；譬如对于类似图片加载我们要通过BitmapFactory.Options设置图片的一些采样比率和复用等，不过过我们一般都用fresco或Glide开源库进行加载。
优化界面交互过程中频繁的内存使用；譬如在列表等操作中只加载可见区域的Bitmap、滑动时不加载、停止滑动后再开始加载。
有些地方避免使用强引用，替换为弱引用等操作。
避免各种内存泄露的存在导致OOM。
对批量加载等操作进行缓存设计，譬如列表图片显示，Adapter的convertView缓存等。
尽可能的复用资源；譬如系统本身有很多字符串、颜色、图片、动画、样式以及简单布局等资源可供我们直接使用，我们自己也要尽量复用style等资源达到节约内存。
对于有缓存等存在的应用尽量实现onLowMemory()和onTrimMemory()方法。
尽量使用线程池替代多线程操作，这样可以节约内存及CPU占用率。
尽量管理好自己的Service、Thread等后台的生命周期，不要浪费内存占用。
尽可能的不要使用依赖注入，中看不中用。
尽量在做一些大内存分配等可疑内存操作时进行try catch操作，避免不必要的应用闪退。
尽量的优化自己的代码，减少冗余，进行编译打包等优化对齐处理，避免类加载时浪费内存。
可以发现，上面只是列出了我们开发中常见的导致OOM异常的一些规避原则，还有很多相信还没有列出来，大家可以自行追加参考即可。
后记
无论是什么电子设备的开发，内存问题永远都是一个很深奥、无底洞的话题，上面的这些内存分析建议也单单只是Android应用开发中一些常见的场景而已，真正的达到合理的优化还是需要很多知识和功底的。
合理的应用架构设计、设计风格选择、开源Lib选择、代码逻辑规范等都会决定到应用的内存性能，我们必须时刻头脑清醒的意识到这些问题潜在的风险与优劣，因为内存优化必须要有一个度，不能一味的优化，亦不能置之不理。
网友评论