Android性能优化-内存篇

前言

在日常开发中，Android的性能优化是我们需要一直关注的点。那么本文也是老生常谈，说说Android的性能优化内存篇。我们在日常开发中该怎么去做内存优化的分析，以及一些内存优化的一些场景。

Android内存优化需要从以下几方面入手分析，利用Android Studio自带工具Profile初步分析。

内存抖动从Profiler可以明显的看出，内存趋势图是一个锯齿状的图，并且伴随着频繁的GC。可以看到Profile图上方一排的白色垃圾桶，这个就是不停的GC的节点。

那么频繁的GC会导致什么问题，我们都知道GC需要在一个安全点进行根节点枚举,这个是需要暂停进程的。频繁的GC会导致应用应用进程不停的被暂停,不停的被“冻帧”。导致屏幕刷新一帧大于16ms，造成掉帧的现象，给用户的感觉就是卡顿不流畅。

那么什么情况下？会导致频繁的GC，我们在日常开发中需要注意哪些点，这里我主要列举以下几个场景：

内存泄漏是指已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

上图是一个测试内存泄漏的场景，我在App一个页面来回进出，发现内存一直在上涨并没有跟着Activity的销毁内存而得到释放。并且我在Profile手动调用GC，内存还是保持占用状态。那么这种情况一定是发生了内存泄漏了。

内存泄漏一般从以下几个场景着手：

Handle内存泄漏 Handler通过发送消息Message与主线程进行交互，如果Handler发送的消息Message尚未被处理，该Message及发送它的Handler对象将被MessageQueue一直持有，这样就可能会导致Handler无法被回收。
单例内存泄漏由于单例的生命周期是和app的生命周期一致的，如果使用不当很容易引发内存泄漏。单例的引用如果是Activity，则会导致Activity无法被回收，从而导致了内存泄漏
非静态内部匿名类内存泄漏非静态内部匿名类会自动持有当前对象的实例，匿名内部类如果被异步线程使用，可能会引起内存泄漏。
注册/反注册内存泄漏例如我们日常开发中使用EventBus这类的框架，如果我们没有在onDestory()中进行反注册，就可能会引起内存泄漏。
资源对象没有关闭导致的内存泄漏在android中，资源性对象比如Cursor、File、Bitmap、视频等，系统都用了一些缓冲技术，在使用这些资源的时候，如果我们确保自己不再使用这些资源了，要及时关闭，否则可能引起内存泄漏。

内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件。

频繁的出现内存抖动或者大量内存泄漏很有可能就会导致内存溢出。

Android中内存优化的常用工具，主要有下面这几种。

Android Profile
这个是我们最常用的官方自带工具，可以很方便的定位出问题代码。具体使用教程这里就不做详情介绍，网上有很多类似的教程。
MAT
MAT是eclipse官方提供的一个内存检测工具，当我们使用Android Profile无法准确定位问题的时候，我们可以借助这个工具来进一步的定位问题代码。从Android Profile中导出堆转储.hprof格式的文件导入MAT工具中即可进行分析。
LeakCanary
LeakCanary是一个三方的分析内存泄漏的工具，它可以通过堆转储.hprof文件准确的定位出内存泄漏的代码，并且对于用户有一个友好的页面。可以快速的进行内存泄漏的分析和排查。